-
• #27
All the eeproms have a delay after writing. I do not know how I would go about making the write process not block while writing several pages, though, since you have to keep writing, then waiting, writing, then waiting. It seems like a nightmare to try to do it with callbacks.
Any way I can think of comes with a monstrous overhead.
yeah, good call on commenting about the i==3.
-
• #28
i==3
With binding the number of arguments to a function is creating a dependency that may come back biting. For sure it is an efficient way to manage the power. If the device has a NOP after the command, this could be used as an escape by artificially extending the command. What ever other four-byte command could then just add the NOP to escape. An alternative to that could be an additional parameter when writing a four byte command, but with the frequency the command is called, it creates overhead. Since until now - and this is a while - it is the only four byte command and thus could be considered rare, I though would stick with the i == 3.
-
• #29
if you don't export the whole class, then you can't add things to the prototype?
...Well, you can, it's just ever so slightly more difficult
What are the possible (bad) side effects when having first to connect to get to the prototype via a - throw-away - instance?
In a language where classes are 1st class objects, I just would add connect() as a class (~static) method, which creates the object, issues the connect, and returns the object. In JavaScript this would be adding the connect as a 'strange' method to the constructor (or class) function. Would that be safe/robust enough in regard to side effects?
If we want to stick with creating a throw-away through connect() to access the prototype, passing no parms to the connect could be the way out of the dilemma. A connect with no passed parms could return the instance right after the new - without following through to the end.
-
• #30
first to connect to get to the prototype via a - throw-away - instance?
Who said it was throw-away?
var eeprom = require("DS2xxx").connect(...); eeprom.__proto__.constructor.prototype.read123 = function() { return ....; } eeprom.read123();
I think that's fine, and it has the nice side-effect that we don't have to re-write any of the existing modules.
-
• #31
For keeping consistency it has to be a throw-away, because quite many connects actually do something and would create an object in a state one is most likely not interested in. If otherwise, the modification can just be sticked to the instance - as per the beauty of JavaScript.
Therefore, I came up with the idea of passing no parms which makes it comparable with the default constructor in Java and it can be assured that nothing unwanted happens. Going that route is the easiest for keeping the require().connect() pattern vs. returning class.
-
• #32
I just realized a really simple way to do conversions to arrays of bytes for saving...
function fToB(f){ var n=new Float32Array([f]); return new Uint8Array(n.buffer,0,4); }
And so on...
-
• #33
@DrAzzy yes, and you can actually do it on an existing buffer, so for instance:
var a=new Uint8Array(12); var f = new Float32Array(a.buffer,0,2); f[0] = ...; f[1] = ...; (new Uint32Array(a.buffer,8,1))[0] = ...; console.log(a);
I guess you could do:
AT24.prototype.aToN=function(a){return (new Uint32Array((new Uint8Array(a)).buffer))[0];}
And another nice one - although you don't use sToA:
function stoA(s) { var a = new Uint8Array(s.length); a.set(s); // I don't think passing a string into set is standard JS though! return a; }
-
• #34
Woah, ya, I forgot about .set()
-
• #35
Does the DSxxx modules still work? I can not seem to make it work with ds2431
-
• #36
N/M got it.
-
• #37
I couldn't get either the DS2xxx module or the code examples in this thread to work for writing to a DS2431, so I ended up porting some Java code I found to JavaScript and writing worked
https://gist.github.com/maxogden/c0b33da285e0fe809a8aa7009bc510f7
// Used with GeekHeart https://www.tindie.com/products/MakersBox/geekheart/ var ow = new OneWire(4) // D2 on NodeMCU var code = ow.search()[0] // will be empty array if it failed to find your DS2431 // write a Uint8Array of arbitrary length 8 bytes at a time with a 100ms delay (add callback if you need it) function write (data) { var buf = new Uint8Array(13) var row = 0 function next () { var pos = row * 8; for (var i = 0; i < 8; i++) { buf[i] = data[pos + i] } write8(pos, buf); if (pos + 8 >= data.length) return console.log('done'); row++; if (row >= 16) return console.log('done'); // EEPROM has 16 rows of 8 bytes setTimeout(next, 100); } next() } // write 8 bytes to addr offset // example write8(0, new Uint8Array([1,1,1,1,1,1,1,1) function write8 (addr, data) { console.log(addr, data) var i ow.reset(); ow.select(code); ow.write(0x0F, 1); // Write ScratchPad ow.write(addr, 1); ow.write(0x00, 1); for ( i = 0; i < 8; i++) ow.write(data[i], 1); ow.reset(); ow.select(code); ow.write(0xAA); // Read Scratchpad for ( i = 0; i < 13; i++) data[i] = ow.read(); ow.reset(); ow.select(code); ow.write(0x55, 1); // Copy ScratchPad ow.write(data[0], 1); ow.write(data[1], 1); // Send TA1 TA2 and ES for copy authorization ow.write(data[2], 1); } // read num bytes from addr offset // example read(0, 8) function read(addr, num) { ow.reset(); ow.select(code); ow.write(0xF0); // read ow.write(addr&0xFF); ow.write(addr>>16); var buf = new Uint8Array(num) for (var i = 0; i < num; i++) buf[i] = ow.read() return buf } // same as read() but decodes into string function readString (addr, num) { var buf = read(addr, num) var str = '' for (var i = 0; i < buf.length; i++) { str += String.fromCharCode(buf[i]) } return str } // write a long string starting at addr 0 function writeString (str) { var data = new Uint8Array(str.split('').map(function (c){ return c.charCodeAt(0) })) write(data) }
Ahh, right! It still makes me cringe a bit :) Maybe just add a comment as to why it's like that?
If the
OneWire.write(Array)
is added it'd actually simplify that a lot.Does the delay after writing seem to be a common thing? If so it might be worth adding a 'finished' callback to the API?
Well, you can, it's just ever so slightly more difficult:
Personally I'm not sure it's really worth the extra effort and memory usage to make it a tiny bit easier for the few people who would want to extend the basic class.