Writing 8-bit data to GPIO pins - does one have to do it a bit at a time?

[c...@isbd.net]

All the examples and libraries (Python mostly) that I can find for
doing IO to the GPIO pins seem to handle only a bit at a time. This
is fine for things like driving relays and LEDs but makes little sense
for 8-bit data.

Are there any sets of 8 GPIO pins that can be used together easily for
outputting 8-bit data? ... and are there any Python IO libraries that
make doing this easy?

At present my Python code is carefully masking, shifting and
outputting the data bit by bit and I have a horrible suspicion that
the library I'm using is carefully doing the opposite before it does
the actual write to GPIO. :-)

--
Chris Green
·

[Jason Kridner]

On Thu, Mar 6, 2014 at 4:25 AM, <c...@isbd.net> wrote:

All the examples and libraries (Python mostly) that I can find for
doing IO to the GPIO pins seem to handle only a bit at a time.  This
is fine for things like driving relays and LEDs but makes little sense
for 8-bit data.

Are there any sets of 8 GPIO pins that can be used together easily for
outputting 8-bit data?

From a hardware standpoint, some of the GPIOs are in the same bank and can be updated in the same register write.

See the TRM at http://www.ti.com/product/am3359.

You have options of using the GPIO_DATAOUT, GPIO_SETDATAOUT and GPIO_CLEARDATAOUT registers. Up to 32 GPIOs can be controlled by each of these registers. The GPIO numbers are given in the format GPIOx_y where x is the bank that will be in a single register and y is the offset within the register.

Of course, it might be more practical for you to utilize the GPMC bus when looking to do parallel operations, especially if you want to use DMA or otherwise perform repeated accesses.

The following blog post shows an example of using 'mmap' to configure and utilize the GPMC bus:

http://engineersofthecorn.blogspot.com/2012/06/faux-gpmc-interfacing-with-beaglebone.html

There is a GPMC driver in the kernel at https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/gpmc.c.

I'm not sure how to use it.

You can also use the PRU for fast parallel bus access.

 

 ... and are there any Python IO libraries that
make doing this easy?

I'm not aware of any that make it possible today, though it could be possible. Most typically, from Linux userspace it is common to utilize the SYSFS entries provided by the kernel to perform GPIO entries.

See the Linux kernel documentation on SYSFS entries at https://www.kernel.org/doc/Documentation/gpio/sysfs.txt.

It is, however, possible to access the GPIO registers directly from within Python using 'mmap':

http://www.alexanderhiam.com/tutorials/beaglebone-io-using-python-mmap/

http://hackaday.com/2013/12/07/speeding-up-beaglebone-black-gpio-a-thousand-times/

Adafruit_BBIO uses the SYSFS entries as can be seen at https://github.com/adafruit/adafruit-beaglebone-io-python/blob/557448a13780149c1ca1f3116262dc4fd002adf2/source/event_gpio.c#L262.

PyBBIO uses 'mmap' as can be seen at https://github.com/alexanderhiam/PyBBIO/blob/81a4a22a3a0c7805db80605edb3212dd4646673c/bbio/platform/beaglebone/gpio.py#L34.

The 'mmap' method exposes the registers. Despite the PyBBIO library not exposing a function today that would perform writes to multiple pins at once, it should be possible to modify the code to expose new functions.

 

At present my Python code is carefully masking, shifting and
outputting the data bit by bit and I have a horrible suspicion that
the library I'm using is carefully doing the opposite before it does
the actual write to GPIO. :-)

What library are you using?

 

--
Chris Green
·

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[c...@isbd.net]

Jason Kridner <jason....@hangerhead.com> wrote:
[snip]

Thanks for that comprehensive answer - there's several things there I
may look into, in particular using python file i/o to read the data.

> >
> > At present my Python code is carefully masking, shifting and
> > outputting the data bit by bit and I have a horrible suspicion that
> > the library I'm using is carefully doing the opposite before it does
> > the actual write to GPIO. :-)
> >
>
> What library are you using?
>

The adafruit one as it seems to be the most univesally used one. I
looked down in the depths of its library code and it does seem to
write single bits actually.

--
Chris Green
·

[Jacek Radzikowski]

Chris,

Out of frustration with having to toggle each bit separately, I wrote a library which addresses the problem of scattered I/O pins and allows to use up to 32 independent lines as one word. Due to design of the I/O in the processor it is not possible to change at the same time pins scattered over multiple banks but, at least from the application point of view, all allocated pins are visible as an n-bit word. The library uses mmap to access the pins, so even with the translation layer between the application and the hardware it still should be faster than using file I/O on /sys entries.

The code is posted on github: https://github.com/piranha32/IOoo

j.

On Thu, Mar 6, 2014 at 4:25 AM, <c...@isbd.net> wrote:

--
Chris Green
·

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Given a choice between two theories, take the one which is funnier

[c...@isbd.net]

Jacek Radzikowski <jacek.ra...@gmail.com> wrote:
> [-- text/plain, encoding quoted-printable, charset: ISO-8859-1, 61 lines --]

>
> Chris,
>
> Out of frustration with having to toggle each bit separately, I wrote a
> library which addresses the problem of scattered I/O pins and allows to use
> up to 32 independent lines as one word. Due to design of the I/O in the
> processor it is not possible to change at the same time pins scattered over
> multiple banks but, at least from the application point of view, all
> allocated pins are visible as an n-bit word. The library uses mmap to
> access the pins, so even with the translation layer between the application
> and the hardware it still should be faster than using file I/O on /sys
> entries.
> The code is posted on github: https://github.com/piranha32/IOoo
>

Thanks Jacek, that looks very useful, especially as you've done a
HD44780-compatible LCD displays device driver as that's what I'm using
it for at the moment.

--
Chris Green
·

[Jacek Radzikowski]

LCD is not the best example of use of the library, because you still have to do some bit magic to set control signals and data lines in the I/O block, but shows how you can abstract the interface from physical allocation of bits.

However it still can save some time if you want to add an alphanumeric display to your design.

j.

 

--
Chris Green
·

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[robert.berger]

Hi,

On Thursday, March 6, 2014 11:25:14 AM UTC+2, c...@isbd.net wrote:

All the examples and libraries (Python mostly) that I can find for
doing IO to the GPIO pins seem to handle only a bit at a time.  This
is fine for things like driving relays and LEDs but makes little sense
for 8-bit data.

Taking your example. If we are talking about a device you want to connect to your beagle user space should not know how you talk to it physically and whether it's 8-bit data or i2c or something else underneath. Having said that there was/is some attempt to do what you want in kernel space [1] and it's called block GPIO [2] but I don't think it made it into mainline.

Regards,

Robert

[1] http://lwn.net/Articles/533632/
[2] http://lwn.net/Articles/533557/

[Brandon I]

user space should not know how you talk to it physically 

I don't think this is generally accepted, otherwise user space device drivers wouldn't exist: http://www.embedded.com/design/operating-systems/4401769/Device-drivers-in-user-space

With user space device drivers, you're free to push as little or as much into the kernel as you like.

-Brandon

[John Syn]

From: Brandon I <brando...@gmail.com>
Reply-To: <beagl...@googlegroups.com>
Date: Friday, March 7, 2014 at 1:27 PM
To: <beagl...@googlegroups.com>
Cc: <c...@isbd.net>
Subject: [beagleboard] Re: Writing 8-bit data to GPIO pins - does one have to do it a bit at a time?

user space should not know how you talk to it physically 

I don't think this is generally accepted, otherwise user space device drivers wouldn't exist: http://www.embedded.com/design/operating-systems/4401769/Device-drivers-in-user-space

With user space device drivers, you're free to push as little or as much into the kernel as you like.

The normal practice is that a badly behaving user space application should not kill your complete system. Only the user space app should die. When you use user space drivers, you no longer have that protection. User space drivers are generally not a good idea unless you want to avoid the user/kernel switching delays. 

Regards,

John

-Brandon

On Thursday, March 6, 2014 12:06:43 PM UTC-8, robert.berger wrote:

Hi,

On Thursday, March 6, 2014 11:25:14 AM UTC+2, c...@isbd.net wrote:

All the examples and libraries (Python mostly) that I can find for
doing IO to the GPIO pins seem to handle only a bit at a time.  This
is fine for things like driving relays and LEDs but makes little sense
for 8-bit data.

Taking your example. If we are talking about a device you want to connect to your beagle user space should not know how you talk to it physically and whether it's 8-bit data or i2c or something else underneath. Having said that there was/is some attempt to do what you want in kernel space [1] and it's called block GPIO [2] but I don't think it made it into mainline.

Regards,

Robert

[1] http://lwn.net/Articles/533632/
[2] http://lwn.net/Articles/533557/

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Brandon I]

> When you use user space drivers, you no longer have that protection.

Since this is so off topic I'll just say, anyone interested about this topic, there is plenty of tutorials and articles about sane user space device drivers, along with production quality open source drivers. The acceptance of the concept is somewhat new, and there are many misconceptions.

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/91ikp6Mxi0s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[John Syn]

From: Brandon I <brando...@gmail.com>
Reply-To: <beagl...@googlegroups.com>

Date: Friday, March 7, 2014 at 3:22 PM
To: beagleboard <beagl...@googlegroups.com>
Subject: Re: [beagleboard] Re: Writing 8-bit data to GPIO pins - does one have to do it a bit at a time?

> When you use user space drivers, you no longer have that protection.

Since this is so off topic I'll just say, anyone interested about this topic, there is plenty of tutorials and articles about sane user space device drivers, along with production quality open source drivers. The acceptance of the concept is somewhat new, and there are many misconceptions.

Reading the article you sighted, there are several issues with UIO, namely no interrupt handling, no resource management, no memory management, etc. For example, you have to use a Kernel mode interrupt handler and then your user space UIO driver has to read and block until an interrupt occurs. After the interrupt occurs, the scheduler has to schedule your UIO driver to run before your driver can respond to the interrupt. That is going to be very slow compared to a kernel driver interrupt handler. The application on the user side has to take care of memory and resource management rather than relying on the core driver components already available in the kernel. I’m not saying that UIO isn’t a good idea. Understand the benefits and limitations of UIO before pursuing this direction. 

Regards,

John