DIYEFI.org Forum

Hi, because I'm a total noob with C and serial stuff I thought I'd put this up, record the thoughts that I have on the subject, outline my plan and let everyone rip it apart and suggest much much much better ways :-)

Vague requirements :

Data types :

autonomous logging data out
instructional packets in
acks and responses out
error packets out
none (running the engine only)

Priority :

Running the engine (no serial code) > Receiving Instructional Packets > Sending Error Packets > Sending Ack and Response Packets > Sending Autonomous Logging Data Packets

For Autonomous logging data :
If a packet is received :
Mechanism :

In order to get "matching sets" of data for logging, we need to buffer the variables in sets. This can be done in an ISR blocked session on demand, or perhaps all the time such that there is always a packet ready to go (or the contents there of) and they can just be sent when ready.

The receive code should look for a start byte, and receive the header, and the contents, and when the finish byte comes in check it for validity, or when some size limit for a packet is reached, reject it as oversized or something. (data size on the ecu will have a finite limit for sure). Once it has a packet, it should disable receipt of more until it has processed that one and either responded, acked, actioned, etc. Once done, it should re-enable receipt of packets.

To send (either responses or logging) a general handler is required. The handler should take a pointer to an array (and length) of bytes to be sent, add a header to it, send it and add a checksum to the end.

This is probably (certainly) full of holes, but we can work on it and when it's ready to go, I can code it up.

Fred.

http://tldp.org/HOWTO/Serial-Programmin ... html#AEN88

New word of the day : Canonical which is what I meant by receives the whole thing and then processes it :-)

Fred.

just wanted to say that perhaps we should consider the non-ISR way of doing comms (to not preempt the important stuff potentially going on in a part of main loop or other ISRs)

ababkin wrote:just wanted to say that perhaps we should consider the non-ISR way of doing comms (to not preempt the important stuff potentially going on in a part of main loop or other ISRs)

I understand how to do that for sending data out, but I can't see how to do that for receiving data in without missing packets. Certainly processing of the packet once received and buffered should be outside of ISR code, but receiving it itself as far as I can tell simply MUST be in ISR code. (though short and simple).

Fred.

Not sure how the chip handles it internally, but some chips have buffers, and perhaps you can make an external buffer if there isn't one, but basically you'd have a listener somewhere which gathers data and you go poll it or get a lowest-priority interrupt then some comes in.

That A/D can chip someone found had three input buffers and two output buffers (visa versa?) just for sorting by priority....

It has a single byte transfer buffer that is dual purpose. If you write the address the data goes into the send buffer to go out, if you read it, it comes from the receive buffer coming in. Because of that, as soon as that byte is stored, and you get your interrupt, you need to read and stash the byte so that the next one is not lost. If you leave it there, the next one on the wire will be dropped to save the first one (this makes sense, you do want contiguous data) and you get an interrupt that says it was overrun. Hence you have to clear the incoming stuff immediately. The outgoing can be sporadic and slow, no worries. Incoming can't as far as I can tell. At least, not at that level. What you do with it after you get a complete packet is another matter. This is called canonical processing. We can do that in the main loop in non ISR time for sure.

Oh, ok, when they said there were multiple buffers, I wasn't sure what did that.

Although, really, a buffer chip should exist (or something could be made) which holds several commands/packets, and sends them out when the CPU tells it to.

8InchesFlacid wrote:Although, really, a buffer chip should exist (or something could be made) which holds several commands/packets, and sends them out when the CPU tells it to.

I like to call this "chip" a "PC" and one with "flow control" ;-)

I think it is a fact of life that serial reception will somewhat interfere with normal operation. I find this 100% acceptable as normal operation is driving and serial is something you only do while tuning etc. Analogous to the MS burn blip.

Fred.

Assuming you aren't using serial to get things like wideband information and other sensors. Which, if it doesn't interfere with normal running, would be very very nice to support. It's hard to go wrong with digital communications. No arguing over whose version of ONE VOLT to reference.

You lost me at wideband. This thread is about serial comms... ??