BCM2835 UART HAL

In the HAL sources in UART on line 216 ( HAL_UARTFeatures ) is stated that the MiniUART doesn’t have Hardware RTS / CTS available on page 16 of the datasheet could deducted otherwise ( AUX_MU_CNTL_REG where bit 6 and 7 give the possibility off auto flow). Also indicated at page 14 of the datasheet which states the possibility of auto-flow control.

That’s here

; int HAL_UARTFeatures(int port)
;
;      Bit 0:  FIFOs available
;      Bit 1:  DMA available
;      Bit 2:  Modem lines available
;      Bit 3:  Hardware RTS/CTS available
;      Bit 4:  Transmitter empty IRQ is actually "TX FIFO under threshold" IRQ
;
HAL_UARTFeatures
 [ MiniUART
        MOV     a1, #2_00001 ; TODO confirm
 |

In the HAL sources in UART on line 216 ( HAL_UARTFeatures ) is stated that the MiniUART doesn’t have Hardware RTS / CTS available on page 16 of the datasheet could deducted otherwise ( AUX_MU_CNTL_REG where bit 6 and 7 give the possibility off auto flow).

The sources probably refer to the fact that the Pi doesn’t have a physical link into anything to provide hardware flow control, so I would assume all handshake is xon/xoff

On the header RTS and CTS are available on GPIO 16 and GPIO 17 just as for the PL11 UART.
Around lines 68 – 71 is stated that it was not available on Model B rev 1 PCB and that the code in this respect is not tested.

On the header RTS and CTS are available on GPIO 16 and GPIO 17 just as for the PL11 UART.

Ah, I hadn’t looked at newer boards. What board revision did they start bringing the handshake out to available pins?

I would say starting at the Pi B+ when the Pi foundation moved to a 40 pins header. Basicly the second generation.

I have setup a build enviroment for the Pi again on a Pi-400 so perhaps I can have look at. Is int port starting at 0 for serial0 or at 1
https://www.riscosopen.org/wiki/documentation/show/HAL_UARTRate

Another question should the HAL be agnostic about UART clk rate and board type or should this be in the HAL ?

Hi, I made the first change in the Risc-OS code base it is for the HALL. I changed HAL_UARTPorts to:
MOV a1, #2 ; Boards before the Pi4 have 2 serial ports after that 6 ?.
CPUDetect r4 ; Detect the CPU . For some reason Board_Model is not available yet.
MOVHI a1, #6
MOV pc, lr
Pi’s don’t have 1 port they have depended on the CPU type 2 to 6 ports and this reflects it better.
My objective is to bring UART HAL more in line with Rpi OS from the Pi foundation ( Rasbian ) and to provide full support of all serials ports on the HAL

My objective is to bring UART HAL more in line with Rpi OS from the Pi foundation ( Rasbian ) and to provide full support of all serials ports on the HAL

Shortly after the Pi 4 was released I did start work on adding support for the extra UARTs. I can’t remember exactly what needs doing to finish up the code, but I think the main thing that needs sorting out is the GPIO pin mux settings – with multiple peripherals sharing the same pins, we need a way of letting the user/software control which peripherals are enabled.

I’ve now rebased it onto the latest HAL and pushed it here: https://gitlab.riscosopen.org/jlee/HAL_BCM2835/-/tree/ExtraUARTs. I haven’t tested this new version, but for the original one I think I did at least confirm that basic RX/TX functionality worked for each of the UARTs.

Hi Jeffrey,

First of all thanks. I’m also working on the UART HAL because of my work on the Bluetooth stack by using the onboard rpi chip. For that I need:
- very high baud-rates ( For the firmware )
- The PL11 ( UART0 ) has to be diverted the bluetooth chip.
If you look to the current UART HAL source it looks oriented towards what is easily accessible to the average user. Although I do understand the reasoning behind it and possible also time and resources play a part in it with the BT stack I run into trouble
Therefore I would like to propose the following:
- We let the HAL show the actual the number of UART available on the board irrespective if the are available for the normal user
- We follow Raspberry Pi OS as it was Jan 2021 assisnments of the UARTS. We access if it changes.
- We take the UART clock from the VC mailbox if available and adjust the baudrate calculations in the HAL accordingly. And remove the set to 3 MHz in the init. So we can support the higher baudrates without problems.
- We also test CTS / RTS. This is for my Belgium friends who need a good working CTS / RTS for their project
Please let me know what you think of it .

That sounds good to me.

Nice I start coding ;-)

I think the main thing that needs sorting out is the GPIO pin mux settings – with multiple peripherals sharing the same pins, we need a way of letting the user/software control which peripherals are enabled.

Wasn’t that what GPIO_WriteMode is supposed to do, but doesn’t on the Pi4, or has that been fixed now?

@Andrew
I have indeed the feeling we should do the minumum on pin mux setting in the HAL for the UART. In the implementation I’m working on I follow the Raspberri Pi OS
I don’t know if the GPIO_WriteMode is fixed but if I need it for the BT stack it will certainly come in my view ;-).

Update on my work done 8 Jan 2021
- Updated Hdr.StaticWS to store the clock frequency of the PL11 UART in a new variable ( UartClock )
- Removed setting the clock frequency in the Messaging source ( s.Messaging )
- Added storing the UART clock in static workspace to be used by the UART HAL
- Updated HAL_UARTDevice to accomodate for the PL11 and MiniUART
These updates make that the init_uart_clock in Config.txt is respected. The working of the UART and the init_uart_clock proper working have been tested with an oscilloscope.

It turned out that UartClock was only given a 0 value. A bit odd because other values were given a value and when I used BCMSupport_SendTempPropertyBuffer for the UARTClock it gave a sensible value. To solve this problem I had to edit s.Top as well. And an two lines around line 880.
It seems that Board_Model is no longer in use and Board_Revision gives the correct data.

Update 10 Jan 2021
Today I have been busy with integrating the code of Jeffrey Lee . Yes I you read it well I just copied code instead of writing it myself ( I tried ;-))
I did however slighly modify it to support all UARTS.

Update 12 Jan 2021. The code from Jeffrey when apllied on one place crashes the boot of RISCOS. It happens in UARTRate in all other functions the new macro for calculating the register base address works.
Also in some functions more done to support the MiniUART

I have placed the sources here :
http://www.timohartong.riscos.fr/HAL/hal.html

So a bit of progress update. Still the pesky crash at setting the baudrate. But I think I have now found the cause of it. For the rest full support for the MiniUART gets shape. Next to that I’m writing unit. ( In BBC Basic because I’m too lazy to write them in C )