UART Flow Control
Locked
 
|
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 |
|
|
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 |
|
|
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 |
«
Return to MicroControllers - Ethernut
|
1 view|%1 views
| Free forum by Nabble | Edit this page |