-
Hi,
Argh, sorry to hear that - it sounds like at some point GND and 5V have got shorted out (maybe those 3 0.05" pins that connect to the board?). It's worth checking they're not still shorted...
It's not the end of the world - it's almost certainly meant that the diode on the Pico that transfers USB power to it has blown up. It's the black 2 legged device with S4 written on it nearest the USB connector. It might even look a bit misshapen/singed.
To test, you could do one of:
- apply 5v to the Gnd and 5v wires on Espruino
- solder a JST battery connector onto the underside and use that
- short out the diode
- replace the diode - let me know if you want to do that and I'll dig out the part number
.. then plug it into USB and it should start working again.
Hope that helps!
- apply 5v to the Gnd and 5v wires on Espruino
-
@Sacha I think for the moment it might be better with
eval
- sorry! To be honest that's almost exactly whataddCached
does behind the scenes anyway. -
-
-
... just to add - it's definitely worth spreading the news about this, but I should do a 1v82 release first I think.
It'd be good to get some feedback about the current GitHub versions though - there have been some pretty major changes in there to try and get memory usage down, so I'm still a bit paranoid about whether some bugs have crept in :)
-
Thanks! We'll have to get some examples together of MQTT + TLS... maybe someone wants to write a tutorial? ... :)
Had anyone tried this yet? All the latest builds like this one should have it in now.
The Pico will actually have the same amount of program space available as before - it had some free flash memory before, but now that's mostly taken up with the TLS stuff :)
-
-
When using SPI send, you can probably get more performance by putting the data into a Uint8Array first.
... did you check the signal with an oscilloscope? Your problem could be electrical - WS2811s don't like running off 5v while being driven off a 3.3v signal. It works on Espruino boards because the 5v line comes off USB via a diode, so is actually nearer 4.5v.
In the docs on the site it's suggested that you put the pin into open drain mode and then pull it up to 5v with a resistor, but I'm not sure if the ESP8266 is 5v tolerant?
-
Well, I think it should be possible. It'd totally depend on the type of FPGA what you had to do to get it to work, but I'm sure you could send configuration data over.
I think it'd be hard to get the JS to modify the FPGA directly, but you could have several different configurations in flash or an SD card and you could write the required one in as needed.
... I actually used to work for Altera, developing a compiler that made C code run on an FPGA. You could definitely get some subset of JS running on an FPGA, but it'd require a lot of work, and the compiler for that is never going to fit on Espruino itself :)
Also it's really not (at least when we did it) a matter of just running code directly on an FPGA and it being faster. If you want to get any kind of performance you've got to think really hard about exactly how your code maps onto the hardware (adds, multiplies, etc) when you write it.
Did you have anything particular in mind that you wanted to use it for?
-
-
Good point... There's plenty of space on there. You'd have to use up a few of the Arduino pins for it though as I don't think there are any spare on the Pico.
Shame really - I sent the next batch off to be made just last week!
I reckon you could put the ESP8266 on there, but you'd need some 0.05" pin strip so you can mount the shim above the Pico rather than underneath it. It'd definitely be a bit fiddly!
-
That info would have to be persisted in the save() area
I'm not sure I understand this? You mean that when you update firmware you don't want to overwrite it?
Really good documentation on the memory layout though - I need one of those for Espruino boards :)
I think if we added
int jshGetFreeFlashAreas(uint32_t **addressAndLength, int maxAreas)
tojshardware.c
then theprocess.memory
implementation could just use that, and report each area back asaddr
andlength
?I guess probably returning a set of ranges (from + length) would be best, as otherwise you're going to get swamped with data items if you ask how many pages are in the 4MB parts :)
... other option is to just have
JsVar *jshGetFreeFlashAreas()
and let each platform return its own array of data (I guess then some platform-specific hints could be added). -
That's great - thanks! I'll merge those changes in in a bit.
Does it make sense to use
dd
in the build process to unifyboot
,espruino
andblank
firmwares into one big 512kB binary? Then users of 512k boards have a much more simple process, and on others a bigblank
image will only be needed if they care about having the remaining flash zeroed?Or am I missing something, like is the MAC address in there or something like that?
-
-
Hi Uli,
Thanks! Yes, getting stuff locally is a complete pain. I'm actually talking to Watterott in Germany about getting Picos stocked at the moment, so hopefully that will be an option for you in a month or so.
I've been pushing Tindie to support different currencies too - but I'm not really sure when that will happen :( Being in the UK and charging in US$ is a real pain!
-
I hadn't heard of the Redbear Duo before, but I see:
JavaScript - Yes. If you know JavaScript already, you are ready to go! We are porting an open source JavaScript interpreter for microcontroller to the Duo
I'd be interested to see which one - I guess it could be Espruino already, given it's an ST chip? Although there's enough RAM that it might not be.
RedBear contacted me just over a year ago about using Espruino:
Just want to inform you that we are porting your code to an ARM M4 platform and if successful, we will sell a board using the ported codes.
So I guess this could be it. At the time I asked if they'd contribute something to help support the project (in return for me listing the board on the site and helping to support their users), and it went quiet soon after.
And I just realised - the copyright case I'm fighting at the moment is with
Beijing Red Fox
(a translation from the legal firm) from Sept. 12, 2014 - one week before I was contacted by Red Bear Labs. It could well just be coincidence at the moment though, especially as Red Bear seem to be based in Hong Kong - I've asked the legal firm for confirmation.... so basically, I have tried to get some manufacturers to support it and will continue to do so. The problem is really that very few people value the actual software (or the documentation/support) - and because it's Open Source many companies think: "Why should I pay for this if my competitors can use it for free?" (that's an actual email I got).
About all I've got that I can convince them with is the fact that I own the copyright and control the website - so can choose whether I advertise their product or not.
Of course the other side of this is say I did manage to get a $1/board royalty in return for providing support on the website. I don't think that would actually pay for the time I spend - I'd have to start providing significantly less support per user if that were the case.
-
-
At the moment there's nothing in there for certificates at all, so I'd have to add that.
But for now I think you can get away without modifying the MQTT lib - it was designed to work over things other than network sockets unless someone wanted to (for instance) use some other kind of radio:
var mqtt = require("MQTT").create(); mqtt.on('connected', function() { mqtt.subscribe("test"); }); require("tls").connect("mqtt://whatever:1234", function(res) { mqtt.connect(res); });
-
Ok, if all goes well, in an hour or so there will be a Pico build here with it in: http://www.espruino.com/binaries/git/commits/4111ee167a43b8b8d80e5579829f562993ff2fe8
require("tls").connect("https://localhost:443", function(res) { console.log("Got response: " + JSON.stringify(res)); res.write("GET / HTTP/1.1\r\n\r\n"); res.on('data', function(data) { console.log(">" + data); }); });
The example above is a broken HTTP request, but it's enough to prove that socket connections work.
I'm leaving out HTTPS and TLS servers for the moment - I think they're probably a lot less use, and it's going to be more effort to add certificate loading.
Note: These builds still don't verify the certificates. While they'll connect to secure services, all that effort is wasted if someone can spoof the DNS and point you at their own TLS server without you noticing :)
-
-
-
Thanks! The reset button is physically connected to the reset pin of the board, so it can't be overwritten in software, but you have two options.
Use the internal RTC
This is actually what you're doing currently, and the internal RTC will keep time between resets.
The problem is that the RTC is only 24 bit, and when you use the
set time
option in the Web IDE it sets the time since 1970, which is too big for 24 bits... So when you reset only the bottom 24 bits are left (there's a bug open for this at the moment) and the time is wrong.To get around it, you can turn off that setting in the Web IDE and can instead store the time since startup (the default) and then add that to a variable that you create which is the time at which you started Espruino. The http://www.espruino.com/clock module will do that for you.
Disable the hard reset button
You might want to do this anyway, as if you're writing to an SD and just hit reset, it could corrupt it.
It's pretty easy - if you look at the
Revision 1.4 layout
at http://www.espruino.com/EspruinoBoard you'll see something marked#3
.See the attached image - just cut across with a sharp blade where I made the red mark reset will stop working.
If you want to re-enable it, just put a blob of solder between those two pads. You can also put a blob of solder on the two pads to the left, and then you can use that extra button on pin C12 (but you need to either add a resistor or run
pinMode(C12,"input_pullup")
to make it work correctly). -
-
Just to add - if you short out the diode, you can't then use an external power source with the Pico - you'll always have to power it via USB. It might be that's good enough for you though.