https://sourceforge.net/project/showfil ... _id=610714
Newly finalised are :
- 8 bit CRC agreed on.
- A header bit defines whether payload type is from the protocol or firmware set
- Strings will be terminated with the null byte
- CRC semantics - should the header be included in the main check?, CRCed separatey?, or header not checked
jbelanger wrote:Also, it would be a good idea to protect the header part of the message with it's own checksum (or another more robust method).
Please discuss.thebigmacd wrote:The reason I reserved 4 bytes in the CRC field is I like having a separate CRC for each field in the datastream - CRC semantics - should the CRC be done on the pre escaped data, or post escaped data?
Please discuss. - Flow control - hardware, software, ignoring incoming requests when busy - requirements for each etc.
http://microcontrollershop.com/download ... E64man.pdf page 12, they discuss using normal pins for hardware control and the jumpers that connect them. I found other references to hardware control via pin toggling too so my assumption that this was done manually with bit banging in software was correct. The plug itself is connected to 8 solderable holes on the board. Labeled W 7 - 10. These are usually used for bridging the connections for loopback use I guess. We can use them to hook some CPU pins and do our flow control. I don't see a need for two directional control. The PC should be able to take anything thrown at it. The FreeEMS on the other hand really needs to be able to say "I'm busy, don't send" some of the time. Because of this I think that one extra pin for FreeEMS to control the PC is enough. Can anyone comment on this? Basiclly I expect it will work like this : the pc can send requests any time except when told it can't. It will be told it can't when the FreeEMS is busy handling a request. So, at boot pc is able to send. pc sends request, FreeEMS recieves the end of that request, disables the interrupt, turns the stop control line to stop, deals with the request, sends a block of ack or data back and then reenables reception of data where the process repeats.
- Stretchy ints, yes or no?, if yes, how?, if no, how big for numbers?
I have Stu's example code and need to analyse it and discuss what I find. - Appendix A payload format details - Interface version request packet size/contents
I think an empty packet with correct payload type etc is fine, discuss. - Appendix A payload format details - Firmware version request packet size/contents
I think an empty packet with correct payload type etc is fine, discuss. - Include extensive "basic" vars in part 1 spec for compatibility with simple devices that can't cope with flash protocols? (would require detailed thinking...)
Undecided, but bit flag for protocol/firmware use of payload type field allows this, discuss. - Acknowledgements :
Any PC -> Device packet can contain an acknowledgement request, the returned packet has a header bit that says whether it is positive or negative. If positive the packet will either be empty, or contain the requested data. If negative the packet will be empty, or contain data that will be read as a X bit number where X is however many bits come through, discuss. - Special protocol packet types :
What is there, errors, special conditions, etc etc, name some please if you can. - Packet size (PC -> Device) :
We need a request for maximum packet size OR we need to write our data down straight away and complain afterwards if it was bad. Or we need to have a fixed max packet size on the protocol, this is bad. Discuss. - I'd like to propose a packet type that requests a block of data either with a page value, address and length, or just an address and length, or possibly two, one for each. I don't want memory access for writes, but reads seems useful and harmless.
Please discuss. - The CRC where used should also be escaped incase it ends up being the stop start or escape byte.
Please discuss.thebigmacd wrote:I don't know the best way to use this so I left it reserved. It likely needs to be a value of 128-255 because we wouldnt want to inadvertently produce a CRC with a !, #, or $ in ascii code.
Thanks for your efforts so far all parties!
Fred.