Most recent activity
-
My vote is making it behave consistently with the spec.
Passing an invalid ID to clearTimeout() silently does nothing; no
exception is thrown.https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/clearTimeout
Passing undefined or no parameters to clearTimeout should do nothing.
-
For anybody else interested in getting the d1 mini pro up and running with Espruino, I've written a guide here: https://github.com/andrewwakeling/espruino-d1-mini-pro
-
Awesome! Enjoy your holiday! No rush on the fixes.
-
Just confirming that I was also able to correctly flash the d1 mini pro using 1v96 using the 4mb-c1 option too.
-
I'm a bit late to the party, but I'm new to Espruino and I too, did miss some of the modern features of JS.
I spend some time handpicking Babel plugins and did some sanity testing to see if the resulting code worked as expected in Espruino.
I found some bugs (which I've raised as issues in GitHub), but I'm so far, pretty happy with the result.
I have published a sample project which could be used as a starting point. It can be found here:
https://github.com/andrewwakeling/espruino-webpack-babel-sampleI would love to hear any feedback here or via GitHub. Thanks!
-
It looks like dgramSocket.send only works after running dgramSocket.bind.
I need to run the following first:
const dgram = require('dgram');
const socket = dgram.createSocket('udp4');
socket.bind(port, res => {});Then I'm able to do something like:
socket.send('hi',3333,'192.168.1.1');Interestingly enough, running send() FIRST seems to queue up the request. Upon running bind() later, the UDP packet gets sent.
I imagine that bind() must be running some sort of UDP initialization. I'm not sure if this is intentional or not but could explain why it seems difficult to send a UDP packet initially from Espruino.
For now, I'm okay with this workaround. I can just wrap a dummy bind() call in a initializeUdp() function.
Btw, I'm in 1v96 using a D1 mini pro.
-
I seem to be having issues getting dgramSocket.send working on ESP8266. It currently looks like it's doing nothing.
To use AM232x with I2C, it requires a specific "wake up" command which requires a command to be sent, followed by a 800 us to 3 ms delay, then a stop signal. (See section 8.2.4 of https://www.isweek.com/Uploads/20180528/5b0bbbc09cff2.pdf )
This doesn't appear to be possible using the I2C Espruino module, as granular functions (like beginTransmission, endTransmission in other platforms) are rolled into the 2 functions writeTo, readFrom.
Admittedly, this sort of granular control with delays isn't exactly Javascript's (or Espruino's) forte.
I'm unsure if this interaction is considered standard (e.g. https://github.com/espruino/Espruino/issues/390 introduced a "Repeated Start" capability), but perhaps it could be added as a capability.
Alternatively, you could always bit bang the entire I2C conversation manually. (e.g. http://forum.espruino.com/conversations/286138/?offset=25 ).
It's probably easier to fall back to the "single-bus" mode (which is wired differently as mentioned above).
I'm trying to use Espruino with an AM2322 and I ran into this complication.