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:rdorfner@gmail.com]
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 <matthew@awma.au.com> 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:cavalkaf@gmail.com]
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 <rdorfner@gmail.com> 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 <matthew@awma.au.com> 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:rdorfner@gmail.com]
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 <matthew@awma.au.com> 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:rdorfner@gmail.com]
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 <matthew@awma.au.com> 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:dhylands@gmail.com]
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
gumstix-users@lists.sourceforge.net
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
gumstix-users@lists.sourceforge.net
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
gumstix-users@lists.sourceforge.net
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
gumstix-users@lists.sourceforge.net
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
gumstix-users@lists.sourceforge.net
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
gumstix-users@lists.sourceforge.net
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