New EEPROM module names

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:

1) The new modules are not backward compatible
2) Why did I name them on Atmel's naming scheme, when over half a dozen companies produce effectively identical parts? In fact, the only thing that seems to distinguish Atmel's EEPROMs is their higher price.... I have a drawer full of EEPROMs (dozens of them) and not one of them was made by Atmel. So I wonder if naming it like that leads people down the wrong path, thinking they'd "better get the AT24's..

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.

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 SPI_EEPROM is fine when there's just one type, but I'm sure there are already a few obscure ones out there that have a different protocol and we don't want it confusing people - and we definitely don't want SPI_EEPROM2 and SPI_EEPROM3 modules :)

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 .md file's title (which will appear everywhere it's linked), and as keywords, so it should be pretty obvious that people can use the other parts.

Any other ideas though?

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?
24-series? xx24? Blah!

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.

I have a drawer full of EEPROMs (dozens of them) and not one of them was made by Atmel.

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.

Modules done. Only thing left is the generic EEPROM page and some conversion functions.

http://drazzy.com/e/espruino/etc/DS2xxx.­js
http://drazzy.com/e/espruino/etc/AT24_ne­w.js
http://drazzy.com/e/espruino/etc/AT25_ new.js

(I don't intend to keep the _new on the filenames, ofc)

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

Looks great. Do you think we should have the extra asString though? I'd be tempted just to always return a Uint8Array.

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:

• I2C.readFrom to return a Uint8Array
  
• OneWire.read to take an optional argument for length, and to return a Uint8Array if it's nonzero
  
• E.asUint8Array to convert all arguments to a Uint8Array, eg: (1,2,511) -> [1,2,255] or (1,[3,4],"Hello") -> [1,3,4,72,101,...]
  
• E.asString which works like E.asUint8Array, but creates a string.
  
  

That's all code that exists anyway (SPI.write uses it to convert whatever args it has to strings).

Any thoughts on the names? I'm not too happy with asString/asUint8Array.

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?

The only odd thing is I currently have E.toArrayBuffer, which only works on strings. toString/toUint8Array would be a little different I guess.

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

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 E :)

I've just implemented E.toString/toUint8Array, as well as Uint8Arrays from I2C.readFrom, and multiple read/write support for OneWire (which would probably simplify your code a little).

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!)

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

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/EspruinoD­ocs/blob/master/devices/EEPROMs.md

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 #feram

1 Attachment

• MRAM_vs_FRAM.pdf

Wow, thanks! That looks amazingly thorough!

And it all works fine with the new changes to 1v72?

Do you think we actually need the asStr argument in read, now that we can just call E.toString? It'd probably help to simplify things even more.

Yeah, I think asStr isn't needed anymore, I've removed it (but those version aren't posted yet, but they are checked into my fork of the github repo)

Ahh, great! I'd been looking at your links on DrAzzy.com :)

Had some time to spend with new serial memory modules.

Loaded AT25 from git, placed it inline as below, and tried to run it (in 1v72). First, the editor complained about several things... mostly just missing semicolons (see screen shot attachment). To get the statement in the wait loop accepted by the IDE, I added a dmy variable.

// using AT25 (copy - inline) to write/read to/from 256KBit FRAM:
// https://github.com/SpenceKonde/EspruinoD­ocs/blob/master/devices/AT25.js
// (?)same as http://drazzy.com/e/espruino/etc/AT25_ne­w.js(?)

// using SPI2 and A2 for CS as used before and posted about experience
// http://forum.espruino.com/comments/11937­103/

var exports = {};
(function() {
  
// AT25 module code

exports.connect = function(spi, pgsz, cap, cspin) {
	if (cap > 4096 || !cap || pgsz > cap || !cspin) {
		throw "Unsupported or invalid options";
	}
    return new AT25(spi, pgsz, cap, cspin);
};

function AT25(spi, pgsz, cap, cspin) {
  this.spi = spi;
  this.cspin=cspin;
  this.pgsz=pgsz;
  this.cap=cap<<7;
  this.ca=0;
}


AT25.prototype.read= function(add,bytes) {
	if (add===undefined) {
		add=this.ca;
	}
	t=(this.cap>65536)?E.toString(3,add>>16&­0xff,add>>8&0xff,add&0xff):E.toString(3,­add>>8&0xff,add&0xff);
	var ov=this.spi.send(t,this.cspin);
	var o=new Uint8Array(ov.buffer,(this.cap>65536?4:3­),bytes);
	this.ca=add+bytes;
	return o;
};


AT25.prototype.write= function(add,data,num) {
	if(typeof data!="string"){data=E.toString(data);}
	var idx=0,dmy;
	while (idx < data.length) {
		this.spi.send(6,this.cspin); //WREN
		var i=this.pgsz?(this.pgsz-(add%this.pgsz)):­data.length;
//      console.log(this.spi.send([5,0],this.csp­in));
		t=(this.cap>65536)?E.toString(2,add>>16&­0xff,add>>8&0xff,add&0xff):E.toString(2,­add>>8&0xff,add&0xff);
		t=t+data.substr(idx,i);
		this.spi.send(t,this.cspin);
		var et=getTime()+0.012;
		while (getTime() < et && this.pgsz) {dmy="";}
		idx+=i; add+=i;
	}
	return data.length;
};

// /AT25 module code

}());
SPI2.setup({sck:B13, miso:B14, mosi:B15, baud: 18000000});
var fram = exports.connect(SPI2,0,256,A2);

console.log(fram.read(0,256));

The tries did not go that well. The console complained:

 1v72 Copyright 2014 G.Williams
>echo(0);
undefined
=undefined
Uncaught Error: Field or method does not already exist, and can't create it on String
 at line 7 col 28
    var o=new Uint8Array(ov.buffer,(this.cap>65536?4:3­),byte...
                            ^
in function "read" called from line 1 col 28
console.log(fram.read(0,256));

Furthermore, I wondered about several items:

1. Why is t in the write() not declared?
   
2. Does it matter - for ESPRUINO's JS interpreter implementation if declarations of variables are inside or outside a loop?
   
3. The console.log() in write() must be a left over... :}
   
   

I'll look a bit more into the code...

2 Attachments

• FRAZZY.js
• 

t should be defined, I forget the devastation, so it's making it a global. I have no idea why it's erroring on you, I'll look into it.

Just to add:

    t=(this.cap>65536)?E.toString(3,add>>16&­0xff,add>>8&0xff,add&0xff):E.toString(3,­add>>8&0xff,add&0xff);
    var ov=this.spi.send(t,this.cspin);
    var o=new Uint8Array(ov.buffer,(this.cap>65536?4:3­),bytes);

If you send a string to SPI.send then I'm pretty sure it'll return a string rather than an ArrayBuffer, which I guess is causing the issue. Looks like the following might fix it?

    var t=(this.cap>65536)?E.toUint8Array(3,add>­>16,add>>8,add):E.toUint8Array(3,add>>8,­add);
    var ov=this.spi.send(t,this.cspin);
    var o=new Uint8Array(ov.buffer,(this.cap>65536?4:3­),bytes);

toUint8Array and toString have an implicit &0xFF as they're converting to 8 bits, so you can also slim down the code a bit (done above) if you want to.

But having said that it looks like you need an SPI.send of bytes in there anyway.

Hmmm, yeah. Thanks, I'll get this fixed today. Code is missing from that version, it looks like.

Had some time to work on memory manger - solidifying code, adding regression, auto gc(). In the cross-implementation environment, I'm about ready for connecting it to the actual memory device API/module - recently published by @DrAzzy (also intended to be cross emulated in the code before moving the memory manager into Espruino context). The attached file has a memory manager configured for 128 byte with a set of tests that can be run as a whole or also step by step to see what's going on. Each step has a pre and post validation... and it was already very helpful in catching glitches on changes and extensions (ability to write/read besides a string also true, false, null, and undefined into the memory). Download the html file and run it by stepping through the tests... behaves like a slide show for geeks... ;)

1 Attachment

• mm.html

Fixed AT25 module, pullrequest in.