Replies: 6 comments 8 replies
-
@jreesun you read my mind on this issue. I agree this is an important move, as we run on four devices today, but rely on a single chip model, the K210. Cam H7 R2 seems to be the perfect target for next port. |
Beta Was this translation helpful? Give feedback.
-
Your child on Android: |
Beta Was this translation helpful? Give feedback.
-
As far as I remember, the Tinyseed and Stackbit commits and files are easy to isolate. I'll clean the code and try to do a BIG PR this week with everything except tiny seed and Nostr. |
Beta Was this translation helpful? Give feedback.
-
Added code and instructions to build Krux Android app on "android" branch of my fork. I think it works quite well, but could be integrated on the project in a more neat way. https://github.com/odudex/krux/blob/android/android/README.md |
Beta Was this translation helpful? Give feedback.
-
Ps: The app contains the Nostr and "Seed QR regions transcript helper" experimental features. But if we have new official releases I plan to match the app code with main code. |
Beta Was this translation helpful? Give feedback.
-
The way I did would require a change in Maixpy. I plan to re-make with rectangles so no Maixpy change is required |
Beta Was this translation helpful? Give feedback.
-
Related:
#39
#123
#161
This discussion is meant to tie together the various issues I've added in the past months and offer a more coherent vision of where I think we should try to take Krux.
I would like Krux to become something like the Linux (or perhaps Ubuntu is a better analogue) of hardware wallet firmware, an open-source device-agnostic signing "OS" you can install on any platform capable of running Micropython. Thanks to @odudex's work, we've expanded the K210-based devices that it supports, but I hope to eventually shim out the MaixPy/K210-specific modules so we can port to other platforms and not be too locked-in to any one vendor. It would be cool to reach a point where someone can come up with their own set of {board + camera + sd card reader + lcd} and either have it "Just Work" or require a small amount of dev effort to wire up their hardware.
When I made the Krux Simulator, I had to create mocks of every module that was not available under Python 3, which can be seen here:
https://github.com/selfcustody/krux/tree/develop/simulator/kruxsim/mocks
This will be a useful reference of what it should take to port Krux to other boards including ESP32, STM32, etc.
One important thing to note is that MaixPy uses OpenMV which adds the
sensor
,lcd
, andimage
modules that we use. Looking more closely at micropython, it appears they don't include baked-in camera support. Furthermore, the list of supported cameras in OpenMV is large and the project seems to be actively developed, so I think we should continue using OpenMV for now. This may mean that we should fork the openmv repo and use it as the basis for our firmware. One big gotcha with OpenMV, however, is that I believe it (currently) doesn't support ESP32 devices and is instead focused on STM32. But we can cross that bridge when we get to it.First things first, we should research and select a non-K210 board to target based on known compatibility with micropython and OpenMV and specs that would support running Krux (e.g., 2MB+ flash without firmware upgrade support, 4MB+ flash for firmware upgrade support). I'm leaning toward the OpenMV Cam H7 R2 with an LCD shield.
What do you think, @odudex? Any better options or other input on this?
Beta Was this translation helpful? Give feedback.
All reactions