Search results for:

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.

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-sample

I 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.