Prev: Analog to Digital conversion using 18F452
Next: flash memory write endurance
From: dlopez on 27 Nov 2009 10:16
Hi,
I'm having trouble figuring out how to architect a robust system using the
FTDI chips in FIFO mode. I'm pretty sure some of you have been through this
before.
I'm using the FT2232H in synchronous FIFO, but my concerns are general.

The system has PC <-> FT2232H <-> FPGA, and is used to both stream/receive
data between the PC and the FPGA.

I'm wanting to stream continuous data at about 1MB/s each way, WHILE also
sending various control commands to the FPGA (low rate).

Now the FPGA will have some kind of state-machine that reads data from the
FTDI. It needs to decide if this 'data' is for streaming, or if it's a
command to write to a register. I thought of building and sending a fixed
'packet', that always contain say 32 kBytes of streaming data, and 8kBytes
of control, or some variant of this.

Now my concern is that there is no synchronization between the FPGA state
machine and the FT2232H FIFO. If something goes wrong, the FPGA could start
mixing the data.

I'm used to I2C, or SPI, where there is either a CLATCH event, or a START
condition, that marks the beginning of a new transfer. Here, there is none
of this.

Any idea?

Diego



---------------------------------------
This message was sent using the comp.arch.embedded web interface on
http://www.EmbeddedRelated.com
From: Vladimir Vassilevsky on 27 Nov 2009 10:28


dlopez wrote:
> Hi,
> I'm having trouble figuring out how to architect a robust system using the
> FTDI chips in FIFO mode. I'm pretty sure some of you have been through this
> before.
> I'm using the FT2232H in synchronous FIFO, but my concerns are general.
>
> The system has PC <-> FT2232H <-> FPGA, and is used to both stream/receive
> data between the PC and the FPGA.
>
> I'm wanting to stream continuous data at about 1MB/s each way, WHILE also
> sending various control commands to the FPGA (low rate).
>
> Now the FPGA will have some kind of state-machine that reads data from the
> FTDI. It needs to decide if this 'data' is for streaming, or if it's a
> command to write to a register. I thought of building and sending a fixed
> 'packet', that always contain say 32 kBytes of streaming data, and 8kBytes
> of control, or some variant of this.
>
> Now my concern is that there is no synchronization between the FPGA state
> machine and the FT2232H FIFO. If something goes wrong, the FPGA could start
> mixing the data.
>
> I'm used to I2C, or SPI, where there is either a CLATCH event, or a START
> condition, that marks the beginning of a new transfer. Here, there is none
> of this.
>
> Any idea?

There are three simple solutions:

0. Do it like Hayes modems. Data mode, Command mode, "+++" and such.

1. Byte stuffing.
Reserve a byte (like 0x00, 0xFF or 0x55) as "Escape" character, so the
next byte will be interpreted as a "command".

2. Packetization. Packet, length, checksum, timeout. The receiver
automatically synchronizes to the packet structure.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

From: dlopez on 27 Nov 2009 11:21
>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?



---------------------------------------
This message was sent using the comp.arch.embedded web interface on
http://www.EmbeddedRelated.com
From: Mel on 27 Nov 2009 11:42
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?

You have to escape the escape character. If one of the commands, for
instance 0x55 0x01, meant start-of-message, then another one like 0x55 0x05
would mean "stuff a 0x55 into the incoming data buffer." The transmitter
would have examine its data stream, replacing any 0x55 data bytes by the
appropriate command.

Mel.


From: Tim Wescott on 27 Nov 2009 12:07
On Fri, 27 Nov 2009 11:42:45 -0500, Mel wrote:

> 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?
>
> You have to escape the escape character. If one of the commands, for
> instance 0x55 0x01, meant start-of-message, then another one like 0x55
> 0x05 would mean "stuff a 0x55 into the incoming data buffer." The
> transmitter would have examine its data stream, replacing any 0x55 data
> bytes by the appropriate command.
>
> Mel.

Except that usually an escaped escape character is just the escape
character repeated -- i.e. <ESC><ESC> means "Put one escape character in
my byte stream".

If your data can be _truely_ random this opens up the possibility for the
pathological case where you have a chuck of data that's rich in escape
characters that suddenly bogs down your transmission. The longer I stay
in this business the more the phrase "that's really unlikely" translates
in my head to "that'll get missed by testing and caught by some important
customer right before my big vacation".

--
www.wescottdesign.com
 |  Next  |  Last
Pages: 1 2 3 4
Prev: Analog to Digital conversion using 18F452
Next: flash memory write endurance