32 bit uart

Possibly, once you match the send and receive clocks to about 1/4 percent. It will probably be necessary to also use 2 stop bits.

32 bits per item is a very unusual number. At least add a 33rd bit for parity error checking, or more for some ECC coding. You will probably be better off sticking with 8 bits and developing some sort of protocol over a normal serial line.

I.e. think about the requirements before doing the coding.

--
 Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.

Homework / study project?

Do you mean that the characters sent between start and stop bits are 32 bits long?

--

Tauno Voipio
tauno voipio (at) iki fi

Is this a problem ?

For instance the SMC ports on any QUICC I/O coprocessor as used on the MC68360, MPC960 etc. will support up to 16 bit characters, so the net character size could be 12-14 bits, depending on if parity is used and if one or two stop bits are used.

With long data word lengths, the baud rate generator accuracy becomes critical.

However, with very long word lengths, it might make sense to move to synchronous transfer and let the message preamble synchronize the baud rate PLL.

Paul

data is 32 bit long,excluding start,parity& 2 stop bits.

You can't use a standard rs232 type UART for this. You would either have to transmit the data in chunks of 8 bits each, or you would have to switch to a custom signalling scheme. One method would be to complement each bit with its inverse, so that a valid bit clock can be recovered at the receiver. Another method is convolutional coding, which has the additional benefit of (limited) error correction capabilities.

Marc

That's probably why he's implementing his own using an FPGA. I would think that modifying the VHDL for an 8-bit UART to make it handle 32-bits wouldn't be that hard.

--
Grant Edwards                   grante             Yow! FROZEN ENTREES may
                                  at               be flung by members of
                               visi.com            opposing SWANSON SECTS ...

The main problem would be in receiving: It is harder to stay in sync with the transmitter if there are four time as many bits between the sync points.

I made such a thing in software about

25 years ago: An old Rohde & Schwarz VHF direction finder sent the results in 35 bit async frames. It proved to be necessary to re-synchronise the sampling point from all transitions to keep in sync.

--

Tauno Voipio
tauno voipio (at) iki fi

Then add a bit-stuffing algorithm to make sure there's a transition or three in every word, and Bob's your uncle. ;) IIRC, even the 8-bit UARTs built into Motorola's 68HC11 series used to resync on all falling edges, but I don't think I ever used baud rate clocks that were bad enough that it mattered.

--
Grant Edwards                   grante             Yow! Here I am in the
                                  at               POSTERIOR OLFACTORY LOBULE
                               visi.com            but I don't see CARL SAGAN
                                                   anywhere!!

As the CAE perpetual novice, I have to ask why are you trying to emulate a uart, for the system, why not try another method of encoding, say biphase mark, where you can have at least 10% timing errors with no ill effect. Ok it will probably increase the bandwidth of the transmission medium by 2. Would this be a problem?

Martin

This will tighten your clock tolerance, to probably exclude ceramic resonators, but crystals will be OK.

Is this some existing product ? - 9600bd and 32 bits is an unusual pairing. I can see merit in longer data blocks, as you know it is then atomic. (even if non-std)

What stops you simply editing std 8 bit UART VHDL code ? That's a fairly safe edit. Start with an 8 bit one, and do the full build/simulate, to have a known reference, and then just widen it ?

-jg

The longer data word only requires a four times better frequency match between the transmitting and receiving bit rate generators (compared to 8 bit UARTs), since you need to keep the receiver sampling point close to the center of each data bit also at the end of the transmitted word. This should not be a big problem with proper crystal oscillators, at least if both equipment are in the same temperature.

Detecting the start bit reliably and accurately is as hard for 32 as well as 5 bit data words.

Most likely the software implementation caused these problems. Even if you could get the exact number of instruction execution times between the sampling points e.g. using busy loops, you still would have to account for interrupts, different cache hits etc.

After all using an on-chip CPU clock oscillator is going to cause frequency drift due to varying CPU temperature, caused by varying processing loads.

Of course, if the transmitting bit rate was fluctuating, then there is not much to be done than searching for transitions to update the receiver bit rate frequency.

Paul