From: Terry F. <te...@cu...> - 2005-07-22 01:58:57
|
Would anybody help me get started? I need to bring 16 bits of data into = the gumstix at a rate of 1 Million 16-bit samples per second. I have an = additional 1 bit signal that tells me when the data is valid. I'd like = to interrupt on the "valid data" signal, and then capture the 16-bit = data to a buffer. When the buffer gets full I want to signal a program = in the XScale to process he data, and then start storing new data into a = second buffer while processing the first buffer. I can reduce the 1 = Million 16-bit samples per second requirement some, but that's my goal. I plan on building a device driver to handle the interrupt, and to = buffer the data. I plan on a user mode program to process the data, and = a usr_signal sent by the driver to trigger the user code. Would a = semaphore be better? I have one of the breakout-gs boards, and from a = cursory examination of the PXA255 developers manual it looks like the = LCD ports can be set up as GPIO'S, so until I find a problem I plan on = using the LCD GPIO's for the 16 bit data. I don't know which pin to use = for an interrupt pin. I've done this stuff before, but I'm new to Linux, and to the PXA255. = Does any of this approach sound bad? Does anyone know of any sample code that does anything like this? Like always, I have a short time frame to develop this code. Anybody = know where to obtain this type of info without searching through = thousands of pages of manuals? Thanks for any assistance. Terry |
From: Jonathan B. <jbr...@ea...> - 2005-07-22 02:35:44
|
On Thu, 2005-07-21 at 20:58 -0500, Terry Frederick wrote: > Would anybody help me get started? I need to bring 16 bits of data > into the gumstix at a rate of 1 Million 16-bit samples per second. I > have an additional 1 bit signal that tells me when the data is valid. > I'd like to interrupt on the "valid data" signal, and then capture the > 16-bit data to a buffer. When the buffer gets full I want to signal a > program in the XScale to process he data, and then start storing new > data into a second buffer while processing the first buffer. I can > reduce the 1 Million 16-bit samples per second requirement some, but > that's my goal. I'll warn you now that getting a consistent < 1 us interrupt latency will be extremely (maybe impossibly) hard. You should seriously consider using a hardware interface that will do some level of buffering and DMA work for you, like the NSSP. That will reduce you interrupt load considerably, but you will still fall short of your bandwidth criteria. > I plan on building a device driver to handle the interrupt, and to > buffer the data. I plan on a user mode program to process the data, > and a usr_signal sent by the driver to trigger the user code. Would a > semaphore be better? I have one of the breakout-gs boards, and from a > cursory examination of the PXA255 developers manual it looks like the > LCD ports can be set up as GPIO'S, so until I find a problem I plan on > using the LCD GPIO's for the 16 bit data. I don't know which pin to > use for an interrupt pin. To the best of my knowledge, you can't gang up a group of the GPIO's to make a parallel bus, at least not with the bandwidth you're talking about. Maybe someone knows if the connex allows you to do 16-bit addressing? Since I'm not using an LCD in my work, I use the LCD pins for scrap GPIO. It is very easy to make your interrupt pin runtime-configurable. You can just choose a pin from whatever auxiliary device you aren't using right now, and it will be easy to reconfigure your software if your hardware choices change. > > I've done this stuff before, but I'm new to Linux, and to the PXA255. > Does any of this approach sound bad? > > Does anyone know of any sample code that does anything like this? I've got some code that received GPIO interrupts, but does other things with the information. It will be going into the buildroot in the near future; you can download it here in the meantime: http://www4.ncsu.edu/~jdbrandm/gumstix-pwm.tar.gz HTH, -Jonathan |
From: Craig H. <cr...@gu...> - 2005-07-22 06:37:43
|
On Jul 21, 2005, at 7:35 PM, Jonathan Brandmeyer wrote: > On Thu, 2005-07-21 at 20:58 -0500, Terry Frederick wrote: > >> I plan on building a device driver to handle the interrupt, and to >> buffer the data. I plan on a user mode program to process the data, >> and a usr_signal sent by the driver to trigger the user code. >> Would a >> semaphore be better? I have one of the breakout-gs boards, and >> from a >> cursory examination of the PXA255 developers manual it looks like the >> LCD ports can be set up as GPIO'S, so until I find a problem I >> plan on >> using the LCD GPIO's for the 16 bit data. I don't know which pin to >> use for an interrupt pin. >> > > To the best of my knowledge, you can't gang up a group of the > GPIO's to > make a parallel bus, at least not with the bandwidth you're talking > about. Maybe someone knows if the connex allows you to do 16-bit > addressing? Yes, you can do 16-bit transfers on the connex connector (ie the PXA bus). But if you're building your own off-board hardware to do some buffering anyway, might make more sense to bunch the transfers and move the data 32-bits (ie 2 samples) at a time. The bus can run at a max rate of 133MHz (normally runs at 100MHz) with 32 bits of width, so there's plenty of bandwidth there. But you will certainly want to buffer things offboard, not have to do the sampling from inside an interrupt handler. There's nothing I can think of which would stop you from being able to use 16 GPIO pins to do the data transfer, except that it's going to be pretty slow -- to read the 16 LDD[0-15] GPIO lines, you'll need to read both GPLR1 and GPLR2 (since GPIOs 58-63 are on GPLR1 and 64-73 are on GPLR2), shift them both to clear bad bits and line things up, and then or them, which is 5 asm ops to re-assemble the 16- bit value: LDR r0, =GPLR1 ; Get the address of GPLR1 into r0 LDMDA r0!, {r1,r2} ; Load GPLR1 to r1 and GPLR2 to r2 MOV r1, r1, LSR#26 ; Shift down 26 bits so GPIO58 is at bit 0 MOV r2, r2, LSL#22 ; Shift up 22 bits (to flush out the top) so GPIO64 ends up at bit 22 ORR r0, r1, r2, LSR#16 ; Combine the two registers to get 16-bit value > Since I'm not using an LCD in my work, I use the LCD pins for scrap > GPIO. It is very easy to make your interrupt pin runtime- > configurable. > You can just choose a pin from whatever auxiliary device you aren't > using right now, and it will be easy to reconfigure your software if > your hardware choices change. >> I've done this stuff before, but I'm new to Linux, and to the PXA255. >> Does any of this approach sound bad? I think the biggest problem is going to processing 1,000,000 interrupts per second -- that's just never gonna work. >> Does anyone know of any sample code that does anything like this? See above :) C |
From: Pascal B. <pas...@wa...> - 2005-07-22 04:08:01
|
Terry Frederick writes: > I need to bring 16 bits of data into the gumstix at a rate of 1 Million 16-bit samples per second. I have an additional 1 bit signal that tells me when the data is valid. I got stuck on a similar requirement while looking for a CMOS camera sensor which could be connected to the Gumstix directly. Although the PXA255 core itself is pretty fast, the internal peripheral bus seems to be a major bottleneck. A 200 MHz core can't read GPIO status registers faster than 4 MHz. This doesn't leave much room for managing interrupt registers etc. Any idea where this limitation comes from ? You can setup the DMAC to copy data from GPIO to memory. But in order to synchronize transfers with your 1-bit signal, you'd need to feed it into DREQ0/DREQ1 (aka GPIO19/GPIO20). Unfortunately these signals are not available on any of the Hirose connectors. Does the Gumstix use them internally ? Your last chance is to sample all 17 bits, either with DMA or with a busy loop, and hope you don't miss a cycle. As Jonathan suggested, NSSP would be more reasonable. By the way if anyone has a CMOS sensor with NSSP output, please let me know. -- Pascal |
From: Doug S. <do...@pr...> - 2005-07-22 22:45:34
|
Pascal Brisset wrote: > As Jonathan suggested, NSSP would be more reasonable. By the way > if anyone has a CMOS sensor with NSSP output, please let me know. NSSP is not a protocol standard, rather its a highly configurable serial port that can support many protocols like Motorola SPI, National Microwire, Texas Instruments SSP, etc. You can send PCM audio over NSSP while at the same time sending ACLINK audio over AC97 or I2S, or send any kind of digital data over the NSSP port. So you won't find a camera that outputs NSSP, but you can probably find many that could send data over NSSP. Specs say you can do 13 Mbps using DMA, and you can do 32-bit samples. -- Doug |