In article <EYCdnQAJ8fKcuozWnZ2dnUVZ_oidnZ2d@giganews.com>, 
d@designgame.ca says...
...
> >> 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?
> >
> >The inbuilt micros inside the FT2232H, deal with some of this, and as it
> >is you have a DUAL channel device where as far as I can see you are using
> >ONE port in synchronous FIFO mode which is bi-directional, and have 
> >another channel you can use in all sorts of ways including GPIO to signal
> >command or data modes, even separate command channel.
> 
> Using the FT2232H in synchronous FIFO mode switches all the ressourcing of
> the chip to Channel A, and Channel B cannot be used for anything. I guess
> this means I need to build up some packets and commands like the previous
> posters recommended. 

If you need the speed or use a different mode like synchronous bitbang 
FIFO, or a different device.

I personally am moving away from FTDI after too many documentation 
and other issues.

> >It appears to me you expect USB and/or a USB device chip to be psychic 
> >about how your design works.
> >
> >Whatever you use, you still have to sort out how to deal with a 
> >datastream (data or commands) to the rest of the hardware, even if
> >this was a serial (RS232) connection.
> 
> Yes this makes more and more sense. However it doesn't seem that easy when
> there are NO extra pins and everything has to be embedded in a continuous
> stream of bi-directional bytes. I guess this is where the fun begins!

If you can design assuming a byte stream, then it is easier to change 
this design, or future designs based on this method to different link 
layers, ege ethernet, wireless, or some other new interface later.

Remember to get byte order sorted for different platforms and 
anything representing larger than byte, well documented as to
what happens in your device and order to/from USB.

Don't forget to document your command/datastream packets.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

>The minimum that I'd suggest would be
>
><start of packet><length><type><data><CRC>
>
>Use a CRC (cyclic redundancy check) instead of a checksum -- it'll be 
>much more likely to catch an error.  I'd suggest two bytes each for 
>length, type, and CRC, and one byte for the start of packet -- but a one-
>byte type field often works well (until you're trying to find a home for 
>the 257th message type -- then it's a disaster).  When folks use a start-
>of-packet byte it's often something obvious like 0x55 or 0xaa, etc.
>
>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.
>

Hi again! I'm working on implementing those ideas and I wonder if usually
the packet protocol is implemented the same way from tx to rx.

Say I describe packet this way (from PC to FPGA):
<SOP><length><type><CRC><data><CRC>

packetWrite is used to write to an 8 bit register in the FPGA.
packetStream is used to send 32kBytes of streaming data. 

The application would be sending packetStream over and over, and once in a
while a packetWrite would get in there. 

Now of course comes the 'packetRead', which would read an 8 bit register
from the FPGA! So fine, the FPGA gets the 8 bit and now needs to transfer
this back to the PC. It also needs to transfer streaming data coming in at
the same time.
I assume this pretty much means that the FPGA needs to be 'building'
packets as well! And at that point might as well use the same protocol?
This does complicate the FPGA design quite a bit though, because it now
needs to analyze the streaming data to create the CRC...

Any obvious simplifications to this?

Diego
	   
					
---------------------------------------		
This message was sent using the comp.arch.embedded web interface on
http://www.EmbeddedRelated.com

>You are not synchronising the USB receiver, you are synchronising your
>application, end hardware and how the MPSSE engine inside the FT2232H
>works.

Very clear! Got it!


>> 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?
>
>The inbuilt micros inside the FT2232H, deal with some of this, and as it
>is you have a DUAL channel device where as far as I can see you are using
>ONE port in synchronous FIFO mode which is bi-directional, and have 
>another channel you can use in all sorts of ways including GPIO to signal
>command or data modes, even separate command channel.

Using the FT2232H in synchronous FIFO mode switches all the ressourcing of
the chip to Channel A, and Channel B cannot be used for anything. I guess
this means I need to build up some packets and commands like the previous
posters recommended. 


>It appears to me you expect USB and/or a USB device chip to be psychic 
>about how your design works.
>
>Whatever you use, you still have to sort out how to deal with a 
>datastream (data or commands) to the rest of the hardware, even if
>this was a serial (RS232) connection.

Yes this makes more and more sense. However it doesn't seem that easy when
there are NO extra pins and everything has to be embedded in a continuous
stream of bi-directional bytes. I guess this is where the fun begins!

Diego



	   
					
---------------------------------------		
This message was sent using the comp.arch.embedded web interface on
http://www.EmbeddedRelated.com

In article <pfadnXRpDaVK5I3WnZ2dnUVZ_vSdnZ2d@giganews.com>, 
d@designgame.ca says...
> >
> >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? 

NO, you are confusing the link transmission method and what you are 
putting in one end to come out the other end. How the rest of your
hardware and/or software deals with the data stream is beyond the
scope of USB and the USB interface chip.

> 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?

Just the same as anybody else who does USB devices like printers, flash
drives, hard disk drives, scanners, digital cameras..... Just like the
implementation of CD/DVD devices over ATAPI (PATA) or SATA inetrfaces 
have to.

That is why drivers have to be loaded onto the host system to match the
device at the other end of USB.

You are not synchronising the USB receiver, you are synchronising your
application, end hardware and how the MPSSE engine inside the FT2232H
works.

> 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?

The inbuilt micros inside the FT2232H, deal with some of this, and as it
is you have a DUAL channel device where as far as I can see you are using
ONE port in synchronous FIFO mode which is bi-directional, and have 
another channel you can use in all sorts of ways including GPIO to signal
command or data modes, even separate command channel.
 
> It just seems like there is a lot of duplicated work going on here, but
> maybe that's normal with USB.

USB in a simple description is a shared form of cabling interface, with 
several bits hidden from normal users.

It appears to me you expect USB and/or a USB device chip to be psychic 
about how your design works.

Whatever you use, you still have to sort out how to deal with a 
datastream (data or commands) to the rest of the hardware, even if
this was a serial (RS232) connection.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate


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

On 2009-11-28, dlopez <d@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

>
>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

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.

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