drivers: uart: bitbang implementation

[joelguittet]

Add support for UART bitbang driver. The initial purpose of this driver is to support specific modes, such as 9-bits mode on target that doesn't support such feature (esp32 for example). It can also be used to have more UART interfaces.

It supports RS485 communication with Driver Enable output.
It supports none, odd, even, mark and space parity configuration and it supports 0.5, 1, 1.5 and 2 stop bits configuration.
It is using 2 counters to generate Tx data and sample Rx line. In the case of Half-Duplex communications the timer can be the same instance.

It has been developed on STM32L4A6 Nucleo board, and the UART passthrough sample is updated to demonstrate the usage of the driver.

Unfortunately for the moment it doesn't support ESP32 targets (my initial expectation) because of the lack of counter driver feature on Espressif port (counter set_top_value API is used to setup periodic interrupts and for the moment this API is not available on every hardware). I may update this Pull-Request later or with a new Pull-Request when it's done, @sylvioalves already looking at this topic.

Regarding to performances, I successfully tested the communications up to 62500 baud. I have regularly errors at 115200. By nature this driver has no synchronization signal and is sensitive to latencies on the target. Having parity/checksum is a good mitigation to detect errors when using this driver.

I'm open to any remark/suggestions, please do not hesitate

[dcpleung]

To be honest, there are too many variables affecting the performance of this. Bitbanging UART data lines need to be done with strict timing control. It would work on baremetal programs as they have total control of the hardware. With an OS, it can lock interrupts and you may miss the tiny time window to send/receive a bit. This will be very hard to debug, and will be very confusing to any user of this.

Any particular reasons that you must have this?

[joelguittet]

@dcpleung yes sure, this is what I have introduced in the first message of the PR. Having specific modes on some platforms that doesn't support it, eg 9-bits mode is not supported on ESP32 UART peripherals (without the cost of extra hardware - SPI or I2C to UART controller for instance).

Of course people using this must take care of this limitation. In case interrupts are disabled during a frame transfert then... as you said may be difficult to debug.

I'm using this for a development using an RS485 interface at 62500 baud. I have parity and checksum so detection of errors is easy and I can send again when this occurs (not seen for the moment but the project is just beginning so not so much stuff in the app).

[joelguittet]

@dcpleung I can add "select EXPERIMENTAL" in the Kconfig if you want.

[joelguittet]

Note: I don't know why some twister tests fail. This seems not related to my modifications...

[dcpleung]

If you are not strict on transferring raw bytes on serial lines, encapsulating the data in another format would properly work better. 8-bit at 115200 should yield faster overall speed than 9-bit at 62500 even accounting for software overhead to en-/de-code data. AFAIK, the UARTs on ESP32 do support RS485 (according to their technical manual).

[joelguittet]

This is not my purpose, the protocol I'm using is not my own design. This is an existing protocol and I'm interfacing with existing devices.
The protocol I'm using is xpressnet, from Lenz. It' used to control hobbyist railroad layouts.

So, instead of keeping a custom implementation for me, I have designed this driver and I'm sharing with the community. The xpressnet protocol part itself has no interest in zephyr of course, but the uart driver can be reused, knowing limitations we have shared above. We know that due to the nature of the uart hardware (no clock signal), it is not possible to do better than relying on the frequency of interrupts, just cross fingers the deviation is enough small (actually on my prototype I'm monitoring this and I'm always under 1% deviation).

Either it's interesting in zephyr and here is the PR, else if we think it has no value, I can close it. Tell me.

[dcpleung]

It would be great if you can add some warnings on the kconfig help about the limitations and downfalls.

There is no need for EXPERIMENTAL as it is for features, not for drivers.

[joelguittet]

Information: I tested on ESP32 and this is working as well, but it depends on #90300 and #89932. I will add an esp32-devkitc board configuration to the passthrough sample if both mentioned PR are integrated.

[dcpleung]

In that case, I think we can wait for those PRs to be merged first.

[sonarqubecloud]

Quality Gate passed

Issues
15 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[joelguittet]

@dcpleung dependencies for esp32 have been merged and I added an overlay to the sample, so it's ready for review.

Question for you: I'm actually thinking to an improvement to have much better timings and avoid the deviation, even if it's low. But this will require 2 additional GPIOs and 2 logic gates. I haven't seen such kind of "requirement" on other drivers. Is it acceptable? Maybe conditioned to an additional configuration option ? Or maybe it should simply be another driver ?

[dcpleung]

That would depend on how complex the additions would be. If these are simple enough, I think it's okay to add into the same, and guard them being kconfigs. Personally, I would use readability to gauge whether this is a good idea. Others will be reading the code in the future. The question would be if they, who only know UART but without your background knowledge, are able to follow the logic in code .

[joelguittet]

Let's say for the moment I keep this implementation. May be a future improvement with a new build option.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[joelguittet]

@dcpleung any news here ? Thanks

[henrikbrixandersen]

Retriggered CI. Previous run was 81 days ago.

[sonarqubecloud]

Quality Gate passed

Issues
15 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud