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

[Fred]

An example of one of those reasons why not :

http://www.msextra.com/viewtopic.php?p=182961#182961

[sry_not4sale]

From what I have read, the tuning software updates the tune via minimal single-value updates?

Is this correct?

Does the firmware need to verify it has a complete tune uploaded?


I am taking it we will also use the serial protocol for sending logging messages?

[Fred]

Most stuff will be done like that with a single "value" of a variable size received and stored, however, if we go with a non-table solution which we hope to, it will be pre-calculated and uploaded as one big chunk.

I think each received message should be verified fairly thoroughly such that no mistakes occur writing to mem or flash. When you send a value to it, it will be updated in memory only. That should be well checked. Then when you are happy with that value you will tell it to burn a particular mem item down to flash. That command should also be checked thoroughly.

As Jean (i think) suggested, we should send back a failed/success message for each write/burn command issued such that the user can know what happened.

The firmware will come with a base "tune" such that it can function. Each adjustment from there should be verified in some fashion to ensure it was a reasonable thing to do. If not, a particular failure code gets sent back.

Initially for logging we will probably use a polled method where by the tuning software sends a "L" (for logging) or something more appropriate and gets a full log back. What we should have is some binary mask as a setting of what stuff to send back and what not to send back. For the purposes of logging without tuning attached, I would like to utilise serial port 1 for full time logging if it is enabled by the tuning software. If it is, it will just continuously write data out of that port as much as it can. If not, it wont. Serial port 0 should be used for tuning and firmware updates and normal visual while you tune style logging. I think this is the cleanest approach and allows simultaneous logging to an external device and tuning at the same time.

If the logging includes any checksums on stored tables etc you could see where you changed it on the fly and what affect that had without guessing.

These are all just thoughts. I'm hoping someone with more experience than myself will step up and confirm/deny/add to this stuff soon :-)

Admin.

[sry_not4sale]

Sounds good to me!

Most stuff will be done like that with a single "value" of a variable size received and stored, however, if we go with a non-table solution which we hope to, it will be pre-calculated and uploaded as one big chunk.

Are we planning on reading/writing to a mass storage device?

[Fred]

If you mean USB disk or such, yes, but through the second serial block. That is a "much later" task :-) For now, just basic serial over the primary port is the way to go. If you mean the 512k flash block inside, yes, thats another highly important piece of code that needs to be written.

Admin.

[sry_not4sale]

Wikid, thanks for putting up with my dumb questions

[dandruczyk]

I'm all for the simplest that gets hte job done EFFECTIVELY manner..

forgive me for my "MS-ness". Right now the MS protocol is pretty simple, even if disjoint and a little hokey in parts. It works pretty well, but there are faults.

Things that I want to see.
Hardware flow control. use a cpu that has the extra two pins do to proper flow control. This solves about 90% of the serial I/O problems, esp when using baud rates over 9600/19200. If using a USB interface (most of which are just usb to rs232 anyways), have it have proper flow control in it.

keep the KISS principle in mind (Keep it Simple Stupid!!)

I think a simple ack or CRC ack would be sufficient.
i.e. tuning software assembles a block and performs a CRC on that block and holds that CRC. Sends the data. the ecu receives, CRC checks the stream and compares it with the crc at the end and report either a a "good" (CRC passed) or "bad" (CRC mismatch) response.

The same would work for whe nthe ecu is told to send back a block or data (rtvars, general memory, etc) ecu would compute a checksum and tack it onto the end of the block, tuning SW would do the same verification of the block.

For non data commands, I don't think a CRC is necessary ,i.e. commands to request data, or to trigger certain actions, like a reboot, or re-init.

I think if u try to go for every possible potential fault, no matter how statistically improbable, you'll make something that no tuning software author (like me) would want to implement. so KISS!!

[Fred]

Hi and welcome along! :-)

Hardware flow control. use a cpu that has the extra two pins do to proper flow control. This solves about 90% of the serial I/O problems, esp when using baud rates over 9600/19200. If using a USB interface (most of which are just usb to rs232 anyways), have it have proper flow control in it.

I have to be honest here, I have very little idea what I a doing with this sort of thing. However, I have never done anything that I didn't catch onto fairly quickly, I'll dig into some googling and reading when I get back and try to get a good feel for it all. I'm guessing that you check one pin for being high, and if it's low you set the other pin high, then you recheck the other one to ensure it is still low, and if so, get on with it, and if not, wait a random time and retry much like ethernet? If so, any random two pins will work for this, correct?

I think a simple ack or CRC ack would be sufficient.
i.e. tuning software assembles a block and performs a CRC on that block and holds that CRC. Sends the data. the ecu receives, CRC checks the stream and compares it with the crc at the end and report either a a "good" (CRC passed) or "bad" (CRC mismatch) response.

The same would work for when the ecu is told to send back a block or data (rtvars, general memory, etc) ecu would compute a checksum and tack it onto the end of the block, tuning SW would do the same verification of the block.

This makes sense, I hadn't considered how to actually do it, but if you just add each byte to the sum of the previous ones as you send, and tag on the end as you say, that makes for a very easy and I presume fairly effective implementation too.

For non data commands, I don't think a CRC is necessary ,i.e. commands to request data, or to trigger certain actions, like a reboot, or re-init.

I agree that it is not required, but considering that they are non time critical anyway, with the exception of data logging/real time which you lumped into being checked already anyway, wouldn't it make sense to have a uniform protocol that always does the check rather than doing it for some and not others? That seems simpler to me. Excuse me if I have missed something important there, and if so, please point it out.

I think if u try to go for every possible potential fault, no matter how statistically improbable, you'll make something that no tuning software author (like me) would want to implement. so KISS!!

An excellent point. I wasn't necessarily advocating a complex protocol, just one that is fairly robust. For all sorts of reasons, a lot of people have serial issues with MS (mostly rs232 headaches I would say), and if that can be eliminated by some thoughtful checksumming of appropriate parts, I'm all for it!

Take your time responding if at all as I won't see it for a week or so unfortunately.

Others with skills in this area, feel free to break me in and/or discuss your thoughts here too!

Thanks again,

Admin.

[ababkin]

IMO, data integrity is paramount and should be the first priority. KISS is good and what should be used for first prototypes, but if it conflicts with the priority of data integrity in any way, i say the extra complexity should be endured.

If the protocol becomes too complex for tuning software creator's comfort, it can be easily fixed by outsourcing the layer closest to the protocol to the person who wrote the protocol. (i.e write a lib for this with a convenient interface for the tuning soft devs)

We are blessed with having a very fast on-die co-processor, and hopefully it won't be too much trouble for us to use it. The CRC number crunching IMO can be offloaded onto the XGATE (perfect task for RISC IMO).

I think we should ultimately keep the Comm ISRs and all the other important ISRs (like tach) on separate cores, this way there is no way of them ever colliding, which would mean the convenience of "burning" while driving/idling with no hiccups for example. Of course, there are also interrupt priorities we can play with, which are not available (i think) on the 9s12c64

Do we have a thread about the memory layout within the chip? Could be a good idea if we don't.

[Serj]

CRC is more than enough for non fixed data. i.e. all functions going to ecu should be a couple/3/4 bytes ie fixed data packet predefined. all daat going from ecu (tables,realtime,etc) should include CRC. no sense to make anything else. the main idea do not to make it slow with all check for integrity etc.

Serj