UART Flow Control

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

UART Flow Control

Dušan-2
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.

--

*Dušan*

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

Re: UART Flow Control

Uwe Bonnes

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 <[hidden email]>
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
--
Uwe Bonnes                [hidden email]

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Reply | Threaded
Open this post in threaded view
|

Re: UART Flow Control

Dušan-2
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, [hidden email] 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 <[hidden email]>
> 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
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion