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

[jbelanger]

What we need is an interface identifier and a firmware identifier. The interface identifier is the only thing anything communicating with the ECU needs to know because that defines everything it needs to know about the interface. The rest is just a black box. I would go as far as saying that the casual user doesn't even need to know more (that's oversimplifying it but not that much).

The only use (and a very important one) for the firmware identifier is for the developers/debuggers/testers. I don't think that any tuning software or other communicating devices should rely on this or even know the existence of it other than for reporting or logging it.

As for the format and if there is a need to split each identifier into two distinct fields, I'm not sure. From what I said above, it certainly seems like it would be useful to have at least a numeric version of the interface (for better version control) and a string for the firmware version (for more consistent display purposes).

And I think there should be some mechanism to allocate official version numbers for both firmware and interface otherwise merging back branches would become a nightmare.

To come back to what Fred was saying before, the interface number could just be a subset of the version number. So if we have firmware a.b.c then the interface will always be a.b. I'm still not sure how to handle different branches though. Adding one or more bytes would be fine for the version number but how it would work for the interface number I'm not sure yet.

Jean

[Fred]

Well, if we go with the interface = high part of version thing, don't expect it to be usable until 1.0.0 is out. I just can't promise to behave on that while still knocking it up from a blank sheet of paper.

We probably aren't going to ever pull back ALL changes from a given branch are we though. It will be "jean made a siamese variant and added this neat feature at the same time, lets pinch that and put it into the main line" sort of thing.

I think the version needs to be there for display at least such that a user knows what they are running obviously. I think the PC software should have access to the version too such that something that SHOULD implement interface 1.2.35 but doesn't can be black listed despite having the same exact interface number which "should" work...

Also, I think because its FOSS and likely to be forked for fun by randoms, we need more than just a version for these things. Stu has a solid point about others versions being supported.

For example

I develop MAIN up to 2.4.5 and Smithy comes along and forks it to EXTRA (LOL...) and calls his next one 2.4.6 then either I need to step past that to 2.4.7 which is ugly and only works IF I know about all non core versions, OR, a version needs to be valid ONLY for a particular string that goes with it.

As I see it we pretty much have to have 255.255.255 + "string of any length" to identify each of the firmware AND another pair for the interface. Without this forks will be a pain to support for a tuning authors at a (much) later date. Stu is showing some good foresight with this as I see it. I hadn't considered the logistics of forking and branching etc in the wild world. When it's closed source and 5 or 10 people can branch/fork/increment a piece of code and you are forced to use the same code and fix/improve it and everyone uses the same version set, then one version number is enough. When its a veritable free for all.... I think we need more.

Am I making sense?

Admin.

[jbelanger]

Makes sense.

Also, I was thinking that if we use a single string which starts with 255.255.255 followed by whatever, it might be interesting, when branching out, to append .1 to the version number and then the identifying string. The 1 gets incremented as needed and you always know where it branched out from. If someone branches out from the branch, add another .1.

This would not be enforceable but if most follow the recommendation it might make thing easier to manage.

Jean

[Fred]

That's a clever idea, however it would mean that they would be limited to 255 revisions of their branch max and restricted from having a proper versioning scheme in the case of large wholesale changes. Do we even want/need to know where it branched from? if we are trying to merge back in, the diff tool should take care of most of it anyway, and we can always just ask the author.

EDIT : In fact, (Semi)automated changes to C source seems like the worst idea ever. You don't see B&G taking any of msextra changes back in do you. I wonder how K&J are going merging ms2e and ms2 code for ms3 now? It seems to me that the point is to try to get it fairly right first off. By intelligent naming of fields they can serve different purposes on different setups etc. Do we ever want configurable stuff running out our ears with a million options at run time, or do we want the most narrow code possible for our specific case. eg you probably want the firmware you load for siamese to always only do siamese and not have to set up the basics each time you load it. You could branch from "1.1.1 FreeEMS Vanilla" and start with "0.0.1 FreeEMS Siamese 36-1" which would almost certainly need a different layer 2 interface description to handle the changed parameters etc needed for that. Even if it was similar at first.

Can we define some basic values at the lower end of layer 2 or a separate "minimum capability" set that you are required to implement such that any tool can always get those values regardless of variant?

I wonder what Stu has to say next :-)

[FlappySocks]

I wonder what Stu has to say next

HA HA Just use a string and have done with it. Let the coders decide how they want to version it. Simply recommend in the protocol spec, that it should be sortable alphanumerically, starting with the name as a constant.

FreeEMS Vanilla 1.0.2a
FreeEMS Vanilla 1.0.2a beta
FreeEMS Vanilla 1.0.2a 2008-05-22
FreeEMS Vanilla 1.0.2a Widget test
FreeEMS Vanilla 1.0.2a JoeBloggs special edition v1

[thebigmacd]

Jumping away from version numbering for a second, this is how GM did it in the 90s:

http://thebigmacd.gotdns.org/jetta/aldl.doc

[jbelanger]

I'm ok with an alpha-numeric string. But then there should be 2: one for the interface and one for the code version. They can be the same except that the code version changes with every code change (duh!) but the interface is updated only when the interface changes (re-duh!). This prevents having to update the tuning software (or the ini file or whatever) for every code change. This is how it's done on MS and it works fine for me.

Jean

[Fred]

OK, how about I make a decision, and people complain if there is a problem with it?

255.255.255 3 digit numeric field for interface variant COMBINED with matching interface type identifier of variable length.

In tuning/display tools you carry a range of supported tested versions for each interface type you support. Initially this will just be something like "FreeEMS Vanilla" and 0 0 1.

Additionally we can carry a code version/name field of variable length to uniquely and readably identify which code is being run.

3 digits + 2 arbitrary length strings for interface type and code uniqueness.

Additionally a fixed length user string field which isn't really part of this discussion will be provided for "tuners" and multiple box owners to ID their boxs electronically. This falls somewhere in layer 2.

Done deal?

Admin.

[ababkin]

my rule of thumb may come to the rescue : "if in doubt, make things flexible"

[Fred]

Sure, but we need a starting point, is that a good one?

This is what all other flexible things will hinge around and indeed is the mechanism to allow flexibility.

We need a workable way of IDing code/interfaces that is adaptable to new stuff into the future and easily handled on the PC/tool side.