tmd3:
That's two bits to select a single block from four blocks, 9 bits of address, and 4 bits of data. Your DRAM, though, requires 18 bits of address: 9 bits for the row address, and 9 more for the column address. With a 9-bit address, you'd have access to 512 memory locations. Instead, you have 262,144 4-bit memory locations. Maybe you only need one of these memories, instead of 4?
You send 9 bits of rows, toggle pins, then send 9 bits of column - same physical 9 pins. For refresh (and i was speaking strictly RAS-refresh) you send 9 rows.
tmd3:
Look at the timing diagram labeled, "RAS-only Refresh Cycle." You'll see that CAS is always inactive, Output enable (OE) is shown as "don't care," and the only things that matter are RAS and 9 bits of address data - the row address. The chip will refresh all 512 locations whose row address is on the address pins when RAS goes active. With CAS inactive, the data outputs are never enabled, and the data bus is tri-stated. The traditional way to implement a refresh is to put the row address on the bus, activate RAS, deactivate it after an appropriate period, and go to the next task. All of the modules should be connected to the same RAS signal, and to the same address bus, so 512 refresh cycles should refresh all the memory. I don't understand your concern about a "voltage divider." Can you clarify that concern?
I am more or less concerned, that four modules, would "divide the voltage", to be too low, for any actual signal to pass through, or that that values being refreshed would have a different resistance, depending on the module and its contents (like, how much needed to be refreshed).
Ive done it, build it (with two blocks), and it works. Thats just not the same as it keeps working, if there was a logic problem here 
Im not really all that into the lower parts of signaling (25+ years coding, but only 6 months hardware building - its still pretty new to me that stuff isn't just 0 or 1, but can have a raising/falling edge .. )
tmd3:
You'd be very unhappy with that result. No one wants a memory that works almost every time.
Yes that is actually what i meant, the need for a controller. If the main arduino just access, as I do now, the ram directly - no problem. But thats not what i want.
tmd3:
A straightforward way might be to let one of the controller's pins signify that the memory is available. The requesting device would then have to wait for the end of the refresh cycle to complete its transaction. No matter what, you'll need some signalling between the controller and the external device to determine when parts of the transaction are complete - things like, "I got your data," or "Data is ready."
Yes exactly. That is what i invision.
tmd3:
I'll note that your memories appear to support "CAS before RAS" refresh, and "Hidden" refresh, suggesting that the IC's maintain internal counters to step through the row addresses, and can can be kept refreshed by simply making sure that enough refresh cycles happen, without the controller keeping track of a row counter. That would certainly speed up a refresh cycle. The datasheet doesn't explicitly state that the memories have that feature. I can't figure out what else a "CAS before RAS" refresh cycle would do. We probably need a DRAM expert to chime in on this.
I have always used the Burst-refresh mechanism, refresh everything at once - and only with Ras-only method. Cas-Before-Ras is smart, you drop CAS and RAS, just toggling it over and over - the internal counter will move to next address automatically. Its like burst mode. I haven't been able to really wrap my head around how to use Hiddden refresh yet.
tmd3:
It sounds like you envision a device that would:
(my edits)
- Controller ready state = 1 pin
- Get the direction - read or write, = 1 pin
- Get an address from another processor = 9 pins + number of ram pins (2 pins for 4 blocks) - you let R/W-pin go up&down to switch from row to column, signal up/down with controller ready state pin that its accepted - kinda like the DRAM does
- Get/write some data for a write/read operation, = 4-8 pins, depending on the ram
17-21 parallel pins. Or very few, in seriel/SPI.
tmd3:
For a write operation, that's 23 bits - 1 bit for read/write, 18 for address, and 4 for data. For a read, it's 19 bits in, and 4 bits out. If you're contemplating a serial interface, then it will take time to receive the address and data information. Transactions will likely be slow enough to make it feasible for the controller refresh memory as its primary task, to be interrupted by access requests.
Yes. Thats actually all i imagine it is. A passthrough, that keeps the memory refreshed.
tmd3:
I can't find any evidence in the datasheet that the memory wants a 64 millisecond refresh. It looks like it wants each row to be refreshed every 8 milliseconds. The first page shows this text:The 4th page of the datasheet lists a "refresh cycle time" of 8 ms. I don't find either of those notations to be overwhelmingly clear, but they seem to be the only thing in the datasheet that describes a required refresh rate. I think the canonical refresh time is 8 ms for these memories. I can't speak from experience, but the Wikipedia article entitled, "memory refresh," claims thatSo, it looks like 0.2% is pretty good.
You can usually, in my experience, stretch the refresh times. Ive read a paper on it somewhere (where i have forgotten, it was "on the internet") that usually a lot of time and energy can be saved by stretching out the refreshes - and it usually works as well.
tmd3:
I think that you can refresh all the modules together. With this memory, it looks like you just have to refresh 512 rows, no matter how many columns you have.
Yes, its a regular RAS-refresh.
tmd3:
I get the feeling that you haven't put any hardware together yet for this project, and haven't yet performed any tests. Is that correct?
Actually I have. At the moment, two ram blocks and the arduino, connected via a serial-parrallel interface. Data is refreshed fine, but I have been concerned that adding more would ruin the "refresh all at once" method. My problem is to "finalise" it. To move the program-logic out of the arduino that uses the dram, and convert that Arduino into a controller, as to be used by other arduinos. I cannot wrap my head around how im supposed to buffer the incoming data or prevent fails.
Perhaps I should just build the darn thing to store and read one byte at a time. Each time wait for ready state, each time, send data and receive it - one byte. Then later, expand that to burst mode.
tmd3:
[Edit: add this] You might want to read the Wikipedia articles on DRAM and "Memory Refresh" before you go much further.
Im already refreshing the ram. But thanks
I am sorry Im giving of the wipe I haven't put the hardware together - since this is a new field for me, its also harder for me to identify where the potential problems are. I am therefore prone for XYProblems, but try my best to communicate what I see as the actual problem without too much hazzle.
Thanks for your reply, comments and time - very much appreciated !
