From: Paul A. <pa...@sd...> - 2005-12-02 17:22:07
|
Hi, whats a good/efficient way to toggle GPIO pins from within C ? At the moment I am simply using system("echo set > /proc/gpio/GPIO47"), which I am sure isnt the best way, but its late and I wanted to see some action ;) Cheers Paul Arch |
From: David I S M. <da...@th...> - 2005-12-02 17:32:00
|
Open the /proc/gpio/GPIO47 file and write into it directly. Paul Arch wrote: > Hi, > > whats a good/efficient way to toggle GPIO pins from within C ? > > At the moment I am simply using system("echo set > /proc/gpio/GPIO47"), > which I am sure isnt the best way, but its late and I wanted to see some > action ;) > > Cheers > > Paul Arch > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users -- David Mandala <davidm at them dot com> www.them.com/~davidm Public Key id: 45B2D952 Murphy TX, 75094 214.774-2569 H 972.693.4007 C |
From: Alexandre P. N. <al...@om...> - 2005-12-02 17:44:25
|
David I S Mandala escreveu: > Open the /proc/gpio/GPIO47 file and write into it directly. > This is a good aproach, not to mention it's quite simple. If however by efficient the guy who asked meant "as fast as possible", then there's the option of mmap()ing the pxa registers and accessing them directly, which in theory requires a memory I/O and no context switches, etc. If I'm not mistaken, the pxaregs utility does that, one can take a look to see in deeper details. I guess however one should try all simples methods before going to something which, besides being complicated, may have collateral damages if one sets (or fails to set) the wrong register by mistake. Alexandre |
From: Craig H. <cr...@gu...> - 2005-12-02 19:52:17
|
On Dec 2, 2005, at 9:44 AM, Alexandre Pereira Nunes wrote: > David I S Mandala escreveu: > >> Open the /proc/gpio/GPIO47 file and write into it directly. >> > > This is a good aproach, not to mention it's quite simple. If > however by > efficient the guy who asked meant "as fast as possible", then there's > the option of mmap()ing the pxa registers and accessing them directly, > which in theory requires a memory I/O and no context switches, etc. > > If I'm not mistaken, the pxaregs utility does that, one can take a > look > to see in deeper details. > > I guess however one should try all simples methods before going to > something which, besides being complicated, may have collateral > damages > if one sets (or fails to set) the wrong register by mistake. Yes, doing the mmap thing and twiddling the GPIO registers directly is the fastest way to go from userspace. You can basically merge the pxaregs code and the code from the proc_gpio driver in linux/drivers/ gpio/proc_gpio.c to do what you need to do. I think though that there'll still be some reasonable overhead there going through the mmap layer. The fastest way of all would be to write a kernel driver to do the GPIO twiddling. C |
From: Dave H. <dhy...@gm...> - 2005-12-02 21:16:46
|
Hi Craig, > Yes, doing the mmap thing and twiddling the GPIO registers directly > is the fastest way to go from userspace. You can basically merge the > pxaregs code and the code from the proc_gpio driver in linux/drivers/ > gpio/proc_gpio.c to do what you need to do. I think though that > there'll still be some reasonable overhead there going through the > mmap layer. The fastest way of all would be to write a kernel driver > to do the GPIO twiddling. Actually, the only overhead is during the mmap call itself. Once mmap returns you've got your own MMU page(s) which is/are mapped directly to the hardware. It just doesn't get any faster. This is as fast as the kernel could access the hardware from inside a driver. This is exactly the same technique that's used to access the frame buffer for an LCD as well (X-Windows is also a user-mode app). The disadvantage of this approach use /dev/mem generally requires root access. On an embedded platform this typically isn't a problem. On a more typical linux machine this would represent a HUGE security breach, which is why traditional drivers are used. Normal drivers can provide some sanity to the mmap's region, so for the framebuffer you can only mmap the framebuffer and not anywhere else in the kernel. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Craig H. <cr...@gu...> - 2005-12-02 22:25:30
|
On Dec 2, 2005, at 1:16 PM, Dave Hylands wrote: > Hi Craig, > >> Yes, doing the mmap thing and twiddling the GPIO registers directly >> is the fastest way to go from userspace. You can basically merge the >> pxaregs code and the code from the proc_gpio driver in linux/drivers/ >> gpio/proc_gpio.c to do what you need to do. I think though that >> there'll still be some reasonable overhead there going through the >> mmap layer. The fastest way of all would be to write a kernel driver >> to do the GPIO twiddling. > > Actually, the only overhead is during the mmap call itself. Once mmap > returns you've got your own MMU page(s) which is/are mapped directly > to the hardware. It just doesn't get any faster. This is as fast as > the kernel could access the hardware from inside a driver. I thought that mmap gives you something which is a virtual address -- ie it needs to go through MMU translation to actually hit the CPU register. From a kernel driver, you can just hit the register directly w/out going through the MMU, since you know that the memory location is not really RAM which might or might not be swapped out, but is for sure there. > The disadvantage of this approach use /dev/mem generally requires root > access. On an embedded platform this typically isn't a problem. On a > more typical linux machine this would represent a HUGE security > breach, which is why traditional drivers are used. Normal drivers can > provide some sanity to the mmap's region, so for the framebuffer you > can only mmap the framebuffer and not anywhere else in the kernel. Yup, I forgot to mention the security issues. C |
From: Dave H. <dhy...@gm...> - 2005-12-03 00:20:46
|
HI Craig, > I thought that mmap gives you something which is a virtual address -- > ie it needs to go through MMU translation to actually hit the CPU > register. From a kernel driver, you can just hit the register > directly w/out going through the MMU, since you know that the memory > location is not really RAM which might or might not be swapped out, > but is for sure there. Everything that the kernel does also goes through virtual addresses, so it's essentially the same thing. The only thing that uses physical addressing is DMA. uboot also uses physical addresses because it runs with the MMU turned off. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Alexandre P. N. <al...@om...> - 2005-12-03 13:07:47
|
Dave Hylands escreveu: >HI Craig, > > > >>I thought that mmap gives you something which is a virtual address -- >>ie it needs to go through MMU translation to actually hit the CPU >>register. From a kernel driver, you can just hit the register >>directly w/out going through the MMU, since you know that the memory >>location is not really RAM which might or might not be swapped out, >>but is for sure there. >> >> > >Everything that the kernel does also goes through virtual addresses, >so it's essentially the same thing. The only thing that uses physical >addressing is DMA. > > > In most cases, that's correct. On linux, the virtual address space is divided into user space and kernel space. "Kernel space" is a portion of the virtual address space which is visible from the kernel as a whole, and direct access to bus addresses on these days pass through a dma API. A user space mmu table is created to every user space process, so the process is unaware of the physical location in memory (not to mention the pages can be swapped to disk or relocated or even discarded, without the process realizing). That's one of the reasons why there's a mmap call: you need to have a virtual address to access things (files, other address spaces, etc) on memory; Accessing unmapped memory triggers a mmu page fault which the kernel interprets as "kill this beast". What a block mmap()ed driver can do is feed pages to the page cache when there's a page fault to a mmaped area, though the "page cache" doesn't work necessarily as the name may imply, you can do uncached access as well. This (uncached access) however costs an involutary context switch, and for accessing data quantities smaller than a page, it's possible that this is not a better choice than creating i.e. a character device driver and reading/writing from it or using ioctl, though, then again, you can mmap() to a this character device (should it provide appropriate support) and get a memory-backed region, so what you have is a virt-to-phys and vice-versa mapping, which is kind of how /dev/mem mapping works (of course, there are a few tricks you can do that /dev/mem doesn't do, and that would happen to help people). I must say I was sort of disappointed when I came to look at linux-arm and found several hand made tools, processor specific, to accessing registers only to read/write to GPIOs. Though different kinds of arm cpus have different set of functionality and thus different sets of registers, I though at least a gpio <-> irq <-> userspace and even a gpio set/unset/read thing would be standard. I was wrong. I'm not using GPIOs for anything that matters right now, so I never took the time to think about it, but I guess a unified interface would be an easy thing to do, at least when comparing intel's pxa 2xx to some atmel arm microcontrollers I only got the docs. If someone is willing to write something as a driver (one to allow things like gpio configuring, reading irq events from user space, etc), my vote would be to make it portable and have a platform backend to every specific implementation, and try to convice people at arm-linux to adopt it, or even cooperate with them in order to get there. But for now, that's only me :-) Alexandre |
From: John A. <jal...@sp...> - 2005-12-02 22:27:41
|
Hi Dave/Craig, What kind of concurrent control mechanism (i.e. locking) would you sugges= t for someone twiddling the GPIOs, or is a device drive atomic enough alrea= dy? John Alfredo -----Original Message----- From: gum...@li... [mailto:gum...@li...] On Behalf Of Dave Hyla= nds Sent: Friday, December 02, 2005 1:17 PM To: gum...@li... Subject: Re: [Gumstix-users] Efficient GPIO from C Hi Craig, > Yes, doing the mmap thing and twiddling the GPIO registers directly > is the fastest way to go from userspace. You can basically merge the > pxaregs code and the code from the proc_gpio driver in linux/drivers/ > gpio/proc_gpio.c to do what you need to do. I think though that > there'll still be some reasonable overhead there going through the > mmap layer. The fastest way of all would be to write a kernel driver > to do the GPIO twiddling. Actually, the only overhead is during the mmap call itself. Once mmap returns you've got your own MMU page(s) which is/are mapped directly to the hardware. It just doesn't get any faster. This is as fast as the kernel could access the hardware from inside a driver. This is exactly the same technique that's used to access the frame buffer for an LCD as well (X-Windows is also a user-mode app). The disadvantage of this approach use /dev/mem generally requires root access. On an embedded platform this typically isn't a problem. On a more typical linux machine this would represent a HUGE security breach, which is why traditional drivers are used. Normal drivers can provide some sanity to the mmap's region, so for the framebuffer you can only mmap the framebuffer and not anywhere else in the kernel. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=CCk _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Dave H. <dhy...@gm...> - 2005-12-03 00:31:44
|
Hi John, > What kind of concurrent control mechanism (i.e. locking) would you sugges= t > for someone twiddling the GPIOs, or is a device drive atomic enough alrea= dy? That's a very good point. Currently there isn't any concurrent control mechaism. This is partially OK= . The issues comes up with read-modify-write cycles (RMW). Modifying the GPDR and GAFR registers requires an RMW so they should disable interrupts (or use some other form of mutual exclusion) around these accesses. Setting a GPIO pin (GPSR), or clearing a GPIO pin (GPCR) is purely a write operation, which is already atomic, so no protection is required. Reading a pin requires reading the GPLR which is a read-only operation, which is also atomic. Since a usermode process can't do the locking, there really should be a driver call it can make to do the twiddling of the GAFR and GPDR happen atomically. The only other type of concurrency control that would be needed would be if two entities are trying to perform RMW on the same bit, but that isn't normally a problem. So, I'd propse that we extend the proc_gpio.c to add a proper driver and provide atomic access as appropriate. It could then also implement mmap to expose the appropriate registers for the GPIO twiddling. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Craig H. <cr...@gu...> - 2005-12-03 01:10:09
|
On Dec 2, 2005, at 4:31 PM, Dave Hylands wrote: > So, I'd propse that we extend the proc_gpio.c to add a proper driver > and provide atomic access as appropriate. It could then also implement > mmap to expose the appropriate registers for the GPIO twiddling. It's actually something which needs to happen at a deeper level -- i've done some thinking on this in the past. You eseentially want something akin to the existing resource allocation system, where you can grab an IRQ, memory chunk, etc. Otherwise, proc_gpio might be whacking a GPIO which is already in use by some driver that needs it configured with some specific alt fn. C |
From: Dave H. <dhy...@gm...> - 2005-12-03 01:16:39
|
Hi Craig, > It's actually something which needs to happen at a deeper level -- > i've done some thinking on this in the past. You eseentially want > something akin to the existing resource allocation system, where you > can grab an IRQ, memory chunk, etc. Otherwise, proc_gpio might be > whacking a GPIO which is already in use by some driver that needs it > configured with some specific alt fn. Good point. Something else to ponder... I guess we can use the existing platform code. I'll have to dig into that a bit more. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: David F. <dav...@ya...> - 2005-12-03 15:13:45
|
--- Craig Hughes <cr...@gu...> wrote: > It's actually something which needs to happen > at a deeper level -- > i've done some thinking on this in the past. > You eseentially want > something akin to the existing resource > allocation system, where you > can grab an IRQ, memory chunk, etc. Otherwise, > proc_gpio might be > whacking a GPIO which is already in use by some > driver that needs it > configured with some specific alt fn. It also needs some function to overload the use of the pins. Many times IO pins can be shared, for example a pseudo bus where the data and control lines can be shared but chip selects are unique. The system also has the potential (with robust stix card harware) of automatic alternate pin allocations in situations where pins are already allocated. I really could use this functionality, every experiment I've done conflicts with some cfstix or etherstix or ??stix pin allocations. I generally avoid new sw releases for this reason, I don't know when a kernel driver for a new board may take away the pins I use. David F. |
From: Dave H. <dhy...@gm...> - 2005-12-03 16:38:46
|
Hi David, > It also needs some function to overload the use > of the pins. > Many times IO pins can be shared, for example a > pseudo bus where the data and control lines can > be shared but chip selects are unique. The system > also has the potential (with robust stix card > harware) of automatic alternate pin allocations > in situations where pins are already allocated. Normally, for a scenario like this, you would create a controller driver, which understands the bus and chip selects, and then have it claim the gpio pins. SPI would be a good example of this. You then use the controller driver to talk to the individual devices. > I really could use this functionality, every > experiment I've done conflicts with some cfstix > or etherstix or ??stix pin allocations. I > generally avoid new sw releases for this reason, > I don't know when a kernel driver for a new board > may take away the pins I use. So this sounds like something a little more fundamental. If there's something that you're not using, then we really need a way of preventing that resource from being consumed. Do you have a concrete example? I know that some of the 92 bit cards consume additional GPIO pins, but they shouldn't be getting used if their modules aren't being loaded. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |