-
-
-
Ahh, great! - I reckon you could probably check the USB Product and Vendor IDs pretty reliably, and presumably they are available in a similar way.
If you did do it, it'd be great if you could submit it as a change for: https://github.com/espruino/EspruinoTools/blob/gh-pages/bin/espruino-cli.js#L273
-
Ok, just changed so the following works:
var page = '<html><body><script>var ws;setTimeout(function(){'; page += 'ws = new WebSocket("ws://" + location.host + "/my_websocket", "protocolOne");'; page += 'ws.onmessage = function (event) { console.log("MSG:"+event.data); };'; page += 'setTimeout(function() { ws.send("Hello to Espruino!"); }, 1000);'; page += '},1000);</script></body></html>'; function onPageRequest(req, res) { res.writeHead(200, {'Content-Type': 'text/html'}); res.end(page); } var server = require('ws').createServer(onPageRequest); server.listen(8000); server.on("websocket", function(ws) { ws.on('message',function(msg) { print("[WS] "+JSON.stringify(msg)); }); ws.send("Hello from Espruino!"); });
All updated and documented here: http://www.espruino.com/ws
-
I mean "serialport" as in the npm module :)
Yes, sorry - typo on my part. That's the lib it uses.
automatically find my espruino if I just plugged it in
No, if there are >0 ports, it'll pick the first one. It isn't able to test to see if an Espruino is on that port - although if it were possible (reported back by the OS?) that'd be really cool.
-
WebSocket Server support now works! http://forum.espruino.com/conversations/278902/#comment12674947
@sameh.hady is there a reason that the
ws
library wraps everything up as JSON? It seems that at least on the client end (as a browser) you don't have to. -
Hi,
Just to say that the latest builds of Espruino now support WebSocket server in JS. Not only that, but mixed WebSocket and HTTP server!.
For instance:
page = '<html><body><script>var ws;setTimeout(function(){'; page += 'ws = new WebSocket("ws://localhost:8000/socketserver", "protocolOne");'; page += 'ws.onmessage = function (event) { console.log("MSG:"+event.data); };'; page += 'setTimeout(function() { ws.send("Hello to Espruino!"); }, 1000);'; page += '},1000);</script></body></html>'; function onPageRequest(req, res) { if (req.headers.Connection=="Upgrade") { var key = req.headers["Sec-WebSocket-Key"]; var accept = btoa(E.toString(require("crypto").SHA1(key+"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"))); res.writeHead(101, { 'Upgrade': 'websocket', 'Connection': 'Upgrade', 'Sec-WebSocket-Accept': accept, 'Sec-WebSocket-Protocol': req.headers["Sec-WebSocket-Protocol"] }); var ws = require("ws")(undefined,{ serverRequest : req, serverResponse : res }); ws.on('message',function(msg) { print("MSG:"+msg); }); ws.send("Hello from Espruino!"); } else { res.writeHead(200, {'Content-Type': 'text/html'}); res.end(page); } } require('http').createServer(onPageRequest).listen(8000);
I had to tweak the WebSocket library a bit, but it hopefully at some point the code above can mostly be rolled into the library and you'll be able to do something like:
function onPageRequest(req, res) { res.writeHead(200, {'Content-Type': 'text/html'}); res.end(page); } require('ws').createServer(onPageRequest).listen(8000);
-
-
-
I'd hope things would have improved with the recent changes to Espruino's variable storage, the minified version doesn't look too big, although:
- adding
var f=String.fromCharCode
at the start could save you a bunch - looks like some things like mqttPacketLength are public. If they weren't their names would get nicely minified.
How much is 'that much'? If it's even 10k, that's kind of hard to justify on other boards where MQTT works fine at the moment, and where on the original Espruino I'm starting to have to make space-saving changes just to get releases out the door.
If you really want to include a USE_MQTT kind of thing for ESP8266 it's Open Source so is up to you at the end of the day - but honestly it's unlikely to get included in Espruino board builds. It's also very unlikely to get any bugfixes/contributions from anyone - the JS code tends to get users debugging and fixing problems in it, but C code puts a lot of people off :)
... also right now any constant data (including the symbol table?) will use up RAM, so the MQTT lib will still be eating into available RAM a little all the time on ESP8266.
Having said all that - @JumJum was asking about how contributed code could get built in on-demand. Maybe it's worth trying to come up with a more flexible way of handling that.
- adding
-
Yes, I think that's the best way - ideally you could use the existing network abstraction layer (not
socketserver
, butnetwork.h
)?I'd been thinking
Telnet
as the name, but yes you could just hijack USB - it's what I do for Linux. You might find that what I did withlibs/bluetooth
helps a lot as it's doing almost the same thing?Whatever it does it'd be great to expose it in a way that could be used in other devices (like WIZnet - ESP8266 AT commands might have trouble since they use JS). As a start, you probably want to develop under Linux anyway because it's so much faster to compile/test/debug :)
Also: realistically you need at least an option to have a password. When the password is entered, I'd look in
execinfo.root
for a variable likePASSWORD
, and check against that. That way, if you have code then there's a password, but if you just reset everything then you can log in fine - but it's not dependent on Espruino being in any working state. -
can anyone run some sanity tests on other platforms?
Actually a really good start would be just
make clean;DEBUG=1 make
in Linux and then./espruino --test test123.js
- you can grep and there are definitely 1 or two HTTP tests in there. That'd test out the socket server pretty well in a way that's easily debuggable (it also tests for memory leaks).404
Interesting. If that's what Nodejs does then we should copy that - still seems a bit crazy though. I wonder how you're supposed to get the contents of a webpage that is sent without the standard return code?
It's probably something to leave out of this PR though - we could file an issue for it.
printing errors
No problem... another issue on GitHub?
MQTT library
I'd be really against a C library for MQTT. It's just adding complexity and bulking out the firmware on other devices, where space is getting pretty tight now. If you're going to implement something resembling full MQTT it'll take a lot of space - most of which will be for the API, and very little of which will be actual code since the protocol is pretty simple.
... but if you're not trying to be full-featured, why not just make a cut-down JS version? Originally, I'd posted some example code that published data with MQTT and used just a few vars.
Sure it wasn't full-featured, but it worked for what it was made for, and it'd definitely be fine on ESP8266.
If you just wanted to publish (or just wanted to subscribe) you could probably get the code size down significantly.
-
You'd need to copy the module locally in case there were any changes you needed (and because the Web IDE can only automatically pull in single file modules), but looking at the main code it pulls in 6 other modules in order to do what's actually a really trivial job.
You might find that even if you do get it running it uses up all the available memory (It using
lodash
definitely won't help).So I'd say it'd be easier (and definitely better with Espruino) to just use that module as a base, but to re-write the code to use Uint8Array or even strings. It's only a handful of functions...
-
-
-
Use
jsvArrayBufferIteratorGetIntegerValue
- the Byte write was (I believe) a special case because the writing of a byte is easier - but for reading there wasn't as much of a difference so I left something more general purpose. You can still do:jsvArrayBufferIteratorSetByteValue(&itDestination, (char)jsvArrayBufferIteratorGetIntegerValue(&itSource))
-
You would have to build your own binary using the documentation here : https://github.com/espruino/Espruino
Once you've followed the steps in the Readme, just type
make clean;MAPLEMINI=1 RELEASE=1 make
-
New tutorial: http://www.espruino.com/Espruino+Home+Computer
https://www.youtube.com/watch?v=0d3uGQUm7tM
I'm pretty pleased with how this came out. Cheap, easy, and I think it shows off what Espruino is actually capable of now.
-
Hi, What you're doing with the
test
commands sounds fine - that's as expected.The Shim v2 has an angled edge on it, whereas the v1 has only 90 degrees edges. The difference is that the v2 shim has other Espruino Pins used up that mean the Pico can put the ESP8266 into bootloader mode rather than you having to mess around with wires.
The problem you've having is almost certainly that the ESP8266 isn't in bootloader mode. Since you have the v1 you'll have to do what those instructions say about connecting the wires. When you do it, the blue LED should flash once (red light on is expected)
It really not that hard once you figure out which 2 pins to connect, but it's hard to explain. I'll see if I can do a video on it.
-
Have you tried just using the instructions for flashing other boards - specifically the ones for the Olimexino/Leaflabs Maple?
-
Just do
setTimeout("LoopbackA.setConsole();",500);
.It's because the code is executed as it is sent to Espruino (in some cases there wouldn't be enough memory to hold all your program's text and execute it too!), so you're actually moving the console out of the way right in the middle of uploading the code (while echo is off).
Adding a setTimeout will mean it gets executed later, after code is executed and echo is turned back on.
-
-
No, sorry, you're not doing anything wrong.
I just restarted it an it should be fine now - there was a power outage at my web hosts and it looks like when the server came back up, there was some strange configuration issue.