PDA

View Full Version : Help with SRAM



mynet43
03-11-2012, 10:50 PM
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

Dr_Acula
03-11-2012, 11:27 PM
There are many options. One favourite for many projects is this 512k chip http://www.futureelectronics.com/en/technologies/semiconductors/memory/static-ram/asynchronous/Pages/5985502-AS6C4008-55PCN.aspx?IM=0

It runs on 3.3V and the 55ns delay means you only need one NOP when reading and writing.

mynet43
03-12-2012, 12:19 AM
Dr_Acula,

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

Rayman
03-12-2012, 12:22 AM
There are a lot of ways to go here...
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...

jazzed
03-12-2012, 12:27 AM
Do you care more about total data burst time or fast address setup time?
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.

jmg
03-12-2012, 12:46 AM
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.


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.

mynet43
03-12-2012, 02:48 AM
Thanks for all the clues, they help.

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

Dr_Acula
03-12-2012, 02:59 AM
20 bits is 2^20 which is 1 megabyte. Just to double check that because the 512k chips have 19 address pins numbered A0-A18.

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.

jazzed
03-12-2012, 03:14 AM
Thanks for all the clues, they help.

OK, I need to drive 20 address pins to store the pixel data I need.



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.

mynet43
03-12-2012, 03:38 AM
Oops, my mistake. I really only need 18 bits, 256KB. Thanks for catching it.

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

jmg
03-12-2012, 03:51 AM
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.


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 )



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?

Depends what you mean by 'simpler' - a single package solution, many would consider simpler...

jazzed
03-12-2012, 04:18 AM
jmg, I'm pretty sure OUTA is a valid djnz destination.



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?

I take it then that I've been filtered. 8 tiny TSSOP8 chips, 10 propeller pins, 5MB/s.

kwinn
03-12-2012, 05:03 AM
Take a look at the 74HC4040. It's a 12 bit counter so you would only need 2 if it is fast enough.

mynet43
03-12-2012, 05:15 AM
I guess by simpler I mean the least amount of work for me :)

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

jmg
03-12-2012, 05:27 AM
Doing something like a second Prop or custom chip is lots of work by the time you get it working.


? but you already know the prop :) - a Prop-as-smart-counter is essentially one line of code, if DJNZ OUTA,adr works
(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 ?

jmg
03-12-2012, 05:38 AM
Take a look at the 74HC4040. It's a 12 bit counter so you would only need 2 if it is fast enough.

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.

Rayman
03-12-2012, 11:06 AM
Sounds like you have a plan.

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...

mynet43
03-12-2012, 02:28 PM
You guys never give up :) Thank you!

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? :) Please help with the second Prop, this is all new to me.

Thank you all for your help and support.

Jim

darreno
03-12-2012, 07:46 PM
256Kx8 SPI FRAMs might be an option. That would hold your frame buffer with room to spare.

cavelamb
03-12-2012, 09:11 PM
A possible auto-increment circuit suggestion?
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.

90529

jmg
03-12-2012, 09:24 PM
Please help with the second Prop, this is all new to me.

You need to specify
* 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.

mynet43
03-12-2012, 11:19 PM
@ cavelamb,

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

Dr_Acula
03-12-2012, 11:37 PM
This camera sounds interesting.

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!

jmg
03-12-2012, 11:41 PM
... In 320 x 240 mode, the horizontal pulses have a big time gap between them, indicating the lines that were skipped. ...
I believe there are 3.1M clocks per frame (2048x1536).


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 ?

mynet43
03-13-2012, 12:52 AM
@ Dr_Acula,

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

jmg
03-13-2012, 01:01 AM
@ 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 vertical 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.


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 ?

kwinn
03-13-2012, 01:21 AM
You can use the output from the msb of the first counter to increment the second counter. It would be better to use one of the faster 8 bit counters that has a carry out as the first chip and have it increment the 4040. That is if you use counters.

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.

Dr_Acula
03-13-2012, 01:43 AM
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.

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?

mynet43
03-13-2012, 01:46 AM
@ jmg,

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

jmg
03-13-2012, 01:57 AM
The horizontal sync goes high while it outputs its 320 pixels.
Then it goes low until time for the next of the 240 lines.


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 ?

Dr_Acula
03-13-2012, 02:11 AM
Is this the camera module? http://www.ovt.com/uploads/parts/OV3640_PB(1.02)_web.pdf

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?

mynet43
03-13-2012, 02:17 AM
Dr_Acula,

No, the camera doesn't have its own screen buffer. I have to grab it as I see it. That's why I'm only able to keep up with one line at a time.

I like the idea of using HC245's to share lines. My problem now is that I've used up all my available pins and need more.

I'm thinking a second Propeller that does nothing but read the camera, store the data in SRAM and transfer it to a display would be best. It could have a simple interface to the main Propeller.

I also like the idea of doing the camera read and store completely with hardware. This doesn't seem like it should be too hard.

The board I'm using right now is designed only for testing the camera and sending display data to my touchscreen. I've attached a picture of the schematic.

The camera lines I'm using are 2.8V and 1.5V supplies and ground. Besides these are the 8 pixel data lines going to P0-P7, the two clock lines, xclk and pclk, the h/v control signals, a reset line and the two comm lines.

I have access pins for all of the camera and Prop pins, as well as a breadboard area.

Take a look and let me know if you have any suggestions.

Thank you for your help and support.

Jim

mynet43
03-13-2012, 02:37 AM
Dr_Acula,

You asked if the link you sent was the camera I'm using. Basically yes, but there is an autofocus added to the model I have. There are only 24 pins available on the connector supplied.

Also, the pixel data come out on pins Data[2:9]. [0,1] are not used. You can set the output to various modes, YUV, raw, RGB565, RGB555, etc. I've chosen to go with RGB565 since it matches the touchscreen I'm using for display.

There is no 'serial' data output. Just a serial interface for the command I/O.

The documentation for this chip is REALLY HARD to find. I have a lot of it, including their SCCB serial interface spec sheet. This is where I discovered that it's almost, but not quite, i2c. I2c won't work!

I'm happy to supply the documentation I have if you're interested in it.

Jim

jmg
03-13-2012, 02:56 AM
I also like the idea of doing the camera read and store completely with hardware. This doesn't seem like it should be too hard.

A CPLD would do that, for Write, and later read.

Start with a 64 macrocell part, (3v3 models like LC4064V, or ATF1504ASVL), and you might manage to fit into a 32MC one later.

This could do clock mux, gated counters/rst and mono-flop capture

mynet43
03-13-2012, 03:32 AM
@ jmg,

The CPLD would be fine, except that I've never used one. One of these days...

It seems like it shouldn't be hard to do with discrete logic chips, an address counter, and use the PCLK to clock the data in after the vsync whenever the hsync goes high. The vsync could be AND'd with a Prop pin to 'enable' a start frame. The Prop could then look at the vsync pin to see when it's started (waitpne) and when it's done (waitpeq), since it's negative true.

Good food for thought.

Anyone want to lay it out? If it looks good, I'll get a board made.

Keep thinking.

Jim

Tubular
03-13-2012, 06:43 AM
I haven't followed this thread too closely, but regarding the address counting, you can use the 23K256's in a mode that auto increments with each clock pulse. They even wrap around when they hit 256kbits (I think)... You might need 8 of them to do the parallel capture, but 320Hx240V is only 76800 bits, so you probably grab 3 frames before reading with the prop.

mynet43
03-13-2012, 12:29 PM
Tubular,

Interesting concept. Keep in mind that 320x240 pixels from this camera take 153600 BYTES of storage, at 2 bytes per pixel.

Maybe I could parallel 8 of these chips and still get good results.

Thanks,

Jim