MicroPython on ESP32 with SPIRAM support

All ESP32 boards running MicroPython.
Target audience: MicroPython users with an ESP32 board.
OutoftheBOTS_
Posts: 847
Joined: Mon Nov 20, 2017 10:18 am

Re: MicroPython on ESP32 with SPIRAM support

Post by OutoftheBOTS_ » Thu Mar 01, 2018 8:23 pm

@tuupola

Just a question on your MPU9250 driver. Does your driver read the raw data from the raw data registers or does it read the data after the calibration has been added from the FIFO register??

User avatar
on4aa
Posts: 70
Joined: Sat Nov 11, 2017 8:41 pm
Location: Europe
Contact:

Re: MicroPython on ESP32 with SPIRAM support

Post by on4aa » Thu Mar 01, 2018 9:06 pm

I would like to deepsleep an M5Stack and wake it on button B or C press.
I am even not sure whether this is possible. Here is what I tried:

import machine
from machine import Pin
rtc = machine.RTC()
rtc.wake_on_ext0(Pin(38), 0)
rtc.wake_on_ext1(Pin(39), 0)

With this, I get the following error:
TypeError: object 'Pin' is not a tuple or list

Thank you in advance for all helpful clues!
Serge

loboris
Posts: 344
Joined: Fri Oct 02, 2015 6:19 pm

Re: MicroPython on ESP32 with SPIRAM support

Post by loboris » Thu Mar 01, 2018 10:48 pm

on4aa wrote:
Thu Mar 01, 2018 9:06 pm
rtc.wake_on_ext1(Pin(39), 0)

With this, I get the following error:
TypeError: object 'Pin' is not a tuple or list
Wakeup on ext0 works for level on the single defined pin

Wakeup on ext1 works on multiple pins.
If the wakeup level is set to 0, all the pins must be at low level to wake up.
If the wakeup level is set to 1, any pin at high level will wake up.

rtc.wake_on_ext1() expects tuple of one or more pins as first argument, see the example.

I'm sorry the documentation is not clear about this. I'll update it as soon as possible.

M5Stack wakes up when buttons A&C are pressed.

Code: Select all

>>> import machine
>>> from machine import Pin
>>> rtc = machine.RTC()
>>> rtc.wake_on_ext1((Pin(37),Pin(39)), 0)
>>> machine.deepsleep(0)
ESP32: DEEP SLEEP
ets Jun  8 2016 00:22:57

rst:0x5 (DEEPSLEEP_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
...
...
FreeRTOS running on BOTH CORES, MicroPython task running on both cores.
Running from Factory partition starting at 0x10000, [MicroPython].
 
 Reset reason: Deepsleep wake-up
Wakeup source: EXT_1 wake-up
    uPY stack: 19456 bytes
     uPY heap: 3073664/6096/3067568 bytes (in SPIRAM using heap_caps_malloc)

MicroPython ESP32_LoBo_v3.1.20 - 2017-02-28 on ESP32 board with ESP32
Type "help()" for more information.
>>> 

User avatar
on4aa
Posts: 70
Joined: Sat Nov 11, 2017 8:41 pm
Location: Europe
Contact:

Re: MicroPython on ESP32 with SPIRAM support

Post by on4aa » Fri Mar 02, 2018 12:06 am

loboris wrote:
Thu Mar 01, 2018 10:48 pm
I'm sorry the documentation is not clear about this. I'll update it as soon as possible.
Thank you for the additional deepsleep information, Boris.
The M5Stack goes into deepsleep now and is awakened by either of two buttons I defined.

Code: Select all

rtc = machine.RTC()
rtc.wake_on_ext0(Pin(38), 0)
rtc.wake_on_ext1((Pin(37),), 0)
machine.deepsleep(0)
The only issue now is that upon awakening, these two buttons have lost their original callback interrupt function they once had before entering deepsleep.
I tried remedying this with below code, but to no avail:

Code: Select all

rtc.wake_on_ext0(None)
rtc.wake_on_ext1(None)
I also tried:

Code: Select all

if machine.wake_reason() == 3:
    del rtc
For your information, I am using tuupola's M5Stack «kitchen sink» button input functions for use with Loboris MicroPython.

So, I still need a little help to deal with this lost functionality. Thanks!
Serge

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

MPU9250

Post by pythoncoder » Fri Mar 02, 2018 8:07 am

It might be of interest that there is an established driver from this chip here which includes support for magnetometer calibration. This is vital in real-world applications. It also supports vector transposition and scaling and sensor fusion using the Madgwick algorithm.
Peter Hinch
Index to my micropython libraries.

User avatar
tuupola
Posts: 54
Joined: Sun Sep 17, 2017 12:10 am
Contact:

Re: MicroPython on ESP32 with SPIRAM support

Post by tuupola » Fri Mar 02, 2018 8:27 am

Mine actually does support both hard and soft iron bias correction. The class methods to calculate those values are not included yet though. Been pondering about the best way to do it.

I did my version mostly for two reason. It was a nice exercise to learn Python. I also have a bit different programming style, for example I believe I2C sensor drivers only responsibility is to provide access to the sensor data.

OutoftheBOTS_
Posts: 847
Joined: Mon Nov 20, 2017 10:18 am

Re: MicroPython on ESP32 with SPIRAM support

Post by OutoftheBOTS_ » Fri Mar 02, 2018 11:01 am

It is also important to calibrate the gyro (although called gyro it is a centrifugal force sensor that allows for a software gyro to be created). When you sit the sensor still and read the gyro you will find it won't read exactly zero even though it is still. To create a software gyro you measure the angular speed (centrifugal forces) at a high freq and multiply it by the time between each poll. Any error will acculate very fast and cause very high gyro drift. There needs to be an offset applied to the gyro sensor data so that it will read zero when still. This offset will change as the temp of the sensor changes. The MPU9250 has a MCU on board that will read internal temp senor then scale the offset in the offset register then add it to the raw data then place it in FIFO register. For accurate calibrated data you need to read it from the FIFO register. Alos be aware the FIFO register fills up fast so if your not polling FIFO fast enough then it will over flow and no longer store the data till you read the old data out.

User avatar
on4aa
Posts: 70
Joined: Sat Nov 11, 2017 8:41 pm
Location: Europe
Contact:

Re: MicroPython on ESP32 with SPIRAM support

Post by on4aa » Fri Mar 02, 2018 11:07 pm

It is great to see the many conversations in this single thread!
However, I am starting to wonder if it were not better for Loboris MicroPython to have its very own subsection in this forum.
This would provide an overview to the many subtopics.

For example, currently I have some useful information to add to a subtopic discussed ten pages ago.
I refrain from doing so, because that would mess up the ongoing conversations…
Serge

OutoftheBOTS_
Posts: 847
Joined: Mon Nov 20, 2017 10:18 am

Re: MicroPython on ESP32 with SPIRAM support

Post by OutoftheBOTS_ » Sat Mar 03, 2018 5:38 am

As laboris keeps adding more and more features it is likely to end up with even more multiple topics being discussed at once.

Since I haven't yet learnt to use github yet I am nor sure what discussions is happening there.

To my understanding the development of the official port of MP for ESP32 is slow compared to this port and at the rate laboris is adding new features it is just becoming a widening gap between the capabilities and docs of the 2 ports, this seems to be leading to more and more users opting to use this port over the official port.

My understanding is also all the MP code is written by volunteers. So to me it doesn't seem logical to have people volunteering their time on the official port instead is there any discussion around laboris port becoming the official port??

OutoftheBOTS_
Posts: 847
Joined: Mon Nov 20, 2017 10:18 am

Re: MicroPython on ESP32 with SPIRAM support

Post by OutoftheBOTS_ » Sat Mar 03, 2018 5:55 am

@laboris

Is I2C like SPI and can use HW I2C bus on any Pin or only certain pins??

I can't seem to find any docs on HW I2C just the esp8266 docs for SW I2C

I am starting to port across some of my robot projects from RPi to ESP32 and many of them use I2C sensors. Since making a custom dev board is so easy with the Wrover module. I am going to make custom PCBs with sensors on them for each robot so that I don't need a number of boards connected together via jumper wires but the down side is the wiring will be how the PCB is designed and won't be able to changed like when using jumper wires.

Post Reply