View unanswered posts | View active topics It is currently Wed Sep 18, 2019 7:35 pm



Reply to topic  [ 17 posts ]  Go to page 1, 2  Next
EMS side serial implementation discussion and group design! 
Author Message
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15331
Location: Home sweet home!
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:
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:
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!


Sun May 25, 2008 5:36 pm
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15331
Location: Home sweet home!
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!


Sun May 25, 2008 7:49 pm
Profile WWW
LQFP112 - Up with the play
User avatar

Joined: Tue Jan 15, 2008 5:14 pm
Posts: 215
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.


Mon May 26, 2008 3:46 am
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15331
Location: Home sweet home!
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!


Mon May 26, 2008 10:47 am
Profile WWW
Post Whore!
User avatar

Joined: Sat Feb 16, 2008 12:11 am
Posts: 629
Location: Sunny San Diego
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....


Tue Jun 03, 2008 8:57 pm
Profile ICQ YIM
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15331
Location: Home sweet home!
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!


Wed Jun 04, 2008 7:31 am
Profile WWW
Post Whore!
User avatar

Joined: Sat Feb 16, 2008 12:11 am
Posts: 629
Location: Sunny San Diego
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.


Wed Jun 04, 2008 7:18 pm
Profile ICQ YIM
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15331
Location: Home sweet home!
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!


Thu Jun 05, 2008 7:01 am
Profile WWW
Post Whore!
User avatar

Joined: Sat Feb 16, 2008 12:11 am
Posts: 629
Location: Sunny San Diego
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.


Thu Jun 05, 2008 6:48 pm
Profile ICQ YIM
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15331
Location: Home sweet home!
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!


Thu Jun 05, 2008 9:45 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 17 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF. ColorizeIt.