Search results for:

This is an issue with Windows & node BLE driver.
Just run espruino --list --no-ble.
More details in this issue

Re: clearWatch / clearInterval:

• calling clearWatch without arguments is valid, and clears all watches
  
• calling clearWatch(undefined) throws an error. To avoid the mistake when you had a watch / interval number stored, cleared it, cleared the number, but call it again, but now accidentally clear all watches
  

Edit: ok, it's posted in the ESP32 forum. Stupid me...
Similar error in this thread DHT11 / DHT22 uses same communication "protocol"

One more thing to check: Settings -> Console, maybe that contains some clue.

Here is the output from my machine (You said you have a windows machine, but may save some time)

>>> Connecting...
ForceThrottle option is set - set Slow Write = true
[object Object]
Connected [object Object]
Got "E (544) spiram: SPI RAM enabled but initialization failed. Bailing out.\r\n"
No Prompt found, got "\n" - issuing Ctrl-C to try and break out
Splitting for Ctrl-C, delay 250
Received a prompt after sending newline... good!
>>> Sending...
---> "\u0010print(\"<\",\"<<\",JSON.stringify­(process.env),\">>\",\">\")\n"
>>> Sent
Got "< << {\"VERSION\":\"2v04\",\"GIT_COMMIT\":\"3­956264e\",\"BOARD\":\"ESP32\",\"FLASH\":­0,\"RAM\":524288,\"SERIAL\":\"3c71bf8b-f­e24\",\"CONSOLE\":\"Serial1\",\"MODULES\­":\"Flash,Storage,heatshrink,fs,net,dgra­m,tls,http,NetworkJS,Wifi,TelnetServer,c­rypto,neopixel\",\"EXPTR\":1073484860} >> >\r\n>"
[notify_info] Found ESP32, 2v04
Loading http://www.espruino.com/json/ESP32.json
Board JSON loaded
ForceThrottle option is set - set Slow Write = true
FIRMWARE: Current 2v04, Available 2v04
Device found {"bitrate":115200,"bufferSize":4096,"con­nectionId":1,"ctsFlowControl":false,"dat­aBits":"eight","name":"","parityBit":"no­","paused":true,"persistent":false,"rece­iveTimeout":0,"sendTimeout":0,"stopBits"­:"one"}
[success] Connected to COM8
>>> Connected to COM8

Oh, something about open source software & it's sustainability:
If some are not aware of the situation, it goes to comical and sad point where a developer publishing FOSS project gets a message from someone at a big company and telling them to fix an issue that's holding back their entire team. Of course no support from the company...
More details in this post.

A bigger community could help, if that bigger community includes new contributors with enough free time.

Maybe a software-only kickstarter, like Damien George did with ESP8266?

Or dive in all-in, and design something with the new ESP32-S2. Might be slightly risky :)

Hi David!

First guess would be you didn't change the communication speed to 115200.

And one more thing: ESP32 is not a perfect one-size-fits-all solution:

• it's power hungry (even without Wifi)
  
• looking at Coremark benchmark results looks like it slower per MHz compared to Cortex M4 chips.
  
• It's ADC is far from perfect (slow, nonlinearity at low values) And looking at Espressif's SDK looks like it's software driven. You can sample, do averaging and transfer results to DMA on a Cortex M without CPU usage.
  
  

But it's cheap, especially boards from china are cheap. And has Wifi.

Regarding google trends:
0: try adding arduino, even ESP8266 pretty much disappears :)
1: STM32s were available 10 years ago, those are "just Cortex M chips", available from multiple manufacturers. Lots of documentation. Not some exotic architecture almost no-one heard about.
2: Google searches can be a metric of wtf/minute :)

IMO a big user base of ESP8266 and ESP32 is arduino and home automation users. You just set up you home automation system of choice, config things, and don't really program the boards, just use them...

To add to @maze1980's point: I do have a couple of ESP32 boards, because well they were cheap direct from china. I live in Hungary, ppl in US or West-EU have more money & may think differently. But looks like a lot of people from richer countries buy from China as well.
I think it's hard to compete money-vise with direct order from China. You avoid customs fees + VAT + taxes to start with. For example a TTGO ESP32 LORA board with display + LiPo charger + SD socket is cheaper than a simple ESP32 DevkitC + lora chip thru Mouser or Farnell.

You can force the console to Bluetooth with Bluetooth.setConsole(1); Docs

Ok, looks like the 2v04 "_4mb" build crashes.
Same ESP flashed with different builds:

  VERSION: "2v01",
  GIT_COMMIT: "748a4d3",
  BOARD: "ESP8266_4MB",

-> works

  VERSION: "2v03",
  GIT_COMMIT: "e77d74f6",
  BOARD: "ESP8266_4MB"

-> works

VERSION: "2v04",
  GIT_COMMIT: "3956264e",
  BOARD: "ESP8266_4MB"

-> crashes

  VERSION: "2v04",
  GIT_COMMIT: "3956264e",
  BOARD: "ESP8266_BOARD"

-> works

(argh, forum ate a longer response, so just a short answer now:)

Works on my machine :)

My machine now includes ESP8266, ESP32, nRF52. JSON.parse(undefined) doesn't cause a reboot.
Most likely some other code either in the init or in the "regular" part of your program that causes a reboot. Some other error, or stuck in an infinite loop waiting for something that never happens because init failed (and rebooted by watchdog).

Even tried this on an ESP8266 (with save to flash)

function onInit(){
  print('@onInit');
  //throw new Error('b00');
  JSON.parse(undefined);
}

Output:

 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v01 (c) 2018 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
Flash map 4MB:1024/1024, manuf 0xef chip 0x4016
>
Running onInit()...
@onInit
Uncaught SyntaxError: Expecting a valid value, got undefined
 at line 1 col 10
undefined
         ^
in function called from system

And works just fine.

Use WSL as @Wilberforce already recommended. Or of course you can use an Ubuntu VM. You can use VS Code with the remote WSL extensions, makes modifying files much easier...

Just install WSL, VSCode, "Remote - WSL" extension

• Start a new VSCode & launch WSL
  
• open the terminal in VSCode
  
• cd ~ (if you are not there by default)
  
• git clone https://github.com/espruino/Espruino.git­
  
• Press the "Open Folder" button
  
• and follow the Linux instructions :)
  
  

One rookie mistake I did: don't try to use WSL in your regular windows file system (by default you are at something like /mnt/c/something == c:\something). Clone the Espruino repo into a WSL directory, otherwise bash scripts just went crazy.

As for debugging: AFAIK you won't be able to single step debug the Espruino code as easily as you could do from VS. There gdb, but that itself has a steep learning curve afaik.

Yes, I too struggled with this couple of times.
Than discovered there is a README_flash.txt in the ESP32 directory that shows pretty much the commands you used.
IIRC, saw somewhere that first you have to flash all parts as above, and after that you can just flash espruino_XvYY_esp32.bin to upgrade.

Actually the docs tell you to do this, but starts with building from source. So splitting Building and Flashing to separate paragraphs would be a good idea IMO. Or even better, moving the Build instructions down, and only showing the download & flashing instructions in the "Getting Started" sections would make it clearer. Maybe the docs were not updated since ESP32 builds are available...

You can always send a PR https://github.com/espruino/EspruinoDocs­/blob/master/boards/ESP32.md :)

Looks like if I disable BLE and disable Wifi, the ESP32 goes into an infinite reboot loop.

>ESP32.enableBLE(0)
...
// normal reboot
...

>ESP32.enableWifi(0)
Erasing saved code.
Done!
ets Jun  8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_d­rv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:2668
load:0x40078000,len:7304
load:0x40080000,len:5312
entry 0x40080274
E (545) spiram: SPI RAM enabled but initialization failed. Bailing out.
WARNING: Bluetooth is disabled per ESP32.enableBLE(false)
Guru Meditation Error: Core  0 panic'ed (StoreProhibited). Exception was unhandled.
Core 0 register dump:
PC      : 0x400d8b18  PS      : 0x00060b30  A0      : 0x800d915b  A1      : 0x3ffde6c0
A2      : 0x00000001  A3      : 0x00001e78  A4      : 0x00001000  A5      : 0x00000000
A6      : 0x3ffc40cc  A7      : 0x3ffd6934  A8      : 0x00000000  A9      : 0x00000001
A10     : 0x00000000  A11     : 0x0001e780  A12     : 0x00000005  A13     : 0x00000000
A14     : 0x00000000  A15     : 0x0003ffff  SAR     : 0x00000019  EXCCAUSE: 0x0000001d
EXCVADDR: 0x0000000e  LBEG    : 0x4009b418  LEND    : 0x4009b423  LCOUNT  : 0xffffffff
Backtrace: 0x400d8b18:0x3ffde6c0 0x400d9158:0x3ffde6e0 0x400f85e5:0x3ffde700
Rebooting...

// and this goes on...

Only way to recover is to erase + reflash the ESP32.

Tested with 2v01 and 2v04 with two boards:

• Generic ESP32 "dev board" chip reported by esptool: ESP32D0WDQ6 (revision 1)
  
• TTGO Lora32 v2.0 ESP32-PICO-D4 (revision 1)
  
  

Ran into this earlier, just ignored... The Chip running hot on blink sketch thread was the final push to re-test this again.
Can someone else confirm this? Any idea how to fix?

I don't have any boards right now with me, but in #4 I measured the "idle" and "blink" power consumption of ESP32 & MicroPython board.
In "idle" - connected to the REPL via USB - no code running, but ready for input, I measured 48mA.
With the "blink" code from #1 with time.sleep_ms(1000), I measured 50mA.
That's ~1/3 of Espruino's power consumption.

Looked at Espruino's ESP32 code, and as far as I can tell, Espruino does not go to sleep mode with the ESP32 port at all. In ESP32 jshardware.c jshSleep does nothing. In other boards it does a bunch of checks, and goes to sleep if nothing is going on. For example nRF52

Not sure what MicroPython does so far, and don't have a real micropython board to check their power consumption. But reading the docs, it looks like it doesn't go to sleep by default as much as an nRF Espruino, you have to explicitly send to sleep if you want to achieve really low power. "Just idles".

But what is not right: According to the ESP32 datasheet, the power consumption in "modem sleep" with dual cores running at 240MHz should be 30-68mA. (the highest without radio). MicroPython is in this range. But in my measurements Espruino by default is well over this range. Ok, I must admit, I can't reliably switch off BLE and Wifi the same time. Goes into an endless reboot loop, and only reflashing helps. (I will post the console output later).
So my hunch is the Espruino ESP32 maybe doesn't turn off the radio? Ok, probably does not make any difference if you are using Wifi...

@allObjects regarding Micropython power consumption & sleep: Maybe you missed, but EPS32 Micropython idling in it's repl did consume less power than the code with sleep (48mA vs 50mA). So it's not the sleep in the code that reduces power consumption significantly. And both was about 1/3 of Espruino's idle power consumption.

In Espruino ESP32 as far as I can tell, all tasks are pinned to the first core. You can make it run single core by setting CONFIG_FREERTOS_UNICORE=y in sdkconfig. And that's supposed to save some power. Tried to build it, but looks like the build just ignored that.
Must have edited the wrong file, because the build went on just fine, even if I added some garbage to the sdkconfig file. Where is the sdkconfig used by the build?

Moving forward: both Espruino (on other boards) and Micropython does like a dozen checks before going to sleep. That was the point when I quit :)

Oh, and there is this issue in MicroPython that shows a bug with multi-core ISRs, so it's far from trivial...

Ok, did some testing, and can confirm @Linyx's findings with the DHT22:

• MDBT42Q module (2v04) - works flawlessly
  
• ESP8266 - I have one that's been running for months without issue
  
• ESP32 (tested with 2v01 and 2v04) - doesn't work.
  
  

Checked the communication with a logic analyzer, and the DHT22 sends the right response (temperature and humidity valid, checksum ok). It's just the ESP32 can't pick up the response properly.

Anybody any idea?

Do you have a pullup resistor (4k7 - 10k) between the data and VCC?
IIRC without an external resistor, it didn't work properly with the ESP32, I think it's internal pullup resistor is not strong enough.

Oh, but I do have a power meter :) And no LED on pin 13, so the LED doesn't interfere with power measurement :)

• Holding reset: 8mA (Wroom32 devboard with CP21x serial)
  
• Espruino Wifi off & blink: 135mA (127mA over baseline)
  
• Espruino Wifi on & blink: 150mA (142mA over baseline)
  
  

142mA / 127mA is 11.8% difference, but that's probably not enough difference to get the temperature differences you reported...

After 8 minutes the ESP32 reports 38°C with 23°C ambient. What is your ambient temperature? Is it stable during the measurements?

• Micropython idle: 48mA (40mA over baseline)
  
• Micropython blink: 50mA (42mA over baseline)
  
  

Yepp, that's a significant difference! I guess python goes to sleep while Espruino on the ESP32 doesn't.

It's getting late to check arduino but if you don't have a power meter & upload the compiled sketch, I will try that tomorrow.

I ran an ESP32 for weeks without problems (after I fixed wifi disconnect and MQTT memory leak...). 65°C shouldn't be a problem for an uC. Unless it's really hot there, and gets even warmer :)
On my ESP projects, I send free memory with sensor data, so it's obvious if I have a memory leak. Helped to correlate wifi disconnects with memory leaks and that eventually lead to some fixes in the tinyMQTT library.

Back on topic:

Do you have a multimeter, or a USB power meter to check the power consumption?
First, run ESP32.enableWifi(0), because by default wifi is enabled. (The setting is saved in flash, and resets the ESP32, so just run it once, not in your onInit!)

And my second guess (absolutely not sure about it) would be that arduino and/or micropython disables the second core, while Espruino not. But it's just a guess. Haven't checked on either platform.

@Robin, I think if @pankleks doesn't have some means to measure power consumption, temperature is the second best indication of power consumption.

Something is not right, start and end is the same after the second call, and elapsed is continuously increasing. Might be some watch / timeout stuck somewhere, the DHT22 library sets timeouts in multiple places...
Try to run reset(1), remove power from the board, and run again with 10000 timeout.

As always, check you wiring. Loose wire can lead to communication errors. And the DHT22 uses a single wire bit-banged protocol, that's not as robust as for example I2C or SPI.

The DHT22 module does retry up to 10 times by default if can't communicate with the DHT22 or there is a CRC error. With 500ms delay between each retry, worst case that's over your 5000ms interval.
If you have a logic analyzer (even a <10USD one), you can check the communication for retries.
Or if not, you can log the time between the start and end:

  setInterval(function() {
    var t0 = new Date
    this.dht.read((response) => {
      var t1 = new Date()
      console.log(response)
      console.log(process.memory())
      console.log('start:', t0, 'end:', t1, 'elapsed:', t1-t0)
      console.log('_____')
    });
  }, 5000);

And if my theory is right, you will see some corelation in over 5 second communication and memory leak. Then you can either increase the interval to ~10 seconds, or you can pass in a lower retry count.

AFAIK the FLASH in process.env shows the total amount of flash on the chip. Defined in boards/BOARD_NAME.py. If I'm right, that is kind of irrelevant from the end users's perspective.

The ESP8266 has all kinds of funky flash parts, I think that's the reason there are multiple free flash regions. For STM32 and nRF parts, the free flash area is continuous.

My thoughts:

On a first-time-to-blink, it's hard to beat the web-ide, I think it's a pretty cool piece of software.
But I do agree that VSCode is powerful. I use it for most of my day-job and most of Espruino development + the Web ide REPL to tweak the code on the fly. The REPL is one of the best features of Espruino!
A nicer SVCode integration would be nice of course :)

Dunno, maybe the web ide as the default beginner option, and VSCode for advanced users? Although the web ide can do "everything", found it a bit clumsy for multiple files, and VSCode has configurable keyboard shortcuts.
Or replace codemirror with monaco editor? Probably there would be a lot of accidental complexity on that path. Also probably VSCode would have better support for multi file editing, wouldn't have to reinvent that many wheels. And a full-blown VSCode plugin would sound "bigger&better" than a "Web Ide 2.0".

ESP - I have mixed feelings: ESP8266 is severely limited IMO. Wifi handling eats up most of it's resources. But -if we ignore the security part - ppl have done great home automation projects with it.
As far as I have seen (might be wrong) even the ESP32 doesn't handle https certificates properly: Most samples I have seen just ignore verification, or hardcode certificate thumbprints & hope for the best.
But looks like there is nina-fw that turns the ESP32 into a dedicated wifi - internet chip. And does have root certificates burnt in. Better, but still can't do anything if a root cert is expired / revoked / replaced...
ESP32's Bluetooth is not 100% stable, but looks like people are "OK" with it, just restart it every day. Meh...
Also, has anyone seen a real-world use of the two cores of the ESP32?
And uses a lot of power even without wifi.

Probably boils down to resources (and money and how do you get income). For example (at least from what's visible to me) Adafruit sells microcontroller boards + Raspberries, and accessories (sensors, LEDs, actuators, radios, batteries, boxes, etc) that can be used for both. They even have their own IOT services, and board that uses an ESP32 as a communication coprocessor.
Circuit python is only supported on their boards (no ESP32 at all). I guess selling "everything" gives enough income, and standing on top of Arduino and Micro/Circuit Python gives them a lot of users.

But I guess Gordon probably knows more about business models than me.

Nice! I think if you use black background, that increases the contrast in bright daylight.
Don't know how the wiring looks now, but if it's one strip, injecting power from multiple points can increase the light output.