NewSoftSerial 9: Direct Port I/O

The latest version of NewSoftSerial is available. This new release employs direct port I/O and is tuned for the best-ever performance at both 8 and 16 MHz on Arduino 0015.

You can read about it here.

I'm curious about what interests people for future NewSoftSerial releases. What are you most interested in?

  • Arduino Mega support
  • Signal inversion option
  • RTS/CTS flow control option
  • Configurability, i.e. E,7, 1 style parity, data and stopbit configuration.

Mikal

Arduino Mega support With four hardware serial ports why bother unless it's a trivial change/addition. Signal inversion option Sure, why not, shouldn't be hard to implement RTS/CTS flow control option This would be cool and useful for RS-485/422 interfaces where you need a output control to turn the driver/receiver chip around.Configurability, i.e. E,7, 1 style parity, data and stopbit configuration. Would make it a more complete libary.

Thanks for your contiuned work and development on this libary.

Lefty

Compiles on Linux with avr-gcc 4.3.3 as well :-)

Most interested in serial receive software interrupts. Wait for either a certain number of characters, a specific byte or sequence of bytes, or a certain amount of delay after a character. This would make it very easy to speak many protocols such as MODBUS. It would useful for any packetized serial communcation, really. And it would eliminate the need to continually poll the buffer to see if anything has been received yet.

macegr--

The facility you describe is an interesting one, and one that I would benefit from with my own TinyGPS library. NewSoftSerial and TinyGPS work pretty well together now, but the user still has to regularly poll the serial port and then send whatever characters show up to the TinyGPS object for processing. I've sometimes thought that it would be cool to be able to hook the two objects directly together, telling NewSoftSerial, in effect, look, when a byte arrives, don't stuff it in the RX buffer. Instead, just automatically send it (or several) to a "byte consumer" for processing.

The problem is that this opens up the potential for having interrupt handlers that are so long that the system mysteriously fails. Software serial RX interrupts are already very long by most standards. It certainly wouldn't be hard to implement a facility like the one you describe, but I fear the support issues that arose would be insurmountable. Or perhaps you have a vision that I don't see?

Mikal

I don't have a solution for the problem of overly-long interrupt handlers, but I wanted to suggest basing any such API on the Processing Serial library: http://processing.org/reference/libraries/serial/index.html