I'd like to see an official option for enabling RTS/CTS flow control on Serial objects. Right now I'm enabling it on an LPC11U35 with the following code:

//Enable hardware flow control using RTS/CTS
LPC_IOCON->PIO0_17 = 0x00000001;    //PIO0_17 = RTS
LPC_IOCON->PIO0_7 = 0x00000001;     //PIO0_7 = CTS
LPC_USART->MCR |= (1 << 6);         //Auto-RTS enabled
LPC_USART->MCR |= (1 << 7);         //Auto-CTS enabled

I think that's all there is to it, and I can confirm that Auto-CTS is working at least... I'm unable to test Auto-RTS due to the way my board is set up.

Hi Neil,

Seems like a good idea - I think we're seeing the same requirements for the BLE modules.

Any proposals on the requirements for the API? I presume it is simply specifying the additional pins (and implicitly or explicitly the fact you want flow control) - any other requirements/methods?

I think the Serial APIs should have better official support for buffering too.

Simon

Merging MODSERIAL into the official Serial lib would be great. Optionally adding flow control on the buffers using either RTS/CTS or even XON/OFF would be the perfect solution. However, maybe the libs should be kept separate somehow. A small footprint is important with the latest mbed enabled devices. It is allready a challenge to use the mbed libs on the lpc812 since it has only a few K of memory.

I also agree the default Serial should have buffering. Maybe MODSERIAL is a bit overkill, it has more options than you would normally need, but some kind of non-blocking library would be good to have. For memory footprint you could I guess either make it a seperate library, or put some ifdef into the class, where the larger devices have it by default enabled, and smaller ones the user can manually enable it if he wants. Although that also has some downsides.

When thinking anyway about stuff you could add to Serial, how about a parity/frame error callback thingie?

Something else I wonder, how is mbed planning to handle changes to the C++ API which would also require changes to the C APIs? Especially ports made by 3rd parties, if they are slow with changing it, or just simply not interested anymore in making the required changes. Remove those ports from the mbed library and tell people (+ the compiler if applicable) to use an older revision?

I also had a need for a buffered serial class, and will need flow control in future, which i plan to add.

I had a look at MODSERIAL but found it also too big for my project, this is why I decided to create a small class that works with or without rtos, and that is hardware independent and based on Serial/API class only. Have a look.

https://mbed.org/teams/ublox/code/C027_Support/ https://mbed.org/teams/ublox/code/C027_Support/file/b084552b03fe/SerialPipe.cpp https://mbed.org/teams/ublox/code/C027_Support/file/b084552b03fe/SerialPipe.h https://mbed.org/teams/ublox/code/C027_Support/file/b084552b03fe/Pipe.h

Maybe this class could be used. it would be nice to see this functionality in the standard api.

Hmm... The easiest way to do it would probably be to add the extra PinNames to the constructor, but default them to NC. That would maintain compatibility with older projects. An extra Serial::flow_control() method would also be nice, it could take an enum to select Disabled, Hardware, or Software flow control.