Serial Protocol Summary Of Ideas And Agreed Components etc

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

Serial Protocol Summary Of Ideas And Agreed Components etc

Post by Fred »

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 :

http://www.diyefi.org/forum/viewtopic.php?f=8&t=89

Serial spec is available for download from here as it develops :

https://sourceforge.net/project/showfil ... _id=277306

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

Overview :
http://freeems.wiki.sourceforge.net/Fre ... munication
Layer 1 :
http://freeems.wiki.sourceforge.net/Fre ... ol-Layer-1
Layer 2 :
http://freeems.wiki.sourceforge.net/Fre ... 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 :

http://www.diyefi.org/forum/viewtopic.php?f=8&t=89

Admin.
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