Serial protocol pre-design discussion - give us your input!

[Fred]

OK, just string, any length, no cap (allow common sense to prevail, same with forum moderation), still needs a set of rules for displaying though, whatever they are, but something consistent across tuning tools preferably.

Just B) and not A) (doing A) is a waste of time if the laptop isn't there IMO and polling interval will reveal that it's come up fairly quickly)

Wouldn't the code look more like :

list supportedVersions;
...
tool.startup(version); // throws unsupported version exception

or

if(supportedVersions.isSupported(version)){
run(version);
}

etc rather than hard coded versions in the logic flow?

[FlappySocks]

Regarding A) I was thinking about the scenario, where you might have more than one ECU device on the test bench, and your testing them one by one - unplugging, and reconnecting the serial lead. The software needs to know if a version has changed, without having to restart it.

My thoughts with the version checking code I presented, is that you probably don't need to know about every individual version thats been released. Only that you can support versions between a range. A small bug fix release for example, is not going to change anything in the PC software, so there is no need for users to grab another update.

[jbelanger]

Just keep it simple. A string of any length, but put a recommended cap on it of say 40 characters. From the firmware writers perspective, all thay have to do is have a constant string variable in the main part of their code, that gets sent A) when powered up. B) when requested.

Sounds good. On the other hand, if it simplifies coding, filling the rest of the string with spaces is no big issue either especially since there would be a hard limit on the number of characters.

In your "Megatune" tune app, you have something like this.

Code: Select all

if (stringVersionIn.StartsWith("FreeEMS")
{
   if (stringVersionIn>"FreeEMS 1.2.3")
   {
     showMesaage("Warning, firmware more recent than this application... update me");
   }
...

That part I don't see how you would do with a free format string. If you have a 255.255.255 3-byte field then it's easy to do but otherwise it would just default to the unknown firmware message.

I think what is needed is an interface version number (which could be a free format string if we don't care about being able to present the message above) and a label (which could include the code version number). Taking Fred's example of the vanilla code vs Joe Blogs code, since the interface changed, then the interface version number would have to change so the tuning software knows what to do and you would also note this in the label (and the code version would have to be changed also since the interface change means code change but version numbering is another discussion). However, if Joe Blogs were to take the FreeEMS vanilla version and use the XGATE to do the injection but keep the same interface then the interface version number could be kept the same but the label would be updated.

Jean

[Fred]

Stu, IMO A) falls under the same category as "flood clear mode" etc. I don't think anything that is only for setup and testing and can be done in an alternative way (eg reset button in tuning software in this case) should be included in the design.

Jean, you raise a good point for having it separate. Now, given that you have to have both to make an intelligent decision, what is the difference between storing the 3 chars separately or as the first 3 of the string? The packet will come through as a series of consecutive bytes either way and be interpreted in a standard way in the exterior tool.

If you want to have the interface number vary and be the sole identifier for an interface then we need the fourth char 0 = FreeEMS Vanilla, 1 = Joe Blogs EMS, 2 = etc...

That actually makes the most sense so far really, doesn't it? 4 chars to identify the firmware to the world (3 version fields and a type field) and a separate short string for naming if we really want, OR, no separate short string, and that simply looked up from the file/code that details how to interact with and display the tuning info.

So then, quick poll :

1. 4 chars as described AND field for name
2. 4 chars as described ONLY
3. Arbitrary string ONLY.

I can't decide between 1 and 2 right now, but I can't see a compelling reason to have a name field if we have a reference table of firmware types on this site and in each distro of the code etc. I can see that it might be nice to just get the name rather than have to look it up, but this breaks our "min code/data inside the ems" rule...

Thoughts?

[FlappySocks]

If you want to have the interface number vary and be the sole identifier for an interface then we need the fourth char 0 = FreeEMS Vanilla, 1 = Joe Blogs EMS, 2 = etc...

I dont think it's the job of the protocol specification to decide which firmware gets which number.
If Joe Blogs decides he has a new idea, and want to test it out, does he need to come to DIYEFI.org first and ask for a number to be allocated him? No he will just make his own number up, and then your going to get into the situation where if any of those versions get into the wild, we will be in a right mess.

At least if all or part of the version is a string, then it keeps it more open.

Plus, everytime a new number is issued, the "Megatune" (for want of a better word) software guys, are going to have to release a new version, so that everyone is up to speed, even if no other protocol changes have been made.


Lastly, If I were to offer a "Fix-your-FreeEMU" service, I will want to see at a glance what firmware is on the box the moment I plug it in. Otherwise, I might be fixing problems that dont exist, because I hadn't realised it was some special firmware that doesn't behave the way I expected.

[Fred]

I dont think it's the job of the protocol specification to decide which firmware gets which number.

I never suggested that it did, we are trying to nail down a mechanism for identifying a firmware revision in a unique way with numbering that can not overlap between variants.

Plus, everytime a new number is issued, the "Megatune" (for want of a better word) software guys, are going to have to release a new version, so that everyone is up to speed, even if no other protocol changes have been made.

Now, what has come up is this :

Interface version and firmware version are not necessarily related.

Perhaps then it would be best to separate them out into what they really are? (firmware version/name AND interface version/name) Of course, once you do that you get back to the totally different interface needing a version numbering scheme that starts somewhere other than 0.0.0 and other than where ever vanilla leaves off (otherwise I will overlap his interface numbering sooner or later). Of course, I SHOULD be sticking to proper versioning where interface definitely changes with any middle number change, and definitely doesn't with any lower number change. I'll stick to that once the first interface is up and running. In the mean time there is no interface and thus I'll keep bumping the lowest one until there is a change in the next one up. I suspect though that early on I should just keep bumping the lower number until something significant happens or I run out of lower number (hit 255 or 65536 or something). Otherwise we will chew through version numbering too fast.

If Joe Blogs decides he has a new idea, and want to test it out, does he need to come to DIYEFI.org first and ask for a number to be allocated him? No he will just make his own number up, and then your going to get into the situation where if any of those versions get into the wild, we will be in a right mess.

At least if all or part of the version is a string, then it keeps it more open.

That is a good point.

Lastly, If I were to offer a "Fix-your-FreeEMU" service, I will want to see at a glance what firmware is on the box the moment I plug it in. Otherwise, I might be fixing problems that dont exist, because I hadn't realised it was some special firmware that doesn't behave the way I expected.

If I understand it correctly, what you have right now with MegaTune is a situation whereby the firmware is silent until something is requested of it. If you haven't received anything from the cable for a while, you poll it once per second or half a second or something, once you get a "i'm here and my name/version numbers are xxx yyy" back you can either keep polling it for version if you have nothing better to do or poll the logging data instead (much more frequently) and only poll version again when a break in transmission occurs. Even if it isn't done in an automatic way like that you can't tell me that hitting an "identify" button is a big deal can you? with a straight face?

Either way, there are dozens of ways instant recognition can be done outside the EMS (where it belongs IMO).

Admin.

[thebigmacd]

I was thinking about a mechanism whereby a random "serial" number is burnt along with the firmware, so that when you poll for version number you also get back the serial number of the device. This way the tuning software can identify which exact ECU it is connected to and associate it with the proper saved settings.

There doesn't have to be really restrictive control on the serial number, it could just be randomized by the tuning/update software just before new firmware is burnt. This way if you do a firmware upgrade through the tuning package, it could assign the old serial number to the new firmware so that it knows it is still the same ECU, or burn an entirely new serial number if you want. The serial numbers would not necessarily have to be unique globally, just unique on a tuner-by-tuner basis.

Just a thought. It would help with software synchronization on the bench. The tuning package could cache the firmware and interface settings until an upgrade is done.

[FlappySocks]

Interface version and firmware version are not necessarily related.

Agreed. I think we talked about protocol version at one point.

you can't tell me that hitting an "identify" button is a big deal can you? with a straight face?
Admin.

Lol, you haven't seen my workbench. The mouse gets buried.
I was thinking that it's just one less thing to remember to do, thats all. It wont make any difference for the end user, but for us overworked developers trying to thrash out the bugs....

[FlappySocks]

I was thinking about a mechanism whereby a random "serial" number is burnt along with the firmware

I like the sound of that. This solves another problem i was thinking of the other day, but alas I cant remember it now.

[Fred]

The "user note" field could be used for that for any particular tuner/user. However, reality is that 9/10 will have only one on their one and only project car. Serial numbers as such are a hardware thing, and we aren't really concerned with that. An identical firmware version will behave the same in the eyes of the tuning software and interface layer regardless of which hardware it is running on.

What we need to establish on hook up is simply how to communicate with the device. Additionally we need to know exactly which firmware we are talking to incase it has a bug with respect to a particular feature that it *should* support. As a way of making that number able to start at 0.0.0 for a branch like msextra we were discussing using a string paired with the versioning scheme. The more I think about this the more it seems to make sense to use a separate interface version number/name pair such that the tuning software can support minimal stuff in the clearest way with maximal variation in firmware. Now I'm starting to lean back to the original line of thought where we have a version number and name or just name and look up which interface that uses in a table/list in the tuning software. However that has the same negative aspect where people have to "apply" for a number for their interface spec. So, to do it right we need 4 fields :

1. Firmware numeric version
2. Firmware string name
3. Interface numeric version
4. Interface string name

Thoughts?

I like the sound of that. This solves another problem i was thinking of the other day, but alas I cant remember it now. :?

As I said above (too slowly lol) the free text field could be used for that purpose. Ideally as a talented tuner using reliable consistent firmware you would try to keep all your projects up to date with the latest at which point those numbers are worthless for that. What you need is a freeform field where you can enter anything memorable and sensical to the particular application.