-
-
-
In the above test, I just discovered, the SD card contents got trashed!
node_modules directory was deleted, and a directory "t" was created, but is not accessible via windows file explorer.
timetemp6.log is empty.
Windows disk repair tool found and recovered all the files when run on the SD card. Am investigating whether there is some issue with the SD card itself.
-
-
Still fails quickly in v57. So far the most stable version has been v55, where it would run for ~4 hrs.
Trace:
http://drazzy.com/espruino/v57failure.txtThe code that generated it (simplified down to a single DHT now):
var d; var e; var inits=new Uint8Array([0,0,0,0]); var curdht=false; var t=-1; var rh=-1; var t2=-1; var rh2=-1; var fs; var havetraced=false; function onInit() { digitalWrite(A14,1); digitalWrite(A13,1); setTimeout("doInit();",2000); } function doInit() { fs=require("fs"); fs.appendFile("timetemp5.log","Espruino restarted") digitalWrite(A13,0); d=require("DHT11dev").connect(C10); d.read(function(a){ t=a.temp; rh=a.rh; inits[1]=1;endInit();}); } function endInit() { if (inits[1]==1 && inits [3]==0) { inits[3]=1; digitalWrite(A14,0); setInterval(function() {var mf=process.memory().free;console.log(mf.toString()+" "+getTime().toFixed().toString()); if (mf < 1100) traceit();doMeasure();},5000); setInterval(function(){dologs();},30000); setBusyIndicator(A13); } } function traceit() { if (!havetraced) { havetraced=true; trace(); } } function doMeasure() { d.read(function(a) { if (a.rh!=-1 && a.temp < 50) { rh=a.rh; t=a.temp; } }); } function dologs() { console.log("trying to log..."); fs.appendFile("timetemp6.log","DHT11,"+t.toString()+","+rh.toString()+",Time,"+getTime().toFixed()+"\n"); } save();
Edit: No, unlike previous tests, log files were not normal.
-
-
Click in the window and hit enter, and see if it does anything. Sometimes the > doesn't display correctly on connect.
To rule out web-ide weirdness, exit all chrome windows, plus the webIDE and restart it.
Assuming it's not that, maybe your OnInit() is doing something bad? Hit reset followed immediately by btn1 (not at the same time, as that will put it into bootloader mode, but right after), it will not run the stored program or call OnInit() - and hopefully that's what's causing your issue.
Edit: Reading your other thread, I wager that you're trying to do something with the CC3000 in onInit(), and it's choking on that (maybe it doesn't like being called immediately on startup?) Have you let it sit after starting for long enough for whatever it's trying to do to have timed out?
-
-
The espruino can provide 3.3v, but only at 150ma - so you can't run heavy stuff off that at 3.3.
The espruino itself will run at 3.3-15v (it has a regulator built in). VBat will be at the supplied voltage - it's not 5v like it is on USB.
It looks like everything there is 3.3 or 5 volts, and the 3.3 stuff has low current requirements, so you can run it off the Espruino's supply (note that for CC3000, you need to use the Vin pin and the +5v - it's peak current is 350ma, which the Espruino's regulator can't handle - but the Adafruit CC3000 board has it's own regulator built in, powered by VIN). Other than large LED strips, you should be able to run all that stuff powering the Esprino off of a USB wall charger.
You can also wire it up to a 5v wallwart, or use the +5v and ground from an old computer power supply, or any other source of 5 volts. You can also power it off batteries, though Li ion batteries are 3.7v, and some of your parts need something closer to 5, so you'd need a dc/dc converter to get the 5v (these are readily available for dirt cheap - small, light ones are available as "UBECs" for model airplanes)
For high current applications (long LED strips, etc), you should not draw the power off the Espruino's VBat pins - get the power before it goes into the Espruino.
Although the Nokia 5110 screen says it will take 3-5v, on 5v, even the pixels that were supposed to be off were partially darkened - it was hard to read. At 3.3v (running off Espruino's 3.3v), it looked much better.
-
Failed real fast on v56 - was setting it up before I went out, and it failed before I got out the door (didn't have a chance to study the results yet, since I'm on my way out the door)
http://drazzy.com/espruino/v56failure.txt
var d; var e; var inits=new Uint8Array([0,0,0,0]); var curdht=false; var t=-1; var rh=-1; var t2=-1; var rh2=-1; var fs; var havetraced=false; function onInit() { digitalWrite(A14,1); digitalWrite(A13,1); setTimeout("doInit();",2000); } function doInit() { fs=require("fs"); fs.appendFile("timetemp5.log","Espruino restarted") digitalWrite(A13,0); d=require("DHT11dev").connect(C10); d.read(function(a){ t=a.temp; rh=a.rh; inits[1]=1;endInit();}); e=require("DHT22dev").connect(C11); setTimeout(function(){ e.read(function(a){ t2=a.temp; rh2=a.rh; inits[2]=1;endInit();});},2000); } function endInit() { if (inits[1]==1 && inits[2]==1 && inits [3]==0) { inits[3]=1; digitalWrite(A14,0); setInterval(function() {var mf=process.memory().free;console.log(mf.toString()+" "+getTime().toFixed().toString()); if (mf < 1100) traceit();curdht=!curdht;if(curdht){doMeasure();}else{doMeasure2();}},5000); setInterval(function(){dologs();},30000); setBusyIndicator(A13); } } function traceit() { if (!havetraced) { havetraced=true; trace(); } } function doMeasure() { d.read(function(a) { if (a.rh!=-1 && a.temp < 50) { rh=a.rh; t=a.temp; } }); } function dologs() { console.log("trying to log..."); fs.appendFile("timetemp5.log","DHT11,"+t.toString()+","+rh.toString()+",DHT22,"+t2.toString()+","+rh2.toString()+",Time,"+getTime().toFixed()+"\n"); } function doMeasure2() { e.read(function(a) { if (a.rh!=-1 && a.temp < 50) { rh2=a.rh; t2=a.temp; } }); } save();
-
Interesting - the time to failure is definitely less than 65K seconds (just under 20 hrs). Not all of these failures have taken the same length of time. Sometimes it would fail after 2-3 hrs (maybe 8000 seconds?), while the most recent one, where the trace was taken when it first started circling the drain, took around 5 hours (16000 seconds?) to fail (I really need to put pinstrips onto my second espruino, so I can have one running tests for stability, while doing stuff with the other one).
I haven't had a chance to try with v56 - but I do still have the log files from v55, and will post them when I get home tonight, as I did record the results of getTime().
Thanks for investigating this.
-
I consider this to be an improvement - As it's laid out currently, the USB and JST connectors are very close to each other, and I found the USB and JST connectors to get in eachother's way when trying to use both at once (though the cables I was using do have chunkier connectors than most). It looks like this gives us a wee bit more space between them, and also, by putting it near the edge, you can use a right angle USB connector to get the USB cable out of the way without blocking anything. I don't see any drawbacks to the new layout.
What, if any, other changes are planned in the new Espruino revision?
-
-
Got a trace of it just before it exploded (down to 61 free at start). Clearly a repetitive structure - but uh... I can't make sense of the trace... What are these multiplied things?
http://drazzy.com/espruino/trace.txtAnother one, where the trace was taken right after the problem first manifested.
http://drazzy.com/espruino/trace2.txt -
-
Also, the Espruino's 3.3v is rated at 150ma, but the CC3000 peak current is 350ma - there's no way it's gonna work off the Espruino's internal 3.3v.
Note also that the CC3000 board VCC spec is 4.6 max - this means you can't expose it to 5v, though the 4.3 off USB is okay).
I think you're going to need a dc-dc converter of some sort - the 12v->5v stepdown ones for USB car chargers (also available as bare boards from china - dirt cheap either way) might be a good choice.
I would be inclined to use a 1S LiPo battery or a 18650 cell, and charge it with an appropriate charging board (powered off a 5v dc-dc converter), instead of using a 12v battery, though this might not be appropriate for your application...
-
And yet, here's a log clearly showing that once the disk errors start, the memory problems begin - I am back to being convinced this is an Espruino bug, as the system was stable for approximately one hour, reporting stable memory usage, then the instant it started disk erroring, it started leaking memory every time it measured the DHT's.
52 952 952 952 952 952 952 952 952 952 ERROR: Unable to write file : DISK_ERR 895 ERROR: Unable to write file : DISK_ERR 854 ERROR: Unable to write file : DISK_ERR 775 ERROR: Unable to write file : DISK_ERR 764 ERROR: Unable to write file : DISK_ERR 707 ERROR: Unable to write file : DISK_ERR 627 ERROR: Unable to write file : DISK_ERR 618 ERROR: Unable to write file : DISK_ERR 560 482 413 356 277 210 152 74 ERROR: Out of Memory! ERROR: Out of Memory! WARNING: Unable to create string as not enough memory at line 1 col 25 {dht.onread(dht.endRead());} ^ in function called from system Execution Interrupted during event processing - clearing all timers and watches. >process.memory() ={"free":997,"usage":803,"total":1800,"history":1,"stackEndAddress":536909500,"flash_start":134217728,"flash_binary_end":134438664,"flash_code_start":134443008,"flash_length":262144} >
The code that's generating this:
var g = 0; var d = 0; var inits=new Uint8Array([0,0,0,0]); var curdht=false; var t=-1; var rh=-1; var t2=-1; var rh2=-1; var line1=""; var line2=""; var fs; var activepin=""; function onInit() { digitalWrite(A14,1); digitalWrite(A13,1); setTimeout("doInit();",2000); } function doInit() { digitalWrite(A15,1); fs=require("fs") SPI3.setup({ baud: 1000000, sck:B3, mosi:B5 }); digitalWrite(A13,0); g=require("PCD8544").connect(SPI3,B6,B7,B4, function() { g.clear(); g.drawString("LCD OK",0,0); g.drawLine(0,10,84,10); g.flip(); digitalWrite(A15,0); setTimeout("inits[0]=1;endInit();",100); }); d=require("DHT11dev").connect(C10) d.read(function(a){ t=a.temp; rh=a.rh; inits[1]=1;endInit();}); e=require("DHT22dev").connect(C11) setTimeout(function(){ e.read(function(a){ t2=a.temp; rh2=a.rh; inits[2]=1;endInit();});},2000); } function endInit() { if (inits[0]==1 && inits[1]==1 && inits[2]==1 && inits [3]==0) { inits[3]=1; digitalWrite(A14,0); g.clear(); g.drawString("Init OK!",0,0); g.flip(); setInterval(function() {console.log(process.memory().free);curdht=!curdht;if(curdht){doMeasure();}else{doMeasure2();}},5000); setInterval(function(){dologs();},30000); setBusyIndicator(A13); } } function doMeasure() { d.read(function(a) { if (a.rh!=-1 && a.temp < 50) { rh=a.rh; t=a.temp; } updateLCD(); }); } function dologs() { fs.appendFile("timetemp2.log","DHT11,"+t.toString()+","+rh.toString()+",DHT22,"+t2.toString()+","+rh2.toString()+",Time,"+getTime().toFixed()+"\n"); } function doMeasure2() { e.read(function(a) { if (a.rh!=-1 && a.temp < 50) { rh2=a.rh; t2=a.temp; } updateLCD(); }); } function updateLCD() { g.clear(); if (t!=-1) { g.drawString("Temp: "+t.toString()+"C",0,0); g.drawString("RH: "+rh.toString()+"%",0,10); g.drawString("Temp: "+t2.toString()+"C",0,20); g.drawString("RH: "+rh2.toString()+"%",0,30); } else { g.drawString("DHT11 not",0,0); g.drawString("working!",0,10); } g.drawString(line1,0,20); g.drawString(line2,0,30); g.flip(); }
Does anyone have any thoughts on what might be going on? Is there any way to get some information about where all that memory is going when it starts to fail?
Using Espruino v55.
-
I've determined that the out of memory issue can happen without logging. So I think there is some condition in which my DHT module explodes. Investigations are ongoing.
However, there is still the issue with the SD card getting unhappy and producing DISK_ERRs, which happens when just logging gibberish. Do you have any thoughts on how to debug this further?
-
-
This is impractical in most cases - and in the few cases that it is possible (and the WiFi is DEFINITELY not one), it's not something for an "absolute beginner".
Getting wifi connectivity on an Espruino will require a solution designed for microcontrollers - Either the CC3000 module from Adafruit, or something like the more elaborate (yet curiously not higher priced) WiFly thingie (which has almost everything built in - it's pretty much a second MCU dedicated to handling wifi, which communicates with the thing you're connecting it to via UART and a few GPIO pins).
Honestly, it's not even worth the time to scrap most things for sensors. You can pick up temperature and humidity sensors, gyros, compasses and all sortsa stuff like that generally for under $5 shipped from china via ebay - and they come on breakout boards too.
-
AAah, well, then - that's the next challenge! Sounds like fun...
I am not familiar with the WiFly module - I just looked it up though (after paging through that manual for a bit), and my jaw hit the floor - I expected to spend a fortune on something like that, but it's the same price as the CC3000 - while the feature set is miles beyond it; it sounds like it offloads a lot of stuff you'd rather not be using precious bits of Espruino memory for. I gotta get me one of those.
-
No, connecting power via USB will prevent it from working over bluetooth (or it did when I was playing with it).
In fact, I think it prevents it from working if it's plugged in at all, even if the other end is dangling - not sure about this last part, but I'm like 80% sure that I wasn't able to get it to connect until I unplugged the USB from the Espruino - call it 60%, because at the time, the HC-05 had a dodgy solder joint on the RX pin, and unplugging the cable might have caused a different amount of pressure to be applied to that dodgy connection, making it work. But the dodgy connection was almost always working at that point.
Also, check the solder joints to the HC-05, it's really easy to get a bad connection there.
-
Check around on ebay and see if modules for this exist (look for stuff on people doing this with arduinos).
The other approach, of course, is to note that you already HAVE a controller and see if you can use the GPIO pins of the Espruino to drive the existing controller....
If they're not arranged in a matrix, the switches on the existing remote control probably just ground the appropriate pin, so if the voltage on it is no higher than 5, you could just hook up the buttons to GPIO pins and drive em like that. I've done this kind of thing all the time with discrete parts, and it could save you a lot of wheel reinvention.
I wish you luck in your plan for world domination - but not too much. I've got my own plans... I just need some fissile material, a foreboding island, an appropriate outfit (I'm thinking Gadaffi meets Lady GaGa)...
-
The smallest LiPo battery that will provide the required battery life ;-)
I'd get everything else set up on the bench and measure how much current it draws running off battery voltage, and let that be my guide. Picking the battery now is putting the cart before the horse. (Though I can't blame you for wanting to get orders placed now, speaking of carts and horses...)
Say I have an I2C EEPROM... Now, obviously I'm going to want to read and write strings, not just arrays of bytes.
I see that I2C.writeTo() is described as accepting a string - so that handles the writing part.
How do I go the other direction?
I2C.readFrom() returns an array of bytes - and you can't eval() an array of bytes - is there any way other than looping through each byte and looking up what character it should be?
(I know the whole I2C EEPROM bit is kinda silly, since we have the microSD card slot... but they're so dirt cheap, I couldn't resist ordering one)