[En-Nut-Discussion] UART Flow Control

[Dušan]

Hi Uwe,

your modification makes sense.
BTW, your link points to the exactly same email, I pointed in my email 
message :-).

---
I need somehow to communicate with my usart device driver portion - 
arch/cm3/dev/nxp/mk64f_usart.inc.c 
<https://github.com/dferbas/ethernut/blob/master/nut/arch/cm3/dev/nxp/mk64f_usart.inc.c>
#define USART_MF_HALFDUPLEX_YZ    0x2000
#define USART_MF_FULLDUPLEX_232    0x4000
#define USART_MF_LOOPBACK_AB    0x8000
#define USART_MF_LOOPBACK_YZ    0x4000        /* same as for 232 if 
piggy-232 board present */

I can compare the feature to the PhyCtl() for ethernet.

The PhyCtl has a dcb, which is registered during NutRegisterPhy().

As there is usually only 1 ethernet, this works.

-----------
But with UARTs, more than 1 interface is common for boards, where Nut/OS 
is a good choice as OS.

for RS232

     control = USART_MF_RTSCONTROL | USART_MF_CTSSENSE;
     _ioctl(_fileno(stream), UART_SETFLOWCONTROL, &control);

for RS485
     u_long duplex_mode = USART_MF_HALFDUPLEX;
     _ioctl(_fileno(hbus_stream), UART_SETFLOWCONTROL, &duplex_mode);

for RS422
...

This generated an idea to tie this with usart driver via ioctl.
And as the ioctl is implemented in the common portion of the driver 
(dev/usart.c 
<https://github.com/dferbas/ethernut/blob/master/nut/dev/usart.c>),
there are only 2 options UART_SETSTATUS and UART_SETFLOWCONTROL,
which can pass arguments to the low level driver portion,
where they can be handled.

Should we extend the USARTDCB with some phyctl ?

Is there anyone who can benefit from using a loopback mode on RS485
for detecting issues with e.g. short circuit on bus lines?

*Dušan*

On 5.3.2020 21:00, bon at elektron.ikp.physik.tu-darmstadt.de wrote:
> Dušan writes:
>> Hi guys,
>>
>> we are working on a Nut/OS port for NXP Kinetis MK64F (LQFP100 - 144,
>> ethernet).
>> Actual state can be seen here: https://github.com/dferbas/ethernut
>>
>> Once tested, I plan to merge it with Nut.
>> It does not use the NutUseCritical() macros.
>>
>> ------------------------
>> We have an issue with USART driver.
>> We use the UART_SETFLOWCONTROL to set half duplex or full duplex and
>> also loopback modes.
>> All this is done with RE, DE signals to 2 RS485 transceivers, nicely
>> hidden from an application through the ioctl.
>>
>> The [r4163] <https://sourceforge.net/p/ethernut/code/4163/> added
>> XONXOFF only, which was later removed at
>>
>> [r4584] <https://sourceforge.net/p/ethernut/code/4584/> with following
>> remark:
>> Do not fix flow control to XON/XOFF handshake.
>> See
>> http://lists.egnite.de/pipermail/en-nut-discussion/2012-August/013821.html
>>
>> ---
>> As the dcb->dcb_modeflags should be hidden from an application,
>> what was the intention to leave it as it is now?
>>
>> What about to simply stay with the old version (#2555 - #4116):
>>       case UART_SETFLOWCONTROL:
>>           rc = (*dcb->dcb_set_flow_control) (lv);
>>           break;
>>
>> This allows everything to be passed from an application.
> I recently also implemented XON/XOFF for STM32 and have following
> patch not yet pushed to sourceforge:
> commit 60a551843e2dd5cb4846939d50b03aaf0d50ce4e
> Author: Uwe Bonnes <bon at elektron.ikp.physik.tu-darmstadt.de>
> Date:   Wed Feb 19 20:27:47 2020 +0100
>
>      usart.c: We must relay XONXOFF to the dcb_modeflags.
>      
>      Only relay dcb_modeflags. See http://lists.egnite.de/pipermail/en-nut-discussion/2012-August/013821.html.
>
> diff --git a/nut/dev/usart.c b/nut/dev/usart.c
> index a8228ef87..008dd036d 100644
> --- a/nut/dev/usart.c
> +++ b/nut/dev/usart.c
> @@ -834,6 +834,11 @@ int UsartIOCtl(NUTDEVICE * dev, int req, void *conf)
>   
>       case UART_SETFLOWCONTROL:
>           lv = dcb->dcb_modeflags;
> +        if (bv & USART_MF_XONXOFF) {
> +            lv |= USART_MF_XONXOFF;
> +        } else {
> +            lv &= ~USART_MF_XONXOFF;
> +        }
>           rc = (dcb->dcb_set_flow_control) (lv);
>           if (rc == 0) {
>               dcb->dcb_modeflags = lv;
>
> This only changes XONXOFF, but keeps other settings, e.g. half-duplex etc.
>
> What do you think of my solution?
>
> As neither Harald nor Ole seem to lurk, the original intention of the
> modification is probably lost.
>
> Should I put up my nutos repo on github?
>
> Bye