Hi Kieran, On Mon, Nov 22, 2021 at 9:25 PM Kieran Bingham <kieran.bingham@xxxxxxxxxxxxxxxx> wrote: > > Hi Magnus, > > Quoting Magnus Damm (2021-11-20 15:41:46) > > From: Magnus Damm <damm+renesas@xxxxxxxxxxxxx> > > > > Here's a work-in-progress patch for shared pin LED and KEY functionality: > > - UART TX Serdev LED driver prototype (functional) > > - UART RX Serdev KEY driver prototype (partial) > > - r8a77995 Draak DTS modifications to use above drivers with SCIF0 > > > > With this code my hope is to use hardware to drive an LED and allow > > detection of a key press without software performing any kind of polling. > > > > In theory on SoCs that support UART RX and TX on the same pin (and also > > open drain output) with the above software it is possible to handle boards > > with single pin shared LED and KEY functionality. > > > > This prototype on r8a77995 Draak makes use of 3 pins and an external circuit: > > - LED13/SW59/GP4_07 <-> EXIO_A:10 (CN46) > > - SCIF0_RX/GP4_20 <- EXIO_A:38 (CN46) > > - SCIF0_TX/GP4_21 -> EXIO_A:36 (CN46) > > Ether-AVB PHY connector (CN23) has 3.3V on pin 54 and 56 and GND on 14 > > In the future SCIF1 and SCIF3 may also be used for other LEDs and switches. > > > > Currently two inverters on SN74HC05 together with pull-ups are used to extend > > the D3 SoC and the Draak board with open drain functionality and also tie > > together the TX and RX pins with LED13/SW59. > > > > The prototype LED driver allows user space to turn on/off the LED using: > > # echo 1 > /sys/class/leds/serial0-0/brightness > > # echo 0 > /sys/class/leds/serial0-0/brightness > > Must be easy to extend the driver with some degree of brightness control. > > > > Apart from some general brush up the following issues have surfaced: > > - "controller busy" error happens when more than one serdev is used > > - it is unclear how to take RX errors from serdev and generate key events > > - there seem to be no way to silence "sh-sci e6e60000.serial: frame error" > > - the DTS "current-speed" property looks like sw config and not hw description > > > > Obviously not for upstream merge as-is. Might however be useful as SCIF error > > test bench and/or as potential (corner) use case for serdev. > > Very interesting use of the DMA capabilities for the SCIF to generate > output on the lines. Indeed there are quite a few hardware components working together to emulate a low signal by sending a mostly-zero pattern on the UART TX line. So far I've adjusted the size of the data buffers to avoid too many wake ups per second for transmitting. In my opinion it would be even better to use some sort of circular DMA mode and have zero wake ups. I'm quite sure the hardware would support such configuration, but how to make it happen with software is a different story. > What's the maximum speed of the SCIF? I could see this being further > used to provide a software defined controller for RGB LEDs [0], which > have often previously used SPI in a similar fashion to your proposal [1]. > > https://github.com/msperl/rgbled-fb/blob/master/ws2812b-spi-fb.c > https://www.arrow.com/en/research-and-events/articles/protocol-for-the-ws2812b-programmable-led Thanks. Indeed a software defined controller for RGB LEDs would be very interesting to see. The maximum speed of the SCIF is most likely in the Mbit-range but it really depends on the SoC type and perhaps also board specific external crystal configuration. And of course the device that the UART is connected to together with the quality of the PCB. Initially I had planned to rely on UART hardware break condition detection for the key press event, but with the 9600 bps on my SN75HC05 breadboard prototype the signals are looking pretty noisy. Now I have adjusted my expectation to "any UART error condition" for the key detection to make something work with what I've got. =) But to get those UART errors related to the key event into the serdev driver some framework extensions would most likely be needed. Cheers, / magnus
