serial usart adding rts/cts flow control to libmaple

LeafLabs Garden » Development

serial usart adding rts/cts flow control to libmaple

(7 posts) (4 voices)

Started 3 years ago by cleemesser
Latest reply from ethanb

cleemesser
Member

Hello, I want to thank you for creating the Maple. I've been learning a lot with my RET6.

I've been working on different ways to stream data to and from the maple. One method I've been looking at is the USARTs. I've been testing them at 2Mb/s with both the FT232RL and FT2232H USB-to-serial solutions. The good news is that it seems to work well and in my tests I get around 180KB/s pretty consistently. I had noticed that intermittently I'm getting errors with the FT232RL approaches. I haven't ever seen it happen with the FT2232H but my sample is limited to a few runs with the longest being about 5 hours. I'm not certain what the cause is because the mean failure time is around every 90 million bytes transferred with a wide variation.

Anyway, I'm not seeking to debug the problem in this post (another day), but to motivate why I thought to add hardware flow control. I have taken a stab at it and done some basic tests with it working when specialized to USART3.

Now I am asking for some help with a few questions:

1. I noticed that the HardwareSerial classes in wirish have private members, which seems to make it difficult to subclass them. Is this truly what is desired? Would using the protected attribute make more sense? I ended up creating HardwareSerialFlowControl as a subclass of Print because of this and duplicated a lot of the code in HardwareSerial.

Alternatively, the functionality could be added directly to HardwareSerial

2. In order to enable the rts/cts for the different USARTs I need something that allows the code to select the correct register bits. Right now, I use the "backdoor" to usart_dev in my main.cpp code to activate USART3 on the maple or maple-ret6. The HardwareSerial class relies upon usart_enable(this->usart_device) so should this go in libmaple proper in order to do the right thing.

3. Is there any easy way to allow the user to reference the correct pins for cts and rts for a given board and USART number. I notice that you use macros and the PIN_MAP to do this in HardwareSerial.cpp

I've forked libmaple on github and added my work-in-progress files:

https://github.com/cleemesser/libmaple/blob/master/wirish/include/wirish/HardwareSerialFlowControl.h
https://github.com/cleemesser/libmaple/blob/master/wirish/HardwareSerialFlowControl.cpp

In case someone wants to look at them.
Thanks again
-Chris

Posted 3 years ago #
feurig
Member

Nice! Hopefully mbolivar or one of the close to the core people will look at it.

Posted 3 years ago #
mbolivar
LeafLabs
Interesting stuff; thanks for posting.

Since you've got a Maple RET6 ed.., you'll likely want to commit any changes to libmaple proper into the libmaple/stm32f1 USART files. For portability, please only put patches into the top-level libmaple/usart.c and libmaple/include/libmaple/usart.h files if you've tested them on STM32F2.

I noticed that the HardwareSerial classes in wirish have private members, which seems to make it difficult to subclass them. Is this truly what is desired? Would using the protected attribute make more sense?

In the current libmaple master, you can get your hands on all the private members with inline accessor functions, so there should be no performance or usability problems with subclassing.

3. Is there any easy way to allow the user to reference the correct pins for cts and rts for a given board and USART number. I notice that you use macros and the PIN_MAP to do this in HardwareSerial.cpp

The corresponding macros for hardware flow control pins (these would be named something like BOARD_USART1_CTS_PIN and BOARD_USART1_RTS_PIN) are currently missing from the board headers (under wirish/boards). I'd take patches that added them.

Alternatively, the functionality could be added directly to HardwareSerial

That's reasonable. I'd review any such patches.

Note that some boards don't break out some flow control pins (e.g. Maple doesn't break out USART1 CTS/RTS). For these, you'd need some sort of feature-test macro. This would be along the lines of BOARD_HAVE_USART1 (see wirish/include/wirish/boards.h), except it'd need a name like BOARD_HAVE_USART1_FLOW_CTRL (although a better name would be nice ;)).

One implementation (feel free to go about it this way or any other way that seems more reasonable to you) would add a HardwareSerial constructor that passed cts_pin and rts_pin arguments. For backwards compatibility, the existing constructor would set them to invalid values[1] that HardwareSerial::begin() would check for. Then HardwareSerial.cpp could define the SerialN based on the feature test macros. The result would look something like this:
```
#ifndef BOARD_HAVE_USART1_FLOW_CTRL
#define BOARD_USART1_CTS_PIN NOT_A_PIN
#define BOARD_USART1_RTS_PIN NOT_A_PIN
#endif

// ... etc for the other USARTs

#define DEFINE_HWSERIAL(name, n)                                   \
    HardwareSerial name(USART##n,                                  \
                        BOARD_USART##n##_TX_PIN,                   \
                        BOARD_USART##n##_RX_PIN,                   \
                        BOARD_USART##n##_CTS_PIN,                  \
                        BOARD_USART##n##_RTS_PIN)
```
I think the default behavior should ignore flow control pins, for simplicity and backwards compatibility. Perhaps you could add a HardwareSerial::beginFlowControl() method (name suggestions?) that configures the pins properly and turns on flow control checking. Or you could add a boolean argument to HardwareSerial::begin() that turned on flow control, and set it to false by default. Other proposals?

[1] We need a standard NOT_A_PIN value and a pin_t type to make this easier, I think. (Wiring has already accepted this proposal.)
Posted 3 years ago #
cleemesser
Member

Thanks.

I've done the easy part: I've added the pin information for the ret6 and the maple board definitions. (See attached patch. I might be able to figure out how to do as a pull request if you would prefer.)
It should work with the above macro. I haven't added the NOT_A_PIN or #ifndef yet. My testing has started to catch up with my transition to the command line tools and I now have a pure-command line version of my test code. I used the template from your (mbolivar's) example-libmaple-project git repo). I can put that on github too if anyone is interested.

diff --git a/wirish/boards/maple/include/board/board.h b/wirish/boards/maple/include/board/board.h index e675806..09e6a53 100644 --- a/wirish/boards/maple/include/board/board.h +++ b/wirish/boards/maple/include/board/board.h @@ -48,11 +48,19 @@ /* USART pin numbers. */ #define BOARD_USART1_TX_PIN 7 #define BOARD_USART1_RX_PIN 8 +#define BOARD_USART1_CK_PIN 6 + #define BOARD_USART2_TX_PIN 1 #define BOARD_USART2_RX_PIN 0 +#define BOARD_USART2_CK_PIN 10 +#define BOARD_USART2_CTS_PIN 2 +#define BOARD_USART2_RTS_PIN 3 + #define BOARD_USART3_TX_PIN 29 #define BOARD_USART3_RX_PIN 30 - +#define BOARD_USART3_CK_PIN 31 +#define BOARD_USART3_CTS_PIN 32 +#define BOARD_USART3_RTS_PIN 33 /* Number of SPI ports broken out to headers. */ #define BOARD_NR_SPI 2 diff --git a/wirish/boards/maple_RET6/include/board/board.h b/wirish/boards/maple_RET6/include/board/board.h index 7c6851b..d51b61d 100644 --- a/wirish/boards/maple_RET6/include/board/board.h +++ b/wirish/boards/maple_RET6/include/board/board.h @@ -46,10 +46,19 @@ #define BOARD_NR_USARTS 3 #define BOARD_USART1_TX_PIN 7 #define BOARD_USART1_RX_PIN 8 +#define BOARD_USART1_CK_PIN 6 + #define BOARD_USART2_TX_PIN 1 #define BOARD_USART2_RX_PIN 0 +#define BOARD_USART2_CK_PIN 10 +#define BOARD_USART2_CTS_PIN 2 +#define BOARD_USART2_RTS_PIN 3 + #define BOARD_USART3_TX_PIN 29 #define BOARD_USART3_RX_PIN 30 +#define BOARD_USART3_CK_PIN 31 +#define BOARD_USART3_CTS_PIN 32 +#define BOARD_USART3_RTS_PIN 33
/* Note: *

Posted 3 years ago #
mbolivar
LeafLabs

(See attached patch. I might be able to figure out how to do as a pull request if you would prefer.)

A forum post is enough for small patches like these. Thanks!

Any chance you could add them for Maple Mini and Maple Native? That would save me some work.

Please note that we do need signed-off commits when merging more significant patches (such as adding new features like USART flow control) into libmaple. The libmaple contributing doc has all the details, but basically, you'll need to include a line in the commit log message that says:

Signed-off-by: Your Real Name <your.email@example.com>

Posted 3 years ago #
cleemesser
Member

I'll add in the others #defines the next time I have a chance to sit down. It strikes me that the beginFlowControl() might be the most pleasant approach.

By the way, I don't have an F2 board, but I do have the F4Discovery which is very nice. I wonder if anyone could convince STM to opensource their design. Does the maple 2 have an ETA?

Posted 3 years ago #
ethanb
Member

Hello!
I was able to find some RTS/CTS definitions in a header file, but I didn't find any code for initializing hardware flow control.
Did any of the implementation get checked in? Are we flow-control capable?

Posted 3 years ago #

RSS feed for this topic

Reply

You must log in to post.