I have a couple of comments about the previous posts.

First, I tend to leave the development work on the end that has the best development tools, or is easiest to debug. Although I don't have any of the in-depth ECU knowledge that the rest of you guys have, I would opt for keeping the ECU routines simple, and using a low level serial protocol... exactly what chrisw had recommended, where you add an additional byte to the header to give the data size.

It would also be nice to add a CRC, or at the very least, a checksum to the packet so that we know the data is valid before assigning values in RAM.

How limited are you in the protocol? Obviously, the larger the packets, the slower the updates, but maybe this isn't a big deal. Error checking would only add 1 or 2 bytes of overhead.

Because this is a real-time modification, it would be useful to have a protocol command that allows you to batch commands. So basically, CMD_STARTQUEUE, then send all of the update commands, then CMD_ENDQUEUE gets sent to commit all changes to RAM sequentially.

 

you would definately want to put the load onto the PC. But gavitron and Matz both have very valid points.

To make this work in realtime, you would have to implement a bullet proof routine that could handle dropped packets or any kind of data loss. After thinking about it for a while, map switching could work in psudo realtime by having 2 maps for every realtime table you want to monitor. 1 map would be used for the current map accessed by the ECU, the other map would be newer parameters sent down by the PC. Like Matz said, once the new data is properly verified, switch maps...

I think if this approach were taken, this would minimize the problem that galvitron pointed out, since if the checksum (or what ever verification method is used) fails, you throw out the bad data, and the ECU could request a resend without interupting the normal ECU operation.

 

See my post/proposal on Aktivematrix.. I actually wrote about this awhile back as it creates a universal method for accessing and manipulating ram..

 

yeah I saw that, but havn't had time to catch up. This new job is keeping me very very busy.

 

What about these? Edit just realised they are rolled up above .

1) Timeout. Set time (possibly configurable) after we tell the ECU that the change is coming that the ECU gives up and continues along its merry way
2) Rollback. Snapshot what we have (PC side) right before we blow it away so that in the "oh ****" moment you can set it back to what it was before.

This can work but as chris is saying about that routine on the ECU is going to need to be strong and that usually increases the lines of code that your going to have to pop in there.

Agree with chris again....make the PC do the work...that's not controlling the engine and we don't want the ECU distracted. Performance is going to be key too, cause we don't want the ECU waiting on our request infinitely and not keeping stuff from going through the block.

 

Copied from my latest post on aktivematrix:

How about this: a first try might be to use request ID E0-E3 with a byte following each to give the four bytes that make up the long address we want to read. Then send E4 to ask for the reply. Then use E5 and E6 to load the two bytes to write and E7 to write it? As Jack suggests, using the echo or reply to confirm we have the correct data would work well? We can also interleave the requests with other request IDs. I think it would be quite economical on comms, and if we increase the baud rate as before (what is the max that works for anyone?) then our request/reply will go from 3 bytes standard to 5 bytes modified.

This would need 2 byte request ID and 1 byte echo plus 2 byte reply. The 2 byte request ID would need new code.

If the PC doesn't get through the whole command no changes will be made.

Of course you don't HAVE TO read before you write.

Also if writing/reading a block, you could increment just E3 to change the address to the next word without reloading E0-2.

 

Thats actually not a bad idea.. then you can stack the data without a huge performance hit..

 

exactly.

 

Further nailing down of this protocol is progressing here:

http://www.aktivematrix.com/forum/viewtopic.php?t=158