i'm on the trail.
this :
------------------------------------
2) The Patch bugfix-serial-register-patch adds the register lsr and mcr to
various functions. In most of the places, the LSR is first read using lsr =
serial_in(up, UART_LSR); and then saved as up->lsr = lsr;
So the LSR status is always updated.
But in function unsigned int serial_pxa_tx_empty we don't update the state
of LSR. We just check the Transmitter empty condition on old value of LSR
and return.ret = up->lsr & UART_LSR_TEMT ? TIOCSER_TEMT : 0;
As the result, if the user check wants to see if the transmitter is empty
using ioctl(fd, TIOCSERGETLSR, &status); he will never get the correct
status.
I would be glad if someone could give me information about these patches.
-----------------------------------
is from our own beloved list. and is where I became suspicious that the
underlying LSR drivers were broken.
I only wish they were broken in such a way that it was inverted or something
easily dealt with like that.
Best regards
Matt Bowles
Embedded Systems Engineer
aWma Pty Ltd
_____
From: richard dorfner [mailto:rdorfner@...]
Sent: Thursday, 3 September 2009 10:20 AM
To: General mailing list for gumstix users.
Subject: Re: [Gumstix-users] GPIO manipulation from a user-space C program
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 <matthew@...> 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:rdorfner@...]
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@...> 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@...]
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@...>
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@...>
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@...]
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@...> 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@...]
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@...>
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@...]
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@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users
No virus found in this incoming message.
Checked by AVG - http://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@...
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 - http://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@...
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 - http://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@...
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@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users
No virus found in this incoming message.
Checked by AVG - http://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@...
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 - http://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
gumstix-users@...
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 - http://www.avg.com
Version: 8.5.409 / Virus Database: 270.13.71/2336 - Release Date: 09/02/09
18:03:00
|