Prev: Analog to Digital conversion using 18F452
Next: flash memory write endurance
From: Paul Carpenter on 28 Nov 2009 03:56
In article <pfadnXRpDaVK5I3WnZ2dnUVZ_vSdnZ2d(a)giganews.com>,
d(a)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(a)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
From: dlopez on 28 Nov 2009 08:34
>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
From: dlopez on 28 Nov 2009 08:50
>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
From: Paul Carpenter on 28 Nov 2009 10:16
In article <EYCdnQAJ8fKcuozWnZ2dnUVZ_oidnZ2d(a)giganews.com>,
d(a)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(a)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
From: -jg on 28 Nov 2009 15:49
On Nov 28, 4:16 am, "dlopez" <d...(a)designgame.ca> wrote:
>
> Any idea?
>

Don't forget you can trade bandwidth for information.

So if you have a 2232H, and 1MB/s, you could change to a base rate of
2MB/s and send byte-pairs.

Byte+!Byte is steered a Data Byte
Byte+Byte is steered as Control.
This also gives some noise protection, as unequal byte-pairs are
flagged as errors. (Or used as a Frame Sync/reset)

This is, of course, very simple to code/decode ;)

-jg
First  |  Prev  | 
Pages: 1 2 3 4
Prev: Analog to Digital conversion using 18F452
Next: flash memory write endurance