Adding features to serial driver what would you guys like?

Kye

Hey guys, I'm thinking about adding a bunch of featues to my serial driver but I'm not sure what would be useful.

I'm making the driver primarily for an RS-232 enviorment so what would you guys think would be needed?

Should I build an interface for the RI, CD, DTR, DSR lines???

Hardware flow control? (RTS and CTS lines)

Software flow control? (Xon and Xoff)

Parity Bit? (Mark, Space, Even, Odd, None)

---

Selectable Stop bit? (1 or 2 bits long?)

Less data bits? (7 or 8)

---

The last two options seem·like they are only for legacy devices so unless anyone knows why I should add them I most likely won't.

So, what would you guys like? I'm trying to make the driver able to interface with as much stuff as possible, but I don't really know what parts are really used anymore. I would like to not add unused code.

Thanks,



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Mike Green

7 data bits is needed if you're using a parity bit since the parity bit is not included in the 7 bits. 2 stop bits is useful when there's a marginal synchronization problem. The extra stop bit allows some slop for the receiver to get ready for the start bit.

There's already a nice version of a serial driver for 4 ports using one cog. It includes optional flow control support with RTS and CTS and you might copy that as much as is reasonable. If you want good RS232 compatibility, you should at least have optional DTR and DSR support with the user able to turn DTR on and off and test DSR. I'm assuming that your driver will be the terminal. Some old devices still use Xon/Xoff, but this could be handled by the user of your driver. You need to be clear what sort of devices you're going to support. If you want to provide a "full service" RS232 driver, you'll need to optionally pass on RI and CD status along with all the other stuff. Most people won't need these features, so they shouldn't take away from other capabilities. For example, the 4 port driver gets configured for the number of ports needed and its maximum speed depends on how many ports are to be used and whether the handshake lines are to be enabled.

Rayman

I think I recall having to add my own "checkRX" function to see if there was something in the RX buffer without actually changing the buffer contents...

Also, I made the "extended" version buffer even bigger for one app...

Kye

Well, I wonder if I can use a null modem approach? Keeping things in the software would be nice. Using loop back etc.

Okay, then. I'll implement the software features for now.

Should they be automatic or user controlled? Like Xon and Xoff?

And mike, can you be more clear on what 7 bits are useful for?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

virtuPIC

Well, I would like some hardware-independt software feature: something like ungetc in C. This function would push a character on the receiver queue that it will be read next.

I frequently need this for lookahead in analysis of received data. Would be nice to have it in the driver instead of patching it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Airspace V - international hangar flying!
www.airspace-v.com/ggadgets for tools & toys

dMajo

Kye,
In the industrial field there are many sensors (laser distance meters, IR temperature meters ...) that send their values ascii coded on 7 bits.

One nice feature could be if, when configured for rs485, the driver remain in listening mode switching the transmitter on with DTR when needed (during transmission) automatically

Kye

virtualPIC, my driver already has that feature. It allows you to check the last received byte with another value to see if its in the receive buffer without removing it. My driver also allows you to remove the last received byte from the receiver buffer (i.e. receive it) and to check the number of bytes in the receiver buffer.

Also, I'll be including my function library with all my drivers from no one so you can send decimal numbers and do string conversion etc.

Okay, so I'm getting that the driver should be able to have all the software configuration options.

Do these need to be able to be changed in run time or can they be constants??? What would you guys prefer?

I'll get to adding support for hardware lines later.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

dMajo

For the 232/485 option it can be run time configurable because you can install in parallel also the 485 line drivers and let the final user (of your equipment) choose the type of communication let say through a menu option (on lcd display for example)
The Start/Stop/Parity bits are transparent to the software (I mean to the in/out buffers) if made at the driver level/layer so they should be runtime configurable for the same reason as above. The same for Xon/Xoff if managed at the driver level and transparent (not included) in the exchange buffers.

For the handshake I think it can be constant since if you have wasted your io's for the rts/cts,dtr/dsr lines in case of 3wire coms you can bridge them on the connector or use a null-modem cable. For the 7/8bits I think that this depends from the protocol that will be developed in the "main" prog, probably it will be one, and so I think it can be constant too.

virtuPIC

Sorry Kye, there was no offense meant! All drivers I've found so far didn't have the 'ungetc' feature. Great that you provide it!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Airspace V - international hangar flying!
www.airspace-v.com/ggadgets for tools & toys

Kye

Well, the idea is to give a developer interface for anyone wanting to use my driver to be able to create drivers for equipment - i.e. the higher level driver.

So, I'll go with null modem built into the connector (the device will be the terminal) for right now.

I'll build in the xon and xoff to be automatic and include the ability to change the stop bits, and parity in the constants section of the driver. This will leave it more functional for now and to have a system set in place to make the fields run time configurable.

Since the driver uses 256 byte FIFO buffers I doubt that it will ever be the device sending Xoff/ or Xon but receiveing them. So I'll make the feature built in to be permanet. Since it will mostlikely not be used unless needed.

I'll not be adding an rs-485 option. If the standards are compatible then the user can get a converter. I plan on giving the user the ability to fully configure the driver, later however.

Thanks guys.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

dMajo

Kye said...

I'll not be adding an rs-485 option. If the standards are compatible then the user can get a converter. I plan on giving the user the ability to fully configure the driver, later however.

The rs485 is difficult to add to back in how much the external converters to apply on rs232 uses dtr/rts (usually selectable by dipsw/jumpers) signal to switch from reception to transmission and you need to have them in sync with rx/tx signals.

Kye

For a converter I mean like some rs232 to rs485 cable or converter box...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

dMajo

Kye said...
For a converter I mean like some rs232 to rs485 cable or converter box...

I have perfectly understood. What I was trying to explain you was that since the rs485 is a differential half-duplex communication you need a signal to switch the drivers in the (external, cable) converter from receive to send mode. Usually this is done with one of DTR/RTS signals. In order to do that you need to manipulate this signal (on the rs232 side) in sync with tx signal. (eg. listen, toggle DTR, send, toggle DTR, listen ...). Now, to do that manually you need to look at the sending buffer (an immediate·toggle of DTR·after the send command may switch off the transmitter while the uart·is still sending buffered data).

Mainly in the 485 mode the dtr should act as a kind of send buffer empty signal to switch the line drivers (hardware) between receive/transmit modes.

Kye

Ah, okay. Well then there would be now way of getting arround that problem without making support for dtr and rts.

I guess I'll need to include full support for those wires then.

But that will be a problem on the board I want to make as I don't have space for anything but the rx and tx lines... err...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Kye

Mmm, well I'm actually gonna start doing this now.

However, after looking at implementing software flow control I realize that you would need an excape sequence to make sure xon and xoff are not triggered....

So, I won't add that feature since it seem like it should be in the program using the serial driver.

As adding support for everything but the rx and tx lines. I can make a seperate driver for you guys in you really want it, right now I'm not sure how I want to use the last I/O pins for my project. I'll submit another driver later with support for those pins if I decide to include them or if its really wanted.

I'll include, however, right now support for different parity bits, stop bits, and data bits. They will be constants in the code since I can't see why you would want to change them during run time.

By the way, thanks for the support. You guys really helped out.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

dMajo

Kye said...
Ah, okay. Well then there would be now way of getting arround that problem without making support for dtr and rts.

I guess I'll need to include full support for those wires then.

But that will be a problem on the board I want to make as I don't have space for anything but the rx and tx lines... err...

On Windows platforms (I have no experience on linux and others) it happens sometimes that even if you are using just a 3-wire communication (rx,tx,gnd) you need to bridge the RTS/CTS and DTR/DSR signals on the PC serial connector in order to have the serial port send and receive the data (it depends on how the Windows application handles the serial port).

You can do the same on your driver:
- you can have always the support for those handshake signals controling the send/receive operations (so your code managing the buffers will not change)
- if you assign those signals to a physical pin they will be available externally, otherwise you keep a virtual bridge between them internally in the driver (a kind of virtual loopback)

Kye

Okay, Well I've taken a close look over what I want to do and the final redesign of the driver will include these features.

Support for all serial pin I/O lines. This will eat up 8 I/O pins on the propeller chip but it will give the user a completely compatible uart interface. The driver will have automatic hardware flow control abilites and support for sending the xon/ and xoff characters in software (I'm just gonna include a method that transmits the xon or xoff character). The driver will pharse the state of the DCD, DSR, and RI Pins and provide a simple to true false method for acessing them within the spin interface. Also included will be the ability to raise or lower the DTR line at will.

As for constants, you will be able to set the baud rate of the serial driver when called, and in the constants section of the code you can change the number of stop bits (to as much as you want) and lower the number of data bits to as little as you want and the driver will behave accordingly.

I can make those features run time reconfigurable now, if you would like, but I'm not sure if I should as it would add a layer of complexity as they would need to be setup correctly first.

And, parity bit checking will not be included within the driver, however, I will include some methods that will check the status of the parity bit for you so you can do the comparison in spin (wait, how do I get the c bit with the and instruction in spin???) The reason for this is that data transfer to and from the main memory can only be a byte large. Since the driver wouldn't know what to do if the parity is worng I'll leave it for the controlling software to figure out.

Does this cover all your concenrs dMajo, would this be enough to be able to interface with rs485 from a serial port? Please let me know what else you would like.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Post Edited (Kye) : 2/9/2009 10:26:18 PM GMT

dMajo

Here you have some examples of 485 transceivers.

If you look at max3160/62 at page·24 you can figure out the 3100 block as your driver the uP as main spin runnin in an other cog and of course the hardware 232/485 transceiver giving the opportunity to support both the standards

Kye

Err, that's gonna be a problem as implementing a full rs232 interface will take pretty much all my I/O pins.

I'll try to get the driver on the object exchange soon.

Thanks, however.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

dMajo

Kye said...
Err, that's gonna be a problem as implementing a full rs232 interface will take pretty much all my I/O pins.

I'll try to get the driver on the object exchange soon.

Thanks, however.

I also hope that the signals would not be directly wired to the io. (I mean io wasted when not needed) You can take tv out hw as model (you can choose a pin group and mask the not used ones)

If you keep an internal copy of the dtr/dsr and rts/cts signals you can have them always working in the flow control (buffer management) so the code will not change.
If the user choose to use them then just copy internal rts/dtr state to the output pins and sample input pins to internal cts/dsr flags.
If the user decide not to use them then just copy internal rts/dtr state to your internal cts/dsr flags.
If you manage the right io position (like tv or vga out: you can chose a group but not exchange the position of the signals in the group) you can do this with masks and shifts very easily. Of course when choosing group four (? p24..p31) that have special function at boot-up that user may want to preserve at running time I will suggest you this sequence P0/8/16/24..P7/15/23/31_RTS,CTS,DTR,DSR,DCD,RI,TX,RX since interleaving the in and out signals is easy to do the loopback test just with shift by one. Second reason dcd and ri are used only on modems and masking them to preserve scl/sda P28/29 will not degrade the uart·on 95% of the application fields

Kye

Um you'll be able to put output on any pin and have the signals on any pin.

I'm also going to make it so that you simply can select like pin 32 to disable the output as the method for making the mask will produce on with zero ones if 32 is used.

All the hardware flow control will run automatically, and dtr and dsr will simply be in spin. The same for the RI and CD mask.

Thanks again.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,