Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000385TunixFreeEMS Pluginpublic2011-11-11 23:392012-04-01 20:25
Assigned ToFred 
PlatformAllOSAllOS VersionAll
Product Version0.9.24-SNAPSHOT 
Target Version0.9.24Fixed in Version0.9.24 
Summary0000385: Interrogation Matches On Firmware Version
DescriptionFirstly, if you're reading this while away on holiday, stop immediately, it can wait till you get back :-p Go and relax! :-)

When you are back, though: Interrogation matches on the firmware version when it should match on interface version. I upgraded the firmware to use always unique version numbers and MTX now refuses to talk to it. There is a work around in that you can change the interrogation profile to match your firmware or change the makefile or globalConstants.c file to match MTX's idea of what the version should be. This is the wrong behaviour, though. Firmware version was always intended to be dynamic and variable and unique per build, now it's unique always. Interface version should be static except for when the interface changes and should be depended upon.

I want to change the interface format specification to a straight string, let me know if now is a good time to do that such that you can move to that system. Before I had int, int, int, string for a 3 part version, but that's pretty limiting. Much better of a little less memory efficient is to use a free form string with a constant word for the interface style/family and a string version number that can be regexed against for tuner purposes.

Currently interface version is 0, 0, 0, "IFreeEMS Vanilla" which I would like to change to "FreeEMS Vanilla 0.0.0" as the I is implicit in the field name... Let me know if you'd like this change made before you fix the above unrelated bug/issue.
TagsNo tags attached.
FirmwareVersionnot provided by submitter
Attached Files

- Relationships

-  Notes
dandruczyk (viewer)
2011-11-13 01:21
edited on: 2011-11-13 01:22

>> Let me know if you'd like this change made before you fix the above unrelated bug/issue.

Yes, You must commit this to firmware as I have nothing to test against in order to do the change. please do this ASAP.

dandruczyk (viewer)
2011-11-13 01:44

Interim code in place. you MUST tell me when hte new firmware code is in place such that it returns a true ASCII string to the interface version call so I can fix the remaining code.
User avatar (0000589)
Fred (administrator)
2011-11-16 14:19

Tested as works. I'll leave this open as a reminder until I create a new issue for the protocol changes.
User avatar (0001358)
Fred (administrator)
2012-04-01 17:00

Correct fields incorrectly adjusted in last change.
dandruczyk (viewer)
2012-04-01 20:10

I don't understand your last comment. It is ambiguous, please be SPECIFIC.
User avatar (0001367)
Fred (administrator)
2012-04-01 20:15

You set the fixed in field to "future" which is a hypothetical version and not possible to be fixed in, except by extension of being fixed in any real version before that time. You changed the priority from high to none after it's already done, which just screws up history. Finally, you left it open when it was resolved ages ago. It's good that you bumped it, as I was able to clean it up. Now I have to clean it up again, as you changed the status to feedback, when it should be resolved. This issue is dealt with, but remains resolved but not closed as a place holder for future yet-to-be created issues. IE, there was nothing to understand, just leave it alone and ignore it.
dandruczyk (viewer)
2012-04-01 20:18

This issue IMHO should be CLOSED and a new issue reside in the Firmware section, when you have your end finalized then create a NEW issue for MegaTunxi describing the exact needs. I don't like having open issues that are unresolable/unclosable because they are dependent on other people's work.
User avatar (0001369)
Fred (administrator)
2012-04-01 20:25

I know that you have anxiety issues, Dave, but that's beside the point. Take consolation in the roadmap view which shows "resolved" issues as crossed out. Have a look in the firmware, there are some old resolved issues that are resolved, but left open as reminders to finish the job properly. Take one of these: [^]

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker