[En-Nut-Discussion] Questions regarding UART implementation

[Ulrich Prinz]

Hi all!

I am still porting STM32F / CortexM3 for Nut/OS and it is going quite well.

During this work I encountered some problems with the uart implementation.

There are a lot of _ioctl() commands that setup the uart in one or the 
other way. Unfortunately most of them have no comment that really 
explains, what it does. Most time the detailed descriptions are only 
copies of the brief header.

/*! \brief UART _ioctl() command code to set the write timeout.
  *
  * The configuration parameter specifies the write timeout in
  * milliseconds.
  */
#define UART_SETWRITETIMEOUT    0x010d

What is the write-timeout?
I guess that this is for USARTs with hardware handshake enabled and will 
turn _write() to return an error if the data was not sent out in time?

/*! \brief UART _ioctl() command code to set the local echo mode.
  *
  * The configuration parameter specifies the local echo mode,
  * 0 (off) or 1 (on).
  */
#define UART_SETLOCALECHO       0x010f

What does this do?
Guess 1: It echoes beck every RXed character to the sender. But that I 
would call a remote echo.
Guess 2: It puts every character that is TXed into the RX-queue.
That produces lots of work and may scramble the rx-queue by not giving 
any benefit.
Guess 3: It is for interfaces that allow listening while talking. I.e. 
One-Wire, RS485. In this case I will implement it for RS485. If one 
switches on local echo, the /RE line will be held low while DE is high 
and the sender is online.
Guess 4: There where some chips that support local loopback for testing 
the UART from databus to port-pins.

/*! \brief UART _ioctl() command code to set the flow control mode.
  *
  * The configuration parameter specifies the flow control mode.
  */
#define UART_SETFLOWCONTROL     0x0111

This option definately needs some more explanation about the parameters, 
as flow control can be...
Hardware: RTS/CTS and DSR/DTR and may be DCD
Software: XON/XOFF and STX/ETX

/*! \brief UART _ioctl() command code to set the buffering mode.
  *
  * The configuration parameter specifies the buffering mode.
  */
#define UART_SETBUFFERMODE      0x0115

What is this?

/*! \brief UART _ioctl() command code to set the block read mode
*
* The configuration parameter specifies the block read mode.
*/
#define UART_SETBLOCKREAD       0x0128

And this?

/*! \brief UART _ioctl() command code to set physical device to half 
duplex mode.
  *
  * The configuration parameter specifies the halfduplex mode for 
device. In raw mode
  */
#define UART_SETHDPXMODE        0x012c

Yes I know, I wrote that long time ago, but it rised a question to me:

For RS485 interfaces some combinations of half-duplex and local-echo are 
interesting. Especially if you support RS422 and RS485.
The HDPX mode simply disables TX while receiving and RX while sending.

For that it could be important to not unblock the mutexes until 
TX-Complete has been detected. But most drivers don't do that. Or am I 
wrong?

Implementation 1:
DE/RE handling is dependent on the nutconfig setting. If a DE and /RE 
line is configured, they will be controlled according the setup.
While transmitting the following logics apply:
ECHO = 0 HDPX = 0: /RE stays high, RX-En = 1 -> no echo
ECHO = 1 HDPX = 0: /RE goes low,   RX-En = 1 -> echo
ECHO = 0 HDPX = 1: /RE stays high, RX-En = 0 -> no echo
ECHO = 1 HDPX = 1: /RE goes low,   RX-En = 0 -> no echo

Why having an echo and optionally switch it off on a RS485? It is a very 
simple thing to check if the line is ok.

Good at this implementation is, that the code is very easy and for my 
taste there are already enough _ioctl() options.
Negative might be that newbies might need to search a while until they 
find that these tokens touch the DE/RE handling.

Implementation 2:
DE/RE are controlled by separate _ioctl() codes.

Good is that everyone can find these comands and might guess what they 
do: UART_NRE_LOWWHILETX or UART_485RE_KEEPLOW?

All above leads me to the question:
How to enable remote echo?

That doesn't work:

	c = UART->DR;
	UART->DR = c;

As RX and TX might work in parallel. Especially if you use ANSI-ESC 
sequences to put some data in coloured or ordered way to your terminal, 
you cannot spray the received characters everywhere.

Or is a control for this missing at all?

Ok, that's enough for tonight.

Thanks for any answer even it is only for one fo the many topics above.

Ulrich