You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Move away from Sipeed's custom MaixPy fork of MicroPython so that the project won't be so tightly tied to the M5StickV / M5Stack.
The longer-term goal here is to move Krux toward platform independence so that eventually it could run on any of MicroPython's supported architectures
EDIT: I think there are two ways to approach this: 1) add shims to ports to give them a "maixpy-like" set of modules that Krux can use, or 2) find a way to add shims to MaixPy so that Krux code can be rewritten to rely on standard micropython modules.
The text was updated successfully, but these errors were encountered:
Note that these mocks were also for Micropython modules that are not found in Python 3, so the actual set of MaixPy-specific logic that would need to be ported is smaller.
EDIT: I should probably refer to these as "shims" in this context, even though they make use of Python's "mock" module...
Move away from Sipeed's custom MaixPy fork of MicroPython so that the project won't be so tightly tied to the M5StickV / M5Stack.
The longer-term goal here is to move Krux toward platform independence so that eventually it could run on any of MicroPython's supported architectures
EDIT: I think there are two ways to approach this: 1) add shims to ports to give them a "maixpy-like" set of modules that Krux can use, or 2) find a way to add shims to MaixPy so that Krux code can be rewritten to rely on standard micropython modules.
The text was updated successfully, but these errors were encountered: