Help with SRAM
mynet43
Posts: 644
I need to store pixel data from a camera and read it back after a frame is stored.
To do this, I need more memory than is available in the Propeller.
Can someone recommend an SRAM chip that's easy to use with the Propeller and stores byte-wide data. I think I can get by with storing less than 256K bytes (320x240x2). One possibility is the Renesas R1LV0808ASB.
Any information you have will be greatly appreciated.
Thank you for your help and support.
Jim
To do this, I need more memory than is available in the Propeller.
Can someone recommend an SRAM chip that's easy to use with the Propeller and stores byte-wide data. I think I can get by with storing less than 256K bytes (320x240x2). One possibility is the Renesas R1LV0808ASB.
Any information you have will be greatly appreciated.
Thank you for your help and support.
Jim
Comments
It runs on 3.3V and the 55ns delay means you only need one NOP when reading and writing.
Thank you for the quick reply. That looks like a good option.
Do you know if there is a circuit available for an address counter that will support this?
I'd like to increment the address with one pin if possible.
Thanks!
Jim
If you need an 8-bit bus and auto-incremement, you might consider 8X of 1-bit SPI SRAM chips (as in 2X of my Rampage modules).
Or, you could perhaps use the SSD1963 as both input buffer and video output buffer...
I once had a FIFO chip, but I think that's hard to find now...
There's really no easy way...
It'll be a whole lot easier with Prop2 though...
How many pins do you have to dedicate to a fast address setup time solution?
How many propellers are you willing to use/program to get more pins?
Well, I see from the cross post that a synchronous solution would be best.
Rayman's solution and others like it are probably easiest.
I have an 8x SPI SRAM schematic if you want it.
You could always put a bunch of 74*161 counters on the address pins of a stock SRAM
like in the old days to achieve the same effect, but it would take up lots of space.
Devices with inbuilt LATCH and COUNTER never made the widespread markets, which is a pity.
An example where 'generic' trumped 'better'.
Closest you could get, would be a CPLD/SPLD, and something like a 22V10 can do a 10 bit Counter/Latch with a mode pin, or a XC2C32A / ATF1502 / LC4032ZE etc would allow even wider address load/inc.
OK, I need to drive 20 address pins to store the pixel data I need.
It all has to be fast because I need to clock it out at the pixel rate, 2 bytes per pixel.
The only way I can figure how to do it right now is by using five 4516 4-bit counters cascaded with one 74HC32.
This looks like it should work, but it takes six chips, which isn't that bad if it solves the problem.
Anyone have an easier way to control 20 address lines with one clock pin? I couldn't find a larger counter with the right carry type output to cascade.
Thanks for your help!
Jim
2 bytes per pixel. There are many many options here and everything is a tradeoff between pins and speed.
With counters, you might need to think about the ripple delay if you daisy chain them - the delays can add up.
One option is to connect 19 pins to the prop pins, 8 address pins and one left to do read or write, and use a latch to select read or write.
You can use less pins and use latches eg 74HC374. Latch in high addresses eg A8-A18 and use prop pins to count through 256 bytes in a block.
And there are all the serial options. All these have been done in various forms.
There is even the option to latch in A0-A18 with three latches and then use two ram chips in parallel and write or read two bytes at once using 16 prop pins. I've got a touchscreen working with that and it is sending 240x320x2 bytes 30x a second so that is 4.6 megabytes a second, or to compare with serial chips, around 36 megabits per second. However, that is a direct transfer from ram to the display and bypassing the propeller. (at these memory sizes the prop would fill very quickly so has to be bypassed anyway)
BTW what is your camera - there could be some interesting synergies with a touchscreen since the display size and pixel data seems the same.
Do you really need 1MB? Ouch. Too bad.
8x SPI-SRAM can deliver up to 5MB/s at 80MHz after startup on P0..7 with CS and CLK,
but that is limited to 512KB single supplier source or 256KB with multiple sources.
That doesn't help much, I still need the same number of 4-bit counters
I can eliminate the ripple time by using the 74HC32 to do a synchronous cascade instead of a ripple. So it should be pretty fast.
My goal is to capture one color frame of an autofocus camera module and transfer it to a touch screen. This is used to select a target for an electron microscope. It uses an SCCB serial command interface which is almost, but not quite, the same as i2c. I've been able to write a driver for this that works fine.
I can almost send the picture now, but it's agonizingly slow, because I can only capture one line at a time, transfer it to the screen buffer, then go back and count down the lines to the 'next' one. I've had to slow down the pixel clock so the Prop can keep up with it. Let me know if you want more info.
This SRAM should solve the speed problem. I should be able to capture a frame in real time, then send it to the touchscreen as a window of pixel data. I don't have that many Prop pins left, which is why I'm trying to minimize what I use here...
So far I haven't seen anything easier than my five 4-bit counters and a quad OR chip.
Any ideas how to make it simpler?
Thanks for all your help!
Jim
Besides the CPLDs mentioned above you can of course, use a second Prop as a address generator for write and read.
Once you've hit 6 chips(!) you could fund a Prop on PCB area cost and assembly costs alone.
If the same device manages read and write, you can pinswap the RAM to shrink the PCB layout.
Someone may know if DJNZ OUTA,adr does what it says ? (ie is OUTA a valid DJNZ target )
Depends what you mean by 'simpler' - a single package solution, many would consider simpler...
I take it then that I've been filtered. 8 tiny TSSOP8 chips, 10 propeller pins, 5MB/s.
Doing something like a second Prop or custom chip is lots of work by the time you get it working.
I'm trying to minimize the changes to an existing board that already uses many of the pins for other stuff.
For the camera, I'm already using 8 data pins and 7 control and I/O pins, so they're going fast.
The board real estate is no problem, I've got room to spare.
I think I'll probably go with the five cmos counters and an OR chip, or possibly just five 74F161's, which look like they can do the same thing.
I took a quick look at the 74HC4040 12 bit counter that someone suggested. The problem with it is there is no carry type output, so I don't think you can cascade two of them.
I'm still open to suggestions. I just want to get it working as quickly as possible.
Thanks again for all your help.
Jim
? but you already know the prop
(even if it does not, only the max speed suffers..) plus another couple of lines to Sync-lock, and another couple for Y scan, and reset ?
What is your pixel rate & line sync / line blanking widths ?
The key bit is "if it is fast enough", as these are ripple counters.
HC4040 is not likely to make it, but the 74LV4040 just might.
It specs _typical_ values of 6.1ns CLk-QA, and a dQ ripple time of 1.2ns, or 14.4ns over 12.
Total time across one device is ~ 20.5ns, and adding the second one gets you to around 36ns for 20 bits
( CLK is =\_ so you can connect CLK.2 to Q12.1)
If we guess a 5MHz pixel rate, that might be OK.
You've got me wondering now if I can use the SSD1963 to both capture raw camera data and then turn around and display it...
There is just just room left over when showing 640x480 to store 256kB...
Have to see if there's an easy way to disconnect the camera data bus from the SSD1963 and Prop, so they can share the bus...
Now you've got me thinking, finally.
First, I'm now really interested in how to use the second prop for some of the timing. Can someone show me the actual code to do this? I've never thought about it before, so I don't want to re-invent the wheel. Another immediate benefit of doing it this way is that I gain more pins. The cost and real estate are not a factor here, so if I can do it without too much pain, I may go for it.
Second. I'm using the OmniVision 3.1 Megapixel (2048x1536) color camera module. I'm using it because it was the only one I could find with autofocus. By sending it commands, I'm able to slow down the pixel clock and put it in a 320x240 output mode with RGB565 16 bit pixels coming out. This is just what I need to send to my touchscreen display, which is a Reach Technology SLCD6 5.7" screen with 320x240 resolution.
You asked what pixel rate I was using, so here's the story. I've slowed the pixel rate down so far that it's now less than 1 MHz. This is good for sampling the pixels, but bad for the total time. It takes around 5 seconds to sample one frame at this rate. It looks like the way they get 240 lines is to skip the intermediate lines and sample evenly spaced lines from top to bottom to get 240 lines.
Now that you've got me thinking, I may have lots of time between line sampling, to send the data out and get ready for the next line. If I take 5 seconds and divide it by 240, that seems to give me around 20 ms between each line of pixels. The fastest baud rate I can use to send out the pixels is 57600, because I'm using the 4-port driver. So if this is around 6000 bytes per second, then in 20 ms I can send out around 120 characters. Unfortunately, I need to send out 640 characters for each line at 2 bytes per pixel. This won't quite work.
I don't want to slow down the pixel clock any more because 5 seconds is approaching too long for anyone to wait for a picture. So it looks like I'm back to the the need for SRAM. Then I can speed up the clock, capture a frame much faster and make everyone happy.
I've used up so many pins that I think the only practical solution is to go to the second prop. I'm already driving two stepper motors, monitoring a trackball, an SD card and 8 ADC pins and driving two serial ports, so there's not much left.
How did I get myself into this?
Thank you all for your help and support.
Jim
Byte addressable (74hc393 would reduce chip count but would introduce a 256 byte page boundry)
Add another 74hc193 counter to the top of the chain, and a decoder (half of a 74hc139?) to pich
out 1 of 4 external memory chips to expand even more.
SOME of those chips could even be eproms instead of just R/W RAM chips?
But to keep power consumption reasonable it would have to power the XM chips up and down separately.
Not a big problems though.
To use:
Set address
set function decoder to READ
read data
stash it somewhere
Bump the ADDRESS pin
read the next byte.
Not only would it be a huge savings in pin count, but a significant performance increase when loading
fonts, pics, sounds, etc.
* the pixel clock speed range, and what edge the pixel is sampled on,
* if the clk edges match the pixels (ie does the Pclk run during any flybacks, on invalid pixels, or does it pause on syncs ? )
* what sync signals are delivered. rates and pulse widths.
* How many clocks per frame, your numbers of 5 seconds @ 1MHz do not match your pixel 320x240 ?
* is 1280w (ie 4x 320) a valid pixel rate for this camera ?
* can the camera pins tri-state for read-back from RAM ?
My reading of the brief has the camera as a master, so it generates PCLK and all syncs.
A CPLD will always work better as a slave device, than a prop, but at lower speeds something may be able to work.
Interesting, I like your diagram.
@ jmg,
Here are a few notes:
The pixel is valid on the rising edge of the pixel clock. I sample the data after the clock goes high.
The pixel clock seems to run all the time. However, I can send it a command (which I haven't bothered to do) to have it run only during the horizontal data period.
The camera delivers vertical sync (negative true), indicating start of frame. It also delivers a horizontal reference positive pulse that indicates the start and end of a relevant horizontal sweep. In 320 x 240 mode, the horizontal pulses have a big time gap between them, indicating the lines that were skipped. It also delivers the pclk (pixel clock) signal.
The Propeller must supply an xclk signal, which must be a minimum of 6 MHz to meet the camera spec. However, there is a command that is used to reduce the pclk signal frequency. It divides the input xclk by a specified value to produce the pclk. Right now I'm using an xclk value of 6 MHz, using ctra/frqa settings. I'm also using a divide factor of 24 to reduce the pclk frequency way down so I can play with it. I can see it slow down on the scope when the command is issued.
I believe there are 3.1M clocks per frame (2048x1536).
Not sure what your question is about the 1280. I think I answered it above.
The camera pins can tri-state but they don't need to. The 8 pixel data lines and control lines are always output from the camera, so the Prop treats them as inputs. The xclk is always input to the camera. The command lines are like i2c lines: sio_clk and sio_dat. They work fine with my SCCB driver. I can read and write as needed.
I hope I answered your questions. It's a complicated device to interface with. Right now the initialization takes more than 200 commands to get it going. Some of these are either called 'reserved' or or not documented at all, which really helps
Please let me know if you have any more questions.
Thank you for the help.
Jim
So are there two ways to get data in to ram. 1) directly using hardware and 2) via the propeller.
Both are valid. Direct hardware will probably be faster but might be harder to test and debug as each change will involve rebuilding a breadboard. Software might be easier to experiment with.
So - is it possible to scan in just one line into the propeller? Set up an array in the prop to hold that line. Direct control of that xclk line by the prop. Send all your complex startup code, then set a cog going as fast as it can to scan in a line.
If so, you could set up a circular buffer with a 'head' and a 'tail' and one cog is grabbing the data from the camera, and another cog is sending it out to the ram chip.
You might still end up with a hardware solution but this might be an easier way to get there?
Simple question - does the camera buffer a frame in internal memory so you can read it out slower?
How cool would it be to have a camera like this on a quadcopter, and it sends the picture via radio to another propeller on the ground which displays the picture the quadcopter sees looking straight down, and then on the ground you tap the touchscreen with that picture, and the quadcopter goes to that new location. Swipe the touchscreen to go up or down. Tap the screen for the x,y location. Flying for dummies!
I'm a little lost here; in how you configure for lower pixel rates.
When you configure for 320x240, does it still output 2048*1536 = 3145728 clocks ?
Does the pixel output data then change on every clock edge, or only as needed for 320 pixels ?
or does the Horiz qualifier have a low duty cycle (2048/320 = 1:6.4 ) during LINE, and also 1536/240 = 1:6.4 during Frame ?
If the Camera does not divide by 6.4 you may be better doing that yourself ?
You've got me thinking again. Thanks! It might actually be easier to just store a frame in SRAM using only hardware. There could be a 'start' signal from the Prop and a 'done' signal back to the Prop. If this worked, then I could command it to store a frame, wait for it to finish, then play with it at my leisure. Cool idea. Let me know if you have more thoughts on this.
@ jmg,
Sorry to confuse you. It's a complicated object to deal with.
Yes, when I configure it for 320x240, it still outputs all the clocks, unless I tell it to only do it on the horizontal trace sync.
The pixel data is only valid when the horizontal sync is high, so that's the only time I read it. This goes high whenever it's time to read one of the 240 lines. The rest of the time it's low.
I've slowed the pixel clock down, so everything slows down accordingly.
I hope this helps.
Jim
What you describe does not match 2048*1536 = 3145728 clocks
Are you saying it still outputs 6.4 clocks per pixel ? (in which case what does config to 320x240 do ? )
If Horiz Signal qualifies by line, what qualifies things in the X direction ?
- Is it your code, or the camera, that makes the 320 pixel decision ?
To get 320 pixels, someone has to be making a 'choose every 6.4' decision
Does it always output 2048 pixels, with some by-line skips, only for the Y axis, which seems to be what you describe ?
I think using a second prop would be a better way to go. You could acquire a line of data at the rate the camera outputs it, buffer it in hub ram, and output it to external ram (or to the other prop) at a somewhat lower rate since you have the extra time the camera hsync provides.
Well I don't understand all your hardware and the timing (does the camera have its own internal ram for a screen buffer?), but this may have some similarities to the touchscreen. With a touchscreen you have picture data like an icon and this can be stored in four places - an SD card, hub ram, external ram, and on the display.
I've been experimenting with transferring data between each of these and the very fastest is external ram directly to the display. I do this with a 16 bit address directly connecting the display to the ram, and then use 18 of the propeller lines to drive the address for the ram. That avoids the need for a counter as it is quicker and easier to use the increment in pasm. Use a few more prop pins for control.
The cunning part is how you recycle the propeller pins for other things. You need to get data into the ram somehow, so those 16 lines need to be isolated, and a couple of 74HC245 chips can do the job there.
And for the address, you want a chip that can pass data through like when the propeller is incrementing, but at other times you might want to latch in addresses, eg when transferring 16 bits, because 16 data bits +18 address bits is more than the number of prop pins, so in this case a 74HC373 is better than a 74HC374.
I wonder if something similar could work with your camera?
Have you got a schematic for this camera? How many pins are there and is it parallel or serial?
You got me, I wasn't quite right. Oops.
I was right when I said it outputs only a selected set of 240 lines.
I was wrong about the number of pixels on a line.
The horizontal sync goes high while it outputs its 320 pixels.
Then it goes low until time for the next of the 240 lines.
It's the camera that keeps track of it, not me.
My scope doesn't have enough memory to store all of the pixel clocks.
I was basing my estimate on the pixel clock width when I'm sampling it and the time it takes to complete a frame.
Let me know if you have more questions. Now back to how to use a second prop...
Thanks!
Jim
OK, so it outputs 320 PCLKS in that time ?
which meas the total PCLKs is 320 * 1536 ? or is it 320 * 240, but spread in a 1536 PCLK time-width
What is the time (in sysclks) from the SYNC to the first pixel sample time ?
If so, I presume you can set it to "raw" instead of "jpeg"?
If the data comes out in a serial format, this could be a perfect use for the propeller as a smart serial to parallel converter. You may not need too many peripheral chips. In fact, you could even reuse a lot of prop pins as you can put the ram chip into HiZ so it will behave as if it is not even there. Recycle the pins for other uses once you have captured a frame.
I'm confused by that spec sheet - are there 8 parallel data lines as well? or 10? - Data[9:0]
Have you got a link to the data protocol?