New EEPROM module names #673
Replies: 50 comments
-
Posted at 2015-01-19 by @gfwilliams Well, I wouldn't be too worried about the backwards-compatibility. I just checked about those 2 modules and they haven't been used that much at all so far - in fact most of the uses so far could have been from you? It's difficult - personally I think going by part numbers is good. Stuff like I guess I'd try and get an idea of either the first chip with that protocol, or the most popular one, and use that. You can still have all the part numbers in the Any other ideas though? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-19 by DrAzzy Hm, okay, i guess that's good, though I'd have been happier if tons of people were using it so we had a big concern over backwards compatibility. I guess it stays AT24 then? Anyway - AT24 (I guess it'll stay AT24/25? I don't know! the I2C one) is done, and tested with 4kbit FRAM, 1kbit, and 16 kbit normal eeproms, plus the 512 kbit ones. Unfortunately the desk lamp is on the fritz again, so I had to make a new board, and it wound up being a real pain - but I put one of those FRAM chips on it for the temp/rh history buffer (last 24 hrs every 30 mins) and the presets. If that hadn't intervened, I'd have the AT25 tested and documented too. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-19 by @allObjects
How many photo-copiers (now digital) do we have and we still speak (in America) of ...go make a Xerox of it? ...Kleenex... and many many more. This goes for many things for which the brand name was and is still used rather than a term of the general taxonomy. So using the brand name is not that strange... last but not least it is still a minting term. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-20 by DrAzzy Modules done. Only thing left is the generic EEPROM page and some conversion functions. http://drazzy.com/e/espruino/etc/DS2xxx.js (I don't intend to keep the _new on the filenames, ofc) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-20 by @allObjects Like the aToS and sToA... both great role models for my iToS and sToI extensions... in order to touch on a subject that was discussed earlier. Having UInt8Array as the base class and the other things as helpers is just the right thing to do! Thanks. Noticed that some xToY and yToX conversion things are hanging out there in duplicates. Could it be worth to have like a module out there that has basic helper functions useful just all over the place? (If require supports nested requires the modules that need this module could just include a require and with that dependency on dependency can easily be managed. I did not test that nested requires works... |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-20 by @gfwilliams Looks great. Do you think we should have the extra I'd be happy to add functions to the 1v72 release of Espruino for easy string/array conversion (could do this today) - which would avoid all that code duplication. I'm thinking:
That's all code that exists anyway ( Any thoughts on the names? I'm not too happy with asString/asUint8Array. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-20 by DrAzzy That sounds great - that would allow me to greatly simplify my code, and would make a lot of common tasks easier. E.toString/toUint8Array for the name, maybe? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-20 by @gfwilliams The only odd thing is I currently have |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-20 by DrAzzy Maybe it should modify the constructor? "new Uint8Array(1,[3,4],"Hello");" sounds pretty reasonable, and it's also consistent with how you let multiple arguments go to the I2C.writeTo() for data - but there's no obvious way to do that for strings, which speaks in favor of the E.toString/toUint8Array.. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-20 by @gfwilliams Sorry, only just saw this. It's a good idea, but a few JS people get very upset when they see me doing things that aren't standards compliant - it's why all the cool stuff gets shoved in I've just implemented |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-20 by DrAzzy Woot woot. I'll try it out tonight. (and, only just saw this? I should think so, since it was only like half an hr since my last post!) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-21 by @allObjects Nothing wrong with shoving cool stuff into E... if backfill is there for other things that are possible in JS but just a bit 'slow(er)'... we could call the module E and have it loaded where E is not there... ;) #conversion #type #typeconversion |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-21 by DrAzzy Updated the demo files (Same links as above) to take advantage of that new functionality - of course, significant improvements in code size. Better still, there's no need to chunk reads! And I've gotten an EEPROM doc (or the basics of one) written: https://github.com/SpenceKonde/EspruinoDocs/blob/master/devices/EEPROMs.md |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-21 by @allObjects Excellent pub and .md! EEPROM vs FRAM/MRAM ... are Ferro-electric RAM - FRAM / FeRAM - and Magneto-resistive RAM - MRAM - are other kinds of non-volatile memory, with MRAM being more robust than FRAM. Fujitsu claims... For comparison of FRAM and (even better) MRAM see attachment (replica of Comparing Technologies: MRAM vs. FRAM, in case the link moves... @drazzy, did you (ever) take advantage of the partial or full write protection features? #mram #fram #feramAttachments: |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-21 by @gfwilliams Wow, thanks! That looks amazingly thorough! And it all works fine with the new changes to 1v72? Do you think we actually need the |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-28 by @allObjects Breaking up an SPI transfer - as far as I know - is possible - because the clock defines what is going on (and of course some other pins too). This is a main reason why clocked communication is so much more faster and more reliable than timed communication. For Espruino, the only penalty can be performance by going back and forth form JavaScript to firmware SPI.send implementation (as I read in Espruino doc).
WP and HOLD are hardwired to high.
I know that CS is NOT floating. Your implementation makes totally sense... but I assume that because of FRAM/MRAMs can handle much faster transfers, the timing can be a challenge... We know that in the past, the CS got raised to fast and communication did not complete - and this has been fixed. Furthermore, I do not know what Espruino - and the chip - 'really' do when changing state on the CS output pin with automatic pinMode() when applying set(), reset(). |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-28 by @gfwilliams
Yes, it should be fine. After all it's clocked so it doesn't (usually) matter if it pauses for a bit. Having said that, using CS like @allObjects does there is a bit of a hack. If you're going to do multiple SPI sends then I'd manually lower and raise it, rather than manually lowering and then supplying cs to the final SPI send.
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-28 by @gfwilliams It's possible that the first If you just perform a |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-28 by @allObjects I personally like the integrated CS pin option - after I understood what it is for and how it works... that's why I used it for the last send... to get rid of an extra statement. What I miss(ed) is(was) to have the same control for the first spi.send... that's why I had to do it - hacky ;-) -manually. Therefore: what about an additional parm in spi.send() that would allow the CS to go low and be kept low... after all, it is a 'hard'-wired sequence of statements that begin a communication, have some 'inner'-segments, and close a communication. After all a connect, do some stuff, disconnect pattern. I do not want to sound ungreatful... it's just the crave for to getting to the bottom of things... and surface back up with increased understanding and confidence... and accept the things that cannot be changed (reasonably). May be it is the ethnic related 'gesunde Unzufriedenheit' and the style of 'Das Bessere is der Feind des Guten' - literally: Better is the enemy of Good - ...only the best is good enough, just short of unhealthy perfection. In sports, it's called practice... - or what answer do you get from any athlete that already has done it yesterday, the day before, three days ago,... and want's to do it today? ...may be for the seventh day the athlete will take a break... ;-) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-28 by DrAzzy Assuming sorting out the functional issue with FRAM doesn't force this (I've got an SPI FRAM chip here from Fujitsu - not Cypress), I don't plan to rewrite that to directly control CS yet. I'll see if it works with my FRAM chip. If it doesn't, I'll put a cypress chip on my digikey shopping list. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-29 by DrAzzy Cannot reproduce with MB85RS64V up to 20mhz (did not test outside mfg specs) http://www.fujitsu.com/downloads/MICRO/fsa/pdf/products/memory/fram/MB85RS64V-DS501-00015-4v0-E.pdf
VCC tied to WP and HOLD, CS going to B6, and everything else connected in the obvious way. What exact code are you using to reproduce the problem? How is everything wired? Do you have HOLD or WP connected to Espruino pins? If so, are these set correctly, or are they being allowed to float? I'll bet if hold was floating, that could cause bad things. I am loving the effect of flat strings on memory use. 8kbytes goes into 504 jsvars - 0.8% overhead! HOWEVER - memory use brings me to a problem with SPI, - specifically with that doubled buffer needed to keep the clock running. For that one line, memory usage is DOUBLE THE SIZE OF THE THING YOU'RE READING. I'm not sure I see how to get around that without changes to SPI functions. We can argue about what the best way to do it, but when it comes down to it, you need to call SPI.send() with something the length of the data I want back (plus the 3 bytes at the front, ofc), so the memory used at that step will always be twice that of the data, whenever using SPI. For writing, there's SPI.write() that ignores the returned data - but there's nothing like that for reading. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-29 by @gfwilliams The only other difference I can think of is that there is something timing-related, and you're using your own BigRam builds (that are compiled without Well, I made a bug yesterday for SPI send. If it returned Uint8Arrays you could conceivably do I think there's room for an |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-29 by @allObjects
two birds with one stone - 7 Fliegen auf einen Streich - ... kind of 'DMA' and streaming in one shot! |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-29 by @allObjects @drazzy thanks for picking this MEMORY thing up... I had touched on that a while ago and more than once in the last few days. I did not think about the sparse array thing, but it helps for sure. When thinking about this DMA hub a few posts ago I was thinking about optionally passing a default transfer max buffer size in the connect and an transfer invocation and implement it the same way you did it for the AT25 module... Even though FRAM does not require paging (waiting), I would have used that mechanism to limit the temporary (excessive) memory use for the read(). Using a page size with FRAM has a performance penalty, it is better than run out of memory. So I thought about an additional parameter for the wait time... In case a EEPROM chips have different wait times, this parameter could come in handy! |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-29 by @allObjects
Did not work for me... what do I miss? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-29 by @allObjects @drazzy, took a look at the AT25.js module code at espruino.com/modules/AT25.js... and wondered a bit about the source (inline) documentation... ;). Published doc at http://www.espruino.com/AT25 at http://www.espruino.com/AT25 show an API parameter asStr - named num in the code. What I'm looking for is a) what exactly AT25 returns on read() - and - b) what is expected to be returned - and - c) what are there compatibility requirements for what is returned. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-29 by DrAzzy asStr was removed - it was for before E.toString() was added. I'll go get rid of it in those places, thanks. It now just returns a Uint8Array, no matter what. The post-overhaul AT24/AT25 drivers are completely incompatible with the old version. It had to be done - the old version was terribad. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-30 by @allObjects @drazzy, did some experimenting with the code... and came up with some hybrid. I was even implementing a 'chunked' read in order to not temporary double the memory needs. Attached are variations of the AT25 module code with mono write, split write (manual and automatic CS handling), and chunked read - mono write. Even though they are called FRAM..., they include all the code for EEPROMs. The chunked-read version has still the data conversion implemented at the end for convenience to return a string. Furthermore, the chunked read includes two versions of chunking:
With version 1 the the application has to call either read-single or read-chunked. Working through the AT25 code in very detail, I made some changes in sequencing: Please take a look at sequence of invalid option detection in connect() and sequence of string conversion and length determination. I wonder if for a split page write string conversion is required. spi.send() understands to send string and Uint8Array. Most other data types create anyway unpredictable results (length). Also notice the approach to factor out (of the loop) the command with address and data building for mono write AND command w/ address building for split write.Attachments: |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-30 by @allObjects Inspired by @drazzy's AT25 module implementations, I implemented a dedicated module for FRAM/MRAM. Here the code with usage example, tests, and test output. Documentation is in code (Attachment includes all in one file ready to be pasted into IDE editor, uploaded, and run. - Chip used: 256 Kbit / 32KB - 32K*8 - Cypress FRAM FM25V02-G about 4$). For more about FRAM/MRAM see 256-Kbit (32 K × 8) Serial (SPI) F-RAM - Ferroelecric RAM - SPI challenges.
Usage example and test code (256 Kbit / 32KB - 32K*8 - Cypress FRAM F25V02-G):
Test output:
Attachments: |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-31 by @allObjects Regarding @drazzy's comment about
and @gordon's option of
made me thinking: How about the SPI.read() still consumes a memory 'block' for keeping the clock ticking like the SPI.send() needs to do so, but the SPI.read() would write into that very same provided memory block. When the data item read is a byte or less, the provided memory block is either a string or an Uint8Array(Buffer) where the byte would get stored, otherwise it has always to be an Array (like thing). The values read could be the same buffer or the number of bytes/itemns read. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-01-19 by DrAzzy
I'm wondering what the right naming scheme for my overhauled EEPROM modules.
Previously, I named them AT24 and AT25.
I have two reservations about continuing that:
And regarding the new OneWire one, I'm still not sure what I want to call it - though at least in that case, the parts all start with DS; it seems Dallas Semi (ie, Maxim) is the only one making them.
Beta Was this translation helpful? Give feedback.
All reactions