However there are some niggles which I would like to address here.
Consider this the public consultation phase :-) Say your piece before I make decisions we all have to live with ;-)
-----------------------------------------------------------------
Number one (my idea) is the proto/firmware bit thing...
Silly idea.
Proposed resolution is to dedicate 256 codes to the protocol (should be heaps) and leave the other 65256 or so for the firmware (will definitely be heaps).
This way will allow you to know its a protocol packet if you want to by reading the upper byte and checking it is zero.
To clarify, the intent was that ALL implementations of the protocol should implement those protocol packet types. This remains the intent, just not with a bit to distinguish, only the range of the ID itself as Stu originally said. The firmware ones on the other hand could be and should be absolutely anything the designer feels like implementing. Unrestrained except by size and speed.y09223 wrote:Payload Type:
It is unclear to me what the difference between a "protocol" and "firmware" payload type is. Why have two separate sets of payload definitions?
The header bit should go though.
-----------------------------------------------------------------
Number two is reply and ack semantics. Right now things are messy. IE, you might want a reply, or you might not and I might want to give you one (error or otherwise and I might not)
To be blunt, I don't like it.
What I would prefer is to *always* send a reply back (except for resets, but even those could be done via a one off start up message).
This keeps things clean and reduces code.
Currently I think the ack field should remain an option. It will be easy enough to send/not send that.
The purpose was to ensure that you KNOW that a packet is for you. IE, a packet of the same type sent at much the same time as a second host on a shared connection will elicit the same type of response. The content of the request could have been different though, depending on which type. The only way to KNOW it's for you and not someone else is the matching ack number being sent back. The chances of it being for someone else are then heavily reduced.y09223 wrote:As best I can tell, the need and use of Ack/Seq Number byte is undefined in the spec. Also, in reading through the forum, I could find no obvious argument in favor of it.
Further to that, it could serve as a sequence number to indicate lost packets to the tuning app if they are sent and received sequentially and attempted to be checked for consistency of replies.
------------------------------------------------------------------
Addresses. I think these should stay as it's easy to handle and essential for a networked environment on CAN later IMO.
However :
Can you elaborate more on this as I do not have a game plan at the moment. My only thought was "if the packets themselves have the address then it doesn't matter how they get there as long as they do and they will always work the same way." If there is a better way, please either here or the original thread or the take 2 thread (preferably the latter) tell use all about it!Addressing Behaviour:
Addressing does not seem to be necessary at the message packet level.<SNIP>If a CAN or LIN bus is to be added to the EMS, CAN and LIN addressing can be easily implemented by defining one of the Payload ID reserved bits to indicated a CAN or LIN bus, with the Payload ID containing the address. The EMS would then simply pass the payload to the bus/address specified, minimizing parsing and processing overhead.
Discussion on CAN stuff and other bits and bobs : http://www.diyefi.org/forum/viewtopic.php?f=8&t=454
-------------------------------------------------------------------
Y09223 pointed out that the bits in the header not used should be reserved, not left open for discussion. Fair enough. Saying they are reserved won't stop me or others using them for experimentation at the end of the day, and will keep things clean into the future.
-------------------------------------------------------------------
Given that we only have 32k of ram, and we only have 512k of flash, and that the chance of filling it all are slim to none, the 65k of packet we can send with a 16 bit (less expensive speed wise) length field seems much more appropriate. Additionally, we can only burn down 1k at a time anyway. The largest single data block currently is 2k and there won't be one over 16k on this platform ever as the flash page window is only 16k and having tables that big is getting absolutely ridiculous. I'm already being accused of making them too big as it is.y09223 wrote:Payload:
Each packet should contain exactly one payload. Given a payload length of 2^32, there should be no need for multi-packet sequences. By the same logic, a string payload should contain one item; if multiple character blocks are to be sent, each block should be in it's own packet. Besides, null-terminated blocks take time to encode and decode.
I really don't see why we can't put an arbitrary number of strings in one packet. What is the problem there? I definitely don't think the packet should know what it is carrying. Only how long and what it's ID is. If the ID means a certain type, the length isn't even required. The null terminations are not a time killer at all except the bandwidth (minimal) as all strings in C will have one on the end anyway.
I think this is a non issue really. Though I've put it here to allow discussion of it.
--------------------------------------------------------------------------
This is not true. Any time they *would* appear they are converted and prefixed with an escape byte. The worst case is a packet made of only special bytes. Worst case is half speed. Normal case is about 0.5% speed hit from this.UART specific items:
STX and ETX characters can appear in a binary data packet. Even with an escaping scheme, the escape sequence can appear in the binary data packet. This is a 30-40 year old problem, with a lot of good solutions out there. But, ALL solutions require additional code (memory) and processing (cycles).
----------------------------------------------------------------------------
For the record, I am concerned about bandwidth, but much much less so about CPU cycles and memory, of those there is a reasonable supply. Thank you for your input John!!
----------------------------------------------------------------------------
On more positive notes :
Payload ID works brilliantly!
Header flags work brilliantly!
Start/Stop/Escape work brilliantly!
Checksum works brilliantly!
Due to the above, it's FAST :-) Not slow! To recap, if you don't have this stuff, you have to basically poll... polling = delays/waiting. With this stuff we can back to back messages and still receive them cleanly. This works in practice to give us double or more what MegaSquirt can do ;-)
For those that haven't seen it, here is a vid of the current two matching code bases in action :
http://www.youtube.com/watch?v=4MS_zc8sZxM
I'd love to get your feedback on this, whoever you are!
Regards,
Fred.