-
Well, you can power it externally and connect over bluetooth (if you have HC-05 installed), but I think you need USB in order to update the firmware (Gordon will know the answer to this - I'm not sure).
Might also be able to buy a replacement connector online and "just" solder on a new one... That's a fun solder job, for sure.
That USB connector is so fragile without anything around it. I don't have a solution for using it without fear on mine yet, so I've been connecting USB as little as possible, and carefully when I do - I do most of my work over bluetooth, while powering it externally.
-
The HC-05 creates 2 COM ports.
You need the second one (probably COM5).Also, you must have the USB cable unplugged from the espruino, otherwise it won't respond on bluetooth.
I've also on several occasions gotten that behavior persistently and had to reboot the computer (and sometimes unpair the HC-05 and re-pair to it).
-
Hm.
On my Espruino, onInit and doInit are DEFINITELY running - if they weren't, it wouldn't work at all. On my Espruino, I've always been able to put strings into setTimeout/setInterval. The IDE warns me that it's "evil", but it works fine*. What I didn't realize is that you could just pass it the name of a function, unquoted, and have it call that function with no arguments! I thought you had to do:
setTimeout(function(){doInit();},2000);So in your case, it sorts itself out after enough disk errors happen? I don't think it was coming back to life for me, will check logs tonight.
*Note that I have not tested whether this "evil" evaluation has resulted in my eternal damnation; testing this seems like a real chore.
-
-
The DISK_ERR issue itself is trivial to reproduce:
var fs=0; function randint(max) { return Math.round(Math.random()*max); } function onInit() { digitalWrite(A14,1); setTimeout("doInit();",2000); } function doInit() { digitalWrite(A14,0); fs=require("fs") setInterval(function(){dologs();},10000); } function dologs() { digitalWrite(A15,1) var temp=randint(10); fs.appendFile("testlog.log","ASDF,"+temp.toString()+",Time,"+getTime().toFixed()+"\n"); digitalWrite(A15,0) } onInit();
This will run for a while, until eventually, every attempt to write results in DISK_ERR. This itself is a Bad Thing.
However, it does not run out of memory!
So why does it run out of memory when running the full setup?
var g = 0; var d = 0; var inits=new Uint8Array([0,0,0,0]); 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("DHT11").connect(C10) d.read(function(a){ t=a.temp; rh=a.rh; inits[1]=1;endInit();}); e=require("DHT22").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() {doMeasure();},5000); setTimeout(function(){setInterval(function(){doMeasure2();},5000);},2500); setInterval(function(){dologs();},30000); } } function doMeasure() { d.read(function(a) { if (a.rh!=-1 && a.temp < 50) { rh=a.rh; t=a.temp; } updateLCD(); }); } function dologs() { fs.appendFile("timetemp.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(); } onInit();
All I can think of is that this DISK_ERR disrupts other things happening at the same time, like DHT read or LCD update.
Unfortunately, I've never been able to catch it between the first time it gives the DISK_ERR and when it runs out of memory, in order to see if it's leaking memory every time, or whether it survives until the error happens at a critical moment.
-
-
Could the vector font system be tweaked such that at small sizes, it doesn't make the lines 2 pixels wide? This results in the spaces between lines being too thin, such that it's hard to read. Try sizes around 8-12 on the Nokia5110 screen, and I think you'll see what +JumJum and I are talking about.
It would be awesome if we could load a replacement bitmap font off the SD card, and use it with the drawString() methods - like setBitmapFont("8x8.fnt")
-
-
I have a program that reads a pair of DHT's (11 and 22, to compare their readings), shows them on a Nokia 5110 screen, and every ten seconds, records the latest data on the SD card. Every time I go away and leave it, I come back to find something like this on the console:
ERROR: Unable to write file : DISK_ERR
ERROR: Unable to write file : DISK_ERR
ERROR: Unable to write file : DISK_ERR
ERROR: Unable to write file : DISK_ERR
ERROR: Unable to write file : DISK_ERR
ERROR: Unable to write file : DISK_ERR
ERROR: Out of Memory!
ERROR: Out of Memory!
WARNING: Unable to create string as not enough memory
ERROR: Out of Memory!
ERROR:(with cursor at the end of the word ERROR:)
Using v55 firmware, connecting via bluetooth. After reset, SD card is found to be working normally.
All of the DISK_ERRs come in fairly rapid succession (either all at once, or once per attempted append once the problem manifests). I don't know what the exact timing is, since I've never been watching the console when it happens.
-
In one of the recent firmware updates, the default font for a graphics object was changed - it is now smaller than it was before.
The new type is uncomfortably small on the Nokia5110 screen, but the vector font sizes of around the same character size are too thick (ie, they look like they're in bold ). Is there any way to get the old font back?
-
I've written module for DHT22 now. Nifty little sensors these are...
The DHT22 and DHT11's disagree about the humidity, though. Both of my 11's say 34%, and the 22 says 24%... They agree about the temperature at least....
I think I'll take data from them over a period of time and see if they track eachother...
-
-
-
-
It'll work same as if it were WS2811's. The control protocol for WS2811 and WS2812/2812B are the same. As for why the ebay seller put the wrong part number in their product desc, i'd say it was just the sloppiness typical of chinese ebay seller. At least it's not something that effects functionality.
A WS2812 is basically a WS2811 die in the same package as an RGB LED, while the WS2811 is a separate IC that drives an RGB LED (look at the WS2811's here http://www.espruino.com/WS2811, see how they have an IC at the base of each LED - that's the WS2811, the LED is just a normal (non-smart) RGB LED)
For strips and arrays, it's pretty much only relevant to the manufacturer of the strip/array - where the '12 is cheaper since you only need one part, assuming you want a 5050 package and are happy with their LEDs (standard RGB leds), while the WS2811 is more versatile and could, for example, be wired to 3 discrete LEDs instead of an RGB one, or a LED in a different package (like the WS2811 light string in the example)
-
I'm Spence Konde aka Dr. Azzy
I live and work in the People's Republic of Cambridge, near Boston, MA. I test the web gateway and web development framework for a database software firm for my day job, and sell PCBs and do electronics stuff on the side. I also own pinball machines, with all the maintenance that entails, and have made modifications to them as well.
In addition to Espruino, I do a lot of work with the Arduino platform and maintain a core that supports almost all ATTiny microcontrollers for the Arduino IDE.
I'm not a real doctor (I'd be happy to write you a prescription - but it'll be on the back of a cocktail napkin, and it'll be for a cocktail);
In a past life when I played Ragnarok Online, I wrote the AzzyAI homunculus and mercenary AI, which was used by thousands of players worldwide (ie, I'm that Azzy)
-
-
WebIDE I think could really benefit from some touchup, both UI and funtional:
No way to enlarge the text, or change the colors to improve visibility if you use the chrome store version. As a result, visibility of text is terribad on retina class displays. Ideally, i'd like support for pinch-to-zoom, but I'll be happy if I can just make the text big enough to read it without squinting...
It's not obvious when the left window has focus, and it often doesn't have focus when I expect that it will.
It will sometimes think it's connected, but the connection is entirely non-functional - can't even enter text in the left side. Happens if you connect via bluetooth on the wrong COM port, or try to connect via bluetooth when a USB cable is plugged in, and maybe in other situations.
If you disconnect the Espruino uncleanly from USB, need to restart chrome and IDE to connect again, otherwise every connect attempt will fail.
It is possible for the IDE to look like it's disconnected (ie, connect button enabled, disconnect disabled), while still being connected via bluetooth, and able to send commands and see responses in left side (happened to me last night, no idea how).
When it says there's a firmware update, it displays a message "Firmware update available, click the (i) button to update"... but the (i) button in the message is just a picture, it isn't clickable like the 'real' button on the right is - should be able to click it to go to firmware update dialog. -
That gets you another two sets unless I'm mistaken? There are two sets of gnd/vbat/3.3 there, at least in the pictures.
Even so, it's very easy to run out of gnd/vbat/3.3 pins, but you can just cut up dupont line to make splitters, or use screw terminals, or a breadboard (I never liked these, I found them unreliable, but some people like them), etc.
-
-
-
-
That doesn't give us the information we need. Somewhere, there is a considerably longer document that describes how to communicate with it. I see 8 data pins, which means parallel input, which might be awkward to do with the espruino (maybe with a shift register? This is outside my experience), but some LCDs like that can also be configured to communicate via SPI (I saw one for sale just the other day on ebay...).
It's also not clear whether the product that that place is selling is simply a breakout board for that LCD, or whether it contains a controller of some sort - in which case, you'd need to identify and scare up the datasheets for that.
Also - there are a few common LCD interfaces that have arduino libraries for them - these can be a good source of information, if such a library exists for yours.
-
The espruino doesn't come with a battery, unless you bought the ultimate kit that came with one, though if you're driving a non-backlit LCD, the battery life will probably be decent. Espruino can run in very low power sleep mode if you tell it to.
I think the Espruino would make for a rather bulky wristwatch, especially if you wanted to add anything beyond a screen (and with just a screen, it doesn't seem very useful...)