[U(S)ART] request list

[fpistm]

This issue aims to list all U(S)ART requests:

• Hardware Flow control for serial communication (Hardware Flow control for serial communication #394) --> [U(S)ART] hardware flow control support #1634
• Support for UART RX/TX level inversion on F3/F7 platforms (Support for UART RX/TX level inversion on F3/F7 platforms #1160)
• HardwareSerial Error Callback( HardwareSerial Error Callback #1162)
• Support 9 Bit Mode ([U(S)ART] request list #1418 (comment))

Note

This is a community projects, Any contribution is welcome, so feel free submit a PR. 😉

[4ndreas]

I needed the 9 Bit Mode for a project and changed all the buffers to uint16_t and it worked. But I'm not sure if there are some side effects.
Could also solved with a flag for the 9th bit.

[fpistm]

Hi @4ndreas
THis was discussed some years ago:
#482 (comment)

Main risk is the compatibility issue. I've added the request to the list.

[matthijskooijman]

I have one more suggestion for the list: Support serial writes when interrupts are disabled (e.g. from an ISR). This would make debugging a lot easier, and prevent surprise when someone prints from an ISR and the entire board locks up as soon as the buffer is full.

To support this usecase, the busy-wait loops in flush() and write() must be modified to call the ISR (or other code that moves the buffer into the UART) whenever a bit is written.

I implemented something similar on the Arduino AVR core, where IIRC it checks if interrupts are disabled, and if so, checks the TXE bit inside the busywait loop and calls the ISR if it is set. A similar approach can be taken here, though there are some complications:

• There is not just a single "interrupts disabled" bit, AFAIU when another interrupt is running, the global interrupt mask is unchanged, but IRQ priorities might still prevent the TX interrupt from firing. To simplify things, I think the busy wait loops should simply disable the TXE/TXC (or whichever is used exactly) before the loop, and then inside the loop always call the ISR manually, even when interrupts were enabled already.
• There is some additional layering with the HAL, the stm32/uart.c and HardwareSerial that makes it a bit more tricky to get this right.

The second point makes this more complicated than I have time for right now, but I at least wanted to share this request and my thoughts.

[fpistm]

Thanks @matthijskooijman for sharing.
Just FYI it exists an uart debug feature which does not rely on IT: serial_debug
Defining DEBUG_UART (USART peripheral, ex: USART1) and DEBUG_PINNAME_TX (PY_n) allows to specify the pin to use else by default it uses the same than default Serial instance. This fallback to uart_debug_write.

[akasona]

This is a community projects, Any contribution is welcome, so feel free submit a PR.

@fpistm I want to make PR for the item: Hardware Flow control for serial communication.
Where can I find any rules or workflows to contribute this project?

[fpistm]

This is a community projects, Any contribution is welcome, so feel free submit a PR.

@fpistm I want to make PR for the item: Hardware Flow control for serial communication.
Where can I find any rules or workflows to contribute this project?

Hi @akasona
Sorry, I missed your comment.
You can refers to the https://github.com/stm32duino/Arduino_Core_STM32/blob/master/CONTRIBUTING.md
To resume:

• Fork

• Implement

• Ensure Astyle is passed

• Submit the PR

• That's all folks 😉

[ht93]

@fpistm For #1160 UART RX/TX level inversion on F3/F7 platforms. Is it possible implement similar function to F4 platform? Or is there any workaround besides hardware way like add physical inverter?

[fpistm]

Hi @ht93 , it seems not available fo F4.

[ht93]

Hi @fpistm, is there any other way to implement this? I am current working on a design with very limit size. Thanks a lot!

[fpistm]

Hi @fpistm, is there any other way to implement this? I am current working on a design with very limit size. Thanks a lot!

I don't know. You could try to ask on the forum.

[akasona]

@fpistm I'm sorry for so slow action! Finally I made up PR in #1634.

[akasona]

Added flow control APIs
https://github.com/stm32duino/wiki/wiki/API#enable-hardware-flow-control

[anatom74]

a suggestion to support for swapping RX/TX pins
(Bit 15 SWAP: Swap TX/RX pins)

[mhmayyan]

Hi
I am unable to start UART with a 1200 baud rate. I used Serial.begin(1200), but no data were transmitted. When I try a 2400 and higher baud rates, it works. Does anyone have any idea?
I tried Nucelo-L476RE and B-L4S5I-IOT01A.

[fronders]

@mhmayyan It's probably that the BRR value would overflow 0xFFFF for your desired rate at given core frequency.
IIRC the core runs by default at 80MHz so that would give you bauds between 1220 bps and 5Mbps. I don't know if you check the return code, but at 1200 it would probably just not initialize and return an error

p.s. I'd recommend opening a separate issue not to flood the request list

[fpistm]

Hi @mhmayyan
@fronders gave the right answer.
BRR is overflowed, you have to decrease the clock config and for this kind of question you can open a GitHub discussion.