FreeEMS Issues - Tunix
View Issue Details
0000421TunixFreeEMS Pluginpublic2011-11-24 15:302013-02-24 14:36
a41c16ba1c7f2e3f220e0fc24d39aca363901195 and later
0000421: Add Missing Interrogation Data Calls
http:// do cs.fre eems.o rg/Vani llaSer ialPro tocolInte rface-0.0.3.pdf

EDIT: Broke the above link because it's out of date. See [^] for the most recent version.

Updated and at your service! :-)

No tags attached.

2011-11-24 18:35   
for payload 0x0100
Replaces a block of RAM memory with the provided data. Some blocks are only allowed to be changed as a whole and not partially, IE, size must match the size of the locationID provided and o set must be zero. General con guration blocks can be adjusted using arbitrary o set and size parameters provided that o set is less than size and size is greater than 0 and less than the locationID size. The locationID provided must have non-zero RAM elds.

There needs to be a flag or something set in the location ID details call (0xF8E0) that says this block MUST be updated in full and never partially, so the tuning software can handle this. Otherwise remove the "some locations must be updated in whole" restriction)
2011-11-24 18:37   
This is unchanged from the version from January that the current MTX source code is based upon. Assigning back.
2011-11-24 18:55   
Unchanged both in code/behaviour and in documentation, btw.

commit a41c16ba1c7f2e3f220e0fc24d39aca363901195
Author: Fred Cooke <>
Date: Tue Jan 11 13:55:10 2011 +1300

    Update the data service stuff, and make errors for resets explicit even though already mentioned in the acknowledgement section. Update both dates.
2011-11-24 21:28   
2011-11-24 21:48   
+2 - I want "reset counters call" button please !!!!
2011-11-25 16:14   
You're not understanding my feedback, go back and re-read it. Your docs explicitely state "some blocks must be written as a whole", however there is no call that returns information to mtx so that it knows to DO THAT, so you need to either add that, or remove the "must be written as a whole" to the location ID's that condition applies to.... the location ID details call doesn't return any param that states that this block must be written as a whole.

reset counters button, WHERE?
2011-11-25 16:53   
I read it perfectly well. That API call, AND its friends, AND their docs, have NOT changed, since JANUARY. Assigning this back to me on the basis that something unrelated to the THINGS THAT IT REFERS TO (Missing Interrogation Data Calls (+ counter reset)) has changed is NOT valid.

Trust in the fact that you can't break anything over the wire (you'll get an error!!! FreeEMS is robust!) and carry on doing whatever you're doing, because, funnily enough, it's working as is... (without errors...)

PS, you're wrong, but i've not time nor energy to explain why right now.

Re the reset counters button, let me take a look... Tools menu and/or Tools tab, because if I said "runtime status window, and runtime vars window, and runtime display tab" you'd just tell me that none of the three were possible. But really, wherever you think it should go. It clears half of the values in the runtime status and vars windows. Perfect for debugging comms and install issues such that it will directly help all of: you, freeems users, me, sean. That's at least 5 people who will benefit :-) Stop being a pain in the arse, and for NO reason.
2011-11-25 17:47   
Read to the end before responding....

Its the UI to your baby, WHERE DO YOU WANT IT??? State what you want AS you want it, and IF I can make it work there, I will, otherwise I'll try to use your second choices... Tools menu, or runtime tab would be easy, I don't recommend it on the runtime status or runtime vars windows as that becomes a special case, that doesn't apply to other firmware families. the runtime vars tab is a specific tab per family so it makes more sense there, likewise the tools menu is also firmware specific.

The api docs may not have changed since january but by my read and the lack of a pointer to the doc from you to explain what what I noted (some locations require full write, but not a partial subset write) as documented and how to deal with it, means that megatunix will not be able to handle things properly. If a location ID requires a full write, right now, mtx has no way to know that it does, thus mtx will get stuck in a loop right now, as if it tries a partial write to a full write page, and you return and error, megatunix doesn't know how to handle that and will just keep retrying over and over and over again. IF your location ID details call returned a flag stating that location id X requires full write, then mtx can at least handle writes within that location ID in the proper way.

Does that make sense??
2011-11-25 17:57   
"Tools menu, or runtime tab would be easy" Both please. I just want obvious access to it. If I care about something, such as the bump button not being called bump, I say so. <goes to check, add iterations is ok, but they're called "cycles" in the rest of that tab, so... "add cycles" is probably best> << I care. Where this goes, as long as I can click it and/or select it easily, great.

When I said that I didn't have time to explain, I meant it. However your description DOES make sense (PS, I always read to the end :-p) and I have other advice, but will open a new issue on that, or add to an old one. Here isn't the place to fix that behaviour or discuss it. Thanks for explaining in detail. One question though: Why the FUCK didn't you explain that the first time and save us all a shit load of time... Jesus...
2011-11-25 20:26   
(edited on: 2011-11-25 20:27)
NOTE: NEVER assume what is obvious to you is obvious to someone else. Being clear and concise is the best point.

Uhhm, your docs should have explained it, but they left it open, ambiguous and unanswered, and should have at least noted: "Certain location ID's need to be written in full and not partially, however the firmware doesn't yet expose this detail to the tuning software via the location ID details call in a way where the tuning software can use this information to act correctly. This documentation deficiency will be resolved at a future date, or this restriction within the firmware is planned on being resolved in the future and an issue tracker note will be sent to the affected parties". You failing to do this is what caused this issue regarding the API documentation in the first place. Take your lump and move on with life, all is well, though updating the docs would be a wise course, as it's only a couple of sentences and it would be of value to more than just me and would eliminate the ambiguity that others would undoubtedly face..

2011-11-26 00:31   
New issue created: [^]

Re the docs, you're wrong, and I still don't have time to explain why.

Just chill about the docs/semantics and deal with stuff that matters such as 0000251 and 0000423 and 0000410 :-)
2011-11-28 01:41   
Feature complete.
2011-11-28 01:41   
Completed bd0ef60..4434572
2011-12-02 10:50   
Hmmm, I was going to close this, but these details no longer seem to be displayed in the General tab, something to do with the new code perhaps?
2011-12-02 13:38   
fixed in 604b7129577fc055e5beaee0f9a31b2fb748e612
2011-12-02 14:05   
Tested in above hash as working! :-)
2013-02-24 14:36   
Broke link because google was showing people this document in their searches. Will update the docs site soon to show a more recent copy.