MicroPython on ESP32 with SPIRAM support

[loboris]

@OutoftheBOTS_

Thanks for reporting the telent AP issue. I've fixed it, it will be pushed with today's update.

del sys.modules['my_module'] does free the heap.
sys.modules.pop("my_module") does not. The method actually returns the module object, so you should execute:

Code: Select all

mdl = sys.modules.pop("my_module")
del mdl

to free it.

@pythoncoder
Thanks for the hint. Maybe I could add the reload function it to the automatically generated boot.py.

[Roberthh]

@loboris Happy new year, and good success in your life and work.
You have chosen to run both SPIRAM and flash at 40MHz. Was there a specific reason in doing that, like better reliability?
The reason why I am asking: I have two LOLIN32 pro boards with the ESP32 Wrover module. One of them runs fin with 80MHz flash frequency, the other crashes from time to time, which is after 15 min to several hours. That is with the Pycom firmware. When using your image, the crashing device runs stable.
Interestingly, In your build the clock signal has rise/fall times of about 4 ns, with a clear capacitive load, whereas in the pycom build the rise/fall times are below 1.5 ns. It seems that they somehow activated a stronger driver.

[OutoftheBOTS_]

Yes I was thinking something like that in boot.py

Now I have only been programming in python less than a year so am still learning lots. (i.e first time I have seen __import__() funtion)

Would something like this be better??

Code: Select all

from sys import modules
def reload(mod_name):
  del sys.modules[mod_name]
  return __import__(mod_name)

what is the advantage of using mod_name = mod.__name__ and not just using the string passed to the function???

Also should we add garbage collection to this fuction after the del sys.modules[mod_name] or is this done automatically??

[loboris]

... You have chosen to run both SPIRAM and flash at 40MHz. Was there a specific reason in doing that, like better reliability? ...

Happy new year.
Running both SPIRAM and flash at 40MHz is only the default configuration, to make shure it will run on all boards.
You can, of course, configure the system to run at different frequencies. I'm always running with Flash (in qio mode) & SPIRAM at 80MHz to get the fastest operation.
The only limit is, if you run SPIRAM at 80 MHz (the Flash in that case must also run at 80 MHz), the VSPI_HOST will not be available, as it used by SPIRAM.

I didn't touch any of the esp-idf functions related to clock generation. I think there were some changes in the latest commits. I'll push an update today which uses the latest esp-idf, you may check if there are some changes.

[pythoncoder]

...what is the advantage of using mod_name = mod.__name__ and not just using the string passed to the function???...

The object passed to reload is a module not a string. So you call it with

Code: Select all

reload(my_module)

rather than

Code: Select all

reload("my_module")

The idea is to replicate the behaviour of the reload function in the Python standard library.

As for garbage collection it would do no harm.

[loboris]

what is the advantage of using mod_name = mod.__name__ and not just using the string passed to the function???
Also should we add garbage collection to this fuction after the del sys.modules[mod_name] or is this done automatically??

You can import the module under different name:

Code: Select all

import module_name as zzz

Code: Select all

del sys.modules['zzz']

will fail, but

Code: Select all

del sys.modules[zzz.__name__]

will pass.

Garbage collection will be executed automaticall when needed. If you have SPIRAM and several MB of free heap, it will probably never be executed, unless you set the lower treshold ( gc.threshold() ).
You can use gc.mem_free() and gc.mem_alloc() to decide if you want to manually run gc.collect().

[OutoftheBOTS_]

@pythoncoder

Thanks for the explanation. i understand now that you don't pass a string containing the name of the module but rather pass a pointer to the module its self. Again I learn something new

I think that I might add gc.collect() to my function just to keep memory clean especially since since my style of coding and debugging will require lots of reloading.

[OutoftheBOTS_]

PWM??
How high a freq can the ESP32 do??

I am not sure that I am reading the ESP32 datasheet properly but it seems to imply that the LED PWM can go as high as 80MHz.

My experimentation with this firmware is that it will do PWM up to 78KHz.

The reason that I ask is that I am playing with quadrature encoders today and I want to compare the count from an external counter LS7366R to what the software will count on the GPIO pins. I did try to use my quadrature encoders on the ESP8266 but at any higher speeds than about 700 signals/sec it would start to miss counting pulses. Toi make the LS7366R work it needs a 40Mhz clock signal and I can't buy a 40Mhz crystal locally so was wanting to create it with the ESP, is this possible or will I have to just till I can order in a 40MHz crystal??

My encoder has 11 poles/revolution with a 31:1 gerabox on the motor, this means 11*31*4=1364 total signals per revolution. The LS7366R running at 3.3v in low speed will count signals at 20Mhz where as with the ESP8266 it could only do about 700Hz.

[dhylands]

I think that you can use any frequency (upto 40Mhz) with the LS7366R. The datasheet says max 20 MHz for 3V operation and the example in the datasheet shows a 30 MHz crystal.

Using a lower frequency crystal will impact the maximum frequency quadrature signal that you can capture. A quick look suggests that as long as the crystal is about 10x the full quadrature frequency that you want then you should be good.

[OutoftheBOTS_]

@dhylands

Thanks. I have some 16MHz crystals around here so will use them and that will be plenty high enough freq for what I want to count. No I will have to workout the caps to go with it and I should be in business.