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.
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.
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
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?
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?
The Gumstix Overo has the pins availible.
Which pins?
The native camera interface
The GPIO pins are grouped in a more sensible manner to make writing an in-kernel parallel type driver easier
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.
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.
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.
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 werent made for bulk amounts of data transfers on a clock
like the ECP/EPP PC parallel ports.
I know this wasnt the answer you were looking for, but hope it anyway
clarified your question?
Best regards
Søren
Fra: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] På
vegne af dasosa@miners.utep.edu
Sendt: 4. november 2008 21:39
Til: beagleboard@googlegroups.com
Emne: [beagleboard] Re: Using the GPIO pins on the BeagleBoard as a
parallel port
Thank you for the reply.
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
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.
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 arent 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...