You are reading a single comment by @DrAzzy and its replies.
Click here to read the full conversation.
-
@DrAzzy, looked at the module and wondered why for each byte the address has to be written - have to say that I have not studied the EEPROM api>
It certainly shouldn't be writing the address for each byte, unless I screwed up...
Only difference between writing EEPROM and SRAM is that EEPROM is organized in pages, and after writing a page, you have to wait 10 ms before the chip will respond. The FRAM looks to be made to be a drop-in no software change necessary replacement for EEPROM.There are 2mbit FRAM chips ;-) Only $15-20 a pop and non-stock @ digikey. No sea of tears - just red ink.
DrAzzy
@DrAzzy, looked at the module and wondered why for each byte the address has to be written - have to say that I have not studied the EEPROM api. For FRAM resetting the address for each byte is not required - see](http://forum.espruino.com/comments/11937103/). Are you referring to that when talking about? Yep, the page size of 0 takes brilliantly care 0f skipping the wait cycles.
You just invented Super-Direct Memory Access! I did not think about that... for cases where the memory is equally or larger in size, this really works: preparing the next image/page in the memory and then update the display at once. For my case, the FRAM I have is a bit too small: 32,768 bytes FRAM vs. 172,800 byte display buffer (=230 x 320 pixel * 2bytes in ILI9341... and spending a lake of tears for 6 FRAMS and also giving up 6 CS lines, will become a sea of tears... nope. I need only a few KB to ship back and forth areas of the display. For that, I have to set two different addresses, and also connect SO of display to SI of FRAM. Super Direct DMA for save and restore... really cool idea.
What I already thought of - but not had the time this morning to write about - was to have a DMA Hub... inspired by the 0 and 1 to indicate source and destination in my envisioned A_to_B API. Since the process would anyway not be multi-threaded, I could just add any communicating device to a hub, and then trigger the transfers between the *from-to*s with device#X to device#Y. For streaming devices, the address would be -1 (MSB = 1) or something other detectable (with 2 byte address and MSBit of MSByte a control bit, 32KB is the max addressable... just what my FRAM gives me. Note that not all devices have a single dimension address, even though they may support continuous read and write across dimensions, such as the ILI9341 display controler. This display controller requires to provide row and column address, but does auto increment/reset columns and rows....