Malban
Posts: 16
Joined: Thu Aug 01, 2019 6:16 pm

Mini UART

Thu Jan 16, 2020 8:05 pm

Gee...

Another one of those questions...

Is there a way to flush the Mini UART?
(there is a topic https://www.raspberrypi.org/forums/view ... p?t=105121, but I can't find a solution to work with mini UART)

For now I want a "simple" echo...

Code: Select all

void handleUARTInterface()
{
	if (RPI_AuxMiniUartReadPending())
	{
	  char r = RPI_AuxMiniUartRead();
	  printf("%c", r);
        }    
}
The character(s) is(are) only displayed after I send a "CR". I would like to display one character at a time...

This is no "BLOCKING" thing - but quite annoying...

Any help would be appreciated (but pls not the obvious one - use the full UART :-) ).

Cheers
Malban

Schnoogle
Posts: 100
Joined: Sun Feb 11, 2018 4:47 pm

Re: Mini UART

Fri Jan 17, 2020 11:48 am

Hey there,

I'm struggling currently a bit what exactly your issue is. On the one hand hand you asking fro flushing (which is the sending part I guess) and on the other hand you provide a code snipped for reading inbound data.

I've never had issues at my UART1(miniUart) that single characters did not make their way to the connected console without additional "flushing".
Maybe you could share your sending code here?

When you say you'd like to simply echo the uart data, what exactly do you mean by that?
Is it that you echo the data you received at the PI miniUart back to the miniUart ? So that when you connected a console and press a key the value is echoed back and displayed at the console as it has been received from the Pi?

Regards,
Schnoogle

Malban
Posts: 16
Joined: Thu Aug 01, 2019 6:16 pm

Re: Mini UART

Fri Jan 17, 2020 12:18 pm

Yep. Sorry - could have been "clearer" I guess...

The own code is always so self explanatory :-)

---

With Echo I ment... (within the code snippet):
I get the char via:

Code: Select all

char r = RPI_AuxMiniUartRead();
And I want to "echo" it back with the printf():

Code: Select all

printf("%c", r);
That printf()... results ultimately in a call to

Code: Select all

void outbyte( char b )
{
    RPI_AuxMiniUartWrite( b );
}
which in turn calls:

Code: Select all

void RPI_AuxMiniUartWrite( char c )
{
    /* Wait until the UART has an empty space in the FIFO */
    while( ( auxillary->MU_LSR & AUX_MULSR_TX_EMPTY ) == 0 ) { }

    /* Write the character to the FIFO for transmission */
    auxillary->MU_IO = c;
}
Anyway - the printf(...); only reaches my terminal after I do a printf("...\r\n")... Which can actually be a couple of hundreds character later...

Malban

Schnoogle
Posts: 100
Joined: Sun Feb 11, 2018 4:47 pm

Re: Mini UART

Fri Jan 17, 2020 12:38 pm

Hey,

thanks for the additional insights. As the code looks good to me and as you are saying the terminal is showing the characters only after "\r\n" may I ask what terminal program you use? Maybe it relates to a setting their ?

I'm using TeraTerm(https://osdn.net/projects/ttssh2/releases/) for windows and have not seen such issues.
So just to have this fully understood:
The data is only appearing after "\r\n" ? There seem to be no size limit or timing when sending data to the Pi and waiting for the response?
I slightly remember that some terminals are only sending data after a \r\n (which could be configured). In this case it's not the PI issue it's the terminal issue as it does not send data to the Pi without the \r\n ?

Regards
Schnoogle

Malban
Posts: 16
Joined: Thu Aug 01, 2019 6:16 pm

Re: Mini UART

Fri Jan 17, 2020 12:55 pm

To clarify:
The PI gets the data (a single character e.g.) DIRECTLY.

I can react promptly on the character I sent (from the terminal) - and see a reaction (if I insert additional code... to react on characters).
The character sending from the Pi to the terminal is what is "buffered"/"deferred".

I am on a Mac OSX. I tried different terminal programs with different settings.
For my current needs "coolterm" is very good and I like using it.

I tried spinning the AUX_MU_LSR_REG -> Transmitter idle , to wait for the transmission...
But as observed - there is no transmission - the FIFO is always filled with one char, and that results in "endless spinning".

I also tried spinning on AUX_MU_STAT_REG -> Transmitter done... same result (endless loop)....

It seems that the pi is not sending any data!

Thx for your response

Malban

Schnoogle
Posts: 100
Joined: Sun Feb 11, 2018 4:47 pm

Re: Mini UART

Fri Jan 17, 2020 3:41 pm

Hm, well.... this sounds interesting. Could you maybe dump the configuration/content of the following registers after you've send a character that is not seen in your terminal:

AUX_MU_STAT_REG
AUX_MU_CNTL_REG
AUX_MU_LSR_REG
AUX_MU_IIR_REG

??

Malban
Posts: 16
Joined: Thu Aug 01, 2019 6:16 pm

Re: Mini UART

Fri Jan 17, 2020 3:58 pm

Code: Select all

AUX_MU_STAT_REG: 0000034e
AUX_MU_CNTL_REG: 00000003
AUX_MU_LSR_REG:  00000060
AUX_MU_IIR_REG:  000000c3
After I send a "\r\n" the contents is:

Code: Select all

AUX_MU_STAT_REG: 08000064
AUX_MU_CNTL_REG: 00000003
AUX_MU_LSR_REG:  00000000
AUX_MU_IIR_REG:  000000c1

dpotop
Posts: 86
Joined: Mon Nov 24, 2014 2:14 pm

Re: Mini UART

Fri Jan 17, 2020 5:09 pm

Hello,

Are you sure that your "printf" routine is not doing some buffering, internally, in order
to print full lines? Such buffering may make sense if you're in a preemptive
environment (which you are not). Check the implementation of printf.

If printf is buffering internally, then the way to flush is implementation-dependent
(unless you are on some POSIX-compliant implementation, in which case you
would not be on this forum).

So, I'd suggest you:
1. Try replacing printf with a "putc" implementation that is a direct call to the
UART routine. This should confirm that your UART is functioning correctly.
2. Take a look at the implementation of printf.

Best regards,
Dumitru
dpotop

Malban
Posts: 16
Joined: Thu Aug 01, 2019 6:16 pm

Re: Mini UART

Fri Jan 17, 2020 5:15 pm

Gee...

You make me feel like I am stupid.
You are correct. printf() does some strange or at least unexpected buffering. A direct output is working great!

That was a great idea and I should have thought of that way earlier.

Thank you very much!

Malban

Return to “Bare metal, Assembly language”