Sending Serial data on UART ?

[digi001]

I am looking to send a serial data stream from an FPGA to a Computer over UART RS-232. The data represents a 32bit signed fixed point number with 28 fractional length.

1.) Do i only need TD and RD or should I also use hardware handshaking - CTS RTS?

2.) My word size is 32bit. So this will take 4 consecutive byte transmissions with a Start and Stop bit?

3.) What is the best way to assemble and parse this data? Should I send a packet of 5 bytes? With the first byte uniquely signifying a new packet?

 

[FvM]

1. The computer has inbut buffering and don't need handshake unless you send large amounts of data want to push data throughput to the limits.
2. Yes
3. You won't easily find an unique start character, because the binary data already covers all possible values. You can however specify, that transmission only starts after an idle period. If this isn't sufficient, you would need to recode the binary data.

 

[digi001]

Thanks!

Ok yes I see that since I am sending binary data and not something like ASCII characters I can't use a unique character. So maybe I will try the idle period like you suggest.

So If I am sending a new 32bit word every 1000Hz that would require 10bits*4bytes*1000=40,000 bits per second minumum.

But if I send these 40,000bits @ 115,000 baud rate then I would have roughly 2 times the needed time. So i could transmit an idle time of 10 clocks of 115,000 or 87uS in between each packet?

 

[digi001]

FvM: Does this seem like a reasonable way to do this communication?

---------- Post added at 09:20 ---------- Previous post was at 08:17 ----------

So +- RS-232 Voltage Levels can be +-5V +-10V or +-12V to a computer?

The dead-zone is from +-3V and as long as it goes beyond these it will register high or low?

 

[FvM]

I mentioned idle time as a principle option to achieve packet synchronization. If the receiver is a PC, you won't be able to detect small idle times reliably. It's not necessary however, to synchronize each data word, it should be sufficient if you can resume receiption after a transmission error at a known correct position e.g. one a second or so.

To match the RS232 physics, you'll need a RS232 level converter at the FPGA side, e.g. a MAX232. Many Dev Kits have it already on board.

 

[digi001]

To match the RS232 physics, you'll need a RS232 level converter at the FPGA side, e.g. a MAX232. Many Dev Kits have it already on board.

Yes I understand that the RS-232 is different from the 3.3V Serial Data coming out of the FPGA, but what I mean is, does it matter if the RS-232 level signals are 5V, 10V or 12V etc? If on the FPGA board my RS-232 Transceiver is running at 5V but on the Computer the RS-232 Transceiver is at 12V. This should be ok?

 

[bigdogguru]

...what I mean is, does it matter if the RS-232 level signals are 5V, 10V or 12V etc?

No.

If on the FPGA board my RS-232 Transceiver is running at 5V but on the Computer the RS-232 Transceiver is at 12V. This should be ok?

Yes. What you have described is a task of the RS-232 Transceiver.

Reference: **broken link removed**

Compatible Versus Compliant

To be compliant with the RS-232 specification, transmitters are required to provide a ±5V output signal level. For RS-232 receivers to be compliant, their thresholds must be ±3V maximum. Therefore, these devices operate with a healthy ±2V noise margin. Thus it is possible to erode a percentage of the margin and still maintain accurate data transmissions. Margins are reduced when transmitter output voltages span a narrower range. When transmitter outputs are a minimum of ±3.7V, they are considered to be compatible, instead of compliant RS-232 outputs. For example, if you power an RS-232 device that doesn't contain charge pumps (thus less expensive and smaller) with ±5V supplies, its output voltages cannot possibly reach ±5V. A device operated under these conditions with transmitter outputs of ±3.7V at minimum is said to be RS-232 compatible instead of compliant.

BigDog

 

[barry]

There are several ways to encode the start of new data. One method is to use a unique start/stop byte, say xFF. But now you can't have xFF in your data, so xFF is represented by TWO BYTES, say xFE, xFE. And xFE is represented by xFE, xFD. So, whenever you see two consecutive xFF's in your data stream, you know it's the start of a new block. Whenever you see xFE in your data, you know that the NEXT byte defines what the actual data is xFF or xFE.

I'm sure there's some name for this type of encoding, but I don't know what it is. You can call it Barry Encoding.

Barry

 

[digi001]

Barry>>Wow I wouldnt want to debug that. Ha but thanks.

 

[barry]

Barry>>Wow I wouldnt want to debug that. Ha but thanks.

It's not really that hard.

Personally, I'd use the handshake lines(or a software method) even with a low data rate. You can't be absolutely sure that the data was received properly; never trust a computer. Or a programmer.

 

[FvM]

I'm sure there's some name for this type of encoding, but I don't know what it is. You can call it Barry Encoding.

FE is usually named an escape character. Because it's an rather old problem of binary data transmission, this and similar solutions are used in a large number of binary protocols, e.g. X-/Y-/ZMODEM, 3964, S-BUS. Sometimes the mnemonic DLE (data link escape) is used for the special character.

A serious disadvantage of the simple ecape character scheme is, that it can double the data length at worst case.