The old serial thread is here : http://www.diyefi.org/forum/viewtopic.php?f=8&t=89
That thread was fairly narrowly targeted in terms of a 1:1 connection that I had envisaged. We need to discuss what it will take to get comms that work on a network style environment. I'm pretty keen to have one set of code to handle serial and CAN comms right off the bat, but I'm not 100% sure what is required to do it.
I made some notes on the train on the way home that I'll paste below :
How multiple physical protocols will affect serial comms
- Headers will change depending on the design.
- Serial escape scheme will be the same
- Serial start/stop will be the same
- Checksum will be the same (no harm in superfluous checksum on CAN even if it does it in hardware too)
- Interrupt handling will be the same or very similar
- Logging and receive interlacing will be the same or very similar
Model of possible interactions required
Properties :
- CAN messages can be addressed when sent on a physical level.
- Serial messages are 1:1, but it IS possible to parallel devices on the line (though not recommended)
- Does CAN have data integrity built in? IE, does it need a checksum as the serial comms does?
- ECU > ALL (data log packets, error packets)
- ECU > specific (response to requests)
- PC/HH > ALL
- PC/HH > specific
- Each node COULD have an address
- Each message COULD have an ID/sequence number
2 * ECU
X * AUXIO units
X * Datalogger
1 * Laptop
X * Display/Dash unit
1 * Handheld device
Where X is defined as 0 – Many.
8 bits is plenty for addresses.
8 will work for sequencing if done right.
A broadcast address is required, and preferably some distinction between from ECU and from PC/HH too such that messages with broadcast from ECU are ONLY received by PC/HH devices, and NOT other ECU devices.
Basically I'm looking for ideas on how the addressing and logic and semantics for one message on a bus with 10 devices listening can work.
Any/All ideas welcome.
Fred.