-
-
Actually it turns out it's a simple thing to add - I had to rush out a 1v69 release because of a serious regression, so I stuck it in.
var ow = new OneWire(A1); var sensor = require("DS18B20").connect(ow); sensor.setAlarm(20,30) // then: sensor.searchAlarm() will return a list of sensor addresses that have the alarm set
-
I've just tracked this down. The problem only happened when so many pulses were being sent that it should have blocked waiting for some empty space in the timer buffer - so sending off a few pulses didn't cause a problem and I didn't notice it :(
I'll push out a 1v69 release in a few minutes that'll fix this.
-
Alarms weren't added, however the module was modified to allow multiple sensors to be connected to a single wire pretty easily, and it allows reading and writing of the scratchpad, so alarms can be set pretty easily.
Having said that, you can't do the 'alarm search' to get devices with alarms set, so it's a bit useless at the moment.
What are you trying to do though? It seems like in most cases you could implement the alarm functionality just by reading the temperature repeatedly and checking it in Espruino?
-
-
I just saw this one - it looks awesome!
https://www.indiegogo.com/projects/vocore-a-coin-sized-linux-computer-with-wifi#activity
I've posted up on the OpenWRT forums asking whether the OpenWRT package is likely to get approved - and if so, I'll see about submitting it...
-
Hmm - looks interesting, but very similar to http://shop.8devices.com/carambola2 - to the point of using the exact same chip. It's a little more expensive, but I guess it does have a chip antenna (although Carambola 1 has one too).
There's already a build for Carambola (OpenWRT) which supports all the IO - it's just not bundled up into a package yet. It got sidelined a bit as nobody seemed even remotely bothered.
It'd be awesome if someone could look at a Raspberry Pi package for it too ;)
-
I've just fixed a bug that stopped the MD5 implementation here from working on the Espruino board - that'll be in 1v68: http://pajhome.org.uk/crypt/md5/md5.html
the cryptojs MD5 still isn't working though...
-
That looks good - I'd wire:
- To Battery 3.7v
- yes - to motor positive (3)
- to diode (2)
4,5,6,7 as you suggested
So the diode will drop 0.7v of the 3.7v. The other diode was so that if there's a voltage spike when the motor is disconnected, it's soaked up in the diode. To do that, simply connect it backwards across the motor (so the band side is on motor +).
Only other thing I'd say is to connect the battery to the actual JST battery connector if at all possible. Espruino's got some circuitry to automatically switch between the JST connector and USB for power, but if you connect to the (slightly misleadingly named) 'Bat' on the pins, when you plug in USB and the battery, it'll be trying to put 4.3v into the Li-Ion battery, which is going to be bad news if it's left in for any length of time.
- To Battery 3.7v
-
For the initial question - no, you can't pipe to eval I'm afraid. Espruino needs to have the whole string of code in memory to execute it.
You may find the 'rollups' are a bit more efficient? For instance: http://crypto-js.googlecode.com/svn/tags/3.0.2/build/rollups/aes.js
However having looked at it, I think that AES implementation is too big to go in Espruino - not so much the code, but it allocates some arrays, and I think those fill up the available memory. With a bit of tweaking and changing to Int32Arrays you might be able to fit it in though.
You could always use MD5, which seems to be a bit more efficient: http://crypto-js.googlecode.com/svn/tags/3.0.2/build/rollups/md5.js
You can actually copy the contents of the rollup, paste it into the Web IDE and do:
function unescape(a){return a;} // this is needed by the MD5 lib... function encodeURIComponent(a){return a;} // this is needed by the MD5 lib... CryptoJS.MD5("Hello").toString()
But having said that, the answer gained from the MD5 library on Espruino doesn't match what I get from a desktop JS implementation. I'll try and find out why, but I'm not sure when I'll have time, so if anyone is able to track down which operation in Espruino isn't working as expected it'd be hugely helpful!
-
I think there are two main issues here:
- In SPI, MISO = Master In Slave Out - so you just have to connect MISO on the chip to MISO on Espruino (and you've connected to MOSI, which is an output on Espruino). Try using B4 instead.
SPI.send
sends only 8 bits, regardless of the number you put in. Instead, you'd have to send 4 sets of 8 bits and recombine them:var d = SPI1.send([0,0,0,0],C0); result = (d[0]<<24)|(d[1]<<16)|(d[2]<<8)|d[3];
Otherwise it's doing what you expect - C0 will be taken low, data clocked in/out, and then C0 is taken high again.
- In SPI, MISO = Master In Slave Out - so you just have to connect MISO on the chip to MISO on Espruino (and you've connected to MOSI, which is an output on Espruino). Try using B4 instead.
-
Hi Jack,
I should have updated the WIZnet docs, but there are pre-compiled WIZnet binaries under: http://www.espruino.com/binaries/
Having said that, you're pretty close. I use a specific codesourcery compiler from that page (codesourcery-2013.05-23-arm-none-eabi) - and it makes the code small enough to go into the available memory.
If you don't want to do that, edit the Makefile, scroll down to where it says
ifdef ESPRUINO_1V3
and change the optimisation flags from-O3
to-Os
- that'll optimise for size and that'll work too. -
-
-
-
-
-
Yes, that's fixed now though?
In that case something that was broken in Espruino got fixed. I guess at some point I could switch to a more comprehensive package management system, with a 'works with Espruino version' tag on each module revision.
My hope has always been that Espruino would stabilise enough that this wasn't a major problem. I think we're pretty much there now... I'm struggling to think of anything in the list of issues that would really cause a problem for existing modules.
-
If you're serving them up from a personal server then you just need to tell it to serve up the files with the correct cache control header.
The other option is to use urls that point straight to github, and then you can reference a specific file revision. Diffs are also automatic there.
I'm interested to hear what problems you've had that have prompted this though. I usually try pretty hard to be backwards compatible, with the only recent 'difficult' change being the addition of exceptions - which loads of people wanted, but which wasn't possible do without breaking stuff that previously produced warnings.
-
-
Nope! Just the same - but because it's got a separate programmer on the board as well it's better to use that. Just follow the instructions here: http://www.espruino.com/Other+Boards
-
-
As @DrAzzy says - while the CC3000 supports WEP, Espruino just sets it up for WPA2.
It wouldn't be too difficult to add the option, but so far you're the only person to ask for it :)
-
About JSON.parse: Looks like it actually is spec compliant now :) https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse
Throws a SyntaxError exception if the string to parse is not valid JSON.
How exactly is it not working? It's unlikely that something would have just happened after 1 minute... are you sure it's not just a bad connection?
I just checked and it seems that at 1mbps it's having trouble keeping the 1 byte SPI buffer full. To be honest it shouldn't really be having problems with that - I'll have to look into why.
However I'd be very surprised if that was the problem. That's why there's a clock and a CS line after all.
If you do really want an unbroken clock signal your other options are to just lower the baud rate (500000 seems to work fine) or to switch to sending/receiving Strings, which are a bit faster to access: