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.