Arlet wrote:> On Mar 3, 4:36 am, CC <cr...@BOGUS.sbcglobal.net> wrote: > >>I wish to transfer binary data in the simplest way possible from a PC to >>either an AVR or TMS320F2812 embedded target via USB. > > You may be interested in RFC 1549 "PPP in HDLC framing", see > http://www.ietf.org/rfc/rfc1549.txt > > The frame format is simple and robust, and has fairly low overhead.:-D -- Good day! ____________________________________ CRC crobcREMOVETHIS@BOGUSsbcglobal.net NOTE, delete texts: "REMOVETHIS" and "BOGUS" from email address to reply.
Designing a protocol for the first time
Started by ●March 2, 2008
Reply by ●March 3, 20082008-03-03
Reply by ●March 3, 20082008-03-03
Jim Stewart wrote:> X-modem CRC. Then you only have to write it for > the target.Yeah, I will spend some time looking at Xmodem to see if I should do it that way. I wonder if there is anything in Python for that? Might have to use some C bindings for Python to use an existing codebase. -- Good day! ____________________________________ CRC crobcREMOVETHIS@BOGUSsbcglobal.net NOTE, delete texts: "REMOVETHIS" and "BOGUS" from email address to reply.
Reply by ●March 3, 20082008-03-03
Chris Carlen wrote:> Arlet wrote: >> On Mar 3, 4:36 am, CC <cr...@BOGUS.sbcglobal.net> wrote: >> >>> I wish to transfer binary data in the simplest way possible from a PC to >>> either an AVR or TMS320F2812 embedded target via USB. >> >> You may be interested in RFC 1549 "PPP in HDLC framing", see >> http://www.ietf.org/rfc/rfc1549.txt >> >> The frame format is simple and robust, and has fairly low overhead. > > > :-DI don't know what the big grin means, but I wasn't talking about PPP, but rather about the encapsulation method of PPP over serial lines, which is quite simple. In fact, it's only slightly more complicated than XMODEM, but more robust.
Reply by ●March 3, 20082008-03-03
Arlet Ottens wrote:> Chris Carlen wrote: >> Arlet wrote: >>> On Mar 3, 4:36 am, CC <cr...@BOGUS.sbcglobal.net> wrote: >>> >>>> I wish to transfer binary data in the simplest way possible from a >>>> PC to >>>> either an AVR or TMS320F2812 embedded target via USB. >>> >>> You may be interested in RFC 1549 "PPP in HDLC framing", see >>> http://www.ietf.org/rfc/rfc1549.txt >>> >>> The frame format is simple and robust, and has fairly low overhead. >> >> >> :-D > > I don't know what the big grin means, but I wasn't talking about PPP, > but rather about the encapsulation method of PPP over serial lines, > which is quite simple. > > In fact, it's only slightly more complicated than XMODEM, but more robust.I wasn't laughing at your suggestion. Only that it would take me more time to understand RFC1549 than to implement my simple protocol. It's just a question of what's minimally necessary. -- Good day! ____________________________________ CRC crobcREMOVETHIS@BOGUSsbcglobal.net NOTE, delete texts: "REMOVETHIS" and "BOGUS" from email address to reply.
Reply by ●March 3, 20082008-03-03
On Mar 2, 10:36 pm, CC <cr...@BOGUS.sbcglobal.net> wrote:> send data out through the virtual COMM port produced by using a FTDI > FT245BM USB-to-FIFO parallel interface chip on the target.snip> Now of course, each state transistion can send a code back to the sender > telling whether things are proceeding smoothly. Another state > transition path to add might be:Your ack scheme will need to be pipelineable, as while USB has fairly high data throughput the latency, so waiting for an ack for the data you've sent will quickly kill you. You need to be able to keep sending, and handle errors after the fact. You might look at network protocols for an example, and then cut one down to the simplest case.
Reply by ●March 3, 20082008-03-03
On Mar 3, 3:23 pm, cs_post...@hotmail.com wrote:> Your ack scheme will need to be pipelineable, as while USB has fairly > high data throughput the latency, so waiting for an ack for the data > you've sent will quickly kill you. You need to be able to keep > sending, and handle errors after the fact.Oh, another thing - USB is packetized. And the virtual serial drivers are not necessarily real smart. If you put bytes into the serial port driver, you may get only one byte of user data per USB packet. So try to pass larger chunks of data to the serial driver (ideally, figure out how much payload it sends at a time and give it that)
Reply by ●March 3, 20082008-03-03
cs_posting@hotmail.com wrote:> On Mar 3, 3:23 pm, cs_post...@hotmail.com wrote: > >>Your ack scheme will need to be pipelineable, as while USB has fairly >>high data throughput the latency, so waiting for an ack for the data >>you've sent will quickly kill you. You need to be able to keep >>sending, and handle errors after the fact. > > Oh, another thing - USB is packetized. And the virtual serial drivers > are not necessarily real smart. If you put bytes into the serial port > driver, you may get only one byte of user data per USB packet. So try > to pass larger chunks of data to the serial driver (ideally, figure > out how much payload it sends at a time and give it that)I get the picture. Thanks for the input! -- Good day! ____________________________________ CRC crobcREMOVETHIS@BOGUSsbcglobal.net NOTE, delete texts: "REMOVETHIS" and "BOGUS" from email address to reply.
Reply by ●March 3, 20082008-03-03
Chris Carlen wrote:> Jim Stewart wrote: > >> X-modem CRC. Then you only have to write it for the target. > > Yeah, I will spend some time looking at Xmodem to see if I > should do it that way. > > I wonder if there is anything in Python for that? Might have > to use some C bindings for Python to use an existing codebase.If you are going to consider X-modem, try Z-modem. Much better error control, speed, etc. Uses the same transmission paths. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section. -- Posted via a free Usenet account from http://www.teranews.com
Reply by ●March 3, 20082008-03-03
Chris Carlen wrote:> The Real Andy wrote: > >> For a first time protocol all i can say is dont use straight >> binary, use ascii (start sentinals and end sentials etc) that >> way you dont have to worry about escape sequences etc. > > Since I have total control over the receiving end driver code and > can design it to provide a getc() that doesn't process any escape > sequences, then as long at the outgoing bytes on from the PC are > also not processed by the PC, there is no problem with binary. > > As far as I have seen so far, it is the case that outgoing bytes > on the PC are emitted directly. > > The problem with ASCII is that it will at least double the > physical layer throughput needed to acheive a certain high-level > data throughput. Ie, if I took each binary byte and sent it as > two ASCII text chars, one for each nibble, which is a common way > of transmitting binary data in ASCII form, while allowing > control chars to be treated as control chars.Zmodem (and Xmodem, or Ymodem) are protocols that transmit binary. They require that the full 8 bits of a byte are usable for transmission. Zmodem provides the best results of the three. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section. -- Posted via a free Usenet account from http://www.teranews.com
Reply by ●March 6, 20082008-03-06
CBFalconer wrote:> If you are going to consider X-modem, try Z-modem. Much better > error control, speed, etc. Uses the same transmission paths. >Sorry to pick on your idea CBF. Xmodem is considerably easier to implement than Zmodem. I implemented Xmodem when I was about 10 or 11 years old, first in Basic, and then in C. I remember Zmodem when it was first released, and it was great. Big improvement over Xmodem and Ymodem, lots of extra features and functionality. But it was also a lot more complex. Sliding windows, automatic recovery, big checksums, transfer of filenames, etc etc. I'm not necessarily advocating anything for your particular application, just wanted to point out that using Zmodem might not be a slam dunk. Oh, and regarding FTDI chips. Their chips, drivers, and support are all top notch. I'm using their FT232BM chip at 2mbps, and it works reliably. I started using their VCP drivers, which work very well. I eventually switched to using their D2XX .dll drivers, because it offers more fine-grain control. Be sure to download the datasheets, app notes, and tips on their website, especially when they talk about latency, baud rates, etc. Hope this helps Keith
