[beagleboard] Using the GPIO pins on the BeagleBoard as a parallel port
das...@miners.utep.edu
I am trying to develop a project in which I have a camera sensor which controls via I2C and has an 8 bit parallel output. I would like to use 8 GPIO pins for this purpose but beyond that I am a little lost as to what the next step should be in this project. I'm still in the planning stages, but I have the newest linux kernel something, and I wanted to know if it's even possible to write a parallel port driver for this project which involves DMA preferrably. I apologize for not being overly technical, but I would appreciate any suggestions as to how this might be achieved.
Thank you,
Daniel A. Sosa
University of Texas at El Paso
Gerald Coley
John Stowers
I don't see an easy way of doing this. The GPIO are not grouped properly on the expansion connector to allow it to easily be read by SW. Generally everyone is using a USB camera to connect a camera to the Beagle. The native camera interface on the OMAP3530 is not accessible on the Beagle.
Yeah, this is a bit of a shame. If you want a uC with supported (i.e. kernel and V4L drivers) native camera interface, check out the i.MX27 ipcamera reference design/platform
John
Bill Gatliff
>
>
> On Mon, Nov 3, 2008 at 2:08 AM, Gerald Coley <ger...@beagleboard.org
> <mailto:ger...@beagleboard.org>> wrote:
>
> I don't see an easy way of doing this. The GPIO are not grouped
> properly on the expansion connector to allow it to easily be read by
> SW. Generally everyone is using a USB camera to connect a camera to
> the Beagle. The native camera interface on the OMAP3530 is not
> accessible on the Beagle.
>
>
> Yeah, this is a bit of a shame. If you want a uC with supported (i.e.
> kernel and V4L drivers) native camera interface, check out the i.MX27
> ipcamera reference design/platform
If one insists on an OMAP 3530-based platform, do/will the Gumstix or Cogent
boards have the required I/O points (or other examples)? And then are the
drivers available?
b.g.
--
Bill Gatliff
bg...@billgatliff.com
Ilja Kamps
The Gumstix Overo has the pins availible.
John Stowers
Which pins?
1) The native camera interface
2) The GPIO pins are grouped in a more sensible manner to make writing an in-kernel parallel type driver easier
John
Ilja Kamps
Both just from reading the public documentation, don't have my Overo in
yet.
das...@miners.utep.edu
Hello all,
thanks for your help regarding my previous question about using the GPIO pins as a parallel port. I suppose the question I have now is more general; I need to be able to know if there is some sort of mechanism to store from GPIO to memory in the Beagle Board (any kind of memory or memory peripheral). I'm a little lost here, but any leads would be trememdously helpful.
Thank you,
Daniel A. Sosa
Date: Mon, 3 Nov 2008 14:57:13 +0100
From: john.s...@gmail.com
To: beagl...@googlegroups.com
Subject: [beagleboard] Re: Using the GPIO pins on the BeagleBoard as a parallel port
Bill Gatliff
>
> Hello all,
>
> thanks for your help regarding my previous question about using the GPIO
> pins as a parallel port. I suppose the question I have now is more
> general; I need to be able to know if there is some sort of mechanism to
> store from GPIO to memory in the Beagle Board (any kind of memory or
> memory peripheral). I'm a little lost here, but any leads would be
> trememdously helpful.
GPIO can emulate SPI and I2C pretty easily, and there are some EEPROMs with
those interfaces. I think I also remember seeing somewhere a GPIO bit-banging
implementation for SD/MMC.
USBH on the Beagleboard won't work for you? That's only four lines. They have
to be a particular four lines, mind you, but only four. Highly unlikely you
could emulate USBH with GPIO, though, because it's basically a 48 MHz DMAC and
that's tough to do even with 500 MHz of instructions.
But if one port isn't enough, you could throw down a hub chip and create as many
ports as you need. You sound like you're planning to spin some hardware, anyway.
das...@miners.utep.edu
I suppose I could be a bit more specific. What I intend to do through these GPIO pins is to fed them pixel data that comes out of a CMOS image sensor, and it would be extremely helpful for me to know if I can continously receive the data through the GPIO pins and store them in memory. Any ideas or suggestions would be highly appreciated.
Thank you,
Daniel A. Sosa
> To: beagl...@googlegroups.com
> Subject: [beagleboard] Re: Using the GPIO pins on the BeagleBoard as a parallel port
>
>
Søren Steen Christensen
I would definitely consider this a no go unless you pixel rate is very slow
– Like maximum (best guess) 100.000 pixels a second or so…
And even in this case it would involve (some) instructions reading the GPIO
ports (, restructuring the data) and transferring it into memory…
The GPIO modules weren’t made for bulk amounts of data transfers on a clock
like the ECP/EPP PC parallel ports.
I know this wasn’t the answer you were looking for, but hope it anyway
clarified your question?
Best regards
Søren
> Fra: beagl...@googlegroups.com [mailto:beagl...@googlegroups.com] På
vegne af das...@miners.utep.edu
> Sendt: 4. november 2008 21:39
> Til: beagl...@googlegroups.com
> Emne: [beagleboard] Re: Using the GPIO pins on the BeagleBoard as a
parallel port
>
jaki...@gmail.com
I am also interested in transferring large amounts of parallel data to
the Beagle board at a fast rate. Would the USB be the best way to go
around it then? Is there a better interface? Too bad the GPIO's cant
go very fast but, where could I find the actual max transfer speed?
All I can think of is to write an assembly program to test it.
Thanks
NM
On Nov 4, 4:19 pm, Søren Steen Christensen
Ilja Kamps
>
> Hello,
>
> I am also interested in transferring large amounts of parallel data to
> the Beagle board at a fast rate. Would the USB be the best way to go
> around it then? Is there a better interface? Too bad the GPIO's cant
> go very fast but, where could I find the actual max transfer speed?
> All I can think of is to write an assembly program to test it.
I might be quite mistaken, but I asked similair questions and
appaerently the transfer speed is quite decent, but there is a little
trick possible appaerently. According to some info the DSP can read from
GPIO pins, so you could run the code to do the actual transfer on the
DSP if you don't need it for other things.
Søren Steen Christensen
I just did a small experiment with the USER0 LED GPIO in U-boot. Having a
tight ARM assembler loop of 3 instructions doing:
:Start
Set GPIO to output
:Label
Set GPIO high
Set GPIO low
Goto Label
From this I was able to obtain a ~1.5MHz square wave signal on an
oscilloscope. From this I still conclude, that GPIOs aren’t the right way
for massive parallel data transfers. In order to achieve such a thing I
really recommend using one of the interfaces build for this, connected to
some kind of external logic in case needed. This could be i.e. the display
interface or the camera interface (unfortunately not available on BB) for
output/input or the MMC interface connected to some kind of logic/CPLD for
converting between "pseudo" MMC commands and whatever parallel data format
needed - This could serve both input and output and is easily available on
BB expansion connector. These three interfaces all contains FIFO buffers and
supports DMA transfers making much higher transfer rates available on low
system/SW cycle cost...
One other drawback of trying to poll/set the GPIOs in a tight loop is that
you have basically no control over exact timing regardless what you do. Not
even if the code is running on the DSP. The reason for this is, that the
requests to access the GPIO IP block must pass through the L3 and L4
interconnects, which might be busy servicing other initiators (HSUSB, DMA,
ARM, DSP, Camera, Display etc.) as well. Unless you take very special care
what you are doing to the complete system, timing will be undeterministic,
and the L4 (and maybe L3 - I'm not completely sure) interconnects might be
flooded with GPIO requests causing a possible degradation of overall system
performance... More information with respect to L3 and L4 of the OMAP can be
found in the TRM chapter 5...
In case of further questions or comments please let me know, and I will try
to help you out...
Best regards
Søren