Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.
my issue is generally a usart has a max 8 bit transmitter register but i want to increase it till 16/32 bit . how will it effect the throughput and latency???
throughput would remain pretty much the same since that depends on the clock speed, but latency would increase while you assemble the larger number of bits to start with. Of course if you are using a parallel load (which is true in most cases), then even latency would only increase by a small fraction for an 8-bit bus, but would be the same if the bus/ memory access was the same width as the usart length.
HOWEVER, for a "normal" usart system, and especially where you are using ASync transmission, the number of Start/ Stop + parity bits PER data bit is LARGER for an 8-bit usart Vs a 16/ 32 bit.
Hence for a 16/32 bit system, the data throughput will ALSO increase
thanks for the previous post .. i wanted to ask you why we have only parity check in usual USART?? and what if error on two parity occurs??
- - - Updated - - -
and i wish to increase the data register length from conventional 8 bit USART to 16 or 32?? is it possible and what are the complication associated with it ???
SIngle parity bit is enough to improve the average BER to some extent, but as you said, not for all cases. Usually there are higher-layer protocols also involved in any communication system which take care of further errors. Putting in a more complex error checking/ correcting system for EVERY 8/16 bits would reduce the throughput considerably. And since (usually) the errors are not THAT common at link layer, it would be an overkill.
As always, there are trade-offs, and which method is used depends to a large extent on what type of system you are designing. Thus (for example) for a high-speed satellite link where the link turn-around time is large, it is worthwhile to have many more bits of redundancy built in, and which include Forward Error Correction (FEC) capability. However to do the same for a simple Rs-422/ 232 asynch link working at lower speeds is not really worthwhile.
Lastly - i see no particular benefit to increasing the USART bit length. Where exactly do you want to use this for ?
i have to make a USART compatible with a proceesor having 16/32 bit data bus . thus i was thinking to increase its bit length as the bus wont be transferring less then 16 bit as a time so why not increase it . whats your view on this?? pls comment ....
My view is simple -- if your system is a 'closed' system, i.e. it sends data only to a similar 16bit system made by you, then go ahead and do whatever you want.
BUT if you need to send/ receive data from devices NOT made by you, i.e. general Usart interface, then you have to stick with 7,8 data bits for compatibility reasons.
The receiver has to already "know" what speed the transmitter is working at, and generate its OWN clock to be almost exactly the same, within maybe +/- 3% or better preferably. Then using this clock, the receiver synchronises to a known START transition of incoming data, and simply sample the receive line exactly N number of times with a gap of 1 bit period. The sample is taken as close to the middle of the (supposed) receive stream's bit boundaries.
So for a typical Async 8 bit data with 1 Start bit, 1-parity, 1-stop bit, the receiver looks for a Hi-Low transition (beginning of START bit). Then waits for 1.5 bit period. Samples the input. Waits for 1.0 bit period. Samples. Keeps doing this 9 times (8 data + 1 parity).
thanks for the above post. another thing i wanted to ask that can USART support transmit to device and reception from another device in case of full duplex mode ??? and that too at different baud rate.....
Thats a very very strange & unusual requirement.
But hey... since YOU are designing the usart, then you can always design it to have different bauds for Tx & Rx. Why not ?
It's got nothing to do with FDX or HDX or whatever mode.... you want to make such a beastie, then go right ahead.
It's the upper layer software which will have to take care of all the issues which arise, and to use such a device meaningfully.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
