Re: [uClinux-dev] Does any of you made an rs485 driver starting from uart?
On Wed, Apr 07, 2010 at 02:59:03PM +0200, Erwin Authried wrote: I have just discovered that there are now 'standard' linux ioctls to work with rs485 lines : TIOCGRS485 TIOCSRS485. (see http://git.kernel.org/?p=linux/kernel/git/gerg/m68knommu.git;a=commitdiff;h=c26c56c0f40e200e61d1390629c806f6adaffbcc) Of course, not all hardware drivers implement them. And also, I do not know how to use them. Philippe I found this example that seems to use those new ioctls: http://foxlx.acmesystems.it/?id=28 If you look into this example, it doesn't look promising because RTS is released by a call from userspace after sending. I can't see much advantage over using tcdrain() and releasing RTS afterwards, if tx_empty is implemented correctly by the serial driver. This example seems closer (at least the name of the ioctl, and some fields in the struct) and more promising : http://wiki.myigep.com/trac/wiki/HowToUseRS485 Philippe -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
RE: [uClinux-dev] Does any of you made an rs485 driver starting from uart?
Quoth Andrew Kohlsmith: I would hate to try and do it from software with an interrupt. Yuck. It's not that bad. :-) IRQ on transmit holding or shift register empty (ideally the latter). If you have only a THRE type interrupt then you have to set a timer for 1 word time (usually 9 bits) and after that timer, disable the transmitter. Of course when you go to send data again you have to make sure you turn on the transmitter. We've gone that route, for a master device (ie. other hardware will start transmitting back on the half-duplex channel almost immediately after the end of transmission) and had no end of trouble with getting the interrupt processed in time to avoid corrupting the reply. And this was on a board that wasn't even running an OS, so demands were relatively light. Sure, it worked fine *most* of the time, but that's not good enough. :) (Of course, it also had a pretty low-spec CPU, which didn't help.) We eventually switched to a UART that had hardware control of that line, and the problems went away. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Does any of you made an rs485 driver starting from uart?
Exactly. This is my greatest fear. In data venerdì 02 aprile 2010 15:54:27, Andrew Kohlsmith (mailing lists account) ha scritto: : On Thursday 01 April 2010 09:38:15 pm Philippe De Muyter wrote: We use a pure user-level solution with ioctl(fd, TIOCMBIS, TIOCM_RTS); /* wait some delay or rely on a CTS */ write(fs, message, message_len); /* eventually wait for a message_len based delay*/ tcdrain(fd); ioctl(fd, TIOCMBIC, TIOM_RTS); The biggest problem with that is not being able to have good control of the delay between the tcdrain() and ioctl(); for things like ModBus you end up with corrupted responses because the unit you've addressed has already started writing its response before you have shut off your transmitter. For ModBus slave devices this solution would work without much issue at all. -A. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev -- Fabio Giovagnini Aurion s.r.l. P.I e C.F. 00885711200 Tel. +39.051.594.78.24 Cell. +39.335.83.50.919 ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Does any of you made an rs485 driver starting from uart?
On Thursday 01 April 2010 09:38:15 pm Philippe De Muyter wrote: We use a pure user-level solution with ioctl(fd, TIOCMBIS, TIOCM_RTS); /* wait some delay or rely on a CTS */ write(fs, message, message_len); /* eventually wait for a message_len based delay*/ tcdrain(fd); ioctl(fd, TIOCMBIC, TIOM_RTS); The biggest problem with that is not being able to have good control of the delay between the tcdrain() and ioctl(); for things like ModBus you end up with corrupted responses because the unit you've addressed has already started writing its response before you have shut off your transmitter. For ModBus slave devices this solution would work without much issue at all. -A. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Does any of you made an rs485 driver starting from uart?
On Thursday 01 April 2010 01:36:52 pm Fabio Giovagnini wrote: I' have connected my SCIF1 port (of sh2a 7203) to a MAX485, and the TXEn/!RxEn to an I/O port. I had the idea to write a driver for proc FS to manage the TxEn/!RxEn line and using the ttySCx driver to send and receive data at 38400. But I need to wait the end of the last byte trasmission before to set low the TxEn/!RxEn line. Now I'm doing it with a dilay time; but I was looking for a more elegent solution There are a couple of solutions that are more elegant. First is to have a transmitter shift register empty interrupt deassert the line, but that's not the most elegant, if you hardware has support to automatically control the RS485 transmitter enable pin. Some UARTs have the ability to do this (ColdFire does for sure, I've never used SH2A) but check your UART documentation for the ability to automatically control a transmit enable pin. -A. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Does any of you made an rs485 driver starting from uart?
On Thu, Apr 01, 2010 at 07:36:52PM +0200, Fabio Giovagnini wrote: Now I'm doing it with a dilay time; but I was looking for a more elegent solution Any suggestion for me? I've done it once for a UART without shift register empty interrupt by starting a hrtimer when the fifo became empty. The fifo empty interrupt was generated by lowering the tx fifo threshold to zero once the normal threshold was reached or when the fifo was filled below the normal threshold. Daniel ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Does any of you made an rs485 driver starting from uart?
On Thursday 01 April 2010 01:48:21 pm Lennart Sorensen wrote: Yeah I have only ever done it using a UART that can automatically control the direction based on the transmit FIFO containing data or not (with a programable delay before switching of the transmitter of course). I would hate to try and do it from software with an interrupt. Yuck. It's not that bad. :-) IRQ on transmit holding or shift register empty (ideally the latter). If you have only a THRE type interrupt then you have to set a timer for 1 word time (usually 9 bits) and after that timer, disable the transmitter. Of course when you go to send data again you have to make sure you turn on the transmitter. So you end up with two IRQs if you don't have a shift register empty type of interrupt. -A. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
