From: Matthew B. <ma...@aw...> - 2009-08-27 07:51:45
|
Hi all I'm trying to track down the cleanest way of manipulating a GPIO signal on my gumstix board. I understand the IN/OUT and AF1, GPIO settings as I can get things working in shell-script land using `echo "GPIO OUT SET" > /proc/gpio/GPIO81` and that sort of thing. but in C, I presume its a bit cludgy to say something resembling - system("echo... /proc/gpio/, etc, etc"); I have found an example here http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs which seems to be giving a nice wrapper around some functions. I am not willing to try it first though, as I've read about the kernel space versus user space limitations. I probably can't break anything and I'll look silly for being so cautious, but does anyone know if this is the way to work directly with hte GPIO lines in C, or am I barking up the wrong tree? thanks for any help. Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd Water Control Solutions Design - Manufacture - Install ------------------------------------------------------------------------- Phone 0427 680 641 Web www.awma.au.com <http://www.awma.au.com/> Email ma...@aw... |
From: Dave H. <dhy...@gm...> - 2009-08-27 14:13:41
|
Hi Matt, > I'm trying to track down the cleanest way of manipulating a GPIO signal on > my gumstix board. I understand the IN/OUT and AF1, GPIO settings as I can > get things working in shell-script land using `echo "GPIO OUT SET" > > /proc/gpio/GPIO81` and that sort of thing. > > but in C, I presume its a bit cludgy to say something resembling > - system("echo... /proc/gpio/, etc, etc"); Presuambly, this is for the verdex. If you want to use the proc interface, then I would open the file (/proc/gpio/etc) using fopen, then fwrite "gpio out set" to it and then fclose it. Wrap it up in a function and away you go. > I have found an example here > http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs > which seems to be giving a nice wrapper around some functions. I am not > willing to try it first though, as I've read about the kernel space versus > user space limitations. I probably can't break anything and I'll look silly > for being so cautious, but does anyone know if this is the way to work > directly with hte GPIO lines in C, or am I barking up the wrong tree? If you want to write directly to the gpio lines, then you'd need to use the gpregs approach. Another way is to write a custom driver and have the user space program talk to the custom driver. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: Matthew B. <ma...@aw...> - 2009-08-28 03:53:36
|
Hi everyone I have got the GPIO access working in C. I did use fputs() instead of fwrite() just to simplify things, but what I am getting is a 50mS lag between. that is, the following code: fputs("GPIO out set",pGPIO_TxRx); fflush(pGPIO_TxRx); fputs("GPIO out clear",pGPIO_TxRx); fflush(pGPIO_TxRx); produces a trace with a +ve edge, followed by a delay of 48.4mS, and then a -ve edge. obviously there's some kernel polling of file-system writes or something. I assumed it would be near instaneous and I need it to be within 3-5 mS. I should have given some better detail on what I'm trying to achieve. I am attempting to get RS485 comms working from my GUMSTIX. At the moment my HW is not ready, but i am working on the synchronisation of the Transmit enable (DE) (which is also the active-low Rx Enable) with the transmit buffer. i have seen some examples of ioctl structure extensions to handle the RS485 transmit enable sync'ing. And it seems to be industry standard to use the RTS line of the serial port if it has one. what I noticed, is that I can control the RTS line but only if the RTS/CTS lines are activated in the serial port config, al la - "c_cflag |= CRTSCTS;" there is a problem with doing this though - you are essentially enabling HW flow control, which means driving CTS in some fashion to allow the port to transmit. to avoid this I thought I would manually drive the TTL output of the RTS pin. But i get the lagging I mentioned when I interact with the pin via the filesystem. Does anyone have any experience with RS485 on the GUMSTIX platform? I may attempt to get the gpregs stuff working unless someone says otherwise. any advice at all would be appreciated. Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd -----Original Message----- From: Dave Hylands [mailto:dhy...@gm...] Sent: Friday, 28 August 2009 12:13 AM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program Hi Matt, > I'm trying to track down the cleanest way of manipulating a GPIO > signal on my gumstix board. I understand the IN/OUT and AF1, GPIO > settings as I can get things working in shell-script land using `echo > "GPIO OUT SET" > /proc/gpio/GPIO81` and that sort of thing. > > but in C, I presume its a bit cludgy to say something resembling > - system("echo... /proc/gpio/, etc, etc"); Presuambly, this is for the verdex. If you want to use the proc interface, then I would open the file (/proc/gpio/etc) using fopen, then fwrite "gpio out set" to it and then fclose it. Wrap it up in a function and away you go. > I have found an example here > http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs > which seems to be giving a nice wrapper around some functions. I am > not willing to try it first though, as I've read about the kernel > space versus user space limitations. I probably can't break anything > and I'll look silly for being so cautious, but does anyone know if > this is the way to work directly with hte GPIO lines in C, or am I barking up the wrong tree? If you want to write directly to the gpio lines, then you'd need to use the gpregs approach. Another way is to write a custom driver and have the user space program talk to the custom driver. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: 08/27/09 08:11:00 |
From: Dave H. <dhy...@gm...> - 2009-08-28 04:12:42
|
Hi Matt, On Thu, Aug 27, 2009 at 8:53 PM, Matthew Bowles<ma...@aw...> wrote: > Hi everyone > > I have got the GPIO access working in C. I did use fputs() instead of > fwrite() just to simplify things, but what I am getting is a 50mS lag > between. that is, the following code: > > fputs("GPIO out set",pGPIO_TxRx); > fflush(pGPIO_TxRx); > fputs("GPIO out clear",pGPIO_TxRx); > fflush(pGPIO_TxRx); > > produces a trace with a +ve edge, followed by a delay of 48.4mS, and then a > -ve edge. > obviously there's some kernel polling of file-system writes or something. I > assumed it would be near instaneous and I need it to be within 3-5 mS. Using the gpregs technique will give you much faster changes. >From the archives: <http://article.gmane.org/gmane.linux.distributions.gumstix.general/7329> somebody got was able to write to a GPIO pin at about 6 MHz from user space. The "modified pxaregs" is essentially the same technique used by gpregs. Note: not a significant contributor, but the printk done by the kernel when you do the above adds a little more than 3 msec to the time. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: Matthew B. <ma...@aw...> - 2009-08-28 04:17:19
|
printk? is that the element of a fputs that does the real work? Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd -----Original Message----- From: Dave Hylands [mailto:dhy...@gm...] Sent: Friday, 28 August 2009 2:12 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program Hi Matt, On Thu, Aug 27, 2009 at 8:53 PM, Matthew Bowles<ma...@aw...> wrote: > Hi everyone > > I have got the GPIO access working in C. I did use fputs() instead of > fwrite() just to simplify things, but what I am getting is a 50mS lag > between. that is, the following code: > > fputs("GPIO out set",pGPIO_TxRx); > fflush(pGPIO_TxRx); > fputs("GPIO out clear",pGPIO_TxRx); > fflush(pGPIO_TxRx); > > produces a trace with a +ve edge, followed by a delay of 48.4mS, and > then a -ve edge. > obviously there's some kernel polling of file-system writes or > something. I assumed it would be near instaneous and I need it to be within 3-5 mS. Using the gpregs technique will give you much faster changes. >From the archives: <http://article.gmane.org/gmane.linux.distributions.gumstix.general/7329> somebody got was able to write to a GPIO pin at about 6 MHz from user space. The "modified pxaregs" is essentially the same technique used by gpregs. Note: not a significant contributor, but the printk done by the kernel when you do the above adds a little more than 3 msec to the time. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: 08/27/09 18:02:00 |
From: Dave H. <dhy...@gm...> - 2009-08-28 04:28:37
|
Hi Matthew, On Thu, Aug 27, 2009 at 9:17 PM, Matthew Bowles<ma...@aw...> wrote: > printk? is that the element of a fputs that does the real work? No, it comes from the code that handles the /proc/gpio/GPIOxx stuff. >From the console, when you do echo "gpio out set" > /proc/gpio/GPIO43 you'll see something like Set (GPIO,outy,set) via /proc/gpio/GPIO43 printed to the console. This is the proc handler. You can find the source in tmp/work/gumstix-custom-verdex-angstrom-linux-gnueabi/gumstix-kernel-2.6.21-r1/linux-2.6.21/drivers/gpio/proc_gpio.c -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: Matthew B. <ma...@aw...> - 2009-08-28 04:33:01
|
oh right - the debug output of sorts. I don't expect that this is the cause of my 48mS lag though. Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd -----Original Message----- From: Dave Hylands [mailto:dhy...@gm...] Sent: Friday, 28 August 2009 2:28 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program Hi Matthew, On Thu, Aug 27, 2009 at 9:17 PM, Matthew Bowles<ma...@aw...> wrote: > printk? is that the element of a fputs that does the real work? No, it comes from the code that handles the /proc/gpio/GPIOxx stuff. >From the console, when you do echo "gpio out set" > /proc/gpio/GPIO43 you'll see something like Set (GPIO,outy,set) via /proc/gpio/GPIO43 printed to the console. This is the proc handler. You can find the source in tmp/work/gumstix-custom-verdex-angstrom-linux-gnueabi/gumstix-kernel-2.6.21- r1/linux-2.6.21/drivers/gpio/proc_gpio.c -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: 08/27/09 18:02:00 |
From: Matthew B. <ma...@aw...> - 2009-08-28 07:25:57
|
ok, I actually got this working. thanks for all the tips Dave, and for answering so quickly. I now have a new problem. I am attempting to read the status of the port using a standard control (copied from earlier work on a PC environment). the code in question is ; ioctl(serialport, TIOCSERGETLSR, &lsr); which should return me a status word, so I can check that the buffer has finished transmitting all bits, before returning the txrx direction to receive again. what I am being returned is a 1? Always a 1. I am not masking the word first. I can see on my oscilloscope that the data packet (8 bytes of formatted modbus) has not finished yet when my software gets a value of 1 from the port status reg. my first question is - can anyone clarify that i am reading the port correctly. I have read here http://www.nabble.com/Patch-information-td23601925.html, that perhaps the status register is not properly supported by the gumstix hardware/kernal/drivers. Is that true? second question is - does anybody know of a suitable alternative to figuring out when the port is ready to be switched back to receiving on the RS485 bus. I would prefer and non-timer-based solution for elegance and portability, but I'm open to anything. thanks Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd -----Original Message----- From: Dave Hylands [mailto:dhy...@gm...] Sent: Friday, 28 August 2009 2:12 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program Hi Matt, On Thu, Aug 27, 2009 at 8:53 PM, Matthew Bowles<ma...@aw...> wrote: > Hi everyone > > I have got the GPIO access working in C. I did use fputs() instead of > fwrite() just to simplify things, but what I am getting is a 50mS lag > between. that is, the following code: > > fputs("GPIO out set",pGPIO_TxRx); > fflush(pGPIO_TxRx); > fputs("GPIO out clear",pGPIO_TxRx); > fflush(pGPIO_TxRx); > > produces a trace with a +ve edge, followed by a delay of 48.4mS, and > then a -ve edge. > obviously there's some kernel polling of file-system writes or > something. I assumed it would be near instaneous and I need it to be within 3-5 mS. Using the gpregs technique will give you much faster changes. >From the archives: <http://article.gmane.org/gmane.linux.distributions.gumstix.general/7329> somebody got was able to write to a GPIO pin at about 6 MHz from user space. The "modified pxaregs" is essentially the same technique used by gpregs. Note: not a significant contributor, but the printk done by the kernel when you do the above adds a little more than 3 msec to the time. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: 08/27/09 18:02:00 |
From: Anch <mu...@ym...> - 2009-09-22 14:13:52
|
Hi Matthew, Sorry, I did check that you have already gone through the thread I asked you to read. So the problem as I mentioned in that patch was that Kernel supports reading the LSR register to get the state. So in an unmodified kernel source, the ioctl call will work. If you go through the kernel code for this call, it reads the LSR register and gives you a value. A gumstix patch disables this read. So you will end up getting a value which was last updated, which might not be the latest one. I had to modify the gumstix patch, which I am attaching. Actually, there were a couple of patches related to serial communication i combined them all in one. On the patch-information thread, I have mentioned what function you have to look at. Go through the patch file and you will figure out what I described above. BTW, this is the sample code I finally used in my app to set,reset the RTS line. if(write(main_app_instance.comm_port,message,message_len) == message_len) { do { ioctl(main_app_instance.comm_port, TIOCSERGETLSR, &status); } while (!(status & TIOCSER_TEMT)); //reset RTS line gpio(OUT, CLEAR, O_BTUART_RTS); } http://www.nabble.com/file/p25530730/bugfix-serial-register-status.patch bugfix-serial-register-status.patch If you do need more info, i will be glad to help. regards Anch Matthew Bowles-2 wrote: > > ok, I actually got this working. > > thanks for all the tips Dave, and for answering so quickly. > > I now have a new problem. > I am attempting to read the status of the port using a standard control > (copied from earlier work on a PC environment). > the code in question is ; > ioctl(serialport, TIOCSERGETLSR, &lsr); > which should return me a status word, so I can check that the buffer has > finished transmitting all bits, before returning the txrx direction to > receive again. > > what I am being returned is a 1? Always a 1. I am not masking the word > first. > I can see on my oscilloscope that the data packet (8 bytes of formatted > modbus) has not finished yet when my software gets a value of 1 from the > port status reg. > > my first question is - can anyone clarify that i am reading the port > correctly. > I have read here http://www.nabble.com/Patch-information-td23601925.html, > that perhaps the status register is not properly supported by the gumstix > hardware/kernal/drivers. Is that true? > > second question is - does anybody know of a suitable alternative to > figuring > out when the port is ready to be switched back to receiving on the RS485 > bus. I would prefer and non-timer-based solution for elegance and > portability, but I'm open to anything. > > thanks > > > Best regards > > Matt Bowles > Embedded Systems Engineer > aWma Pty Ltd > > > -----Original Message----- > From: Dave Hylands [mailto:dhy...@gm...] > Sent: Friday, 28 August 2009 2:12 PM > To: General mailing list for gumstix users. > Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program > > Hi Matt, > > On Thu, Aug 27, 2009 at 8:53 PM, Matthew Bowles<ma...@aw...> > wrote: >> Hi everyone >> >> I have got the GPIO access working in C. I did use fputs() instead of >> fwrite() just to simplify things, but what I am getting is a 50mS lag >> between. that is, the following code: >> >> fputs("GPIO out set",pGPIO_TxRx); >> fflush(pGPIO_TxRx); >> fputs("GPIO out clear",pGPIO_TxRx); >> fflush(pGPIO_TxRx); >> >> produces a trace with a +ve edge, followed by a delay of 48.4mS, and >> then a -ve edge. >> obviously there's some kernel polling of file-system writes or >> something. I assumed it would be near instaneous and I need it to be > within 3-5 mS. > > Using the gpregs technique will give you much faster changes. > >>From the archives: > <http://article.gmane.org/gmane.linux.distributions.gumstix.general/7329> > somebody got was able to write to a GPIO pin at about 6 MHz from user > space. > The "modified pxaregs" is essentially the same technique used by gpregs. > > Note: not a significant contributor, but the printk done by the kernel > when > you do the above adds a little more than 3 msec to the time. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.DaveHylands.com/ > > ---------------------------------------------------------------------------- > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and focus > on what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: 08/27/09 > 18:02:00 > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/GPIO-manipulation-from-a-user-space-C-program-tp25167968p25530730.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Matthew B. <ma...@aw...> - 2009-09-22 22:50:32
|
Hi Anch i was aware that there was a solution relating to undoing a gumstix patch, but I didn't know exactly how to implement it, and my rootfs is not something I wanted to play with as its standardised across 10+ installations (read: pain in rear-end to upgrade). but I think Timo who posted here yesterday asking about RS485 transmit and receive. He will still need to use the gpregs thing to toggle the TxRx signal, but if he (un)patches the kernel he can use the ioctl calls to read the LSR, which is not only cleaner but is portable. The gpregs approach to reading the LSR is *definitely not* portable. I say this for everyone's benefit, not because I think you wouldn't know Anch :) Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd -----Original Message----- From: Anch [mailto:mu...@ym...] Sent: Tuesday, 22 September 2009 11:41 PM To: gum...@li... Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program Hi Matthew, Sorry, I did check that you have already gone through the thread I asked you to read. So the problem as I mentioned in that patch was that Kernel supports reading the LSR register to get the state. So in an unmodified kernel source, the ioctl call will work. If you go through the kernel code for this call, it reads the LSR register and gives you a value. A gumstix patch disables this read. So you will end up getting a value which was last updated, which might not be the latest one. I had to modify the gumstix patch, which I am attaching. Actually, there were a couple of patches related to serial communication i combined them all in one. On the patch-information thread, I have mentioned what function you have to look at. Go through the patch file and you will figure out what I described above. BTW, this is the sample code I finally used in my app to set,reset the RTS line. if(write(main_app_instance.comm_port,message,message_len) == message_len) { do { ioctl(main_app_instance.comm_port, TIOCSERGETLSR, &status); } while (!(status & TIOCSER_TEMT)); //reset RTS line gpio(OUT, CLEAR, O_BTUART_RTS); } http://www.nabble.com/file/p25530730/bugfix-serial-register-status.patch bugfix-serial-register-status.patch If you do need more info, i will be glad to help. regards Anch Matthew Bowles-2 wrote: > > ok, I actually got this working. > > thanks for all the tips Dave, and for answering so quickly. > > I now have a new problem. > I am attempting to read the status of the port using a standard > control (copied from earlier work on a PC environment). > the code in question is ; > ioctl(serialport, TIOCSERGETLSR, &lsr); which should return me a > status word, so I can check that the buffer has finished transmitting > all bits, before returning the txrx direction to receive again. > > what I am being returned is a 1? Always a 1. I am not masking the word > first. > I can see on my oscilloscope that the data packet (8 bytes of > formatted > modbus) has not finished yet when my software gets a value of 1 from > the port status reg. > > my first question is - can anyone clarify that i am reading the port > correctly. > I have read here > http://www.nabble.com/Patch-information-td23601925.html, > that perhaps the status register is not properly supported by the > gumstix hardware/kernal/drivers. Is that true? > > second question is - does anybody know of a suitable alternative to > figuring out when the port is ready to be switched back to receiving > on the RS485 bus. I would prefer and non-timer-based solution for > elegance and portability, but I'm open to anything. > > thanks > > > Best regards > > Matt Bowles > Embedded Systems Engineer > aWma Pty Ltd > > > -----Original Message----- > From: Dave Hylands [mailto:dhy...@gm...] > Sent: Friday, 28 August 2009 2:12 PM > To: General mailing list for gumstix users. > Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C > program > > Hi Matt, > > On Thu, Aug 27, 2009 at 8:53 PM, Matthew Bowles<ma...@aw...> > wrote: >> Hi everyone >> >> I have got the GPIO access working in C. I did use fputs() instead of >> fwrite() just to simplify things, but what I am getting is a 50mS lag >> between. that is, the following code: >> >> fputs("GPIO out set",pGPIO_TxRx); >> fflush(pGPIO_TxRx); >> fputs("GPIO out clear",pGPIO_TxRx); >> fflush(pGPIO_TxRx); >> >> produces a trace with a +ve edge, followed by a delay of 48.4mS, and >> then a -ve edge. >> obviously there's some kernel polling of file-system writes or >> something. I assumed it would be near instaneous and I need it to be > within 3-5 mS. > > Using the gpregs technique will give you much faster changes. > >>From the archives: > <http://article.gmane.org/gmane.linux.distributions.gumstix.general/73 > 29> somebody got was able to write to a GPIO pin at about 6 MHz from > user space. > The "modified pxaregs" is essentially the same technique used by gpregs. > > Note: not a significant contributor, but the printk done by the kernel > when you do the above adds a little more than 3 msec to the time. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.DaveHylands.com/ > > ---------------------------------------------------------------------- > ------ > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day trial. Simplify your report design, integration and deployment > - and focus on what you do best, core application coding. Discover > what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: > 08/27/09 18:02:00 > > > ---------------------------------------------------------------------- > -------- Let Crystal Reports handle the reporting - Free Crystal > Reports 2008 30-Day trial. Simplify your report design, integration > and deployment - and focus on what you do best, core application > coding. Discover what's new with Crystal Reports now. > http://p.sf.net/sfu/bobj-july > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/GPIO-manipulation-from-a-user-space-C-program-tp251679 68p25530730.html Sent from the Gumstix mailing list archive at Nabble.com. ---------------------------------------------------------------------------- -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.110/2385 - Release Date: 09/21/09 17:55:00 |
From: richard d. <rdo...@gm...> - 2009-08-28 13:06:55
|
While writing to the /proc entry is easiest, it also adds delay because what you are *REALLY* doing is writing to a data structure, which the os then passes to the device driver, which when the device driver wakes up to handle it sees that it is a request to write to the gpio pin, which it then does. If you need your gpio pins to wiggle IMMEDIATELY upon writing to them, then you need to write directly to the hardware. RIck On Thu, Aug 27, 2009 at 10:53 PM, Matthew Bowles <ma...@aw...>wrote: > Hi everyone > > I have got the GPIO access working in C. I did use fputs() instead of > fwrite() just to simplify things, but what I am getting is a 50mS lag > between. that is, the following code: > > fputs("GPIO out set",pGPIO_TxRx); > fflush(pGPIO_TxRx); > fputs("GPIO out clear",pGPIO_TxRx); > fflush(pGPIO_TxRx); > > produces a trace with a +ve edge, followed by a delay of 48.4mS, and then a > -ve edge. > obviously there's some kernel polling of file-system writes or something. > I > assumed it would be near instaneous and I need it to be within 3-5 mS. > > I should have given some better detail on what I'm trying to achieve. > > I am attempting to get RS485 comms working from my GUMSTIX. At the moment > my > HW is not ready, but i am working on the synchronisation of the Transmit > enable (DE) (which is also the active-low Rx Enable) with the transmit > buffer. > > i have seen some examples of ioctl structure extensions to handle the RS485 > transmit enable sync'ing. And it seems to be industry standard to use the > RTS line of the serial port if it has one. > what I noticed, is that I can control the RTS line but only if the RTS/CTS > lines are activated in the serial port config, al la - "c_cflag |= > CRTSCTS;" > > there is a problem with doing this though - you are essentially enabling HW > flow control, which means driving CTS in some fashion to allow the port to > transmit. > > to avoid this I thought I would manually drive the TTL output of the RTS > pin. But i get the lagging I mentioned when I interact with the pin via the > filesystem. > > Does anyone have any experience with RS485 on the GUMSTIX platform? I may > attempt to get the gpregs stuff working unless someone says otherwise. > > any advice at all would be appreciated. > > > Best regards > > Matt Bowles > Embedded Systems Engineer > aWma Pty Ltd > > > -----Original Message----- > From: Dave Hylands [mailto:dhy...@gm...] > Sent: Friday, 28 August 2009 12:13 AM > To: General mailing list for gumstix users. > Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program > > Hi Matt, > > > I'm trying to track down the cleanest way of manipulating a GPIO > > signal on my gumstix board. I understand the IN/OUT and AF1, GPIO > > settings as I can get things working in shell-script land using `echo > > "GPIO OUT SET" > /proc/gpio/GPIO81` and that sort of thing. > > > > but in C, I presume its a bit cludgy to say something resembling > > - system("echo... /proc/gpio/, etc, etc"); > > Presuambly, this is for the verdex. If you want to use the proc interface, > then I would open the file (/proc/gpio/etc) using fopen, then fwrite "gpio > out set" to it and then fclose it. Wrap it up in a function and away you > go. > > > I have found an example here > > http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs > > which seems to be giving a nice wrapper around some functions. I am > > not willing to try it first though, as I've read about the kernel > > space versus user space limitations. I probably can't break anything > > and I'll look silly for being so cautious, but does anyone know if > > this is the way to work directly with hte GPIO lines in C, or am I > barking > up the wrong tree? > > If you want to write directly to the gpio lines, then you'd need to use the > gpregs approach. > > Another way is to write a custom driver and have the user space program > talk > to the custom driver. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.DaveHylands.com/ > > > ---------------------------------------------------------------------------- > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: 08/27/09 > 08:11:00 > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > -- Say you can or say you can't, either way you will be right. Computers are like old testament gods: Lots of rules and no mercy. |
From: Matthew B. <ma...@aw...> - 2009-08-27 22:34:20
|
Thanks Dave. I didn't even think of that.. my brain didn't seem to transition well from shell-script to C. :) thanks again. Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd -----Original Message----- From: Dave Hylands [mailto:dhy...@gm...] Sent: Friday, 28 August 2009 12:13 AM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program Hi Matt, > I'm trying to track down the cleanest way of manipulating a GPIO > signal on my gumstix board. I understand the IN/OUT and AF1, GPIO > settings as I can get things working in shell-script land using `echo > "GPIO OUT SET" > /proc/gpio/GPIO81` and that sort of thing. > > but in C, I presume its a bit cludgy to say something resembling > - system("echo... /proc/gpio/, etc, etc"); Presuambly, this is for the verdex. If you want to use the proc interface, then I would open the file (/proc/gpio/etc) using fopen, then fwrite "gpio out set" to it and then fclose it. Wrap it up in a function and away you go. > I have found an example here > http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs > which seems to be giving a nice wrapper around some functions. I am > not willing to try it first though, as I've read about the kernel > space versus user space limitations. I probably can't break anything > and I'll look silly for being so cautious, but does anyone know if > this is the way to work directly with hte GPIO lines in C, or am I barking up the wrong tree? If you want to write directly to the gpio lines, then you'd need to use the gpregs approach. Another way is to write a custom driver and have the user space program talk to the custom driver. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: 08/27/09 08:11:00 |
From: Anch <mu...@ym...> - 2009-09-22 13:19:41
|
HI Matthew, I couldnt go through the whole thread, but It seems you are trying to make rs-485 working on the gumstix. I made it work on my verdex pro using openembedded. I am not sure if you are using it. The culprit in my case a gumstix patch. The kernel updates the LSR register correctly, but a gumstix patch disables this. SO you will always get stale information when you try to read it and see if the message was transmitted successfully. check this link, http://www.nabble.com/Patch-information-tt23601925.html#a23601925 I have posted what I had to do to make it work. Hope this helps, else you can mail me and I can rewrite the whole thing step by step:) Regards Anch Matthew Bowles-2 wrote: > > Thanks Dave. > I didn't even think of that.. my brain didn't seem to transition well from > shell-script to C. :) > > thanks again. > > > Best regards > > Matt Bowles > Embedded Systems Engineer > aWma Pty Ltd > > > -----Original Message----- > From: Dave Hylands [mailto:dhy...@gm...] > Sent: Friday, 28 August 2009 12:13 AM > To: General mailing list for gumstix users. > Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program > > Hi Matt, > >> I'm trying to track down the cleanest way of manipulating a GPIO >> signal on my gumstix board. I understand the IN/OUT and AF1, GPIO >> settings as I can get things working in shell-script land using `echo >> "GPIO OUT SET" > /proc/gpio/GPIO81` and that sort of thing. >> >> but in C, I presume its a bit cludgy to say something resembling >> - system("echo... /proc/gpio/, etc, etc"); > > Presuambly, this is for the verdex. If you want to use the proc interface, > then I would open the file (/proc/gpio/etc) using fopen, then fwrite "gpio > out set" to it and then fclose it. Wrap it up in a function and away you > go. > >> I have found an example here >> http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs >> which seems to be giving a nice wrapper around some functions. I am >> not willing to try it first though, as I've read about the kernel >> space versus user space limitations. I probably can't break anything >> and I'll look silly for being so cautious, but does anyone know if >> this is the way to work directly with hte GPIO lines in C, or am I >> barking > up the wrong tree? > > If you want to write directly to the gpio lines, then you'd need to use > the > gpregs approach. > > Another way is to write a custom driver and have the user space program > talk > to the custom driver. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.DaveHylands.com/ > > ---------------------------------------------------------------------------- > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and focus > on what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: 08/27/09 > 08:11:00 > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/GPIO-manipulation-from-a-user-space-C-program-tp25167968p25530714.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: richard d. <rdo...@gm...> - 2009-08-28 13:16:48
|
Usually , when someone tells me they want to do something like this, I generally suggest putting it all into the serial device driver. If they need stateful infomration, like handling some kind of simple ack/nak protocol and turnign the 485 transceiver on and off, then Doing so with a static state variable works nicely to remember state across ISR's. From there, instead of just having the serial port generate an ISR on thre and rxrdy, have it also generate an ISR on status register state change. Not sure if the serial port on the overo/verdex is very flexible with what kinds of isr's it can generate, but it will most certainly get your 485 line turned around within a millisecond or two of shoveling out the last bit. Rick On Thu, Aug 27, 2009 at 10:53 PM, Matthew Bowles <ma...@aw...>wrote: > Hi everyone > > I have got the GPIO access working in C. I did use fputs() instead of > fwrite() just to simplify things, but what I am getting is a 50mS lag > between. that is, the following code: > > fputs("GPIO out set",pGPIO_TxRx); > fflush(pGPIO_TxRx); > fputs("GPIO out clear",pGPIO_TxRx); > fflush(pGPIO_TxRx); > > produces a trace with a +ve edge, followed by a delay of 48.4mS, and then a > -ve edge. > obviously there's some kernel polling of file-system writes or something. > I > assumed it would be near instaneous and I need it to be within 3-5 mS. > > I should have given some better detail on what I'm trying to achieve. > > I am attempting to get RS485 comms working from my GUMSTIX. At the moment > my > HW is not ready, but i am working on the synchronisation of the Transmit > enable (DE) (which is also the active-low Rx Enable) with the transmit > buffer. > > i have seen some examples of ioctl structure extensions to handle the RS485 > transmit enable sync'ing. And it seems to be industry standard to use the > RTS line of the serial port if it has one. > what I noticed, is that I can control the RTS line but only if the RTS/CTS > lines are activated in the serial port config, al la - "c_cflag |= > CRTSCTS;" > > there is a problem with doing this though - you are essentially enabling HW > flow control, which means driving CTS in some fashion to allow the port to > transmit. > > to avoid this I thought I would manually drive the TTL output of the RTS > pin. But i get the lagging I mentioned when I interact with the pin via the > filesystem. > > Does anyone have any experience with RS485 on the GUMSTIX platform? I may > attempt to get the gpregs stuff working unless someone says otherwise. > > any advice at all would be appreciated. > > > Best regards > > Matt Bowles > Embedded Systems Engineer > aWma Pty Ltd > > > -----Original Message----- > From: Dave Hylands [mailto:dhy...@gm...] > Sent: Friday, 28 August 2009 12:13 AM > To: General mailing list for gumstix users. > Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program > > Hi Matt, > > > I'm trying to track down the cleanest way of manipulating a GPIO > > signal on my gumstix board. I understand the IN/OUT and AF1, GPIO > > settings as I can get things working in shell-script land using `echo > > "GPIO OUT SET" > /proc/gpio/GPIO81` and that sort of thing. > > > > but in C, I presume its a bit cludgy to say something resembling > > - system("echo... /proc/gpio/, etc, etc"); > > Presuambly, this is for the verdex. If you want to use the proc interface, > then I would open the file (/proc/gpio/etc) using fopen, then fwrite "gpio > out set" to it and then fclose it. Wrap it up in a function and away you > go. > > > I have found an example here > > http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs > > which seems to be giving a nice wrapper around some functions. I am > > not willing to try it first though, as I've read about the kernel > > space versus user space limitations. I probably can't break anything > > and I'll look silly for being so cautious, but does anyone know if > > this is the way to work directly with hte GPIO lines in C, or am I > barking > up the wrong tree? > > If you want to write directly to the gpio lines, then you'd need to use the > gpregs approach. > > Another way is to write a custom driver and have the user space program > talk > to the custom driver. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.DaveHylands.com/ > > > ---------------------------------------------------------------------------- > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: 08/27/09 > 08:11:00 > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > -- Say you can or say you can't, either way you will be right. Computers are like old testament gods: Lots of rules and no mercy. |
From: Dave H. <dhy...@gm...> - 2009-08-28 15:19:13
|
Hi Matt, On Fri, Aug 28, 2009 at 6:16 AM, richard dorfner<rdo...@gm...> wrote: > Usually , when someone tells me they want to do something like this, I > generally suggest putting it all into the serial device driver. If they > need stateful infomration, like handling some kind of simple ack/nak > protocol and turnign the 485 transceiver on and off, then Doing so with a > static state variable works nicely to remember state across ISR's. From > there, instead of just having the serial port generate an ISR on thre and > rxrdy, have it also generate an ISR on status register state change. > > Not sure if the serial port on the overo/verdex is very flexible with what > kinds of isr's it can generate, but it will most certainly get your 485 line > turned around within a millisecond or two of shoveling out the last bit. Personally, I'm with Rick, in that I would be inclined to do this from kernel space. There are at least 3 buffers that need to be cleared 1 - The buffer that the uart driver uses 2 - The hardware FIFO that the uart HW has 3 - The shift register which holds the current character being transmitted. It's not until all 3 of these are empty that you're done. The uart driver has the most amount of information available to it to make that determination. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: Matthew B. <ma...@aw...> - 2009-08-30 23:59:07
|
Hi everyone thanks for the info Rick. I'm actually using a basix-200 COM. I will not be able to play with device drivers and kernel space software. Our product has a fixed rootfs that i haven't modified for a few years, and all our custom software resides on various MMC partitions. Dave mentioned that there were 3 things I need to keep track of to know when to revert back to receive mode: watch 2 buffers, and the shift-register empty flags. I believed that I could track all of this information by reading the "TIOCSERGETLSR" status register using ioclt(). I can read that register but it doesn't seem to contain information that relates to the serial port. The 1bit flag that should reflect the shift-register empty state, is always 1 (which means empty). perhaps i need to read it a few times? maybe i'm reading it too quickly after writing a packet to the buffer? does anyone have a good resource for the contents of the "TIOCSERGETLSR" status register, or perhaps a more suitable status register, and maybe any GUMSTIX specific parts of those registers? thank you. Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd _____ From: richard dorfner [mailto:rdo...@gm...] Sent: Friday, 28 August 2009 11:16 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program Usually , when someone tells me they want to do something like this, I generally suggest putting it all into the serial device driver. If they need stateful infomration, like handling some kind of simple ack/nak protocol and turnign the 485 transceiver on and off, then Doing so with a static state variable works nicely to remember state across ISR's. From there, instead of just having the serial port generate an ISR on thre and rxrdy, have it also generate an ISR on status register state change. Not sure if the serial port on the overo/verdex is very flexible with what kinds of isr's it can generate, but it will most certainly get your 485 line turned around within a millisecond or two of shoveling out the last bit. Rick On Thu, Aug 27, 2009 at 10:53 PM, Matthew Bowles <ma...@aw...> wrote: Hi everyone I have got the GPIO access working in C. I did use fputs() instead of fwrite() just to simplify things, but what I am getting is a 50mS lag between. that is, the following code: fputs("GPIO out set",pGPIO_TxRx); fflush(pGPIO_TxRx); fputs("GPIO out clear",pGPIO_TxRx); fflush(pGPIO_TxRx); produces a trace with a +ve edge, followed by a delay of 48.4mS, and then a -ve edge. obviously there's some kernel polling of file-system writes or something. I assumed it would be near instaneous and I need it to be within 3-5 mS. I should have given some better detail on what I'm trying to achieve. I am attempting to get RS485 comms working from my GUMSTIX. At the moment my HW is not ready, but i am working on the synchronisation of the Transmit enable (DE) (which is also the active-low Rx Enable) with the transmit buffer. i have seen some examples of ioctl structure extensions to handle the RS485 transmit enable sync'ing. And it seems to be industry standard to use the RTS line of the serial port if it has one. what I noticed, is that I can control the RTS line but only if the RTS/CTS lines are activated in the serial port config, al la - "c_cflag |= CRTSCTS;" there is a problem with doing this though - you are essentially enabling HW flow control, which means driving CTS in some fashion to allow the port to transmit. to avoid this I thought I would manually drive the TTL output of the RTS pin. But i get the lagging I mentioned when I interact with the pin via the filesystem. Does anyone have any experience with RS485 on the GUMSTIX platform? I may attempt to get the gpregs stuff working unless someone says otherwise. any advice at all would be appreciated. Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd -----Original Message----- From: Dave Hylands [mailto:dhy...@gm...] Sent: Friday, 28 August 2009 12:13 AM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program Hi Matt, > I'm trying to track down the cleanest way of manipulating a GPIO > signal on my gumstix board. I understand the IN/OUT and AF1, GPIO > settings as I can get things working in shell-script land using `echo > "GPIO OUT SET" > /proc/gpio/GPIO81` and that sort of thing. > > but in C, I presume its a bit cludgy to say something resembling > - system("echo... /proc/gpio/, etc, etc"); Presuambly, this is for the verdex. If you want to use the proc interface, then I would open the file (/proc/gpio/etc) using fopen, then fwrite "gpio out set" to it and then fclose it. Wrap it up in a function and away you go. > I have found an example here > http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs > which seems to be giving a nice wrapper around some functions. I am > not willing to try it first though, as I've read about the kernel > space versus user space limitations. I probably can't break anything > and I'll look silly for being so cautious, but does anyone know if > this is the way to work directly with hte GPIO lines in C, or am I barking up the wrong tree? If you want to write directly to the gpio lines, then you'd need to use the gpregs approach. Another way is to write a custom driver and have the user space program talk to the custom driver. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: 08/27/09 08:11:00 ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users -- Say you can or say you can't, either way you will be right. Computers are like old testament gods: Lots of rules and no mercy. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: 08/27/09 18:02:00 |
From: richard d. <rdo...@gm...> - 2009-08-31 03:44:31
|
well, it is quite possible that you are getting everything sent out before you ever manage to get that bit read. When you have to go through the drivers to get status like that, it takes time. a few to perhaps ten or more milliseconds.So, at 9600 baud, n,8,1 given the start bit, a stop bit and 8 data bits, you are likely going to have about 1millisecond per character.. so if you message if 5 characters long, and you send it via the driver, then go to read the status register and it takes ten milliseconds to get that status back, you are very likely going to find that you will NEVER see that bit being low since by teh time you get to it, all the serial data has indeed been sent. SO.. an experiment might help you out here.. Try sending a 1kilobyte long message, and THEN start spinning on that bit that tells you if the shift register is empty or not. I am assuming that the driver will queue up all those bytes so that it frees your program from having to wait on them actually going out the data line on the serial port. You should then see that the bit will be low for a while before it comes high. If you want, you can also get the system time when you start looking, and then the system time when it actually goes high and start figuring out your latency times as well. Rick On Sun, Aug 30, 2009 at 6:58 PM, Matthew Bowles <ma...@aw...> wrote: > Hi everyone > > thanks for the info Rick. > > I'm actually using a basix-200 COM. I will not be able to play with device > drivers and kernel space software. Our product has a fixed rootfs that i > haven't modified for a few years, and all our custom software resides on > various MMC partitions. > > Dave mentioned that there were 3 things I need to keep track of to know > when to revert back to receive mode: watch 2 buffers, and the shift-register > empty flags. I believed that I could track all of this information by > reading the "TIOCSERGETLSR" status register using ioclt(). I can read that > register but it doesn't seem to contain information that relates to the > serial port. > > The 1bit flag that should reflect the shift-register empty state, is always > 1 (which means empty). perhaps i need to read it a few times? maybe i'm > reading it too quickly after writing a packet to the buffer? > > does anyone have a good resource for the contents of the "TIOCSERGETLSR" > status register, or perhaps a more suitable status register, and maybe any > GUMSTIX specific parts of those registers? > > thank you. > > Best regards > > Matt Bowles > Embedded Systems Engineer > *aWma**** Pty Ltd* > > > ------------------------------ > *From:* richard dorfner [mailto:rdo...@gm...] > *Sent:* Friday, 28 August 2009 11:16 PM > > *To:* General mailing list for gumstix users. > *Subject:* Re: [Gumstix-users] GPIO manipulation from a user-space C > program > > Usually , when someone tells me they want to do something like this, I > generally suggest putting it all into the serial device driver. If they > need stateful infomration, like handling some kind of simple ack/nak > protocol and turnign the 485 transceiver on and off, then Doing so with a > static state variable works nicely to remember state across ISR's. From > there, instead of just having the serial port generate an ISR on thre and > rxrdy, have it also generate an ISR on status register state change. > > Not sure if the serial port on the overo/verdex is very flexible with what > kinds of isr's it can generate, but it will most certainly get your 485 line > turned around within a millisecond or two of shoveling out the last bit. > > Rick > > > On Thu, Aug 27, 2009 at 10:53 PM, Matthew Bowles <ma...@aw...>wrote: > >> Hi everyone >> >> I have got the GPIO access working in C. I did use fputs() instead of >> fwrite() just to simplify things, but what I am getting is a 50mS lag >> between. that is, the following code: >> >> fputs("GPIO out set",pGPIO_TxRx); >> fflush(pGPIO_TxRx); >> fputs("GPIO out clear",pGPIO_TxRx); >> fflush(pGPIO_TxRx); >> >> produces a trace with a +ve edge, followed by a delay of 48.4mS, and then >> a >> -ve edge. >> obviously there's some kernel polling of file-system writes or something. >> I >> assumed it would be near instaneous and I need it to be within 3-5 mS. >> >> I should have given some better detail on what I'm trying to achieve. >> >> I am attempting to get RS485 comms working from my GUMSTIX. At the moment >> my >> HW is not ready, but i am working on the synchronisation of the Transmit >> enable (DE) (which is also the active-low Rx Enable) with the transmit >> buffer. >> >> i have seen some examples of ioctl structure extensions to handle the >> RS485 >> transmit enable sync'ing. And it seems to be industry standard to use the >> RTS line of the serial port if it has one. >> what I noticed, is that I can control the RTS line but only if the RTS/CTS >> lines are activated in the serial port config, al la - "c_cflag |= >> CRTSCTS;" >> >> there is a problem with doing this though - you are essentially enabling >> HW >> flow control, which means driving CTS in some fashion to allow the port to >> transmit. >> >> to avoid this I thought I would manually drive the TTL output of the RTS >> pin. But i get the lagging I mentioned when I interact with the pin via >> the >> filesystem. >> >> Does anyone have any experience with RS485 on the GUMSTIX platform? I may >> attempt to get the gpregs stuff working unless someone says otherwise. >> >> any advice at all would be appreciated. >> >> >> Best regards >> >> Matt Bowles >> Embedded Systems Engineer >> aWma Pty Ltd >> >> >> -----Original Message----- >> From: Dave Hylands [mailto:dhy...@gm...] >> Sent: Friday, 28 August 2009 12:13 AM >> To: General mailing list for gumstix users. >> Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program >> >> Hi Matt, >> >> > I'm trying to track down the cleanest way of manipulating a GPIO >> > signal on my gumstix board. I understand the IN/OUT and AF1, GPIO >> > settings as I can get things working in shell-script land using `echo >> > "GPIO OUT SET" > /proc/gpio/GPIO81` and that sort of thing. >> > >> > but in C, I presume its a bit cludgy to say something resembling >> > - system("echo... /proc/gpio/, etc, etc"); >> >> Presuambly, this is for the verdex. If you want to use the proc interface, >> then I would open the file (/proc/gpio/etc) using fopen, then fwrite "gpio >> out set" to it and then fclose it. Wrap it up in a function and away you >> go. >> >> > I have found an example here >> > http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs >> > which seems to be giving a nice wrapper around some functions. I am >> > not willing to try it first though, as I've read about the kernel >> > space versus user space limitations. I probably can't break anything >> > and I'll look silly for being so cautious, but does anyone know if >> > this is the way to work directly with hte GPIO lines in C, or am I >> barking >> up the wrong tree? >> >> If you want to write directly to the gpio lines, then you'd need to use >> the >> gpregs approach. >> >> Another way is to write a custom driver and have the user space program >> talk >> to the custom driver. >> >> -- >> Dave Hylands >> Shuswap, BC, Canada >> http://www.DaveHylands.com/ >> >> >> ---------------------------------------------------------------------------- >> -- >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: 08/27/09 >> 08:11:00 >> >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > > > -- > Say you can or say you can't, either way you will be right. > Computers are like old testament gods: Lots of rules and no mercy. > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: 08/27/09 > 18:02:00 > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- Say you can or say you can't, either way you will be right. Computers are like old testament gods: Lots of rules and no mercy. |
From: Matthew B. <ma...@aw...> - 2009-08-31 04:07:58
|
very good tips here for anyone else following. But that's the only bit where I am very comfortable in knowing what's happening. My packet is a 8 byte mesage(Modbus RTU if you're interested). The gory details are as follows. my code does the following. 1. Set RTS high. 2. write packet to port. (buffered to begin with of course) 3. check LSR (status reg.) 4. Clear RTS low. my dig. analyser shows that: - It takes just shy of 8mS to transmit the message - from the RTS going high to the start bit of the first byte is 200uS. - the RTS line comes up just over 3mS later (which is still within the packet-sending timeframe) so from that I am very confident that the LSR is being read whilst the port is still pumping bits out. However - the one unknown is the sync of the shift-reg empty bit to my read. Perhaps I am reading it when it is momentarily empty between successive bytes. I cannot prove this either way. Can anyone shed some light on a good fix for this? also, I have found precious little detail on the bits and flags within the LSR - ie. the data struct of that register. has anyone got some good resource on that front? thank you all Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd _____ From: richard dorfner [mailto:rdo...@gm...] Sent: Monday, 31 August 2009 1:44 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program well, it is quite possible that you are getting everything sent out before you ever manage to get that bit read. When you have to go through the drivers to get status like that, it takes time. a few to perhaps ten or more milliseconds. So, at 9600 baud, n,8,1 given the start bit, a stop bit and 8 data bits, you are likely going to have about 1millisecond per character.. so if you message if 5 characters long, and you send it via the driver, then go to read the status register and it takes ten milliseconds to get that status back, you are very likely going to find that you will NEVER see that bit being low since by teh time you get to it, all the serial data has indeed been sent. SO.. an experiment might help you out here.. Try sending a 1kilobyte long message, and THEN start spinning on that bit that tells you if the shift register is empty or not. I am assuming that the driver will queue up all those bytes so that it frees your program from having to wait on them actually going out the data line on the serial port. You should then see that the bit will be low for a while before it comes high. If you want, you can also get the system time when you start looking, and then the system time when it actually goes high and start figuring out your latency times as well. Rick On Sun, Aug 30, 2009 at 6:58 PM, Matthew Bowles <ma...@aw...> wrote: Hi everyone thanks for the info Rick. I'm actually using a basix-200 COM. I will not be able to play with device drivers and kernel space software. Our product has a fixed rootfs that i haven't modified for a few years, and all our custom software resides on various MMC partitions. Dave mentioned that there were 3 things I need to keep track of to know when to revert back to receive mode: watch 2 buffers, and the shift-register empty flags. I believed that I could track all of this information by reading the "TIOCSERGETLSR" status register using ioclt(). I can read that register but it doesn't seem to contain information that relates to the serial port. The 1bit flag that should reflect the shift-register empty state, is always 1 (which means empty). perhaps i need to read it a few times? maybe i'm reading it too quickly after writing a packet to the buffer? does anyone have a good resource for the contents of the "TIOCSERGETLSR" status register, or perhaps a more suitable status register, and maybe any GUMSTIX specific parts of those registers? thank you. Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd _____ From: richard dorfner [mailto:rdo...@gm...] Sent: Friday, 28 August 2009 11:16 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program Usually , when someone tells me they want to do something like this, I generally suggest putting it all into the serial device driver. If they need stateful infomration, like handling some kind of simple ack/nak protocol and turnign the 485 transceiver on and off, then Doing so with a static state variable works nicely to remember state across ISR's. From there, instead of just having the serial port generate an ISR on thre and rxrdy, have it also generate an ISR on status register state change. Not sure if the serial port on the overo/verdex is very flexible with what kinds of isr's it can generate, but it will most certainly get your 485 line turned around within a millisecond or two of shoveling out the last bit. Rick On Thu, Aug 27, 2009 at 10:53 PM, Matthew Bowles <ma...@aw...> wrote: Hi everyone I have got the GPIO access working in C. I did use fputs() instead of fwrite() just to simplify things, but what I am getting is a 50mS lag between. that is, the following code: fputs("GPIO out set",pGPIO_TxRx); fflush(pGPIO_TxRx); fputs("GPIO out clear",pGPIO_TxRx); fflush(pGPIO_TxRx); produces a trace with a +ve edge, followed by a delay of 48.4mS, and then a -ve edge. obviously there's some kernel polling of file-system writes or something. I assumed it would be near instaneous and I need it to be within 3-5 mS. I should have given some better detail on what I'm trying to achieve. I am attempting to get RS485 comms working from my GUMSTIX. At the moment my HW is not ready, but i am working on the synchronisation of the Transmit enable (DE) (which is also the active-low Rx Enable) with the transmit buffer. i have seen some examples of ioctl structure extensions to handle the RS485 transmit enable sync'ing. And it seems to be industry standard to use the RTS line of the serial port if it has one. what I noticed, is that I can control the RTS line but only if the RTS/CTS lines are activated in the serial port config, al la - "c_cflag |= CRTSCTS;" there is a problem with doing this though - you are essentially enabling HW flow control, which means driving CTS in some fashion to allow the port to transmit. to avoid this I thought I would manually drive the TTL output of the RTS pin. But i get the lagging I mentioned when I interact with the pin via the filesystem. Does anyone have any experience with RS485 on the GUMSTIX platform? I may attempt to get the gpregs stuff working unless someone says otherwise. any advice at all would be appreciated. Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd -----Original Message----- From: Dave Hylands [mailto:dhy...@gm...] Sent: Friday, 28 August 2009 12:13 AM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program Hi Matt, > I'm trying to track down the cleanest way of manipulating a GPIO > signal on my gumstix board. I understand the IN/OUT and AF1, GPIO > settings as I can get things working in shell-script land using `echo > "GPIO OUT SET" > /proc/gpio/GPIO81` and that sort of thing. > > but in C, I presume its a bit cludgy to say something resembling > - system("echo... /proc/gpio/, etc, etc"); Presuambly, this is for the verdex. If you want to use the proc interface, then I would open the file (/proc/gpio/etc) using fopen, then fwrite "gpio out set" to it and then fclose it. Wrap it up in a function and away you go. > I have found an example here > http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs > which seems to be giving a nice wrapper around some functions. I am > not willing to try it first though, as I've read about the kernel > space versus user space limitations. I probably can't break anything > and I'll look silly for being so cautious, but does anyone know if > this is the way to work directly with hte GPIO lines in C, or am I barking up the wrong tree? If you want to write directly to the gpio lines, then you'd need to use the gpregs approach. Another way is to write a custom driver and have the user space program talk to the custom driver. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: 08/27/09 08:11:00 ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users -- Say you can or say you can't, either way you will be right. Computers are like old testament gods: Lots of rules and no mercy. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: 08/27/09 18:02:00 ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users -- Say you can or say you can't, either way you will be right. Computers are like old testament gods: Lots of rules and no mercy. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.71/2336 - Release Date: 08/30/09 17:51:00 |
From: Dave H. <dhy...@gm...> - 2009-08-31 06:24:37
|
Hi Matt, > my dig. analyser shows that: > - It takes just shy of 8mS to transmit the message > - from the RTS going high to the start bit of the first byte is 200uS. > - the RTS line comes up just over 3mS later (which is still within the > packet-sending timeframe) > > so from that I am very confident that the LSR is being read whilst the port > is still pumping bits out. However - the one unknown is the sync of the > shift-reg empty bit to my read. Perhaps I am reading it when it is > momentarily empty between successive bytes. I cannot prove this either way. > > Can anyone shed some light on a good fix for this? also, I have found > precious little detail on the bits and flags within the LSR - ie. the data > struct of that register. has anyone got some good resource on that front? I believe that the LSR register originates from the 8250 register set: <http://www.techedge.com.au/tech/8250tec.htm> Try calling tcdrain. It supposedly doesn't return until all of the data written to the file descriptor has been transmitted. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: richard d. <rdo...@gm...> - 2009-08-31 13:04:10
|
Hmmm, so much for THAT idea then. And from what you are saying, yeah, I'd agree, timing is likely not at all the issue. At this point, I would have to say it would be worth your time venturing down into the device driver itself and seeing what the serial port is doing. It might be that the driver is not functioning correctly, or it might be that the driver is returning information that isn't quite what we understand. As Dave has asserted, it would seem that the driver just would return the LSR right off of the serial port without any modification. It's the easiest, quickest way to get status back up to user land without adding tons of abstraction. And since it's a user land program, you probably are better served doing as he sugggested and just calling the function that holds you off automagically until the data is gone, that way you don't have to CARE if it's still sending or not, you just know it's gone and you can do what you need to. Your supposition on the bit being read int he middle of finishing a shift vs. getting the next byte, while POSSIBLE, if very improbable. The serial ports that I have seen tend to not raise that bit until all data has been sent, completely, from the serial holding register, and the serial shifft register. So typically, as long as the holding register has some data in it, that serial shift register will also be asserted. Rick On Sun, Aug 30, 2009 at 11:07 PM, Matthew Bowles <ma...@aw...>wrote: > very good tips here for anyone else following. > But that's the only bit where I am very comfortable in knowing what's > happening. > My packet is a 8 byte mesage(Modbus RTU if you're interested). > > The gory details are as follows. > my code does the following. > 1. Set RTS high. > 2. write packet to port. (buffered to begin with of course) > 3. check LSR (status reg.) > 4. Clear RTS low. > > my dig. analyser shows that: > - It takes just shy of 8mS to transmit the message > - from the RTS going high to the start bit of the first byte is 200uS. > - the RTS line comes up just over 3mS later (which is still within the > packet-sending timeframe) > > so from that I am very confident that the LSR is being read whilst the port > is still pumping bits out. However - the one unknown is the sync of the > shift-reg empty bit to my read. Perhaps I am reading it when it is > momentarily empty between successive bytes. I cannot prove this either way. > > Can anyone shed some light on a good fix for this? also, I have found > precious little detail on the bits and flags within the LSR - ie. the data > struct of that register. has anyone got some good resource on that front? > > thank you all > > Best regards > > Matt Bowles > Embedded Systems Engineer > *aWma**** Pty Ltd* > > > ------------------------------ > *From:* richard dorfner [mailto:rdo...@gm...] > *Sent:* Monday, 31 August 2009 1:44 PM > > *To:* General mailing list for gumstix users. > *Subject:* Re: [Gumstix-users] GPIO manipulation from a user-space C > program > > well, it is quite possible that you are getting everything sent out before > you ever manage to get that bit read. When you have to go through the > drivers to get status like that, it takes time. a few to perhaps ten or > more milliseconds. So, at 9600 baud, n,8,1 given the start bit, a stop bit > and 8 data bits, you are likely going to have about 1millisecond per > character.. so if you message if 5 characters long, and you send it via the > driver, then go to read the status register and it takes ten milliseconds to > get that status back, you are very likely going to find that you will NEVER > see that bit being low since by teh time you get to it, all the serial data > has indeed been sent. > > SO.. an experiment might help you out here.. > > Try sending a 1kilobyte long message, and THEN start spinning on that bit > that tells you if the shift register is empty or not. > I am assuming that the driver will queue up all those bytes so that it > frees your program from having to wait on them actually going out the data > line on the serial port. You should then see that the bit will be low for a > while before it comes high. > > If you want, you can also get the system time when you start looking, and > then the system time when it actually goes high and start figuring out your > latency times as well. > > Rick > > > > On Sun, Aug 30, 2009 at 6:58 PM, Matthew Bowles <ma...@aw...>wrote: > >> Hi everyone >> >> thanks for the info Rick. >> >> I'm actually using a basix-200 COM. I will not be able to play with device >> drivers and kernel space software. Our product has a fixed rootfs that i >> haven't modified for a few years, and all our custom software resides on >> various MMC partitions. >> >> Dave mentioned that there were 3 things I need to keep track of to know >> when to revert back to receive mode: watch 2 buffers, and the shift-register >> empty flags. I believed that I could track all of this information by >> reading the "TIOCSERGETLSR" status register using ioclt(). I can read >> that register but it doesn't seem to contain information that relates to the >> serial port. >> >> The 1bit flag that should reflect the shift-register empty state, is >> always 1 (which means empty). perhaps i need to read it a few times? maybe >> i'm reading it too quickly after writing a packet to the buffer? >> >> does anyone have a good resource for the contents of the "TIOCSERGETLSR" >> status register, or perhaps a more suitable status register, and maybe any >> GUMSTIX specific parts of those registers? >> >> thank you. >> >> Best regards >> >> Matt Bowles >> Embedded Systems Engineer >> *aWma**** Pty Ltd* >> >> >> ------------------------------ >> *From:* richard dorfner [mailto:rdo...@gm...] >> *Sent:* Friday, 28 August 2009 11:16 PM >> >> *To:* General mailing list for gumstix users. >> *Subject:* Re: [Gumstix-users] GPIO manipulation from a user-space C >> program >> >> Usually , when someone tells me they want to do something like this, I >> generally suggest putting it all into the serial device driver. If they >> need stateful infomration, like handling some kind of simple ack/nak >> protocol and turnign the 485 transceiver on and off, then Doing so with a >> static state variable works nicely to remember state across ISR's. From >> there, instead of just having the serial port generate an ISR on thre and >> rxrdy, have it also generate an ISR on status register state change. >> >> Not sure if the serial port on the overo/verdex is very flexible with what >> kinds of isr's it can generate, but it will most certainly get your 485 line >> turned around within a millisecond or two of shoveling out the last bit. >> >> Rick >> >> >> On Thu, Aug 27, 2009 at 10:53 PM, Matthew Bowles <ma...@aw...>wrote: >> >>> Hi everyone >>> >>> I have got the GPIO access working in C. I did use fputs() instead of >>> fwrite() just to simplify things, but what I am getting is a 50mS lag >>> between. that is, the following code: >>> >>> fputs("GPIO out set",pGPIO_TxRx); >>> fflush(pGPIO_TxRx); >>> fputs("GPIO out clear",pGPIO_TxRx); >>> fflush(pGPIO_TxRx); >>> >>> produces a trace with a +ve edge, followed by a delay of 48.4mS, and then >>> a >>> -ve edge. >>> obviously there's some kernel polling of file-system writes or something. >>> I >>> assumed it would be near instaneous and I need it to be within 3-5 mS. >>> >>> I should have given some better detail on what I'm trying to achieve. >>> >>> I am attempting to get RS485 comms working from my GUMSTIX. At the moment >>> my >>> HW is not ready, but i am working on the synchronisation of the Transmit >>> enable (DE) (which is also the active-low Rx Enable) with the transmit >>> buffer. >>> >>> i have seen some examples of ioctl structure extensions to handle the >>> RS485 >>> transmit enable sync'ing. And it seems to be industry standard to use the >>> RTS line of the serial port if it has one. >>> what I noticed, is that I can control the RTS line but only if the >>> RTS/CTS >>> lines are activated in the serial port config, al la - "c_cflag |= >>> CRTSCTS;" >>> >>> there is a problem with doing this though - you are essentially enabling >>> HW >>> flow control, which means driving CTS in some fashion to allow the port >>> to >>> transmit. >>> >>> to avoid this I thought I would manually drive the TTL output of the RTS >>> pin. But i get the lagging I mentioned when I interact with the pin via >>> the >>> filesystem. >>> >>> Does anyone have any experience with RS485 on the GUMSTIX platform? I may >>> attempt to get the gpregs stuff working unless someone says otherwise. >>> >>> any advice at all would be appreciated. >>> >>> >>> Best regards >>> >>> Matt Bowles >>> Embedded Systems Engineer >>> aWma Pty Ltd >>> >>> >>> -----Original Message----- >>> From: Dave Hylands [mailto:dhy...@gm...] >>> Sent: Friday, 28 August 2009 12:13 AM >>> To: General mailing list for gumstix users. >>> Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C >>> program >>> >>> Hi Matt, >>> >>> > I'm trying to track down the cleanest way of manipulating a GPIO >>> > signal on my gumstix board. I understand the IN/OUT and AF1, GPIO >>> > settings as I can get things working in shell-script land using `echo >>> > "GPIO OUT SET" > /proc/gpio/GPIO81` and that sort of thing. >>> > >>> > but in C, I presume its a bit cludgy to say something resembling >>> > - system("echo... /proc/gpio/, etc, etc"); >>> >>> Presuambly, this is for the verdex. If you want to use the proc >>> interface, >>> then I would open the file (/proc/gpio/etc) using fopen, then fwrite >>> "gpio >>> out set" to it and then fclose it. Wrap it up in a function and away you >>> go. >>> >>> > I have found an example here >>> > http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs >>> > which seems to be giving a nice wrapper around some functions. I am >>> > not willing to try it first though, as I've read about the kernel >>> > space versus user space limitations. I probably can't break anything >>> > and I'll look silly for being so cautious, but does anyone know if >>> > this is the way to work directly with hte GPIO lines in C, or am I >>> barking >>> up the wrong tree? >>> >>> If you want to write directly to the gpio lines, then you'd need to use >>> the >>> gpregs approach. >>> >>> Another way is to write a custom driver and have the user space program >>> talk >>> to the custom driver. >>> >>> -- >>> Dave Hylands >>> Shuswap, BC, Canada >>> http://www.DaveHylands.com/ >>> >>> >>> ---------------------------------------------------------------------------- >>> -- >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day >>> trial. Simplify your report design, integration and deployment - and >>> focus >>> on what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> No virus found in this incoming message. >>> Checked by AVG - www.avg.com >>> Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: >>> 08/27/09 >>> 08:11:00 >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day >>> trial. Simplify your report design, integration and deployment - and >>> focus on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >> >> >> >> -- >> Say you can or say you can't, either way you will be right. >> Computers are like old testament gods: Lots of rules and no mercy. >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: 08/27/09 >> 18:02:00 >> >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > > -- > Say you can or say you can't, either way you will be right. > Computers are like old testament gods: Lots of rules and no mercy. > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.409 / Virus Database: 270.13.71/2336 - Release Date: 08/30/09 > 17:51:00 > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- Say you can or say you can't, either way you will be right. Computers are like old testament gods: Lots of rules and no mercy. |
From: Felipe B. C. <cav...@gm...> - 2009-08-31 13:58:33
|
I did have some problems with the timing on the Gumstix as well - my solution was to switch to a real-time Linux system (Xenomai - I am writing a tech note on how to get it to work on the OpenEmbedded platrform) and than use memory manipulation functions to edit the desired registers directly. I can now read/write to the serial port within 500 us (with no buffered data), and GPIO functions take around 100us (at most). Maybe it is a solution worth looking at. However, I did have to write quite a bit of custom code to get it to work, and testing has only been done by me so far. I am organizing most of it, and I am planning on making that available as soon as possible. Hope this helps, -- -Felipe Brandão Cavalcanti LARA - Robotics and Automation Laboratory Department of Electrical Engineering UnB - University of Brasília, Brazil http://www.lara.unb.br/ On Mon, Aug 31, 2009 at 10:03 AM, richard dorfner <rdo...@gm...>wrote: > Hmmm, so much for THAT idea then. And from what you are saying, yeah, I'd > agree, timing is likely not at all the issue. > > At this point, I would have to say it would be worth your time venturing > down into the device driver itself and seeing what the serial port is > doing. > > It might be that the driver is not functioning correctly, or it might be > that the driver is returning information that isn't quite what we > understand. > > As Dave has asserted, it would seem that the driver just would return the > LSR right off of the serial port without any modification. It's the > easiest, quickest way to get status back up to user land without adding tons > of abstraction. And since it's a user land program, you probably are better > served doing as he sugggested and just calling the function that holds you > off automagically until the data is gone, that way you don't have to CARE if > it's still sending or not, you just know it's gone and you can do what you > need to. > > Your supposition on the bit being read int he middle of finishing a shift > vs. getting the next byte, while POSSIBLE, if very improbable. The serial > ports that I have seen tend to not raise that bit until all data has been > sent, completely, from the serial holding register, and the serial shifft > register. So typically, as long as the holding register has some data in it, > that serial shift register will also be asserted. > > Rick > > > > On Sun, Aug 30, 2009 at 11:07 PM, Matthew Bowles <ma...@aw...>wrote: > >> very good tips here for anyone else following. >> But that's the only bit where I am very comfortable in knowing what's >> happening. >> My packet is a 8 byte mesage(Modbus RTU if you're interested). >> >> The gory details are as follows. >> my code does the following. >> 1. Set RTS high. >> 2. write packet to port. (buffered to begin with of course) >> 3. check LSR (status reg.) >> 4. Clear RTS low. >> >> my dig. analyser shows that: >> - It takes just shy of 8mS to transmit the message >> - from the RTS going high to the start bit of the first byte is 200uS. >> - the RTS line comes up just over 3mS later (which is still within the >> packet-sending timeframe) >> >> so from that I am very confident that the LSR is being read whilst the >> port is still pumping bits out. However - the one unknown is the sync of the >> shift-reg empty bit to my read. Perhaps I am reading it when it is >> momentarily empty between successive bytes. I cannot prove this either way. >> >> Can anyone shed some light on a good fix for this? also, I have found >> precious little detail on the bits and flags within the LSR - ie. the data >> struct of that register. has anyone got some good resource on that front? >> >> thank you all >> >> Best regards >> >> Matt Bowles >> Embedded Systems Engineer >> *aWma**** Pty Ltd* >> >> >> ------------------------------ >> *From:* richard dorfner [mailto:rdo...@gm...] >> *Sent:* Monday, 31 August 2009 1:44 PM >> >> *To:* General mailing list for gumstix users. >> *Subject:* Re: [Gumstix-users] GPIO manipulation from a user-space C >> program >> >> well, it is quite possible that you are getting everything sent out before >> you ever manage to get that bit read. When you have to go through the >> drivers to get status like that, it takes time. a few to perhaps ten or >> more milliseconds. So, at 9600 baud, n,8,1 given the start bit, a stop >> bit and 8 data bits, you are likely going to have about 1millisecond per >> character.. so if you message if 5 characters long, and you send it via the >> driver, then go to read the status register and it takes ten milliseconds to >> get that status back, you are very likely going to find that you will NEVER >> see that bit being low since by teh time you get to it, all the serial data >> has indeed been sent. >> >> SO.. an experiment might help you out here.. >> >> Try sending a 1kilobyte long message, and THEN start spinning on that bit >> that tells you if the shift register is empty or not. >> I am assuming that the driver will queue up all those bytes so that it >> frees your program from having to wait on them actually going out the data >> line on the serial port. You should then see that the bit will be low for a >> while before it comes high. >> >> If you want, you can also get the system time when you start looking, and >> then the system time when it actually goes high and start figuring out your >> latency times as well. >> >> Rick >> >> >> >> On Sun, Aug 30, 2009 at 6:58 PM, Matthew Bowles <ma...@aw...>wrote: >> >>> Hi everyone >>> >>> thanks for the info Rick. >>> >>> I'm actually using a basix-200 COM. I will not be able to play with >>> device drivers and kernel space software. Our product has a fixed rootfs >>> that i haven't modified for a few years, and all our custom software resides >>> on various MMC partitions. >>> >>> Dave mentioned that there were 3 things I need to keep track of to know >>> when to revert back to receive mode: watch 2 buffers, and the shift-register >>> empty flags. I believed that I could track all of this information by >>> reading the "TIOCSERGETLSR" status register using ioclt(). I can read >>> that register but it doesn't seem to contain information that relates to the >>> serial port. >>> >>> The 1bit flag that should reflect the shift-register empty state, is >>> always 1 (which means empty). perhaps i need to read it a few times? maybe >>> i'm reading it too quickly after writing a packet to the buffer? >>> >>> does anyone have a good resource for the contents of the "TIOCSERGETLSR" >>> status register, or perhaps a more suitable status register, and maybe any >>> GUMSTIX specific parts of those registers? >>> >>> thank you. >>> >>> Best regards >>> >>> Matt Bowles >>> Embedded Systems Engineer >>> *aWma**** Pty Ltd* >>> >>> >>> ------------------------------ >>> *From:* richard dorfner [mailto:rdo...@gm...] >>> *Sent:* Friday, 28 August 2009 11:16 PM >>> >>> *To:* General mailing list for gumstix users. >>> *Subject:* Re: [Gumstix-users] GPIO manipulation from a user-space C >>> program >>> >>> Usually , when someone tells me they want to do something like this, I >>> generally suggest putting it all into the serial device driver. If they >>> need stateful infomration, like handling some kind of simple ack/nak >>> protocol and turnign the 485 transceiver on and off, then Doing so with a >>> static state variable works nicely to remember state across ISR's. From >>> there, instead of just having the serial port generate an ISR on thre and >>> rxrdy, have it also generate an ISR on status register state change. >>> >>> Not sure if the serial port on the overo/verdex is very flexible with >>> what kinds of isr's it can generate, but it will most certainly get your 485 >>> line turned around within a millisecond or two of shoveling out the last >>> bit. >>> >>> Rick >>> >>> >>> On Thu, Aug 27, 2009 at 10:53 PM, Matthew Bowles <ma...@aw...>wrote: >>> >>>> Hi everyone >>>> >>>> I have got the GPIO access working in C. I did use fputs() instead of >>>> fwrite() just to simplify things, but what I am getting is a 50mS lag >>>> between. that is, the following code: >>>> >>>> fputs("GPIO out set",pGPIO_TxRx); >>>> fflush(pGPIO_TxRx); >>>> fputs("GPIO out clear",pGPIO_TxRx); >>>> fflush(pGPIO_TxRx); >>>> >>>> produces a trace with a +ve edge, followed by a delay of 48.4mS, and >>>> then a >>>> -ve edge. >>>> obviously there's some kernel polling of file-system writes or >>>> something. I >>>> assumed it would be near instaneous and I need it to be within 3-5 mS. >>>> >>>> I should have given some better detail on what I'm trying to achieve. >>>> >>>> I am attempting to get RS485 comms working from my GUMSTIX. At the >>>> moment my >>>> HW is not ready, but i am working on the synchronisation of the Transmit >>>> enable (DE) (which is also the active-low Rx Enable) with the transmit >>>> buffer. >>>> >>>> i have seen some examples of ioctl structure extensions to handle the >>>> RS485 >>>> transmit enable sync'ing. And it seems to be industry standard to use >>>> the >>>> RTS line of the serial port if it has one. >>>> what I noticed, is that I can control the RTS line but only if the >>>> RTS/CTS >>>> lines are activated in the serial port config, al la - "c_cflag |= >>>> CRTSCTS;" >>>> >>>> there is a problem with doing this though - you are essentially enabling >>>> HW >>>> flow control, which means driving CTS in some fashion to allow the port >>>> to >>>> transmit. >>>> >>>> to avoid this I thought I would manually drive the TTL output of the RTS >>>> pin. But i get the lagging I mentioned when I interact with the pin via >>>> the >>>> filesystem. >>>> >>>> Does anyone have any experience with RS485 on the GUMSTIX platform? I >>>> may >>>> attempt to get the gpregs stuff working unless someone says otherwise. >>>> >>>> any advice at all would be appreciated. >>>> >>>> >>>> Best regards >>>> >>>> Matt Bowles >>>> Embedded Systems Engineer >>>> aWma Pty Ltd >>>> >>>> >>>> -----Original Message----- >>>> From: Dave Hylands [mailto:dhy...@gm...] >>>> Sent: Friday, 28 August 2009 12:13 AM >>>> To: General mailing list for gumstix users. >>>> Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C >>>> program >>>> >>>> Hi Matt, >>>> >>>> > I'm trying to track down the cleanest way of manipulating a GPIO >>>> > signal on my gumstix board. I understand the IN/OUT and AF1, GPIO >>>> > settings as I can get things working in shell-script land using `echo >>>> > "GPIO OUT SET" > /proc/gpio/GPIO81` and that sort of thing. >>>> > >>>> > but in C, I presume its a bit cludgy to say something resembling >>>> > - system("echo... /proc/gpio/, etc, etc"); >>>> >>>> Presuambly, this is for the verdex. If you want to use the proc >>>> interface, >>>> then I would open the file (/proc/gpio/etc) using fopen, then fwrite >>>> "gpio >>>> out set" to it and then fclose it. Wrap it up in a function and away you >>>> go. >>>> >>>> > I have found an example here >>>> > http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs >>>> > which seems to be giving a nice wrapper around some functions. I am >>>> > not willing to try it first though, as I've read about the kernel >>>> > space versus user space limitations. I probably can't break anything >>>> > and I'll look silly for being so cautious, but does anyone know if >>>> > this is the way to work directly with hte GPIO lines in C, or am I >>>> barking >>>> up the wrong tree? >>>> >>>> If you want to write directly to the gpio lines, then you'd need to use >>>> the >>>> gpregs approach. >>>> >>>> Another way is to write a custom driver and have the user space program >>>> talk >>>> to the custom driver. >>>> >>>> -- >>>> Dave Hylands >>>> Shuswap, BC, Canada >>>> http://www.DaveHylands.com/ >>>> >>>> >>>> ---------------------------------------------------------------------------- >>>> -- >>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>> 30-Day >>>> trial. Simplify your report design, integration and deployment - and >>>> focus >>>> on what you do best, core application coding. Discover what's new with >>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>> _______________________________________________ >>>> gumstix-users mailing list >>>> gum...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>> No virus found in this incoming message. >>>> Checked by AVG - www.avg.com >>>> Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: >>>> 08/27/09 >>>> 08:11:00 >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>> 30-Day >>>> trial. Simplify your report design, integration and deployment - and >>>> focus on >>>> what you do best, core application coding. Discover what's new with >>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>> _______________________________________________ >>>> gumstix-users mailing list >>>> gum...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>> >>> >>> >>> >>> -- >>> Say you can or say you can't, either way you will be right. >>> Computers are like old testament gods: Lots of rules and no mercy. >>> >>> No virus found in this incoming message. >>> Checked by AVG - www.avg.com >>> Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: >>> 08/27/09 18:02:00 >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day >>> trial. Simplify your report design, integration and deployment - and >>> focus on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >> >> >> -- >> Say you can or say you can't, either way you will be right. >> Computers are like old testament gods: Lots of rules and no mercy. >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 8.5.409 / Virus Database: 270.13.71/2336 - Release Date: 08/30/09 >> 17:51:00 >> >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > > -- > Say you can or say you can't, either way you will be right. > Computers are like old testament gods: Lots of rules and no mercy. > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > |
From: Matthew B. <ma...@aw...> - 2009-09-02 05:46:37
|
thanks Felipe. I'm not really in a position to switch over my underlying platform. but it seems like you are avoiding the linux drivers and writing to the PXA255/270 registers. I am also more comfortable in that arena, but I think they are hidden from me for a reason. Also the API available in C should be able to handle what i need. I suspect that the LSR underlying driver is broken as alluded to earlier in the discussion. Has anyone ever read the LSR from a serial port (for any reason) with something like this: ioctl(serialport, TIOCSERGETLSR, &lsr); , and had it work correctly. My main gripe is that I'm getting a value of one for the entire register (ie. unmasked) regardless of when I read it - when the data message is just starting, halfway through, finished 10mS ago. I'm stumped!! I have done some more tests, particularly using a range of functions provided in termios.h like tcdrain() and tcflush(). I wouldn't be surprised if they rely on the LSR shift-reg empty bit, beacuse they return immediately aswell, and still a relatively long time before the packet is finished. thanks for the advice so far everyone Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd _____ From: Felipe Brandão Cavalcanti [mailto:cav...@gm...] Sent: Monday, 31 August 2009 11:58 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program I did have some problems with the timing on the Gumstix as well - my solution was to switch to a real-time Linux system (Xenomai - I am writing a tech note on how to get it to work on the OpenEmbedded platrform) and than use memory manipulation functions to edit the desired registers directly. I can now read/write to the serial port within 500 us (with no buffered data), and GPIO functions take around 100us (at most). Maybe it is a solution worth looking at. However, I did have to write quite a bit of custom code to get it to work, and testing has only been done by me so far. I am organizing most of it, and I am planning on making that available as soon as possible. Hope this helps, -- -Felipe Brandão Cavalcanti LARA - Robotics and Automation Laboratory Department of Electrical Engineering UnB - University of Brasília, Brazil http://www.lara.unb.br/ On Mon, Aug 31, 2009 at 10:03 AM, richard dorfner <rdo...@gm...> wrote: Hmmm, so much for THAT idea then. And from what you are saying, yeah, I'd agree, timing is likely not at all the issue. At this point, I would have to say it would be worth your time venturing down into the device driver itself and seeing what the serial port is doing. It might be that the driver is not functioning correctly, or it might be that the driver is returning information that isn't quite what we understand. As Dave has asserted, it would seem that the driver just would return the LSR right off of the serial port without any modification. It's the easiest, quickest way to get status back up to user land without adding tons of abstraction. And since it's a user land program, you probably are better served doing as he sugggested and just calling the function that holds you off automagically until the data is gone, that way you don't have to CARE if it's still sending or not, you just know it's gone and you can do what you need to. Your supposition on the bit being read int he middle of finishing a shift vs. getting the next byte, while POSSIBLE, if very improbable. The serial ports that I have seen tend to not raise that bit until all data has been sent, completely, from the serial holding register, and the serial shifft register. So typically, as long as the holding register has some data in it, that serial shift register will also be asserted. Rick On Sun, Aug 30, 2009 at 11:07 PM, Matthew Bowles <ma...@aw...> wrote: very good tips here for anyone else following. But that's the only bit where I am very comfortable in knowing what's happening. My packet is a 8 byte mesage(Modbus RTU if you're interested). The gory details are as follows. my code does the following. 1. Set RTS high. 2. write packet to port. (buffered to begin with of course) 3. check LSR (status reg.) 4. Clear RTS low. my dig. analyser shows that: - It takes just shy of 8mS to transmit the message - from the RTS going high to the start bit of the first byte is 200uS. - the RTS line comes up just over 3mS later (which is still within the packet-sending timeframe) so from that I am very confident that the LSR is being read whilst the port is still pumping bits out. However - the one unknown is the sync of the shift-reg empty bit to my read. Perhaps I am reading it when it is momentarily empty between successive bytes. I cannot prove this either way. Can anyone shed some light on a good fix for this? also, I have found precious little detail on the bits and flags within the LSR - ie. the data struct of that register. has anyone got some good resource on that front? thank you all Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd _____ From: richard dorfner [mailto:rdo...@gm...] Sent: Monday, 31 August 2009 1:44 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program well, it is quite possible that you are getting everything sent out before you ever manage to get that bit read. When you have to go through the drivers to get status like that, it takes time. a few to perhaps ten or more milliseconds. So, at 9600 baud, n,8,1 given the start bit, a stop bit and 8 data bits, you are likely going to have about 1millisecond per character.. so if you message if 5 characters long, and you send it via the driver, then go to read the status register and it takes ten milliseconds to get that status back, you are very likely going to find that you will NEVER see that bit being low since by teh time you get to it, all the serial data has indeed been sent. SO.. an experiment might help you out here.. Try sending a 1kilobyte long message, and THEN start spinning on that bit that tells you if the shift register is empty or not. I am assuming that the driver will queue up all those bytes so that it frees your program from having to wait on them actually going out the data line on the serial port. You should then see that the bit will be low for a while before it comes high. If you want, you can also get the system time when you start looking, and then the system time when it actually goes high and start figuring out your latency times as well. Rick On Sun, Aug 30, 2009 at 6:58 PM, Matthew Bowles <ma...@aw...> wrote: Hi everyone thanks for the info Rick. I'm actually using a basix-200 COM. I will not be able to play with device drivers and kernel space software. Our product has a fixed rootfs that i haven't modified for a few years, and all our custom software resides on various MMC partitions. Dave mentioned that there were 3 things I need to keep track of to know when to revert back to receive mode: watch 2 buffers, and the shift-register empty flags. I believed that I could track all of this information by reading the "TIOCSERGETLSR" status register using ioclt(). I can read that register but it doesn't seem to contain information that relates to the serial port. The 1bit flag that should reflect the shift-register empty state, is always 1 (which means empty). perhaps i need to read it a few times? maybe i'm reading it too quickly after writing a packet to the buffer? does anyone have a good resource for the contents of the "TIOCSERGETLSR" status register, or perhaps a more suitable status register, and maybe any GUMSTIX specific parts of those registers? thank you. Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd _____ From: richard dorfner [mailto:rdo...@gm...] Sent: Friday, 28 August 2009 11:16 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program Usually , when someone tells me they want to do something like this, I generally suggest putting it all into the serial device driver. If they need stateful infomration, like handling some kind of simple ack/nak protocol and turnign the 485 transceiver on and off, then Doing so with a static state variable works nicely to remember state across ISR's. From there, instead of just having the serial port generate an ISR on thre and rxrdy, have it also generate an ISR on status register state change. Not sure if the serial port on the overo/verdex is very flexible with what kinds of isr's it can generate, but it will most certainly get your 485 line turned around within a millisecond or two of shoveling out the last bit. Rick On Thu, Aug 27, 2009 at 10:53 PM, Matthew Bowles <ma...@aw...> wrote: Hi everyone I have got the GPIO access working in C. I did use fputs() instead of fwrite() just to simplify things, but what I am getting is a 50mS lag between. that is, the following code: fputs("GPIO out set",pGPIO_TxRx); fflush(pGPIO_TxRx); fputs("GPIO out clear",pGPIO_TxRx); fflush(pGPIO_TxRx); produces a trace with a +ve edge, followed by a delay of 48.4mS, and then a -ve edge. obviously there's some kernel polling of file-system writes or something. I assumed it would be near instaneous and I need it to be within 3-5 mS. I should have given some better detail on what I'm trying to achieve. I am attempting to get RS485 comms working from my GUMSTIX. At the moment my HW is not ready, but i am working on the synchronisation of the Transmit enable (DE) (which is also the active-low Rx Enable) with the transmit buffer. i have seen some examples of ioctl structure extensions to handle the RS485 transmit enable sync'ing. And it seems to be industry standard to use the RTS line of the serial port if it has one. what I noticed, is that I can control the RTS line but only if the RTS/CTS lines are activated in the serial port config, al la - "c_cflag |= CRTSCTS;" there is a problem with doing this though - you are essentially enabling HW flow control, which means driving CTS in some fashion to allow the port to transmit. to avoid this I thought I would manually drive the TTL output of the RTS pin. But i get the lagging I mentioned when I interact with the pin via the filesystem. Does anyone have any experience with RS485 on the GUMSTIX platform? I may attempt to get the gpregs stuff working unless someone says otherwise. any advice at all would be appreciated. Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd -----Original Message----- From: Dave Hylands [mailto:dhy...@gm...] Sent: Friday, 28 August 2009 12:13 AM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program Hi Matt, > I'm trying to track down the cleanest way of manipulating a GPIO > signal on my gumstix board. I understand the IN/OUT and AF1, GPIO > settings as I can get things working in shell-script land using `echo > "GPIO OUT SET" > /proc/gpio/GPIO81` and that sort of thing. > > but in C, I presume its a bit cludgy to say something resembling > - system("echo... /proc/gpio/, etc, etc"); Presuambly, this is for the verdex. If you want to use the proc interface, then I would open the file (/proc/gpio/etc) using fopen, then fwrite "gpio out set" to it and then fclose it. Wrap it up in a function and away you go. > I have found an example here > http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs > which seems to be giving a nice wrapper around some functions. I am > not willing to try it first though, as I've read about the kernel > space versus user space limitations. I probably can't break anything > and I'll look silly for being so cautious, but does anyone know if > this is the way to work directly with hte GPIO lines in C, or am I barking up the wrong tree? If you want to write directly to the gpio lines, then you'd need to use the gpregs approach. Another way is to write a custom driver and have the user space program talk to the custom driver. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: 08/27/09 08:11:00 ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users -- Say you can or say you can't, either way you will be right. Computers are like old testament gods: Lots of rules and no mercy. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: 08/27/09 18:02:00 ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users -- Say you can or say you can't, either way you will be right. Computers are like old testament gods: Lots of rules and no mercy. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.71/2336 - Release Date: 08/30/09 17:51:00 ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users -- Say you can or say you can't, either way you will be right. Computers are like old testament gods: Lots of rules and no mercy. ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.71/2336 - Release Date: 08/30/09 17:51:00 |
From: richard d. <rdo...@gm...> - 2009-09-02 13:07:17
|
Well, if I understand the situation correctly, you are working on a system that you can't touch the rootfs of, and therefor can't add/delete device drivers to/from. So you are stuck with working what you are working with. It also would appear that the driver itself is not working right, which is another huge annoyance. SOoo, uhm... is there a /proc entry for this thing that you can query and see if maybe *IT* shows the lsr register correctly? Other than that, you might be stuck with having to use a timer to just time out when the packet will be done by and then change the state of your 485 line from tx to rx..? Honestly, that's about the best I can think of at this point. Even if you could delve into the driver to fix it, (if it is truly broken, which it sounds like it is, since that stuff should 'just work') you wouldn't be able to change it. The only other thing I can think of is to see if you can locate the source for the driver and dig through it to see if you can find an error in it or not and if there is a possible work around with the state of the driver as it currently exists in your system. Rick On Wed, Sep 2, 2009 at 12:46 AM, Matthew Bowles <ma...@aw...> wrote: > thanks Felipe. > > I'm not really in a position to switch over my underlying platform. but it > seems like you are avoiding the linux drivers and writing to the PXA255/270 > registers. I am also more comfortable in that arena, but I think they are > hidden from me for a reason. Also the API available in C should be able to > handle what i need. I suspect that the LSR underlying driver is broken as > alluded to earlier in the discussion. > > Has anyone ever read the LSR from a serial port (for any reason) with > something like this: > ioctl(serialport, TIOCSERGETLSR, &lsr); > , and had it work correctly. > My main gripe is that I'm getting a value of one for the entire register > (ie. unmasked) regardless of when I read it - when the data message is just > starting, halfway through, finished 10mS ago. > I'm stumped!! > > I have done some more tests, particularly using a range of functions > provided in termios.h like tcdrain() and tcflush(). I wouldn't be surprised > if they rely on the LSR shift-reg empty bit, beacuse they return immediately > aswell, and still a relatively long time before the packet is finished. > > thanks for the advice so far everyone > > Best regards > > Matt Bowles > Embedded Systems Engineer > *aWma**** Pty Ltd* > > > ------------------------------ > *From:* Felipe Brandão Cavalcanti [mailto:cav...@gm...] > *Sent:* Monday, 31 August 2009 11:58 PM > > *To:* General mailing list for gumstix users. > *Subject:* Re: [Gumstix-users] GPIO manipulation from a user-space C > program > > I did have some problems with the timing on the Gumstix as well - my > solution was to switch to a real-time Linux system (Xenomai - I am writing a > tech note on how to get it to work on the OpenEmbedded platrform) and than > use memory manipulation functions to edit the desired registers directly. > > I can now read/write to the serial port within 500 us (with no buffered > data), and GPIO functions take around 100us (at most). Maybe it is a > solution worth looking at. > > However, I did have to write quite a bit of custom code to get it to work, > and testing has only been done by me so far. I am organizing most of it, and > I am planning on making that available as soon as possible. > > Hope this helps, > -- > -Felipe Brandão Cavalcanti > LARA - Robotics and Automation Laboratory > Department of Electrical Engineering > UnB - University of Brasília, Brazil > http://www.lara.unb.br/ > > On Mon, Aug 31, 2009 at 10:03 AM, richard dorfner <rdo...@gm...>wrote: > >> Hmmm, so much for THAT idea then. And from what you are saying, yeah, I'd >> agree, timing is likely not at all the issue. >> >> At this point, I would have to say it would be worth your time venturing >> down into the device driver itself and seeing what the serial port is >> doing. >> >> It might be that the driver is not functioning correctly, or it might be >> that the driver is returning information that isn't quite what we >> understand. >> >> As Dave has asserted, it would seem that the driver just would return the >> LSR right off of the serial port without any modification. It's the >> easiest, quickest way to get status back up to user land without adding tons >> of abstraction. And since it's a user land program, you probably are better >> served doing as he sugggested and just calling the function that holds you >> off automagically until the data is gone, that way you don't have to CARE if >> it's still sending or not, you just know it's gone and you can do what you >> need to. >> >> Your supposition on the bit being read int he middle of finishing a shift >> vs. getting the next byte, while POSSIBLE, if very improbable. The serial >> ports that I have seen tend to not raise that bit until all data has been >> sent, completely, from the serial holding register, and the serial shifft >> register. So typically, as long as the holding register has some data in it, >> that serial shift register will also be asserted. >> >> Rick >> >> >> >> On Sun, Aug 30, 2009 at 11:07 PM, Matthew Bowles <ma...@aw...>wrote: >> >>> very good tips here for anyone else following. >>> But that's the only bit where I am very comfortable in knowing what's >>> happening. >>> My packet is a 8 byte mesage(Modbus RTU if you're interested). >>> >>> The gory details are as follows. >>> my code does the following. >>> 1. Set RTS high. >>> 2. write packet to port. (buffered to begin with of course) >>> 3. check LSR (status reg.) >>> 4. Clear RTS low. >>> >>> my dig. analyser shows that: >>> - It takes just shy of 8mS to transmit the message >>> - from the RTS going high to the start bit of the first byte is 200uS. >>> - the RTS line comes up just over 3mS later (which is still within the >>> packet-sending timeframe) >>> >>> so from that I am very confident that the LSR is being read whilst the >>> port is still pumping bits out. However - the one unknown is the sync of the >>> shift-reg empty bit to my read. Perhaps I am reading it when it is >>> momentarily empty between successive bytes. I cannot prove this either way. >>> >>> Can anyone shed some light on a good fix for this? also, I have found >>> precious little detail on the bits and flags within the LSR - ie. the data >>> struct of that register. has anyone got some good resource on that front? >>> >>> thank you all >>> >>> Best regards >>> >>> Matt Bowles >>> Embedded Systems Engineer >>> *aWma**** Pty Ltd* >>> >>> >>> ------------------------------ >>> *From:* richard dorfner [mailto:rdo...@gm...] >>> *Sent:* Monday, 31 August 2009 1:44 PM >>> >>> *To:* General mailing list for gumstix users. >>> *Subject:* Re: [Gumstix-users] GPIO manipulation from a user-space C >>> program >>> >>> well, it is quite possible that you are getting everything sent out >>> before you ever manage to get that bit read. When you have to go through the >>> drivers to get status like that, it takes time. a few to perhaps ten or >>> more milliseconds. So, at 9600 baud, n,8,1 given the start bit, a stop >>> bit and 8 data bits, you are likely going to have about 1millisecond per >>> character.. so if you message if 5 characters long, and you send it via the >>> driver, then go to read the status register and it takes ten milliseconds to >>> get that status back, you are very likely going to find that you will NEVER >>> see that bit being low since by teh time you get to it, all the serial data >>> has indeed been sent. >>> >>> SO.. an experiment might help you out here.. >>> >>> Try sending a 1kilobyte long message, and THEN start spinning on that bit >>> that tells you if the shift register is empty or not. >>> I am assuming that the driver will queue up all those bytes so that it >>> frees your program from having to wait on them actually going out the data >>> line on the serial port. You should then see that the bit will be low for a >>> while before it comes high. >>> >>> If you want, you can also get the system time when you start looking, and >>> then the system time when it actually goes high and start figuring out your >>> latency times as well. >>> >>> Rick >>> >>> >>> >>> On Sun, Aug 30, 2009 at 6:58 PM, Matthew Bowles <ma...@aw...>wrote: >>> >>>> Hi everyone >>>> >>>> thanks for the info Rick. >>>> >>>> I'm actually using a basix-200 COM. I will not be able to play with >>>> device drivers and kernel space software. Our product has a fixed rootfs >>>> that i haven't modified for a few years, and all our custom software resides >>>> on various MMC partitions. >>>> >>>> Dave mentioned that there were 3 things I need to keep track of to know >>>> when to revert back to receive mode: watch 2 buffers, and the shift-register >>>> empty flags. I believed that I could track all of this information by >>>> reading the "TIOCSERGETLSR" status register using ioclt(). I can read >>>> that register but it doesn't seem to contain information that relates to the >>>> serial port. >>>> >>>> The 1bit flag that should reflect the shift-register empty state, is >>>> always 1 (which means empty). perhaps i need to read it a few times? maybe >>>> i'm reading it too quickly after writing a packet to the buffer? >>>> >>>> does anyone have a good resource for the contents of the "TIOCSERGETLSR" >>>> status register, or perhaps a more suitable status register, and maybe any >>>> GUMSTIX specific parts of those registers? >>>> >>>> thank you. >>>> >>>> Best regards >>>> >>>> Matt Bowles >>>> Embedded Systems Engineer >>>> *aWma**** Pty Ltd* >>>> >>>> >>>> ------------------------------ >>>> *From:* richard dorfner [mailto:rdo...@gm...] >>>> *Sent:* Friday, 28 August 2009 11:16 PM >>>> >>>> *To:* General mailing list for gumstix users. >>>> *Subject:* Re: [Gumstix-users] GPIO manipulation from a user-space C >>>> program >>>> >>>> Usually , when someone tells me they want to do something like this, >>>> I generally suggest putting it all into the serial device driver. If they >>>> need stateful infomration, like handling some kind of simple ack/nak >>>> protocol and turnign the 485 transceiver on and off, then Doing so with a >>>> static state variable works nicely to remember state across ISR's. From >>>> there, instead of just having the serial port generate an ISR on thre and >>>> rxrdy, have it also generate an ISR on status register state change. >>>> >>>> Not sure if the serial port on the overo/verdex is very flexible with >>>> what kinds of isr's it can generate, but it will most certainly get your 485 >>>> line turned around within a millisecond or two of shoveling out the last >>>> bit. >>>> >>>> Rick >>>> >>>> >>>> On Thu, Aug 27, 2009 at 10:53 PM, Matthew Bowles <ma...@aw...>wrote: >>>> >>>>> Hi everyone >>>>> >>>>> I have got the GPIO access working in C. I did use fputs() instead of >>>>> fwrite() just to simplify things, but what I am getting is a 50mS lag >>>>> between. that is, the following code: >>>>> >>>>> fputs("GPIO out set",pGPIO_TxRx); >>>>> fflush(pGPIO_TxRx); >>>>> fputs("GPIO out clear",pGPIO_TxRx); >>>>> fflush(pGPIO_TxRx); >>>>> >>>>> produces a trace with a +ve edge, followed by a delay of 48.4mS, and >>>>> then a >>>>> -ve edge. >>>>> obviously there's some kernel polling of file-system writes or >>>>> something. I >>>>> assumed it would be near instaneous and I need it to be within 3-5 mS. >>>>> >>>>> I should have given some better detail on what I'm trying to achieve. >>>>> >>>>> I am attempting to get RS485 comms working from my GUMSTIX. At the >>>>> moment my >>>>> HW is not ready, but i am working on the synchronisation of the >>>>> Transmit >>>>> enable (DE) (which is also the active-low Rx Enable) with the transmit >>>>> buffer. >>>>> >>>>> i have seen some examples of ioctl structure extensions to handle the >>>>> RS485 >>>>> transmit enable sync'ing. And it seems to be industry standard to use >>>>> the >>>>> RTS line of the serial port if it has one. >>>>> what I noticed, is that I can control the RTS line but only if the >>>>> RTS/CTS >>>>> lines are activated in the serial port config, al la - "c_cflag |= >>>>> CRTSCTS;" >>>>> >>>>> there is a problem with doing this though - you are essentially >>>>> enabling HW >>>>> flow control, which means driving CTS in some fashion to allow the port >>>>> to >>>>> transmit. >>>>> >>>>> to avoid this I thought I would manually drive the TTL output of the >>>>> RTS >>>>> pin. But i get the lagging I mentioned when I interact with the pin via >>>>> the >>>>> filesystem. >>>>> >>>>> Does anyone have any experience with RS485 on the GUMSTIX platform? I >>>>> may >>>>> attempt to get the gpregs stuff working unless someone says otherwise. >>>>> >>>>> any advice at all would be appreciated. >>>>> >>>>> >>>>> Best regards >>>>> >>>>> Matt Bowles >>>>> Embedded Systems Engineer >>>>> aWma Pty Ltd >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Dave Hylands [mailto:dhy...@gm...] >>>>> Sent: Friday, 28 August 2009 12:13 AM >>>>> To: General mailing list for gumstix users. >>>>> Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C >>>>> program >>>>> >>>>> Hi Matt, >>>>> >>>>> > I'm trying to track down the cleanest way of manipulating a GPIO >>>>> > signal on my gumstix board. I understand the IN/OUT and AF1, GPIO >>>>> > settings as I can get things working in shell-script land using `echo >>>>> > "GPIO OUT SET" > /proc/gpio/GPIO81` and that sort of thing. >>>>> > >>>>> > but in C, I presume its a bit cludgy to say something resembling >>>>> > - system("echo... /proc/gpio/, etc, etc"); >>>>> >>>>> Presuambly, this is for the verdex. If you want to use the proc >>>>> interface, >>>>> then I would open the file (/proc/gpio/etc) using fopen, then fwrite >>>>> "gpio >>>>> out set" to it and then fclose it. Wrap it up in a function and away >>>>> you go. >>>>> >>>>> > I have found an example here >>>>> > http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs >>>>> > which seems to be giving a nice wrapper around some functions. I am >>>>> > not willing to try it first though, as I've read about the kernel >>>>> > space versus user space limitations. I probably can't break anything >>>>> > and I'll look silly for being so cautious, but does anyone know if >>>>> > this is the way to work directly with hte GPIO lines in C, or am I >>>>> barking >>>>> up the wrong tree? >>>>> >>>>> If you want to write directly to the gpio lines, then you'd need to use >>>>> the >>>>> gpregs approach. >>>>> >>>>> Another way is to write a custom driver and have the user space program >>>>> talk >>>>> to the custom driver. >>>>> >>>>> -- >>>>> Dave Hylands >>>>> Shuswap, BC, Canada >>>>> http://www.DaveHylands.com/ >>>>> >>>>> >>>>> ---------------------------------------------------------------------------- >>>>> -- >>>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>>> 30-Day >>>>> trial. Simplify your report design, integration and deployment - and >>>>> focus >>>>> on what you do best, core application coding. Discover what's new with >>>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>>> _______________________________________________ >>>>> gumstix-users mailing list >>>>> gum...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>>> No virus found in this incoming message. >>>>> Checked by AVG - www.avg.com >>>>> Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: >>>>> 08/27/09 >>>>> 08:11:00 >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>>> 30-Day >>>>> trial. Simplify your report design, integration and deployment - and >>>>> focus on >>>>> what you do best, core application coding. Discover what's new with >>>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>>> _______________________________________________ >>>>> gumstix-users mailing list >>>>> gum...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>>> >>>> >>>> >>>> >>>> -- >>>> Say you can or say you can't, either way you will be right. >>>> Computers are like old testament gods: Lots of rules and no mercy. >>>> >>>> No virus found in this incoming message. >>>> Checked by AVG - www.avg.com >>>> Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: >>>> 08/27/09 18:02:00 >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>> 30-Day >>>> trial. Simplify your report design, integration and deployment - and >>>> focus on >>>> what you do best, core application coding. Discover what's new with >>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>> _______________________________________________ >>>> gumstix-users mailing list >>>> gum...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>> >>>> >>> >>> >>> -- >>> Say you can or say you can't, either way you will be right. >>> Computers are like old testament gods: Lots of rules and no mercy. >>> >>> No virus found in this incoming message. >>> Checked by AVG - www.avg.com >>> Version: 8.5.409 / Virus Database: 270.13.71/2336 - Release Date: >>> 08/30/09 17:51:00 >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day >>> trial. Simplify your report design, integration and deployment - and >>> focus on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >> >> >> -- >> Say you can or say you can't, either way you will be right. >> Computers are like old testament gods: Lots of rules and no mercy. >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.409 / Virus Database: 270.13.71/2336 - Release Date: 08/30/09 > 17:51:00 > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- Say you can or say you can't, either way you will be right. Computers are like old testament gods: Lots of rules and no mercy. |
From: Matthew B. <ma...@aw...> - 2009-09-02 23:18:19
|
I suppose its worth a look at the code. I will go for the /proc thing first, but I expect that even if there's something there, it's going to be to slow to access, for it to be useful to me. I'll chase up the info about it being broken again. see if that will lead me to some source code. Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd _____ From: richard dorfner [mailto:rdo...@gm...] Sent: Wednesday, 2 September 2009 11:07 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program Well, if I understand the situation correctly, you are working on a system that you can't touch the rootfs of, and therefor can't add/delete device drivers to/from. So you are stuck with working what you are working with. It also would appear that the driver itself is not working right, which is another huge annoyance. SOoo, uhm... is there a /proc entry for this thing that you can query and see if maybe *IT* shows the lsr register correctly? Other than that, you might be stuck with having to use a timer to just time out when the packet will be done by and then change the state of your 485 line from tx to rx..? Honestly, that's about the best I can think of at this point. Even if you could delve into the driver to fix it, (if it is truly broken, which it sounds like it is, since that stuff should 'just work') you wouldn't be able to change it. The only other thing I can think of is to see if you can locate the source for the driver and dig through it to see if you can find an error in it or not and if there is a possible work around with the state of the driver as it currently exists in your system. Rick On Wed, Sep 2, 2009 at 12:46 AM, Matthew Bowles <ma...@aw...> wrote: thanks Felipe. I'm not really in a position to switch over my underlying platform. but it seems like you are avoiding the linux drivers and writing to the PXA255/270 registers. I am also more comfortable in that arena, but I think they are hidden from me for a reason. Also the API available in C should be able to handle what i need. I suspect that the LSR underlying driver is broken as alluded to earlier in the discussion. Has anyone ever read the LSR from a serial port (for any reason) with something like this: ioctl(serialport, TIOCSERGETLSR, &lsr); , and had it work correctly. My main gripe is that I'm getting a value of one for the entire register (ie. unmasked) regardless of when I read it - when the data message is just starting, halfway through, finished 10mS ago. I'm stumped!! I have done some more tests, particularly using a range of functions provided in termios.h like tcdrain() and tcflush(). I wouldn't be surprised if they rely on the LSR shift-reg empty bit, beacuse they return immediately aswell, and still a relatively long time before the packet is finished. thanks for the advice so far everyone Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd _____ From: Felipe Brandão Cavalcanti [mailto:cav...@gm...] Sent: Monday, 31 August 2009 11:58 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program I did have some problems with the timing on the Gumstix as well - my solution was to switch to a real-time Linux system (Xenomai - I am writing a tech note on how to get it to work on the OpenEmbedded platrform) and than use memory manipulation functions to edit the desired registers directly. I can now read/write to the serial port within 500 us (with no buffered data), and GPIO functions take around 100us (at most). Maybe it is a solution worth looking at. However, I did have to write quite a bit of custom code to get it to work, and testing has only been done by me so far. I am organizing most of it, and I am planning on making that available as soon as possible. Hope this helps, -- -Felipe Brandão Cavalcanti LARA - Robotics and Automation Laboratory Department of Electrical Engineering UnB - University of Brasília, Brazil http://www.lara.unb.br/ On Mon, Aug 31, 2009 at 10:03 AM, richard dorfner <rdo...@gm...> wrote: Hmmm, so much for THAT idea then. And from what you are saying, yeah, I'd agree, timing is likely not at all the issue. At this point, I would have to say it would be worth your time venturing down into the device driver itself and seeing what the serial port is doing. It might be that the driver is not functioning correctly, or it might be that the driver is returning information that isn't quite what we understand. As Dave has asserted, it would seem that the driver just would return the LSR right off of the serial port without any modification. It's the easiest, quickest way to get status back up to user land without adding tons of abstraction. And since it's a user land program, you probably are better served doing as he sugggested and just calling the function that holds you off automagically until the data is gone, that way you don't have to CARE if it's still sending or not, you just know it's gone and you can do what you need to. Your supposition on the bit being read int he middle of finishing a shift vs. getting the next byte, while POSSIBLE, if very improbable. The serial ports that I have seen tend to not raise that bit until all data has been sent, completely, from the serial holding register, and the serial shifft register. So typically, as long as the holding register has some data in it, that serial shift register will also be asserted. Rick On Sun, Aug 30, 2009 at 11:07 PM, Matthew Bowles <ma...@aw...> wrote: very good tips here for anyone else following. But that's the only bit where I am very comfortable in knowing what's happening. My packet is a 8 byte mesage(Modbus RTU if you're interested). The gory details are as follows. my code does the following. 1. Set RTS high. 2. write packet to port. (buffered to begin with of course) 3. check LSR (status reg.) 4. Clear RTS low. my dig. analyser shows that: - It takes just shy of 8mS to transmit the message - from the RTS going high to the start bit of the first byte is 200uS. - the RTS line comes up just over 3mS later (which is still within the packet-sending timeframe) so from that I am very confident that the LSR is being read whilst the port is still pumping bits out. However - the one unknown is the sync of the shift-reg empty bit to my read. Perhaps I am reading it when it is momentarily empty between successive bytes. I cannot prove this either way. Can anyone shed some light on a good fix for this? also, I have found precious little detail on the bits and flags within the LSR - ie. the data struct of that register. has anyone got some good resource on that front? thank you all Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd _____ From: richard dorfner [mailto:rdo...@gm...] Sent: Monday, 31 August 2009 1:44 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program well, it is quite possible that you are getting everything sent out before you ever manage to get that bit read. When you have to go through the drivers to get status like that, it takes time. a few to perhaps ten or more milliseconds. So, at 9600 baud, n,8,1 given the start bit, a stop bit and 8 data bits, you are likely going to have about 1millisecond per character.. so if you message if 5 characters long, and you send it via the driver, then go to read the status register and it takes ten milliseconds to get that status back, you are very likely going to find that you will NEVER see that bit being low since by teh time you get to it, all the serial data has indeed been sent. SO.. an experiment might help you out here.. Try sending a 1kilobyte long message, and THEN start spinning on that bit that tells you if the shift register is empty or not. I am assuming that the driver will queue up all those bytes so that it frees your program from having to wait on them actually going out the data line on the serial port. You should then see that the bit will be low for a while before it comes high. If you want, you can also get the system time when you start looking, and then the system time when it actually goes high and start figuring out your latency times as well. Rick On Sun, Aug 30, 2009 at 6:58 PM, Matthew Bowles <ma...@aw...> wrote: Hi everyone thanks for the info Rick. I'm actually using a basix-200 COM. I will not be able to play with device drivers and kernel space software. Our product has a fixed rootfs that i haven't modified for a few years, and all our custom software resides on various MMC partitions. Dave mentioned that there were 3 things I need to keep track of to know when to revert back to receive mode: watch 2 buffers, and the shift-register empty flags. I believed that I could track all of this information by reading the "TIOCSERGETLSR" status register using ioclt(). I can read that register but it doesn't seem to contain information that relates to the serial port. The 1bit flag that should reflect the shift-register empty state, is always 1 (which means empty). perhaps i need to read it a few times? maybe i'm reading it too quickly after writing a packet to the buffer? does anyone have a good resource for the contents of the "TIOCSERGETLSR" status register, or perhaps a more suitable status register, and maybe any GUMSTIX specific parts of those registers? thank you. Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd _____ From: richard dorfner [mailto:rdo...@gm...] Sent: Friday, 28 August 2009 11:16 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program Usually , when someone tells me they want to do something like this, I generally suggest putting it all into the serial device driver. If they need stateful infomration, like handling some kind of simple ack/nak protocol and turnign the 485 transceiver on and off, then Doing so with a static state variable works nicely to remember state across ISR's. From there, instead of just having the serial port generate an ISR on thre and rxrdy, have it also generate an ISR on status register state change. Not sure if the serial port on the overo/verdex is very flexible with what kinds of isr's it can generate, but it will most certainly get your 485 line turned around within a millisecond or two of shoveling out the last bit. Rick On Thu, Aug 27, 2009 at 10:53 PM, Matthew Bowles <ma...@aw...> wrote: Hi everyone I have got the GPIO access working in C. I did use fputs() instead of fwrite() just to simplify things, but what I am getting is a 50mS lag between. that is, the following code: fputs("GPIO out set",pGPIO_TxRx); fflush(pGPIO_TxRx); fputs("GPIO out clear",pGPIO_TxRx); fflush(pGPIO_TxRx); produces a trace with a +ve edge, followed by a delay of 48.4mS, and then a -ve edge. obviously there's some kernel polling of file-system writes or something. I assumed it would be near instaneous and I need it to be within 3-5 mS. I should have given some better detail on what I'm trying to achieve. I am attempting to get RS485 comms working from my GUMSTIX. At the moment my HW is not ready, but i am working on the synchronisation of the Transmit enable (DE) (which is also the active-low Rx Enable) with the transmit buffer. i have seen some examples of ioctl structure extensions to handle the RS485 transmit enable sync'ing. And it seems to be industry standard to use the RTS line of the serial port if it has one. what I noticed, is that I can control the RTS line but only if the RTS/CTS lines are activated in the serial port config, al la - "c_cflag |= CRTSCTS;" there is a problem with doing this though - you are essentially enabling HW flow control, which means driving CTS in some fashion to allow the port to transmit. to avoid this I thought I would manually drive the TTL output of the RTS pin. But i get the lagging I mentioned when I interact with the pin via the filesystem. Does anyone have any experience with RS485 on the GUMSTIX platform? I may attempt to get the gpregs stuff working unless someone says otherwise. any advice at all would be appreciated. Best regards Matt Bowles Embedded Systems Engineer aWma Pty Ltd -----Original Message----- From: Dave Hylands [mailto:dhy...@gm...] Sent: Friday, 28 August 2009 12:13 AM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program Hi Matt, > I'm trying to track down the cleanest way of manipulating a GPIO > signal on my gumstix board. I understand the IN/OUT and AF1, GPIO > settings as I can get things working in shell-script land using `echo > "GPIO OUT SET" > /proc/gpio/GPIO81` and that sort of thing. > > but in C, I presume its a bit cludgy to say something resembling > - system("echo... /proc/gpio/, etc, etc"); Presuambly, this is for the verdex. If you want to use the proc interface, then I would open the file (/proc/gpio/etc) using fopen, then fwrite "gpio out set" to it and then fclose it. Wrap it up in a function and away you go. > I have found an example here > http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs > which seems to be giving a nice wrapper around some functions. I am > not willing to try it first though, as I've read about the kernel > space versus user space limitations. I probably can't break anything > and I'll look silly for being so cautious, but does anyone know if > this is the way to work directly with hte GPIO lines in C, or am I barking up the wrong tree? If you want to write directly to the gpio lines, then you'd need to use the gpregs approach. Another way is to write a custom driver and have the user space program talk to the custom driver. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: 08/27/09 08:11:00 ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users -- Say you can or say you can't, either way you will be right. Computers are like old testament gods: Lots of rules and no mercy. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: 08/27/09 18:02:00 ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users -- Say you can or say you can't, either way you will be right. Computers are like old testament gods: Lots of rules and no mercy. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.71/2336 - Release Date: 08/30/09 17:51:00 ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users -- Say you can or say you can't, either way you will be right. Computers are like old testament gods: Lots of rules and no mercy. ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.71/2336 - Release Date: 08/30/09 17:51:00 ---------------------------------------------------------------------------- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users -- Say you can or say you can't, either way you will be right. Computers are like old testament gods: Lots of rules and no mercy. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.71/2336 - Release Date: 09/01/09 20:03:00 |
From: richard d. <rdo...@gm...> - 2009-09-03 00:43:22
|
Good luck with that Matt, If you need help in understanding the source code, don't hesitate to ask. Rick On Wed, Sep 2, 2009 at 6:17 PM, Matthew Bowles <ma...@aw...> wrote: > I suppose its worth a look at the code. > I will go for the /proc thing first, but I expect that even if there's > something there, it's going to be to slow to access, for it to be useful to > me. > > I'll chase up the info about it being broken again. see if that will lead > me to some source code. > > > Best regards > > Matt Bowles > Embedded Systems Engineer > *aWma**** Pty Ltd* > > > ------------------------------ > *From:* richard dorfner [mailto:rdo...@gm...] > *Sent:* Wednesday, 2 September 2009 11:07 PM > > *To:* General mailing list for gumstix users. > *Subject:* Re: [Gumstix-users] GPIO manipulation from a user-space C > program > > Well, if I understand the situation correctly, you are working on a system > that you can't touch the rootfs of, and therefor can't add/delete device > drivers to/from. So you are stuck with working what you are working with. It > also would appear that the driver itself is not working right, which is > another huge annoyance. SOoo, uhm... is there a /proc entry for this thing > that you can query and see if maybe *IT* shows the lsr register correctly? > > Other than that, you might be stuck with having to use a timer to just time > out when the packet will be done by and then change the state of your 485 > line from tx to rx..? > > Honestly, that's about the best I can think of at this point. Even if you > could delve into the driver to fix it, (if it is truly broken, which it > sounds like it is, since that stuff should 'just work') you wouldn't be able > to change it. > > The only other thing I can think of is to see if you can locate the source > for the driver and dig through it to see if you can find an error in it or > not and if there is a possible work around with the state of the driver as > it currently exists in your system. > > Rick > > On Wed, Sep 2, 2009 at 12:46 AM, Matthew Bowles <ma...@aw...>wrote: > >> thanks Felipe. >> >> I'm not really in a position to switch over my underlying platform. but it >> seems like you are avoiding the linux drivers and writing to the PXA255/270 >> registers. I am also more comfortable in that arena, but I think they are >> hidden from me for a reason. Also the API available in C should be able to >> handle what i need. I suspect that the LSR underlying driver is broken as >> alluded to earlier in the discussion. >> >> Has anyone ever read the LSR from a serial port (for any reason) with >> something like this: >> ioctl(serialport, TIOCSERGETLSR, &lsr); >> , and had it work correctly. >> My main gripe is that I'm getting a value of one for the entire register >> (ie. unmasked) regardless of when I read it - when the data message is just >> starting, halfway through, finished 10mS ago. >> I'm stumped!! >> >> I have done some more tests, particularly using a range of functions >> provided in termios.h like tcdrain() and tcflush(). I wouldn't be surprised >> if they rely on the LSR shift-reg empty bit, beacuse they return immediately >> aswell, and still a relatively long time before the packet is finished. >> >> thanks for the advice so far everyone >> >> Best regards >> >> Matt Bowles >> Embedded Systems Engineer >> *aWma**** Pty Ltd* >> >> >> ------------------------------ >> *From:* Felipe Brandão Cavalcanti [mailto:cav...@gm...] >> *Sent:* Monday, 31 August 2009 11:58 PM >> >> *To:* General mailing list for gumstix users. >> *Subject:* Re: [Gumstix-users] GPIO manipulation from a user-space C >> program >> >> I did have some problems with the timing on the Gumstix as well - my >> solution was to switch to a real-time Linux system (Xenomai - I am writing a >> tech note on how to get it to work on the OpenEmbedded platrform) and than >> use memory manipulation functions to edit the desired registers directly. >> >> I can now read/write to the serial port within 500 us (with no buffered >> data), and GPIO functions take around 100us (at most). Maybe it is a >> solution worth looking at. >> >> However, I did have to write quite a bit of custom code to get it to work, >> and testing has only been done by me so far. I am organizing most of it, and >> I am planning on making that available as soon as possible. >> >> Hope this helps, >> -- >> -Felipe Brandão Cavalcanti >> LARA - Robotics and Automation Laboratory >> Department of Electrical Engineering >> UnB - University of Brasília, Brazil >> http://www.lara.unb.br/ >> >> On Mon, Aug 31, 2009 at 10:03 AM, richard dorfner <rdo...@gm...>wrote: >> >>> Hmmm, so much for THAT idea then. And from what you are saying, yeah, >>> I'd agree, timing is likely not at all the issue. >>> >>> At this point, I would have to say it would be worth your time venturing >>> down into the device driver itself and seeing what the serial port is >>> doing. >>> >>> It might be that the driver is not functioning correctly, or it might be >>> that the driver is returning information that isn't quite what we >>> understand. >>> >>> As Dave has asserted, it would seem that the driver just would return the >>> LSR right off of the serial port without any modification. It's the >>> easiest, quickest way to get status back up to user land without adding tons >>> of abstraction. And since it's a user land program, you probably are better >>> served doing as he sugggested and just calling the function that holds you >>> off automagically until the data is gone, that way you don't have to CARE if >>> it's still sending or not, you just know it's gone and you can do what you >>> need to. >>> >>> Your supposition on the bit being read int he middle of finishing a shift >>> vs. getting the next byte, while POSSIBLE, if very improbable. The serial >>> ports that I have seen tend to not raise that bit until all data has been >>> sent, completely, from the serial holding register, and the serial shifft >>> register. So typically, as long as the holding register has some data in it, >>> that serial shift register will also be asserted. >>> >>> Rick >>> >>> >>> >>> On Sun, Aug 30, 2009 at 11:07 PM, Matthew Bowles <ma...@aw...>wrote: >>> >>>> very good tips here for anyone else following. >>>> But that's the only bit where I am very comfortable in knowing what's >>>> happening. >>>> My packet is a 8 byte mesage(Modbus RTU if you're interested). >>>> >>>> The gory details are as follows. >>>> my code does the following. >>>> 1. Set RTS high. >>>> 2. write packet to port. (buffered to begin with of course) >>>> 3. check LSR (status reg.) >>>> 4. Clear RTS low. >>>> >>>> my dig. analyser shows that: >>>> - It takes just shy of 8mS to transmit the message >>>> - from the RTS going high to the start bit of the first byte is 200uS. >>>> - the RTS line comes up just over 3mS later (which is still within the >>>> packet-sending timeframe) >>>> >>>> so from that I am very confident that the LSR is being read whilst the >>>> port is still pumping bits out. However - the one unknown is the sync of the >>>> shift-reg empty bit to my read. Perhaps I am reading it when it is >>>> momentarily empty between successive bytes. I cannot prove this either way. >>>> >>>> Can anyone shed some light on a good fix for this? also, I have found >>>> precious little detail on the bits and flags within the LSR - ie. the data >>>> struct of that register. has anyone got some good resource on that front? >>>> >>>> thank you all >>>> >>>> Best regards >>>> >>>> Matt Bowles >>>> Embedded Systems Engineer >>>> *aWma**** Pty Ltd* >>>> >>>> >>>> ------------------------------ >>>> *From:* richard dorfner [mailto:rdo...@gm...] >>>> *Sent:* Monday, 31 August 2009 1:44 PM >>>> >>>> *To:* General mailing list for gumstix users. >>>> *Subject:* Re: [Gumstix-users] GPIO manipulation from a user-space C >>>> program >>>> >>>> well, it is quite possible that you are getting everything sent out >>>> before you ever manage to get that bit read. When you have to go through the >>>> drivers to get status like that, it takes time. a few to perhaps ten or >>>> more milliseconds. So, at 9600 baud, n,8,1 given the start bit, a stop >>>> bit and 8 data bits, you are likely going to have about 1millisecond per >>>> character.. so if you message if 5 characters long, and you send it via the >>>> driver, then go to read the status register and it takes ten milliseconds to >>>> get that status back, you are very likely going to find that you will NEVER >>>> see that bit being low since by teh time you get to it, all the serial data >>>> has indeed been sent. >>>> >>>> SO.. an experiment might help you out here.. >>>> >>>> Try sending a 1kilobyte long message, and THEN start spinning on that >>>> bit that tells you if the shift register is empty or not. >>>> I am assuming that the driver will queue up all those bytes so that it >>>> frees your program from having to wait on them actually going out the data >>>> line on the serial port. You should then see that the bit will be low for a >>>> while before it comes high. >>>> >>>> If you want, you can also get the system time when you start looking, >>>> and then the system time when it actually goes high and start figuring out >>>> your latency times as well. >>>> >>>> Rick >>>> >>>> >>>> >>>> On Sun, Aug 30, 2009 at 6:58 PM, Matthew Bowles <ma...@aw...>wrote: >>>> >>>>> Hi everyone >>>>> >>>>> thanks for the info Rick. >>>>> >>>>> I'm actually using a basix-200 COM. I will not be able to play with >>>>> device drivers and kernel space software. Our product has a fixed rootfs >>>>> that i haven't modified for a few years, and all our custom software resides >>>>> on various MMC partitions. >>>>> >>>>> Dave mentioned that there were 3 things I need to keep track of to know >>>>> when to revert back to receive mode: watch 2 buffers, and the shift-register >>>>> empty flags. I believed that I could track all of this information by >>>>> reading the "TIOCSERGETLSR" status register using ioclt(). I can read >>>>> that register but it doesn't seem to contain information that relates to the >>>>> serial port. >>>>> >>>>> The 1bit flag that should reflect the shift-register empty state, is >>>>> always 1 (which means empty). perhaps i need to read it a few times? maybe >>>>> i'm reading it too quickly after writing a packet to the buffer? >>>>> >>>>> does anyone have a good resource for the contents of the "TIOCSERGETLSR" >>>>> status register, or perhaps a more suitable status register, and maybe any >>>>> GUMSTIX specific parts of those registers? >>>>> >>>>> thank you. >>>>> >>>>> Best regards >>>>> >>>>> Matt Bowles >>>>> Embedded Systems Engineer >>>>> *aWma**** Pty Ltd* >>>>> >>>>> >>>>> ------------------------------ >>>>> *From:* richard dorfner [mailto:rdo...@gm...] >>>>> *Sent:* Friday, 28 August 2009 11:16 PM >>>>> >>>>> *To:* General mailing list for gumstix users. >>>>> *Subject:* Re: [Gumstix-users] GPIO manipulation from a user-space C >>>>> program >>>>> >>>>> Usually , when someone tells me they want to do something like this, >>>>> I generally suggest putting it all into the serial device driver. If they >>>>> need stateful infomration, like handling some kind of simple ack/nak >>>>> protocol and turnign the 485 transceiver on and off, then Doing so with a >>>>> static state variable works nicely to remember state across ISR's. From >>>>> there, instead of just having the serial port generate an ISR on thre and >>>>> rxrdy, have it also generate an ISR on status register state change. >>>>> >>>>> Not sure if the serial port on the overo/verdex is very flexible with >>>>> what kinds of isr's it can generate, but it will most certainly get your 485 >>>>> line turned around within a millisecond or two of shoveling out the last >>>>> bit. >>>>> >>>>> Rick >>>>> >>>>> >>>>> On Thu, Aug 27, 2009 at 10:53 PM, Matthew Bowles <ma...@aw...>wrote: >>>>> >>>>>> Hi everyone >>>>>> >>>>>> I have got the GPIO access working in C. I did use fputs() instead of >>>>>> fwrite() just to simplify things, but what I am getting is a 50mS lag >>>>>> between. that is, the following code: >>>>>> >>>>>> fputs("GPIO out set",pGPIO_TxRx); >>>>>> fflush(pGPIO_TxRx); >>>>>> fputs("GPIO out clear",pGPIO_TxRx); >>>>>> fflush(pGPIO_TxRx); >>>>>> >>>>>> produces a trace with a +ve edge, followed by a delay of 48.4mS, and >>>>>> then a >>>>>> -ve edge. >>>>>> obviously there's some kernel polling of file-system writes or >>>>>> something. I >>>>>> assumed it would be near instaneous and I need it to be within 3-5 mS. >>>>>> >>>>>> I should have given some better detail on what I'm trying to achieve. >>>>>> >>>>>> I am attempting to get RS485 comms working from my GUMSTIX. At the >>>>>> moment my >>>>>> HW is not ready, but i am working on the synchronisation of the >>>>>> Transmit >>>>>> enable (DE) (which is also the active-low Rx Enable) with the transmit >>>>>> buffer. >>>>>> >>>>>> i have seen some examples of ioctl structure extensions to handle the >>>>>> RS485 >>>>>> transmit enable sync'ing. And it seems to be industry standard to use >>>>>> the >>>>>> RTS line of the serial port if it has one. >>>>>> what I noticed, is that I can control the RTS line but only if the >>>>>> RTS/CTS >>>>>> lines are activated in the serial port config, al la - "c_cflag |= >>>>>> CRTSCTS;" >>>>>> >>>>>> there is a problem with doing this though - you are essentially >>>>>> enabling HW >>>>>> flow control, which means driving CTS in some fashion to allow the >>>>>> port to >>>>>> transmit. >>>>>> >>>>>> to avoid this I thought I would manually drive the TTL output of the >>>>>> RTS >>>>>> pin. But i get the lagging I mentioned when I interact with the pin >>>>>> via the >>>>>> filesystem. >>>>>> >>>>>> Does anyone have any experience with RS485 on the GUMSTIX platform? I >>>>>> may >>>>>> attempt to get the gpregs stuff working unless someone says otherwise. >>>>>> >>>>>> any advice at all would be appreciated. >>>>>> >>>>>> >>>>>> Best regards >>>>>> >>>>>> Matt Bowles >>>>>> Embedded Systems Engineer >>>>>> aWma Pty Ltd >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Dave Hylands [mailto:dhy...@gm...] >>>>>> Sent: Friday, 28 August 2009 12:13 AM >>>>>> To: General mailing list for gumstix users. >>>>>> Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C >>>>>> program >>>>>> >>>>>> Hi Matt, >>>>>> >>>>>> > I'm trying to track down the cleanest way of manipulating a GPIO >>>>>> > signal on my gumstix board. I understand the IN/OUT and AF1, GPIO >>>>>> > settings as I can get things working in shell-script land using >>>>>> `echo >>>>>> > "GPIO OUT SET" > /proc/gpio/GPIO81` and that sort of thing. >>>>>> > >>>>>> > but in C, I presume its a bit cludgy to say something resembling >>>>>> > - system("echo... /proc/gpio/, etc, etc"); >>>>>> >>>>>> Presuambly, this is for the verdex. If you want to use the proc >>>>>> interface, >>>>>> then I would open the file (/proc/gpio/etc) using fopen, then fwrite >>>>>> "gpio >>>>>> out set" to it and then fclose it. Wrap it up in a function and away >>>>>> you go. >>>>>> >>>>>> > I have found an example here >>>>>> > http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs >>>>>> > which seems to be giving a nice wrapper around some functions. I am >>>>>> > not willing to try it first though, as I've read about the kernel >>>>>> > space versus user space limitations. I probably can't break anything >>>>>> > and I'll look silly for being so cautious, but does anyone know if >>>>>> > this is the way to work directly with hte GPIO lines in C, or am I >>>>>> barking >>>>>> up the wrong tree? >>>>>> >>>>>> If you want to write directly to the gpio lines, then you'd need to >>>>>> use the >>>>>> gpregs approach. >>>>>> >>>>>> Another way is to write a custom driver and have the user space >>>>>> program talk >>>>>> to the custom driver. >>>>>> >>>>>> -- >>>>>> Dave Hylands >>>>>> Shuswap, BC, Canada >>>>>> http://www.DaveHylands.com/ >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------------- >>>>>> -- >>>>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>>>> 30-Day >>>>>> trial. Simplify your report design, integration and deployment - and >>>>>> focus >>>>>> on what you do best, core application coding. Discover what's new with >>>>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>>>> _______________________________________________ >>>>>> gumstix-users mailing list >>>>>> gum...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>>>> No virus found in this incoming message. >>>>>> Checked by AVG - www.avg.com >>>>>> Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: >>>>>> 08/27/09 >>>>>> 08:11:00 >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>>>> 30-Day >>>>>> trial. Simplify your report design, integration and deployment - and >>>>>> focus on >>>>>> what you do best, core application coding. Discover what's new with >>>>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>>>> _______________________________________________ >>>>>> gumstix-users mailing list >>>>>> gum...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Say you can or say you can't, either way you will be right. >>>>> Computers are like old testament gods: Lots of rules and no mercy. >>>>> >>>>> No virus found in this incoming message. >>>>> Checked by AVG - www.avg.com >>>>> Version: 8.5.392 / Virus Database: 270.13.67/2326 - Release Date: >>>>> 08/27/09 18:02:00 >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>>> 30-Day >>>>> trial. Simplify your report design, integration and deployment - and >>>>> focus on >>>>> what you do best, core application coding. Discover what's new with >>>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>>> _______________________________________________ >>>>> gumstix-users mailing list >>>>> gum...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>>> >>>>> >>>> >>>> >>>> -- >>>> Say you can or say you can't, either way you will be right. >>>> Computers are like old testament gods: Lots of rules and no mercy. >>>> >>>> No virus found in this incoming message. >>>> Checked by AVG - www.avg.com >>>> Version: 8.5.409 / Virus Database: 270.13.71/2336 - Release Date: >>>> 08/30/09 17:51:00 >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>> 30-Day >>>> trial. Simplify your report design, integration and deployment - and >>>> focus on >>>> what you do best, core application coding. Discover what's new with >>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>> _______________________________________________ >>>> gumstix-users mailing list >>>> gum...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>> >>>> >>> >>> >>> -- >>> Say you can or say you can't, either way you will be right. >>> Computers are like old testament gods: Lots of rules and no mercy. >>> >>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day >>> trial. Simplify your report design, integration and deployment - and >>> focus on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 8.5.409 / Virus Database: 270.13.71/2336 - Release Date: 08/30/09 >> 17:51:00 >> >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > > -- > Say you can or say you can't, either way you will be right. > Computers are like old testament gods: Lots of rules and no mercy. > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.409 / Virus Database: 270.13.71/2336 - Release Date: 09/01/09 > 20:03:00 > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- Say you can or say you can't, either way you will be right. Computers are like old testament gods: Lots of rules and no mercy. |