Hi guys, In my protocol, or should I say, in the lib that defines the protocol, you can configure how the communication will be set between a PIC and the PC (PIC to PIC com. is not the purpose, though it might work... Isn't i2c a better solution ?). For instance, you can specify how frames will be built:
* start of frame (SOF) * end of frame (EOF) * type * length Then, when you call "send_message()" or "send_response()", it builds the appropriate frame. For now, receving frames (the requests), have no SOF/EOF, have no type (because only one, request), and the length is supposed to be known by the PIC, because it knows how many bytes it needs to receive for a given action. This is obviously a big limitation I need to deal with. About the length, even if configurable, I prefer using SOF/EOF since you can't know sometime how big the frame will be. It could also be longer than 256. For instance, I used to record sounds with my PIC and send the wave to the PC... About checksum: if checksum is wrong, this means some bad things occured during the com. So I also need some kind of "Repeat Request" message. I'd also need a ACK mecanism, with timeout: no ACK received for X msecs ? Re-send the message. For now, I need to implement the Escape char: used to transmit a char which is reserved (mainly the EOF, so not detected as a real end of frame). To be continued... Seb 2008/12/12 Joep Suijs <[email protected]> > > 2008/12/12, Eur van Andel <[email protected]>: > > > >> There are a lot. Wbus is one of them, used to communicate the wisp > >> programmer. > > Mine is close to the wisp programmer: the PC program is an extension of > > wisp.py > I don't like the break char used by wbus. Avoid this if you can. > > >check > >check > >check > >check > We seem to agree on this topic ;) > > > On top of this you could: > > - add a data lenght field in the frame. > > frame is fixed length of four bytes > You should have made it 5: one byte length field. > In the early nineties I was involved in a protocol for parking > systems. It had a frame-type field and each frame type had a > corresponding length. This was a big mistake and the guy who supports > the current systems still carries the burden. All systems must know > all frame types until the last component is upgraded to the new > protocol... > > > On top of this: my protocol works with a bootloader too. > Neat! > > > Joep > > > > -- Sébastien Lelong http://www.sirloon.net http://sirbot.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jallib?hl=en -~----------~----~----~----~------~----~------~--~---
