View unanswered posts | View active topics It is currently Fri May 24, 2019 7:57 am

Reply to topic  [ 1 post ] 
Serial Protocol Summary Of Ideas And Agreed Components etc 
Author Message
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15249
Location: Home sweet home!
Before you go "but but but, the wiki!!??" I want the information to be easy to find for someone browsing the forum. To find the wiki page you have to go through that thread which to be fair is huge now. So, links and lists and summary here. If we agree on something in the other thread, post it up here in a concise way. Don't discuss things here, use this thread :


Serial spec is available for download from here as it develops : ... _id=277306

wiki pages for those that want to use them are here :

Overview : ... munication
Layer 1 : ... ol-Layer-1
Layer 2 : ... ol-Layer-2

Summary (some of which is in the released documents) :

  • We will have only one protocol and it will be binary/fast/compact especially for the EMS side
  • We want a generic lower layer that is standardised in format etc for moving data. (part 1)
  • A mechanism for identifying version of firmware is required to be part of lower level and standard across all firmwares. To be used as a "ping" as well.
  • Version specific stuff should be separate to that interface spec (part 2)
  • Where checksums are used, they should come at the end of each packet
  • All EMS bound packets should have optional checksum and/or acknowledgment
  • All PC bound packets should have optional checksum (ack will probably never be used in that direction but will be present for later higher powered EMSes)
  • Autonomous messages are limited to serious error conditions and data log packets as fast as can be sent IF enabled.
  • All other data should be requested by the external device (including
  • Where an ACK is required an ACK flag will be set, and an ACK ID number assigned to the request packet, the return packet will be just an ID ack if no return data is required, or a packet of data with an ID and ack attached.
  • Reliable transmission will be up to the external device. The EMS will do it's best to respond, however if it never does, the external device needs to ask again till it gets an answer.
  • The EMS will perform flow control in an asymmetric way. When handling a request it will block further requests until it is done. The external device will accept all data sent to it and process it in a timely fashion.
  • Loading of new firmware will be done using the standard Freescale serial monitor and bootloader switch.
  • Packets will be IDed by start, stop bytes that if found inside a packet are masked and escaped with another special char that is also masked and escaped with itself when found
  • 9 bit raw data byte size with start, stop and single parity at the end (11 bits total per byte)

Please keep the comments and discussion in this thread :



_________________ - where Open Source means Open Source, and Free means Freedom - 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!

Fri May 23, 2008 1:45 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 1 post ] 

Who is online

Users browsing this forum: No registered users and 1 guest

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:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF. ColorizeIt.