Re: [Gumstix-users] GPIO manipulation from a user-space C program

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

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