UART API Question

DavidZemon

I've designed a configurable UART module in C++ (the language doesn't matter for this question though) and have now run into a question with no right answer. One of the configurable options is data width which can be anywhere from 1-16 bits with my current code - typical UART values are 5-9 bits and I want to keep at least that much flexibility. I use a 16-bit variable for data, which is no problem when you're just sending a single data word. However, I am now about to add functionality to send an array of data words, at which point data type size matters a lot. Of course, the most common data width is 8-bits - the width of a char (character). To allow the user to (easily) send a string, the function must accept an array of 8-bit variables NOT 16-bit variables. But that means the method will not work for all data widths allowed by the module. The choices that I can come up with are:

• Create a single method such as send_array(uint8_t *array) and document that this method will not work for data-widths greater than 8-bits. Provide no alternative to users requiring more than 8-bits
• Create two methods such as send_array(uint8_t *array) and send_wide_array(uint16_t *array). Highly functional but... a little "smelly" to me
• Create a single method send_array(uint16_t *array) and provide no good alternative for users that want to send out a string of text

I'd love to hear anyone's comments on this. If you like one of the above suggestions or have a new suggestion or just want to think out loud, please do.

Also - shameless plug - this module is part of PropWare, linked to in my signature. At the time of writing it is only in the release-2.0-nightly branch.

David

Duane Degn

I know it's common to have 16-bits sent via SPI but I don't think I've come across an asynchronous serial protocol using a 16-bit data size.

I've just recently been working on a Modbus project and even though Modbus uses 16-bit registers, the data is sent byte by byte. Is there a device other than a Propeller running your 16-bit data code that will be able to take advantage of these extra bits?

Just yesterday with the help of Tracy Allen I modified his serial driver to use even parity. I think adding the ability to use parity would be something useful for your driver but I'm not sure when a 16-bit driver would ever be used?

DavidZemon

Duane Degn wrote: »

I know it's common to have 16-bits sent via SPI but I don't think I've come across an asynchronous serial protocol using a 16-bit data size.

I've just recently been working on a Modbus project and even though Modbus uses 16-bit registers, the data is sent byte by byte. Is there a device other than a Propeller running your 16-bit data code that will be able to take advantage of these extra bits?

Just yesterday with the help of Tracy Allen I modified his serial driver to use even parity. I think adding the ability to use parity would be something useful for your driver but I'm not sure when a 16-bit driver would ever be used?

It actually already does odd, even, or no parity, any number of stop bits, and any baud up to 122,000. I want to get the max baud up higher but haven't yet looked at where the bottleneck is. I think it's on the receive side (so a receive_array() function would probably help).

DavidZemon

I don't know of any device using more than 8 bits, but I wanted the possibilities to be open. For anyone doing Prop-to-Prop communication, a 16-bit protocol might be helpful. More than anything though, I just wanted to conform to the standards that wikipedia lists:

Wikipedia wrote:

Each character is sent as a logic low start bit, a configurable number of data bits (usually 8, but users can choose 5 to 8 or 9 bits depending on which UART is in use), an optional parity bit if the number of bits per character chosen is not 9 bits, and one or more logic high stop bits.

Duane Degn

SwimDude0614 wrote: »

I don't know of any device using more than 8 bits, but I wanted the possibilities to be open. For anyone doing Prop-to-Prop communication, a 16-bit protocol might be helpful. More than anything though, I just wanted to conform to the standards that wikipedia lists:

I'm not sure how useful a 16-bit communication line would be. Often the limiting factor with serial communication on the Propeller is how fast the Propeller can move the bytes around internally. The actually sending of bits isn't the bottleneck. Still, I can see how it could be useful if you had a lot of 16-bit data to send and receive.

Mike Green

There are a few devices that use 8 data bits plus a parity bit for a total of 9 bits (plus the start and stop bits). You don't need to support any more bits than that unless it's easier to support up to 16 bits if you support more than 8 data bits or more than 7 data bits plus parity.

DavidZemon

Parity is taken into account after the fact, so you can still have 16 data bits plus a parity. from my docs:

Detailed Description
Abstract base class for all UART devices.
Configurable with the following options:

• Data width: 1-16 bits
• Parity: No parity, odd parity, even parity
• Stop bits: Any number of stop bits between 1 and 14

Note Total number of bits within start, data, parity, and stop cannot exceed 32. For instance, a configuration of 16 data bits, even or odd parity, and 2 stop bits would be 1 + 16 + 1 + 2 = 20 (this is allowed). A configuration of 30 data bits, no parity, and 2 stop bits would be 1 + 30 + 2 = 33 (not allowed).

I take it from your comments (Mike and Duane) then, you are in favor of a single function send_array(uint8_t *array)? (i think this question is actually rhetorical lol)

ericpine

8 bit all day. I've never found an application or device that was higher than 8bit or lower than 7 bit. I suppose you could build a proprietary com setting here eh? : )

kwinn

ericpine wrote: »

8 bit all day. I've never found an application or device that was higher than 8bit or lower than 7 bit. I suppose you could build a proprietary com setting here eh? : )

Eric is right. The standard is 8 bits. In the past there were protocols that used anywhere from 5 to 8 and occasionally 9 data bits, but that is rare if it exists at all. One of the reasons a 16 bit protocol is not used is the synchronization problem. The start and stop bits guarantee that there will be no more than 8 (or is it 9?) bit times between a transition for the receiver to synchronize on. With 16 bit data the number of bit times between transitions could be twice as long. This is not usually a problem within a board or module but for long transmission distances it may lead to a lot of errors. Better to split the word into 2 byte transmissions.