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

[Fred]

As I see it, the tuning tool (initial one) and firmware will develop together and the number of fields would be fixed for a particular version. I imagine a byte array of some length would be used for the mask. It would need to be defined in code on the firmware side in a clear and easy to read/code/understand way. That's kind of similar to a linked list, and I'm not sure how a variable long thing with undefined size will fit into our memory management scheme. I'm open to suggestions though. Did I mention I'm also a total noob at C ? :-) I seem to be doing OK so far though.

Admin.

[Fred]

Perhaps you could start a tuning software design/feature/implementation overview discussion thread? I'm quite keen for our tuning tool to be "in-code" like MTX is. The ini files and ability for random users to fiddle them gives me the s$%&s to put it mildly. Thus a version of FreeEMSTune or whatever it ends up being called if we go that way would be it's own version say 2.6.5 and a hyphenated code variant that it is attached to say 0.0.11 and some revision number, eg 24 ending up like this :

2.6.5-0.0.11-24

That way the base and stuff would be the same between different firmware revisions, and the attempt at getting it right for the firmware is encapsulated in that revision field.

Of course, it makes sense for some things to be in config, but not everything, it's just too big and hairy once fully featured and incredibly difficult to understand.

Start that thread and I'll move this post to it :-)

[FlappySocks]

I really do believe that getting the protocol right, and allowing it to be extendable, even at this early stage is very important. If its not right now, it will fustrate developers & ultermatly users later on.

If I were developing an add-on LCD screen for example, I would expect it to work in all future versions. If the protocol is done correctly, any future extensions that the LCD screen doesn't recognise, will be ignored, without breaking anything.

IMO the underlying protocol should really be treated like a separate project, with a set of rules, and specifications.

[Fred]

Sure, I 100% agree about that. I think. If you want to throw up a draft spec this is the thread for it. Did you read right through and see my ideas about a lookup table of data types etc compared to index number and location such that the addresses are encapsulated? After I get ignition working I would like to move forward with something else, and serial seems the next logical thing. Neither Aaron or Cam have posted any progress in that regard, so I can only assume that they haven't done anything. That would be fair enough though, as neither have I really. After serial comes flash, and after flash comes math. Hardest first, easiest last IMO. Lets get stuck in and get it working :-)

Admin.

[FlappySocks]

Sure, I'll have a go at proposing a protocol specification. Dunno what others think, but maybe diyefi.org could do with a wiki, to organise the documentation.

[Fred]

It's been suggested, but there isn't much to document just yet. Those who are willing to put the time in to read the threads that are around (any that matter are being posted to or sticky) will know where everything is already.

Once things start to get a move on, a wiki is a fine idea, esp if I can integrate the users from the board on it to keep track of who did what etc.

At the moment, any docs I have created (and serial stuff would be included too once it exists) are included in the ./docs/ directory of the release so that everything is together.

Perhaps you can do it in an OpenOffice document (text or spread sheet) and email it to me to host, or host yourself while we work on it. Once it takes a bit of shape, I can include it in the release.

If you grab a release and look in the docs, most stuff you need is there as far as I can tell.

Forums = discussion / development
Wiki = documentation

Alex is a fan, I'm sure he'll chime in here :-)

Admin.

[FlappySocks]

Update: I have made a start on two documents. One is the basic serial protocol, which I think if accepted, could be cast in stone fairly quickly. It's job is to get a payload of data, from A to B reliably, efficiently, and indicate what type of data it is. The second document, will be some ideas about how the payload data is constructed. This will be more specific to it's application, and will no doubt be forever changing until the hardware/firmware becomes mature (and beyond).

I will make them available in a few days once I have tided them up a bit.

Stuart.

PS.
Forums = discussion / brainstorming
Wiki = development / documentation

[GartnerProspect]

Pardon me for being a moron.

When I'm thinking Serial protocol I think of two things.

One: I want data integrity for all writes to the hardware.
Two: I want an easy way to get data out of the hardware for add-on modules.



Perhaps there will be a couple outputs dedicated to just a steaming output of engine variables rather than using the general purpose serial interface? For me, a total noob, I'd love an easy way on the software end to pull specific data out of the hardware for add-on modules without having to muddle with a full-blown two-way protocol. For example a digital gauge thingy. I don't need iron clad error protection, two way communication even. While my experience with protocol is extremely limited it seems that a one-way-bus style output might be easy to implement on both ends while not hogging the main serial interface...

[thebigmacd]

Basically what should be ended up with is basically a standard akin to OBDII, where instead of fault codes, the codes identify standard information blocks to be read or written. You need a standardized set of "codes" that identify the data required.

[Fred]

Thanks Stuart!

Gartner, 1,2,3 : agree,agree,see pinout spec and firmware feature wishlist which show the second serial out assigned to continuous serial output. CAN could be used instead, or something else, but I also would like a permanently streaming set of data which can be read by anything in parallel with the primary tuning interface. Having said that, it may be most practical to have them both on one comm line and T-ed.

Keith, That sounds like what I was thinking about. Do you have a good noobs guide/overview to it? I think I have the full blown CAN spec somewhere already, but it might be good to have a read of something more superficial and have it linked here.

Admin.