From: Tim Wescott on 27 Nov 2009 14:04 On Fri, 27 Nov 2009 12:33:18 -0600, dlopez wrote: > Tim, > Thanks a lot for the reply, it's really helpful. > >>On a really noisy link, or one that absolutely positively must >>synchronize quickly, it's often useful to put a CRC on the header: >> >><SOP><length><type><CRC><data><CRC> >> >>This adds two bytes to each packet as overhead, but it vastly simplifies >>sorting through a stream of data for a packet start, as it lets you >>discard a bad packet a lot quicker. > > Trying to confirm my understanding: > > So let's say for some reason that things are not in-sync (maybe power > up...). The FPGA would be reading bytes from the FTDI. It wants to see a > <SOP> byte, so would keep reading until it gets it. 1) If it's a > legitimate <SOP> we're in-sync again. > > 2) If it was just a random data byte with the same value, the FPGA would > start reading the <length> and <type>, which would be 'garbage' but > there is no way to know. Then it reads <CRC>, which would hopefully > fail, and start this process again. I guess there IS a slight chance > that this CRC passes, so we would keep reading the data and we might be > doing some very bad things with it. > > Are you saying you should NOT execute any command until the last <CRC> > is read and passes? I guess this requires a buffer in the FPGA that is > the length of the longest packet. This could be quite big in the case of > the streaming packet... Yes. Although if the cost of misreading a command is low enough you could maybe just go ahead and execute. An example of a high-cost command would be one that triggers a charge of dynamite -- you don't want that one executed unless it's really right. An example of a low-cost command might be a chunk of sound for a speaker -- get it wrong and at worst there'll be a pop or a second of loud static, but no one dies, no one accidentally buys 1000000 candy bars, etc. -- www.wescottdesign.com
From: Arlet on 27 Nov 2009 19:54 On Fri, 27 Nov 2009 11:32:23 -0600, dlopez wrote: > Hi, > When you say 'packetization', does it mean you have only and only ONE > packet structure? For example: > > myPacket = [startByte, dataStream(32 kbytes), dataControl(512 bytes), > Checksum, StopByte] > > startByte: 0x55 > Stream: whatever random data to stream > dataControl: say a bunch of [address, data] to be written in the FPGA. > CRC: a few bytes here > stopByte: 0x99 > > Then you send this packet over and over, regardless if the PC is needing to > send control data or not? > > Actually, after re-reading your email, I think you were saying to build > different packets, some for only streaming, some for control etc...The > streaming one are the longest, so they add latency before the next command > could be received. > > Are there any hands-on litterature on this type of stuff? I don't want a > 'communication systems' texbook:) > You could use HDLC, which does what you want, is standard, and not too complicated. http://www.interfacebus.com/Design_HDLC.html You can use the address byte to switch between data and control streams.
From: dlopez on 27 Nov 2009 20:16 > >You could use HDLC, which does what you want, is standard, and not too >complicated. > >http://www.interfacebus.com/Design_HDLC.html > >You can use the address byte to switch between data and control streams. > Hi, This is all getting clearer now. However, I wonder if using this FT2232H IC in synchronous FIFO mode isn't complicating everything. Isn't all of this 'packet' and 'layer' and 'CRC' stuff handled by the clever people who designed USB in the first place? Then I use a chip which takes care of all of this, but only give me access to a bunch of bytes, with no way to make sure that the receiver is synchronized. I then have to re-do the job of USB by creating my own underlying protocol? I wonder if the Cypress EZ-USB chip isn't a better option. It seem to support different channels (endpoints in USB terminology). Maybe one could be for data, the other for control? It just seems like there is a lot of duplicated work going on here, but maybe that's normal with USB. Diego --------------------------------------- This message was sent using the comp.arch.embedded web interface on http://www.EmbeddedRelated.com
From: Grant Edwards on 27 Nov 2009 23:34 On 2009-11-28, dlopez <d(a)designgame.ca> wrote: > This is all getting clearer now. However, I wonder if using this FT2232H IC > in synchronous FIFO mode isn't complicating everything. Isn't all of this > 'packet' and 'layer' and 'CRC' stuff handled by the clever people who > designed USB in the first place? "Clever people designed USB" ROTFL Good one! -- Grant
From: Vladimir Vassilevsky on 28 Nov 2009 00:05 dlopez wrote: >>1. Byte stuffing. >>Reserve a byte (like 0x00, 0xFF or 0x55) as "Escape" character, so the >>next byte will be interpreted as a "command". > > > The streaming data is random, so I can't prevent an Escape character like > 0x55 to be in there. Does that rule out this solution or I'm missing > something? Then transmit "0x55 0x55" instead of 0x55. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: Analog to Digital conversion using 18F452 Next: flash memory write endurance |