Closed nucflash closed 5 years ago
It appears the ffi
module in the Unix port is a "Foreign Function Interface" library, correct?
And I'm assuming you mean this micropython-schedule library?
Yes and yes. In my understanding, micropython-schedule is internally using functools for building function partials which depends on FFI functionality.
Well, the functools in micropython/micropython-lib doesn't appear to need FFI.
You're right, my bad. Below is the error I'm getting. It seems that the time
module is choking. Have you seen this before?
import schedule
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/lib/schedule/__init__.py", line 39, in <module>
File "/lib/time.py", line 4, in <module>
ImportError: no module named 'ffi'
The time
module in micropython/micropython-lib will only work on the Unix port, because it's using FFI to access libc for the time functions.
There's a built-in µPy time
module in the ESP32 firmware. It appears that that time
module will probably work with the micropython-schedule; seems to have all the necessary functions. Should just be a matter of deleting time.py
from your ESP32 filesystem.
@dpgeorge Why do we have a "pure" Python time
library that will only work on Unix (i.e. not at all pure)? Why not a built-in C time
library?
Why do we have a "pure" Python time library that will only work on Unix
Good question! The history of the micropython-lib
repo is that it was intended to be individual add-on modules for the unix port of uPy. But over time some of the modules there have been written to target all ports of uPy (eg uasyncio, umqtt), and some other modules might work on any port because they are "pure".
ffi is not supported on esp32. To get micropython-schedule working on the esp32 would require modifying it to not rely on ffi.
Hi, I need FFI support in
ports/esp32
because I want to use themicropython-schedule
package. I tried to build commit 292816a15bda188be75f8c50936dba0b59af262c but it seems that the FFI library, which is an external dependency forports/unix
is not linked inports/esp32
. Can you confirm if this is the case, and if it is if there is a plan to support it in the future?