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

[Fred]

I do, but which piece of code runs and the timing of it should not affect how the data is sent etc. We need a simple robust solution for moving it back and forward with minimal features that we need. I agree that we should be able to change it later if need arises, BUT, I'd like to get a first implementation out earlyish. Thanks for updating the wiki. I could have made a new page for that if you wanted. I may still.

I'll have a think over the weekend while not being scared to death by insane driving (yeah right) and get back to you soon.

Admin.

[Fred]

http://freeems.wiki.sourceforge.net/Fre ... munication

I've moved your content here and reverted the other one. That way we can see both potentially develop.

I think the numbering of layers is good as it allows for more than 2 "lower and upper" don't cut it for me. Either named or numbered uniquely.

Anyway, lets knock this page into shape and see WHY we need the other 2! :-)

Admin.

[sry_not4sale]

Wiki!!!! +1

[Fred]

Lets see what you guys can do with it while I'm away! You have 4 days, your time starts NOW :-)

[FlappySocks]

I'd spend all day working on this project if I could, but I have too many other projects to do - not enough time I'd like to to a megatune/megtuneix

Have a nice time Fred.

[ababkin]

ok, so i decided to do some research to avoid reinventing a bicycle...

and here is what i found:

DDCMP reliable stack (specified in 70's). Looks good but can someone read the whole thing over and condense it for everyone?
http://telecom.tbi.net/ddcmp.txt

S.N.A.P. protocol, which seems to be open source, with some sample embedded implementations:
http://www.hth.com/snap/

also here are some well explained pointers on how to optimize one's comm stack design
http://www.allbusiness.com/technology/c ... 040-1.html


Alex

[GartnerProspect]

Good call. Serial comms have been in place for decades. I'm not sure there is much room for massive improvement at the protocol level for the datarates we're looking to use.

[FlappySocks]

As far as datalogging goes, I would prefer that all messages were recorded. That way if you have a log and you were tuning while taking it you can see where your changes went in and which behaviour matches with which tune. This could be done in raw form, or translated into a special line in the log indicated by a flag field being on or off that means the rest of the values signify something else.

Agree

Maybe we dont have Ping, and just have version number requests.

This is a good idea, "are you there?, (and if so, what are you?)". The firmware number could be checked against known versions in a table from config/memory and if it's not known, just not work. I'm ok with 24 bits for version numbering on the code itself. do we need a 4th byte for anything else or not? So can we flesh this command out now? give it some structure etc...

24 bits sounds ok. I suggest we add a String as part of the version too, which will describe the codebase in use. If someone decides to develop an alternative firmware, they can give it a different name, and use their own version numbering.

With regards ack vs response and encapsulation I understand encapsulation, I'm just not sure what you mean. It sounds like you send a packet and the exception thing occurs if it doesn't get to the ECU AND/OR? get processed by the ECU, perhaps it needs two stages of response :

Not everybody working on the firmware will be interested in the Comms side of it. It's one of the reasons why we need to create a separate "Comms class" & Protocol that takes care of it. These discussions are the first step towards it.

So, if your the programmer responsible for say the Air Intake Sensor, your going to want to tell the world about what the temperature is doing. So, you call up the "Comms class", and instruct it to send your payload (the temperature). One of the options, will be to specify whether you care if it gets received or not. If the temperature hasn't changed in a while, you may want to send it anyway, but not get too worried if it's lost. If however, the temperture changes, you will want to insist the message is received.

I think there are three ways for the "comms class" to make sure the message gets received:

1) Halt all further comms, until it receives an acknowledgment back. Resend if necessary.

2) Keep an index of messages sent, and when they were sent. If an acknowledgment is received, remove from list. If not received within a time limit, notify the process that sent it.

3) Store and Forward. All messages requiring an acknowledgment, get stored in a stack, within the Comms Class. If an acknowledgment is received, remove from stack. If not received in time limit, resend. If still not acknowledged after further attempts, log the error, remove from the stack, and continue as as normal.

OK, No1 is easy to do, but can hold up vital data. No2 requires "callbacks" which will add a lot of complexity, and might cause the Air Intake Programmer to have a fit, and run for cover. No3 is easy to do, completely self contained in the "comms class" but is (a little bit) costly in CPU time/memory space.

What about flow control. Can this be done correctly in software? Or does it have to use up two more gpio pins? What about the physical side of that, do most/all USB/rs232 adapters handle hardware flow control if we go that way? It seems to me that to KISS in the ECU we need to handle requests serially.

I haven't investigated this hardware platform in detail, but I never do software flow control if it's available in hardware. Just not worth he hassle IMO.

[FlappySocks]

ok, so i decided to do some research to avoid reinventing a bicycle...

Hi Alex. The DDCMP and SNAP protocols you mentioned are not really serial protocols. They are network protocols, where several devices can share the same communications lines. DDCMP especially, looks like an alternative to IP as it can be routed, which is way more complicated than anything we are talking about here.

There is nothing very revolutionary in the protocol I have proposed. In fact, it's all borrowed from other protocols i have used in the past. For this type of project, it's more common to make a new protocol than use a generic one. This is because protocol design is important for the task at hand, to maximize the resources. Otherwise, I would just suggest we use XML.

The last link you posted looks like A good read. Also the SNAP protocol may have some interesting ideas on CRCs. thanks.

Stuart.

[ababkin]

Hi Alex. The DDCMP and SNAP protocols you mentioned are not really serial protocols. ...

I've looked over the docs and i thought both of them said that they aren't constrained to network type of topology and will work happily in point-to-point
No, we absolutely don't have to implement the whole protocol described, but only parts that we'll require. I just figure it'd be smart to leverage the work/research/testing that's already been done by professionals, is free and does work.

Alex