EMS side serial implementation discussion and group design!

Official FreeEMS vanilla firmware development, the heart and soul of the system!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

EMS side serial implementation discussion and group design!

Post by Fred »

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 :

Code: Select all

Each time period check to see if we should be sending data and if the buffer to receive it is empty
    if so, prepare logging packet per mask and transfer to the sending mechanism.
If a packet is received :

Code: Select all

Check to ensure it is valid
    if so, and if it needs a response (with or without ack), prepare response packet and data
    if so, and if it doesn't need a response, perform action, if ack required, send ack (pass or fail)
    if not, send error packet
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.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: EMS side serial implementation discussion and group design!

Post by 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.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
ababkin
LQFP112 - Up with the play
Posts: 215
Joined: Tue Jan 15, 2008 5:14 pm

Re: EMS side serial implementation discussion and group design!

Post by ababkin »

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)
Legal disclaimer for all my posts: I'm not responsible for anything, you are responsible for everything. This is an open and free world with no strings attached.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: EMS side serial implementation discussion and group design!

Post by Fred »

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.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
AbeFM
Post Whore!
Posts: 629
Joined: Sat Feb 16, 2008 12:11 am
Location: Sunny San Diego
Contact:

Re: EMS side serial implementation discussion and group design!

Post by AbeFM »

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....
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: EMS side serial implementation discussion and group design!

Post by Fred »

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.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
AbeFM
Post Whore!
Posts: 629
Joined: Sat Feb 16, 2008 12:11 am
Location: Sunny San Diego
Contact:

Re: EMS side serial implementation discussion and group design!

Post by AbeFM »

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.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: EMS side serial implementation discussion and group design!

Post by Fred »

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.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
AbeFM
Post Whore!
Posts: 629
Joined: Sat Feb 16, 2008 12:11 am
Location: Sunny San Diego
Contact:

Re: EMS side serial implementation discussion and group design!

Post by AbeFM »

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.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: EMS side serial implementation discussion and group design!

Post by Fred »

You lost me at wideband. This thread is about serial comms... ??
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply