Search results for:

So far I've tried D2, D3, D26, and D27 and they all lock up :( I've also changed the led toggle so it ends up on by the time the neopixel call happens, and the led stays on when it locks up (suggesting that it is indeed locked up and not just a broken console connection).

It's not urgent though, but I'm doing a road test of the PAN1780 eval kit for Element14 and one of the things I wanted to showcase its BT capabilities was doing some light shows with neopixels. I can always do something else instead (like the home automation I'm currently running with the Puck and EpsruinoHub and Tasmota, but this time with the extra TX power available with the nRF52840).

So there's this thing called Hacktoberfest https://hacktoberfest.digitalocean.com/details

Maybe Espruino might want to encourage participation? :)

I guess what would help with new contributions would be some sort of list that can guide what it is that need to be worked on, like some kind of triage ranked by difficulty or something like that.

I'll try it out, sorry I'll need to be on a few calls but I'll get back soon :)

FWIW I tried it on a different nRF52840 board (the waveshare eval kit) and it locks up as well.

I was playing around with the PAN1780 eval kit (it mimics the nRF52840DK closely except for the lack of QSPI) and I seem to have issues with neopixel.

Has anyone been able to get an nRF52840 working with neopixels? Doing something like

require("neopixel").write(D28, [255,0,0]);

seem to lock up the board. The web ide console (connected through ble) stops responding, and a blinky I have running to check if the board was still actually working behind the scenes stops blinking. It doesn't seem to matter whether I have a neopixel connected or not.

Here's what I use for testing this:

let on = 0;

const toggle = () => {
  on = !on;
  digitalWrite(LED1, on);
};

setInterval(toggle, 100);  

setTimeout(()=>{
  require("neopixel").write(D28, [255,0,0]);
}, 1000);

I have an actual nRF52840DK arriving sometime next week so I can see if it's just this particular board that's the problem, but I wanted to see if anyone has had success with neopixels on any kind of board that has the nRF52840 (like the particle boards for example)

Really useful!

But I think we should think of getting an Espruino (or at least a Bangle.js) app in the app store :P

The app can help do the agps update once a day, and maybe even configure application settings. And of course have a repl like the web ide.

We do have gadgetbridge but I don't think it can send the agps data on a scheduled basis :(

You're welcome, glad I can help :)

Were you not able to get it from https://www.f-droid.org/ ?

Manually calling disconnect does call the callback (and in this case, also reconnect)

Connected to Wifi.  IP address is: 192.168.43.151
connected!
>wifi.getStatus()
={
  station: "connected",
  ssid: "Mi A3",
  bssid: "2e:1d:1f:e3:55:21",
  channel: 8, rssi: -18,
  htMode: "HT20",
  authMode: "wpa2",
  mode: "APSTA",
  powersave: "modem"
 }
>http.get("http://www.pur3.co.uk/hello.txt");
=httpCRq: { type: 1,
  res: httpCRs: {  },
  opt: {
    protocol: "http:",
    method: "GET",
    host: "http://www.pur3.co.uk",
    path: "/hello.txt",
    pathname: "/hello.txt",
    search: null, port: null, query: null },
  dSnd: "GET /hello.txt HT" ... "ww.pur3.co.uk\r\n\r\n",
  sckt: 59, cls: true }
>wifi.disconnect()
=undefined
disconnected!
WARNING: Wifi:startMDNS - espressif
WARNING: Wifi:stopMDNS
Connected to Wifi.  IP address is: 192.168.43.151
connected!

Just to add, connecting and disconnecting the hotspot in quick succession will sometims leave the wifi status as AUTH_LEAVE and will not call the callback (because it technically isn't disconnected yet?)

>wifi.getStatus()
={
  station: "AUTH_LEAVE",
  mode: "APSTA",
  powersave: "modem"
 }

I just flashed an ESP32 I have with 2.07 and uploaded this code:

var ssid = 'Mi A3';
var password = 'parasquid';

var wifi = require('Wifi');

wifi.on('disconnected', () => {
  console.log('disconnected!');
  setInterval(connectToWifi, 1000);
});
wifi.on('connected', () => console.log('connected!'));

const connectToWifi = () => {
  wifi.connect(ssid, {password: password}, function() {
      console.log('Connected to Wifi.  IP address is:', wifi.getIP().ip);
      wifi.save(); // Next reboot will auto-connect
  });
};

connectToWifi();

I then setup a hotspot on my phone to control the wifi connection and disconnection outside of the ESP32.

The callbacks are running, but it looks like the issue is that disconnect status isn't immediately detected. I can force the detection of the disconnect (and the callback) by doing something on the network (like getting a url)

Connected to Wifi.  IP address is: 192.168.43.111
connected!
connected!
>require("http").get("http://www.pur3.co.uk/hello.txt")
Uncaught InternalError: Unable to locate host
 at line 1 col 54
require("http").get("http://www.pur3.co.uk/hello.txt")
                                                     ^
disconnected!
disconnected!
disconnected!
disconnected!
disconnected!
disconnected!
disconnected!
disconnected!
disconnected!
disconnected!
WARNING: Wifi:startMDNS - espressif
WARNING: Wifi:stopMDNS
Connected to Wifi.  IP address is: 192.168.43.111
connected!
connected!
>require("http").get("http://www.pur3.co.uk/hello.txt")
=httpCRq: { type: 1,
  res: httpCRs: {  },
  opt: {
    protocol: "http:",
    method: "GET",
    host: "http://www.pur3.co.uk",
    path: "/hello.txt",
    pathname: "/hello.txt",
    search: null, port: null, query: null },
  dSnd: "GET /hello.txt HT" ... "ww.pur3.co.uk\r\n\r\n",
  sckt: 56, cls: true }
> 

Sometimes though, disconnection is immediately detected and the callback runs (again tested by turning on or off the hotspot on my phone). And if you wait long enough, the ESP32 detects the disconnection and then runs the callback.

So maybe the best solution for now is to have a setInterval that pings a known good url so as to trigger a disconnect if it goes down?

Not sure if this would work but can you try putting the wifi.on stuff outside of the connect function? (I'm assuming this is what you were referring to as the callback)

Actually nvm, consider me confused which callback you're referring to :D I saw an emit somewhere and I'm not sure what's happening anymore.

I personally just do simple things like the ones found here: https://www.espruino.com/ESP32#connecting-to-wifi

Maybe try this one first and see if the wifi.connect callback runs? (again, I'm not really sure which callback you're referring to).

-- nvm, see mabe's post below :)

-- nvm, see mabe's post below :)

So what about my question can the firmware be running multiple scripts?

The firmware doesn't run multiple scripts; there is just one forever loop running and when you "upload" you execute the code you are uploading line by line, as if you typed them in the left hand side (except for things like modules and inline c/asm which are preprocessed or minified by the web ide then uploaded).

Like everyone said, reset should have fixed this but maybe it is a bug in the ESP32 port? If it's just a matter of resetting, you can always wire up something to the reset pin and trigger that through software when you want to reset. This would make you lose connection, but then again when your project is deployed you don't always need to be connected.

There's also the jlink edu mini which is around $20 from digikey https://www.digikey.com/product-detail/en/segger-microcontroller-systems/8-08-91-J-LINK-EDU-MINI/899-1061-ND/7387472 but then again the nrf52832 DK is just $40 which gives you a chip, as well as a jlink you can use to program other chips.

Too bad Nordic stopped supporting the nrf52832 DK though :( So maybe the jlink edu mini would be your best bet? I used to flash with my stlink and openocd as well, but I was amazed at how much faster the segger stuff is when I got them.

Have you tried the native ide? I think with the web ide you need to enable WebUSB in chrome via chrome://flags/#new-usb-backend

The native ide should work better when programming through the serial port though. (I use a pico though and windows 10, so your mileage may vary)

Can you get just the AT commands working at least? Better start from a simpler one without the fancy mdns. The goal is to get the at command object working for you: https://www.espruino.com/modules/ESP8266WiFi_0v25.js

This is (again) from the original post

var wifi = require("ESP8266WiFi_0v25").connect(Serial, function(err) {

But you're requiring Wifi so I'm not sure if you should be expecting AT commands there as that's a completely different module. http://www.espruino.com/Reference#Wifi

In the original post:

console.log("Start connection process");
var wifi = require("ESP8266WiFi_0v25").connect(Serial, function(err) {
  if (err)return 1;// throw err;
  Wifi=wifi;

Wifi is set to the result of the connect() function. In your case, wifi is set to the actual library.

You might need to show us the rest of your code. this is a tricky problem in javascript so it's best to get the complete picture.

If I'm to hazard a guess, this.at.cmd means this.at contains the object that is the wifi library, which you then call the cmd function of. So that means you'll need to replace this.at with Wifi.at

I just found another possible reason. I think that LED is usually used as a TX indicator by the default AT firmware (it flashes whenever there's data being sent).

https://electronics.stackexchange.com/a/78102

Apparently, TX is set to high by default. If the LED were connected with TX and ground, that means the LED would be on all while the chip is inactive, which would be horrible in terms of power consumption because you're just using power even when there's nothing being done.

So in this case, the LED is wired to VCC which means no voltage potential between the two. Then when TX goes low (e.g. the mcu starts transmitting data), the LED turns off. It blinks of course because the TX pin goes low and high alternately, but at the end of a transmission it defaults to high again, and the LED remains off.

The Espruino reference is accurate for official boards. The ESP8266, being a community port and manufactured by parties other than Espruino, may wire things up differently as @Robin has mentioned several times.

You seem to be under the impression that a "1" or a "true" means on, while a "0" or a "false" means off. Those really are just conventions, and will do different things depending on how things are wired. Sending "true" just means pulling the gpio up, while sending "false" means pulling it down (to ground).

There's a good explanation on stackoverflow: https://electronics.stackexchange.com/questions/20740/why-are-pull-up-resistors-more-common-than-pull-down-resistors which talk about switches; however since we're talking about LEDs one possible reason is that that in this case LED is wired to be pulled up in hardware; hence when setting the gpio low the LED turns on (because the circuit is complete) while setting the gpio high the LED turns off (because there is no voltage potential anymore).

We don't have the schematics so we can't know for sure. The official boards have schematics of course so we can inspect that and know for sure.

That said, there are ways to "invert" the logic so it's more "intuitive" but that involves possible issues with backwards compatibility on future firmware upgrades. Another one is to update the documentation on the ESP8266 specific page to mention this fact (then again, with all the different manufacturers of ESP8266 modules how do we know for sure which one we're working with?)

No, it doesn't look like the serial issue was the problem. That was totally my misunderstanding.

Sorry I don't think I can help you with this specifically; it looks like things should be working as they should and I don't know why the fan wouldn't behave as expected.

If you're able to find it with the nRF connect app then that means it's definitely advertising (and wasn't left connected to the pi for example). Barring possible antenna orientation issues, txpower or something of the sort, I can't think of anything else that could be the issue :(

Could it be because I'm already connected via BLE to the Web IDE and I am trying to connect to another BLE device?

Sorry for all the serial talk, I got confused by this. I thought you were connecting to another espruino that's also connected to another webide. The devices don't advertise (you can't connect to it) if they're already connected to a different device (which in this case is your computer).

While it can handle more than one BLE connection, the webide can only be connected to the puck's serial. By default it's the BLE serial. If you move the Serial from BLE to the pins, then serial would be running there and webide doesn't have anything to connect to.

One other thing: are you sure the device you want to connect to is advertising? You can use nRF connect app on your phone and scan it and see if you can see it.

Another thing is that not all bluetooth is the same. Puck is a Bluetoothe Low Energy device, which is completely different from plain old bluetooth. What's the device you're trying to connect to?

You don't have to stay connected with the serial just to test that you can actually find the device. You can blink the leds for example while searching and blink differently when found.

Also, if you're moving the serial somewhere else then the webide won't show anything since you moved the console messages to the new serial.