From: Alexandre P. N. <al...@om...> - 2005-10-11 20:08:19
|
Hi there, I understand that pxa27x to be used on next-gen gumstix does video cap natively. However I'm considering doing analog video capture with current gumstix, and went to this tiny thing: http://www.semiconductors.philips.com/acrobat_download/datasheets/SAA7113H_2.pdf I have a usb video cap device which is built with it (and a usb-specific chip which manages the above chip, plus does video encoding). Looking at it i've noticed that building a circuit with the SAA7113 is quite simple: it requires a crystal, 2 wires for programmint it through i2c, it outputs video through a 8-bit bus, plus some standard filtering stuff (capacitors, etc) and analog inputs. Besides that, I already found a (WIP) linux driver for SAA7113. So my main doubt is: How to connect it's 8bit bus to gumstix? I considered putting it on a buffer and them throwing it direct at bus data lines (on the 92-pin header), but I have no idea how to do it; I never done it before. How do I address that question? I think due to the relatively high data rate that would be my best option... Someone else thinks it is worth the shot? Thoughs? Thanks in advance! Alexandre |
From: George F. <cha...@gm...> - 2005-10-11 20:37:31
|
Hi Alexandre, I'm in the process of something similar. I'd be interested to know how much use an existing driver would be with custom hardware. I'm laying out a pcb for a quick test of a camera chip (OV7620). One of the problems with this kind of stuff is that the data is a constant (fairly high) data rate, so I'm using a FIFO buffer to store a few lines of image, then an ISR can read them in at a high rate. That way the processor is only tied up for short bursts. Don't hold your breath though, I'm doing this in my spare time, I'm not familiar with the arm architecture (though I am an electronics eng) and my linux programming hasnt got to the device drivers stage yet :) George. |
From: Craig H. <cr...@gu...> - 2005-10-12 16:22:07
|
On Oct 11, 2005, at 1:37 PM, George Francis wrote: > I'm in the process of something similar. I'd be interested to know > how much use an existing driver would be with custom hardware. > > I'm laying out a pcb for a quick test of a camera chip (OV7620). One > of the problems with this kind of stuff is that the data is a constant > (fairly high) data rate, so I'm using a FIFO buffer to store a few > lines of image, then an ISR can read them in at a high rate. That way > the processor is only tied up for short bursts. It should then be fairly easy to hook the buffer up to the PXA, following the schematics for the etherstix or any of the netstix. You basically end up with some IO port on the PXA for one of the chip- selects connected to the IO device, then from the PXA's point of view, you just read a byte/halfword/word (depending on what the device wants to do) at a time from what to the PXA looks like memory. Oh, there's one other step which is you have to configure the PXA memory controller to tell it the specs of the device you're connecting. Normally that's just a matter of taking the device's datasheet, and reading off the numbers that the Intel configuration tool wants. The Intel tool then will spit out a value which you can stick in (iirc) MDCFG in the u-boot code to initialize things. Then your linux driver will have to allocate a resource for the memory address, then you can just read/write to the device. Of the device drivers the 'stix already uses, the smc91x one is probably easiest to understand. C |
From: George F. <cha...@gm...> - 2005-10-12 18:37:00
|
Hi Craig, Thanks, thats fantastic, thats the kind of stuff I need to get me going. One thing that shocked me was that the RDY line is also a GPIO, I've not seen bus control lines multitasking like that before, I'll have to check that thats set up right first. Pcb is progressing well....I'm off to read the smc91x source code. George. On 12/10/05, Craig Hughes <cr...@gu...> wrote: > On Oct 11, 2005, at 1:37 PM, George Francis wrote: > > > I'm in the process of something similar. I'd be interested to know > > how much use an existing driver would be with custom hardware. > > > > I'm laying out a pcb for a quick test of a camera chip (OV7620). One > > of the problems with this kind of stuff is that the data is a constant > > (fairly high) data rate, so I'm using a FIFO buffer to store a few > > lines of image, then an ISR can read them in at a high rate. That way > > the processor is only tied up for short bursts. > > It should then be fairly easy to hook the buffer up to the PXA, > following the schematics for the etherstix or any of the netstix. > You basically end up with some IO port on the PXA for one of the chip- > selects connected to the IO device, then from the PXA's point of > view, you just read a byte/halfword/word (depending on what the > device wants to do) at a time from what to the PXA looks like > memory. Oh, there's one other step which is you have to configure > the PXA memory controller to tell it the specs of the device you're > connecting. Normally that's just a matter of taking the device's > datasheet, and reading off the numbers that the Intel configuration > tool wants. The Intel tool then will spit out a value which you can > stick in (iirc) MDCFG in the u-boot code to initialize things. Then > your linux driver will have to allocate a resource for the memory > address, then you can just read/write to the device. Of the device > drivers the 'stix already uses, the smc91x one is probably easiest to > understand. > > C > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Alexandre P. N. <al...@om...> - 2005-10-13 01:45:16
|
Craig Hughes escreveu: > On Oct 11, 2005, at 1:37 PM, George Francis wrote: > >> I'm in the process of something similar. I'd be interested to know >> how much use an existing driver would be with custom hardware. >> >> I'm laying out a pcb for a quick test of a camera chip (OV7620). One >> of the problems with this kind of stuff is that the data is a constant >> (fairly high) data rate, so I'm using a FIFO buffer to store a few >> lines of image, then an ISR can read them in at a high rate. That way >> the processor is only tied up for short bursts. > > > It should then be fairly easy to hook the buffer up to the PXA, > following the schematics for the etherstix or any of the netstix. > You basically end up with some IO port on the PXA for one of the chip- > selects connected to the IO device, then from the PXA's point of > view, you just read a byte/halfword/word (depending on what the > device wants to do) at a time from what to the PXA looks like > memory. Oh, there's one other step which is you have to configure > the PXA memory controller to tell it the specs of the device you're > connecting. Normally that's just a matter of taking the device's > datasheet, and reading off the numbers that the Intel configuration > tool wants. The Intel tool then will spit out a value which you can > stick in (iirc) MDCFG in the u-boot code to initialize things. Then > your linux driver will have to allocate a resource for the memory > address, then you can just read/write to the device. Of the device > drivers the 'stix already uses, the smc91x one is probably easiest to > understand. > > C What about DMA? I guess it would be nice if the frame grabber writes direct on memory (through a buffer), and when i.e. a scanline is complete, it triggers an irq on the cpu. That would be close to optimal, i guess. I read somewhere that there are missing line(s) on the 92 pin connector in order to do dma, is that so? With the saa chip i mentioned before, it would be somewhat easy to do that, if dma would be easy as well. I don't know. Alexandre |
From: Craig H. <cr...@gu...> - 2005-10-13 03:34:29
|
On Oct 12, 2005, at 6:45 PM, Alexandre Pereira Nunes wrote: > What about DMA? I guess it would be nice if the frame grabber writes > direct on memory (through a buffer), and when i.e. a scanline is > complete, it triggers an irq on the cpu. That would be close to > optimal, > i guess. I read somewhere that there are missing line(s) on the 92 pin > connector in order to do dma, is that so? > > With the saa chip i mentioned before, it would be somewhat easy to do > that, if dma would be easy as well. I don't know. Yeah, there's no DREQ line coming out on either connector on the current gumstix. We're in the process of revising the gumstix as part of replacing the ROK104001 bluetooth module with the PBA31307 which is its replacement (the ROK is being EOLed). As part of that revision, we're going to be taking the JTAG lines off the 60-pin connector, and instead putting the BTUART lines and I think one of the DREQs on there instead. So then people who don't have the onboard bluetooth will be able to get 4 UARTs over the 60-pin connector, and though the data&address lines are on the 92-pin connector, there'll at least be a half-assed way of doing DMA from a device on a daughtercard (half-assed because you'll have to use both connectors to get it done). C |
From: Alexandre P. N. <al...@om...> - 2005-10-13 12:00:41
|
Craig Hughes wrote: > [cut] > Yeah, there's no DREQ line coming out on either connector on the > current gumstix. We're in the process of revising the gumstix as > part of replacing the ROK104001 bluetooth module with the PBA31307 > which is its replacement (the ROK is being EOLed). As part of that > revision, we're going to be taking the JTAG lines off the 60-pin > connector, and instead putting the BTUART lines and I think one of > the DREQs on there instead. So then people who don't have the > onboard bluetooth will be able to get 4 UARTs over the 60-pin > connector, and though the data&address lines are on the 92-pin > connector, there'll at least be a half-assed way of doing DMA from a > device on a daughtercard (half-assed because you'll have to use both > connectors to get it done). > > C > That is weird to say the least, what about taking out one of GNDs on the 92pin bus header and putting DREQ in there? |
From: Dave H. <dhy...@gm...> - 2005-10-11 20:52:52
|
Hi George, > I'm laying out a pcb for a quick test of a camera chip (OV7620). One > of the problems with this kind of stuff is that the data is a constant > (fairly high) data rate, so I'm using a FIFO buffer to store a few > lines of image, then an ISR can read them in at a high rate. That way > the processor is only tied up for short bursts. There's a project called AVRCam (http://www.jrobot.net/Projects/AVRcam.html) which uses an ATMega8 to connect to an OV6620 (similar to the OV7620). Just in case you're interested in looking at somebody else that's connected to a similar camera. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: George F. <cha...@gm...> - 2005-10-11 21:24:47
|
Hi Dave, Cool, thanks, I'll have a look at the circuit and code to see if I can get some ideas. Looks similar to the CMUcam (based around a fast PIC equivalent). Colour thresholding just isnt up to anything more interesting than following an orange ball round the lab :) One of the advantages of very simple processing like that is that a small micro can do it on the fly as the pixels come in. I want to do optic flow, so I need to buffer a couple of frames in the gumstix memory. George. On 11/10/05, Dave Hylands <dhy...@gm...> wrote: > Hi George, > > > I'm laying out a pcb for a quick test of a camera chip (OV7620). One > > of the problems with this kind of stuff is that the data is a constant > > (fairly high) data rate, so I'm using a FIFO buffer to store a few > > lines of image, then an ISR can read them in at a high rate. That way > > the processor is only tied up for short bursts. > > There's a project called AVRCam > (http://www.jrobot.net/Projects/AVRcam.html) which uses an ATMega8 to > connect to an OV6620 (similar to the OV7620). > > Just in case you're interested in looking at somebody else that's > connected to a similar camera. > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Pascal A. B. <pas...@wa...> - 2005-10-13 03:35:20
|
Alexandre Pereira Nunes writes: > What about DMA? I guess it would be nice if the frame grabber writes > direct on memory (through a buffer), and when i.e. a scanline is > complete, it triggers an irq on the cpu. That would be close to optimal, > i guess. I read somewhere that there are missing line(s) on the 92 pin > connector in order to do dma, is that so? I once mentioned that DREQ was apparently missing. As far as I understand the PXA specs, if the sensor could signal that data is available by asserting DREQ, then the DMAC would read it immediately. So you could have a much smaller FIFO. I'm not sure what the bandwidth would be, though. DREQ must remain high for 4 MEMCLKs to start a transaction, and low for 4 MEMCLKs afterward. Hopefully up to 32 bytes could be transferred per burst. But you can do DMA without DREQ, of course. -- Pascal |
From: George F. <cha...@gm...> - 2005-10-13 07:14:53
|
> But you can do DMA without DREQ, of course. You can?? give me a clue, which part of the manual do I read for that? George |
From: Pascal A. B. <pas...@wa...> - 2005-10-13 12:47:16
|
George Francis writes: > > But you can do DMA without DREQ, of course. > > You can?? give me a clue, which part of the manual do I read for that? Intel PXA255 Processor Developer's Manual, section 5, 5.3.7. Disable DCMD.FLOWSRC and DCMD.FLOWTRG (flow control), and set DCSR.RUN. The DMAC will perform transfers as fast as it can. See smc91x.h for example. I tried DMA from GPIO pins to memory this way. It works, but it's useless without a handshake signal, and GPIO is very slow anyway. With a fast FIFO on the 92-pin bus, you could probably synchronize transfers with a CS signal. The drawback w.r.t. using DREQ would be that the software would have to monitor the status of the FIFO more closely. I'd appreciate if anyone could confirm this before I purchase a Connex, a Hirose connector and a very small soldering iron :) -- Pascal |
From: George F. <cha...@gm...> - 2005-10-15 17:32:43
|
Aha, very interesting. Now, my FIFO has a half-full output flag, which I was thinking of using as an IRQ. So DCMD.LENGTH =3D <half the size of my FIFO>, start the DMA in my ISR, and it will empty most of the data into the stix.=20 I won't loose any data since it's a continuous stream, and I'll get the next byte in the data stream when the FIFO is half full again. Does that sound reasonable? Pcb is now in the etchant :) George. |
From: George F. <cha...@gm...> - 2005-10-29 14:42:15
|
On 13/10/05, Pascal A. Brisset <pas...@wa...> wrote: > George Francis writes: > > > But you can do DMA without DREQ, of course. > > > > You can?? give me a clue, which part of the manual do I read for that? > <snip> > With a fast FIFO on the 92-pin bus, you could probably synchronize > transfers with a CS signal. The drawback w.r.t. using DREQ would be > that the software would have to monitor the status of the FIFO more > closely. I'd appreciate if anyone could confirm this before I purchase > a Connex, a Hirose connector and a very small soldering iron :) > > -- Pascal OK, I'm making slow but steady progress on my project. Yes Pascal, it does work. It works very well in fact. I'm using the half-full flag on the FIFO to trigger an interrupt. Using VLIO interface with a 16 bit wide bus, 1024 bytes transfers in 70uS (a little under 15 M bytes/sec) which is looking useful for my vision app. Are you familiar with the DMA on a PXA255? At the moment my dma is running for half the time, as if the DMAC is servicing another channel at the same time. Without a /proc/dma to read, I'm not sure how you find out what else is using it. If it was something I didn't need, maybe I could disable it and double my transfer rate. George. |