Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
|
Forum Index : Microcontroller and PC projects : New family introduces high density SPI EERAMs, extending up to 1 Mb
Author | Message | ||||
Pluto Guru Joined: 09/06/2017 Location: FinlandPosts: 321 |
Something for coming microMite designs? Press release 02 Dec 2019: https://www.microchip.com/en/pressreleasepage/reduce-memory-costs-and-retain-data-at-power-loss-with SPI EERAM from 64kb to 1Mb. |
||||
vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1081 |
Interesting. Note though that the sizes are in BITS. 1Mb = 128k bytes. 66MHz is nice and quick, with the usual sequential reads and writes, no worrying about write banks or any of that. 100,000 store cycle endurance, so you can safely turn it off a few times a day... ;-) From the data sheet: Visit Vegipete's *Mite Library for cool programs. |
||||
zeitfest Guru Joined: 31/07/2019 Location: AustraliaPosts: 369 |
Nice...I am wondering about making an interpreter use one to store the program ASCII. That would expand the max program size (length) at the cost of a small performance hit, could be good. |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3163 |
The performance hit would be painful. An interpreter does a lot of scanning of the program (ie, the NEXT in a FOR loop, skipping to the end of an multiline IF command, etc) and that would be far too slow over an SPI bus. Geoff Graham - http://geoffg.net |
||||
zeitfest Guru Joined: 31/07/2019 Location: AustraliaPosts: 369 |
Yes that is sensible. I got my interpreter to do the scanning in a pre-pass which is a once-only, but as you say there would still be the relatively slow SPI access as a problem. Pity the sram does not have a parallel i/o instead of serial. The microchip spi/eeram IC's seem to have the same pinout as the similar Winbonds, maybe CaptainBoing or BigMik can have a bash with them as well I briefly thought about using eight in parallel..but decided to have a coffee instead and forget that idea . It would be just my luck to get that going, then have an IC maker introduce them in quad spi or similar . |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1983 |
SPI is not slow (Stock I2C is 400KHz) - SPI on a '170 will storm along at 24MHz. Looking at things from the Winbond W25Qxx PoV: I have a couple on my test '170 - piggy-backed with no thought for RF or anything, literally just slapped together with the CS pins bent out and wired to different pins on the MM. They are perfectly happy at the full 24MHz SPI clock. If my code could keep up, that gives a 333nS per byte on sequential reading (the address automatically increments). It does become a bit slower when you have to point to a new memory location i.e. Random Access reads as you have to load up the address pointer with the location set command and three bytes of address = 1.3uS. I think the W25Qxx tops out at 27MHz. You could read a whole 16MB flash memory in a snip under 5.5 seconds. Winbond tout this speed as XIP - eXecute In Place and I see what they mean. Writes are a different subject - it all depends how you manage the memory. They only action zero bits so if you want to modify something and you want a 1 where there was 0, you have to buffer the area, tweak it, erase it in flash then write the buffer back. If you only write to previously erased addresses (e.g. sequentially filling memory with log entries), writes are not that much slower than reads. You do have to do some foot work depending on where you are writing and how much but if it all happens within the same 256byte block, writes are only a tiny bit slower than reads. Getting more exotic, certain members of the W25Qxx series do support quad SPI, where you can access four bits in parallel per read (4 DI/DO pins, so only two clocks required to snag a byte not eight) which brings things up to 104MHz but requires a specialist SPI interface with four data lines - your microcontroller chip would have to support that in the hardware and firmware. I have worked quite a bit with these chips in the past 7 or 8 months and they are very flexible and quite forgiving - I'm hooked at around $0.40 for a 4MByte device. There is mention of a Microchip flash memory in MatherP's original thread and looking at the datasheet, there is pin and code compatibility but I seem to remember there is an extra flag that needs to be set in the initialization to get it working right - but I haven't looked closely. If there were demand I would tweak my code so your MMX/ARMMite can play, but they are more expensive that the Winbond chips pound for pound so why bother? What am I missing? Eight in parallel. I wouldn't bother - these devices work in terms of bytes, just each bit is clocked in or out. If yu did actually get 8 working together you be accessing in blocks of 64Bytes and I think you'd spend more time trying to sort out that mess. Coffee sounds good. hope this helps |
||||
JohnL Senior Member Joined: 10/01/2014 Location: SeychellesPosts: 128 |
Micropython runs very nicely on esp32 with SPI Ram . Modules and development boards available with 4Mbytes to 8Mbytes of SPI Ram. With 3 simple lines of code to configure and mount Ramdisk of whatever size you want. Cheap development boards with Lipo battery chargers etc. https://www.aliexpress.com/item/32921310591.html?algo_pvid=613584e7-4e06-41c3-b2b7-1525e9bd0d89&algo_expid=613584e7-4e06-41c3-b2b7-1525e9bd0d89-38&btsid=eefa70dd-0c77-4ffd-ad38-765da6125cb6&ws_ab_test=searchweb0_0,searchweb201602_3,searchweb201603_53 Micropython is an open source and as easy and interactive as basic but so much more powerful and flexible. |
||||
CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1421 |
Years ago I implemented a BASICStamp-like device using an AVR and serial memory. The official stamp used a small EEPROM for code and data storage. It has a set of simple 8-bit data movement and manipulation opcodes. It was fun making opcodes for my version, as I decided to make 16-bit long opcodes and use a really large EEPROM. These opcodes were much less "RISC" than those of the original stamp. For what it was it was a fun design. I wrote code in the opcode "assembly" though, as I never took the time to try to make a BASIC or any other higher (!) level language for the device. Its speed is nothing compared to what MMBasic does two decades later, but it was fantastically fast for the little chores that I had it do. Downside is it was a one-of-a-kind language. Micromites and Maximites! - Beginning Maximite |
||||
Print this page |