MicroPython on ESP32 with SPIRAM support

[loboris]

@OutoftheBOTS_

The problem is 32-bit Ubuntu.
The included toolchain is built for 64-bit Linux and can't work on 32-bit.
Here is what you can do:
Change the working directory to MicroPython_ESP32_psRAM_LoBo/Tools and execute:

Code: Select all

rm ver20171105.id
cd Linux
wget http://loboris.eu/ESP32/xtensa-esp32-elf_32.tar.xz
rm xtensa-esp32-elf.tar.xz
mv xtensa-esp32-elf_32.tar.xz xtensa-esp32-elf.tar.xz

Change the working directory to MicroPython_ESP32_psRAM_LoBo/MicroPython_BUILD
Execute:

Code: Select all

./BUILD menuconfig
./BUILD all

The build process should now finish without error.

When working with Linux VM without desktop it is better to access the Linux system via ssh using Putty.
In VirtualBox set the network as "Bridged adapter"
If not installed, install ssh in Ubuntu (sudo apt-get install ssh).
Check your IP address with ifconfig (you will need it for Putty)
In Putty you can set the desired screen size, and copy/paste will also be possible.
It is also recommended to set the number of processors in VirtualBox to at least 2, that way you can use -j2 (-j4) options with BUILD.sh to speed the build process.

[carsten]

I would be interested if you can give me some example application where uasyncio is better suited then threads.

I guess I can only give the obvious answers. It keeps the code a little simpler, I don't have to make it thread safe, memory footprint is smaller. I have routines that control neopixel in certain intervals. I wouldn't benefit at all from threads, it would just make the code more complicated. But for sure, most things with sockets are something I would intuitively write as a thread. Thing is, I started with an esp8266 but ran out of memory very early during development, so I had things written for uasyncio and started to like it.

On a side note, thanks a lot for your work, it's really impressive. To be honest though, I'm really hesitating to use it. For sure your esp32 port is much more advanced than the official repository but I would rather stay on the mainstream source because it has a larger developer base and is changing more conservatively. You're breaking the api, e.g. for neopixel and ntptime, that at least had some consistency between the espressif ports. In case you stopped developing, I'd be stuck with code that only works with your fork. Also, you're doing some work twice, e.g. the deepsleep and RTC code from MrSurly. Are you planning on backporting some of your work to the official branch?

[Capstan]

I'm feeling somewhat out on a limb with it too, hesitate to depend on unique features and API even if they are superior to the official repository. I'm hoping there can be a merge.

[OutoftheBOTS_]

@Loboris thanks a lot for your time especially at Christmas.

I followed your advice on getting a 32bit toolchain working but the ./BUILD.sh menuconfig failed to build.

I am at the stage that if I want to continue to learn and develop my programming skills I think that I need to have a computer running Linux. I am super busy at the moment but will hopefully get a Linux computer up[ and running for your next release in the new year.

Again thanks for your help

[pythoncoder]

I would be interested if you can give me some example application where uasyncio is better suited then threads.

From the perspective of a firmware writer cooperative multi-tasking is almost always better than pre-emptive. Not only because it uses far fewer resources (with uasyncio being particularly efficient). Nor solely because (depending on hardware) task switching occurs in times measured in a few hundred μs. The overwhelming reason is because you control precisely where in your code context switching can occur. This vastly simplifies real time programming and eliminates sources of evil bugs which crop up after months of uneventful operation. At 3am on Boxing Day when the kit is on site 200 miles away...

If you fancy some Christmas reading this is an interesting exposition of the issues.

[VisualEcho]

Here is the simplified description of available mqtt methods:

Thank you, thank you, thank you. Extremely well timed post, as I went looking for a better explanation of the MQTT module functions and found this... only to notice that it was posted two days prior. I must admit I'm getting a little used to reading the code itself for documentation.

[EasyRider]

Hello Borislav,

Have been testing simple mqtt client publish and subscribe on Lolin esp32 Pro with SPI ram.

Board crashes repeatedly with "Guru Meditation Error" at random intervals generally within 10-15 minutes.

Crash report:

• Guru Meditation Error of type LoadProhibited occurred on core 1. Exception was unhandled.
  Register dump:
  PC : 0x4013f93f PS : 0x00060a30 A0 : 0x8013f923 A1 : 0x3ffd37d0
  A2 : 0x3ffd37d0 A3 : 0x3ffd37d0 A4 : 0x3ffcbcf0 A5 : 0x3ffcbe2c
  A6 : 0x00000003 A7 : 0x3ffd3aa0 A8 : 0x8013f93f A9 : 0x3ffd37b0
  A10 : 0x00000000 A11 : 0x3ffcbdcc A12 : 0x00000000 A13 : 0x00000057
  A14 : 0x3ffcbdd4 A15 : 0x3ffd3a40
  
  SAR : 0x00000000 EXCCAUSE: 0x0000001c
  EXCVADDR: 0x0000000c LBEG : 0x40122a30 LEND : 0x40122a9a LCOUNT : 0x00000000
  
  Backtrace: 0x4013f93f:0x3ffd37d0 0x4013f920:0x3ffd3800 0x4013f920:0x3ffd3830 0x4013f920:0x3ffd3860 0x4013f920:0x3ffd3890 0x4013f920:0x3ffd38c0 0x4013f920:0x3ffd38f0 0x4013f920:0x3ffd3920 0x4013f920:0x3ffd3950 0x4013f965:0x3ffd3980 0x401230c6:0x3ffd39a0 0x40122921:0x3ffd39d0 0x40131ffb:0x3ffd39f0 0x40132a21:0x3ffd3a10 0x401454d9:0x3ffd3a30 0x40189bff:0x3ffd3a60 0x40189e69:0x3ffd3ac0 0x4018a0c0:0x3ffd3ae0
  
  CPU halted.

micropython simple mqtt test code:

Code: Select all

import network
import time
from time import sleep
from network import mqtt 
import machine


SERVER = '192.168.1.163' 
CLIENT_ID = 'ESP32_DHT22_Sensor'
TOPIC = b'LoBo_Test1'

def datacb(msg):
    print(("subscribed - ", msg))

    
wlan = network.WLAN(network.STA_IF)
wlan.active(True)
if not wlan.isconnected():
  print('connecting to network...')
  wlan.connect('RR2', '')
  while not wlan.isconnected():
    pass
  time.sleep(1)
  print('network config:', wlan.ifconfig())   
 
client = mqtt(CLIENT_ID, SERVER, data_cb=datacb)
#client.set_callback(sub_cb)

client.start()   # Connect to MQTT broker
time.sleep(2)
client.subscribe("temp_humidity")
time.sleep(3)
  

  
def run():
  cnt=0
  while True:
    cnt +=1
    c=str(cnt)
    msg = (c)
    client.publish(TOPIC, msg)  
    print("published - ",msg)
    time.sleep(1)   
    
run()

Have also tested standard micropython mqtt library (simple.py) that has also been crashing on your platform.
However this can run for a few days before crashing.

error report:

• assertion "time_after_timebase_us > s_timer
  us_per_overflow" failed: file "/home/jl/MicroPython_ESP32_psRAM_LoBo/Tools/esp-idf/components/esp32/./esp_timer_esp32.c", line 177,
  
  function: esp_timer_impl_set_alarm
  abort() was called at PC 0x4014932b on core0
  
  Backtrace: 0x4008c1f0:0x3ffaf930 0x4008c2bb:
  0x3ffaf950 0x4014932b:0x3ffaf970 0x40081e0c:
  0x3ffaf9a0 0x400d122a:0x3ffaf9c0 0x400d125f:
  0x3ffaf9e0
  
  CPU halted.

Hope that you can look into it and see what the issue is.

[slzatz]

I had at least a superficially similar problem that was fixed at Boris’ suggestion by putting gc.collect() at the end of datacb() so you may want to try that while waiting for a more definitive answer.

[EasyRider]

By adding gc.collect() at the end of datacb causes an immediate "Guru Mediation" crash.
It reads and prints first subscribed message OK and then crashes when it calls gc.collect().

Code: Select all

published -  1
('subscribed - ', ('ESP32_DHT22_Sen', 'temp_humidity', 'OFF'))
Guru Meditation Error of type LoadProhibited occurred on core  0. Exception was unhandled.
Register dump:
PC      : 0x401228f6  PS      : 0x00060030  A0      : 0x8012c3f9  A1      : 0x3ffd3970  
A2      : 0x3ffcba44  A3      : 0x3f41a878  A4      : 0x00060021  A5      : 0x00000001  
A6      : 0x00060021  A7      : 0x3ffd3aa0  A8      : 0x801228f6  A9      : 0x3ffd3950  
A10     : 0x00000000  A11     : 0x3f41a878  A12     : 0x00000000  A13     : 0x00000029  
A14     : 0x0000000a  A15     : 0x00000000  SAR     : 0x00000020  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x00000008  LBEG    : 0x4009bedd  LEND    : 0x4009beed  LCOUNT  : 0xfffffff5  

Backtrace: 0x401228f6:0x3ffd3970 0x4012c3f6:0x3ffd3990 0x4012c40b:0x3ffd39b0 0x40122935:0x3ffd39d0 0x40131fe5:0x3ffd39f0 0x40132a21:0x3ffd3a10 0x401454d9:0x3ffd3a30 0x40189bff:0x3ffd3a60 0x40189e69:0x3ffd3ac0 0x4018a0c0:0x3ffd3ae0

CPU halted.

Well, this may add another clue as to what is causing the crash?

[OutoftheBOTS_]

Ok I am getting further all the time.

I have installed 64bit Ubuntu on another laptop and successfully ran menuconfig and then built and flashed the firmware to ESP32 board.

I logged onto the board with my windows PC using putty serail and everything worked fine. I enabled AP and connected to it with my windows PC. I ran the code "network.telnet.start()" and it returned True.

I have tried to connect to the ESP32 at 192.168.4.1 using both WinSCP and FileZilla using your settings in your docs but it returns Connection attempt failed with "ECONNREFUSED - Connection refused by server".