Building Krux for Maix Bit

[odudex]

Hi, I'm adventuring on trying to build krux for a Maix Bit board with camera and display. Its cheaper, but from the same "family" from M5sitckV.
I'm new to uPython and got stuck in a probably simple issue. I'm using the "maixpy_k210" project/firmware from MaixPy instead of "maixpy_m5stickv", and run krux docker scripts to gather all necessary files from build in a SD card. But it won't run because it doesn't find "io" module.
My question is: Should "io" module be embedded in firmware/uPython interpreter or should it be with other krux files? What am I missing?

[ghost]

Welcome!

The io module is baked into the firmware as a Micropython module (written in C). The Krux python files under src used to be kept separate from the firmware and placed on the root of a microSD card, but recently this was changed so that the python files could be baked into the firmware. With this change, you technically no longer need an SD card at all if you're fine with flashing new updates. Or, you can now drop the firmware file on the card and reboot the device to do a completely airgapped upgrade. Anyway, at this point the SD card no longer has python files stored on it.

So, this leads me to believe you're working with older code. If it's very old (several months), there used to only be a uio module until an alias was added in the firmware for io back in August. It's possible if you're using old code that this is what you're running into.

If you've gotten to the point of successfully flashing the firmware to the device and getting to the REPL (I'm assuming you're using something like screen to see this output?), you should be able to send an interrupt Ctrl+C to drop into the interpreter where you can try importing the io module manually with import io to verify if it's there.

Backing up a bit, there are a lot of issues you're likely to run into at the moment trying to get it to work on a different device. I've spent some time the past few weeks trying to make changes to get it to run on other devices like the Maix Amigo, but those changes haven't landed in main just yet and ended up being more extensive than I initially thought they would be. Here are the problems you're likely to run into:

1. The builtin_py and compile folders of the other projects don't have the changes that were made in the maixpy_m5stickv project, but you can mostly get around this by just copying the changed files over.
2. The Dockerfile and krux script both assume you're building the maixpy_m5stickv project, so that also needs to be updated. I'm leaning toward making DEVICE an argument in the Dockerfile that defaults to maixpy_m5stickv but can be overridden when you call krux.
3. The pins for the M5StickV are likely not the same as those for the Maix Bit, which could affect the ability to read from the SD card or write to the display. These pins need to be baked into the firmware. It seems the way Maixpy does it is with the main.cpp file. You can look at the maixpy_amigo_tft project's file to see how they're overriding the SD card pins for example.
4. The Krux python files have some hard-coded assumptions such as:
   • In display.py, the procedure to initialize the LCD is specific to the M5StickV. This should be done in the firmware code but wasn't for some reason. Ideally, you'd be able to just run lcd.init() and have it work, but that isn't the case yet..
   • In input.py, the code expects there to be a board module (from the builtin_py folder) with a board_info object that has BUTTON_A and BUTTON_B keys, but that's only the case for M5StickV. Those names are just aliases for the specific pin numbers which are likely different on other devices.
   • In light.py, it's assumed there is a LED_W key corresponding to the pin for a white LED which at least in the Amigo's case doesn't exist
5. The Maix Bit doesn't seem to have buttons available for input (Krux needs two buttons separate from the power/reset button(s)). I'm only seeing that it has reboot and power buttons. So, I think you'd need to add your own and set the appropriate pin numbers there too.

Sorry about the wall of text, I just wanted to give you appropriate warning about how difficult this will be to do right now. I'm hoping to push up my branch with those changes in the next few weeks. Right now my focus is on getting a stable Version 1.0.0 of Krux with test coverage out the door, then I'm hoping to come back to this. I would at least like for Krux to support the Maix Amigo and the Maix Cube moving forward (since they have all the necessary parts), with the ability for DIYers like yourself to make more custom builds like this without too much extra effort.

[odudex]

First, thanks for all the explanations!
Yes it seems the alias was added to the "maixpy_m5sitckV" firmware, but I was working with a different one, the "maixpy_k210". I replaced "io" with "uio" and it moved on. Now it asking for "flash" module which also seems is not par of k210 firmware. Tried menuconfig but there wasn't options to bake this item. These Chinese tool-chains are quite messy.
Also tried m5sitckV firmware on bit board, changed display size and frequency, but probably pinout is also different, because it didn't work too.
I'm debugging output from minicom, or miniterm. Tried to setup a custom environment and also your vagrant setup.
To add buttons, or even a rotary encoder was in my plans, I intend to do it after I succeed on running it, then I would design and print a case for it. My goal is to help lower the price, could be a ~U$30 device. But now board prices are increasing.

[odudex]

Found a typo on krux/firmware/MaixPy/components/drivers/flash/include/w25qxx.h that didn't let me compile flash.c
line 93 is: w25qxx_status_t w25qxx_64k_block_erase(uint32_t addr);
should be: w25qxx_status_t w25qxx_64k_block_erase_dma(uint32_t addr);

[ghost]

it seems the alias was added to the "maixpy_m5sitckV" firmware, but I was working with a different one, the "maixpy_k210". I replaced "io" with "uio" and it moved on

This is strange, the alias was made in a place where I would expect it to affect all the projects. I'll have to look into it more to make sure.

These Chinese tool-chains are quite messy.

Yes, and MaixPy has deviated a fair amount from standard Micropython unfortunately. I recently explored a cleaner alternative, Micropython for K210 by Lobo, however it's missing a lot of functionality + modules used by this project (in particular, OpenMV) and it isn't actively maintained, so I decided to just stick with MaixPy for now. Hoping to chip away at it over time though!

To add buttons, or even a rotary encoder was in my plans

That would be awesome!

then I would design and print a case for it.

That would also be awesome!

By the way, have you gotten Krux running on a M5StickV and used it yet? And if so, have you had a chance to use the thermal printer attachment for printing QR codes? The reason I ask is I've been wanting to figure out a design that could combine Adafruit's "Thermal Printer Guts" with the M5StickV (or a device like the Maix Bit if we can get it working) so that you could have a neatly packaged all-in-one device capable of printing QRs--ideally with a rechargeable battery pack that could power both devices--but such a thing is currently beyond my abilities :)

My goal is to help lower the price, could be a ~U$30 device

I think you can still get some of the M5StickV's for ~$30-40 depending on the distributor, but point taken! The prices will probably end up reaching $50 eventually once those distributors sell their current supplies.

Found a typo on krux/firmware/MaixPy/components/drivers/flash/include/w25qxx.h

Good catch! If you make a PR, I'll merge it. Otherwise, I'll incorporate it into the branch I'm working in right now and it should (hopefully) make its way into main in 1-2 weeks

[odudex]

I don't have a M5stickV, I thought it would be easier to use the Maix bit, but it is not.
I'm thinking about buying one. Could also buy a printer and pack them with a 18650 lithium cell and charger. That's within my abilities, I've already build a Raspiblitz full node with integrated battery as UPS (it's in my GitHub page). I thought as Maix bit is already only "guts" it would be more cost effective to join it with other modules e build an unique little monster. But the code uses a lot of M5's specifics, so maybe it is simpler to just get one and grab its guts.

[odudex]

I just remembered something about thermal paper that maybe you aren't aware off. Thermal printed stuff fade away pretty easily.

[ghost]

That's true, it does fade easily. I think that's fine for certain use cases (thinking of PSBTs), but obviously not great for seed backups. What I want to explore more, though, is printing QRs on stickers (thermal paper with adhesive on the back side) and putting these stickers on steel plates so that you can hole punch a recreation of one, similar to what is being doing here:
https://twitter.com/SeedMint21/status/1465428957847867408

[odudex]

The sticker seems a good idea! I just ordered a M5sitckV, will take a while to arrive, after that I intend to contribute more

[odudex]

Made some progress, its running. Pic1, Pic2
Now have to add buttons and make some adjustments.
Learned that Bit board may even have some advantages such as parallel bus display(faster)

[ghost]

Awesome, great job getting that to work! Seeing that first picture is a good motivator to work on a (new) proper icon for Krux that can render on vertical and horizontal displays, haha.

Does the camera work as-is?

[odudex]

Seems this display inits by default on landscape, so to "fix" it a rotated it to portrait after init. I saw you used lcd.init() to put in portrait, so I also modified that to: self.rotation(1) instead. obs. self.rotation(0) mess things up. Now it looks like this
Camera works out of the box, as well as the display. No register needs to be set, its just init() an go.
Buttons and LED are also working(with different GPIOs).
I did a lot of attempts do make it work, but after my M5stick i will try to summarize and make some code that minimally changes your source, maybe with a simple definition we can make your hole setup work for both boards.

[ghost]

Wow, that really came together a lot quicker than I expected. Nice job!

Make sure you check out my changes in the tests branch (#74), and ideally branch your changes from that one for your PR so we don't have too many collisions. In it, I refactored the various maixpy project folders and changed how the board.py files are defined so that they now include a krux.pins key mapping the names that the Krux python files expect to find to the specific pins for that device. The rest of the data in those JSON configs are essentially the untouched versions that MaixPy puts in their upstream repo. In those configs, they also include an lcd section specifying the orientation (dir) of the screen that we could leverage to solve the initial display orientation problem you ran into.

In my tests branch I've already updated the Krux side of things to look for those new config keys, like this:
https://github.com/jreesun/krux/blob/524547c936c26e938b1be8941e121d10f93b2472/src/krux/display.py#L49-L50

Also, I added a DEVICE arg to the Dockerfile (and as a CLI param to the krux script) for building so that you can point it to the right project folder when building now.

So, from the sounds of it, your changes should (hopefully) all fit within the confines of a new maixpy_maixbit folder and some tweaks to that display.py file to end up with the right orientation 🙏

[odudex]

Designing a case for Maix Bit, does it resemble a krux?
https://twitter.com/odudex/status/1473641970262228997
Encoder and printer are still in plans for 2022

[ghost]

@odudex I just wanted to notify you that I ran into a regression in the tests branch that was causing the firmware not to run when flashed to the device. Sorry if you ran into this! I've pushed up a new commit to the tests branch that fixes this, among other things (a9d60cf)

[odudex]

Hi Jeff, I received my M5STICKV and did got into the dead import error, but was able to fix it. Nice you fixed it and did all those other improvements. I hope I get some free time soon to familiarize with the code and hopefully do some contribution on a neat way to port it for other boards

[odudex]

Running the same code!
1642097819864-01

[ghost]

Woot woot! Looking good.

I've been wondering, how do QR codes look on the larger screen?

[odudex]

Have some work to do in the QR codes
Probably have some more issues.

Also found you uses sys.exc_info in "logging.py"
You should add in (~line 180) of:
firmware/MaixPy/components/micropython/port/include/mpconfigport.h
#define MICROPY_PY_SYS_EXC_INFO (1)

[odudex]

Jeff, you might take a look and test run my "tests" branch. Besides improving Bit compatibility I added a cool feature (the "loading" text at boot was a test) that complement your "autocomplete" function, I disable "impossible letters" to speed up a lot seed typing.

[ghost]

Great! I'll try to check it out this week or next (and hopefully get that tests branch merged). Sorry for the delayed response!

[ghost]

@odudex Planning on incorporating your "impossible letters" work! Do you want me to backport it myself or wait for your PR?

[odudex]

Nice!
As I'm a Github newbie too, let me try to create a clean PR with only "impossible letters", without some "junk code" and other things I was tinkering on my commits. If I don't manage to do it than backport it.
Talking about other things, I think I finally managed to understand the Maixpy font size and its limitations. I'm working on fonts for better use of bigger displays. I also ordered a Maix Amigo, so a third device will be running Krux soon.

[ghost]

Hey @odudex, in my most recent PR, I forked https://github.com/sipeed/MaixPy from commit sipeed/MaixPy@8972141 and made my fork a submodule at firmware/MaixPy in Krux now.

As recommended by Giszmo, I consolidated all my changes into one commit to make an audit easier:
selfcustody/MaixPy@90b61f7

As part of that work, I decided to minimize my changes to sipeed's version by leaving in "dead" or unused code, instead opting to update all the projects' config_defaults.mk files to disable all unused modules, in many cases adding new configs to allow me to do that. I figure this will make it a lot easier to update to new releases of MaixPy in the future by keeping my changes to a minimum.

Also, I had to create a fork of micropython as well, again with my changes in one commit for easier auditing:
selfcustody/micropython@9b9d109

Finally, I took our discussion here about fonts into account and made a change to how Krux's default font is baked into the firmware:
I added a (simple) step to the build process where just before building a project, any files and directories under a project's compile/overrides folder are merged into firmware/MaixPy. You'll notice every project now has a compile/overrides/components/micropython/port/src/omv/img/font.c file.

This should give you the ability to add a new font.c under your maixpy_maixbit project with a larger font. I'm thinking you could then add krux.font: { width: x, height: y } to board.py's JSON and pull that in in display.py for the font width / height calculations. Since you have more devices to test with than me at this point, I'm going to leave that for you to figure out though! I just wanted to make it easier for you on the firmware side of things to be able to do that. Let me know what you think!

PS: I know it's probably been a nightmare to stay up to date with my changes the past few weeks; thank you for your patience! 😅

[odudex]

Hi @jreesun! Don't worry about the changes, I'll catch them up. It has been great for learning about uPython and bitcoin signing, which is my main goal here. My impression is the project is getting better more organized fast.
Last week I didn't do anything. I'll receive my Maix Amigo probably by the and of this week than it will be a good opportunity to update from your most recent PR at the same time I do and test the port. I'm also baking some ideas to make good use of Amigo's touch screen(I know I need to check how much of the touch support have been removed).
My priorities, in order, will be:

• Port Krux to Amigo and use with side buttons (page and enter)
• Implement up/previous button
• Take a look and try to improve font size
• Implement touch screen for menus and keypads
  Let's see how it goes.

[ghost]

I'm also baking some ideas to make good use of Amigo's touch screen(I know I need to check how much of the touch support have been removed).

As part of this work, the touchscreen module(s) I had removed are now back. From CMakeLists.txt:

    # touch screen
    if(CONFIG_MAIXPY_TOUCH_SCREEN_ENABLE)
        list(APPEND ADD_INCLUDE "${mpy_port_dir}/src/touchscreen/include"
                                )
        append_srcs_dir(ADD_SRCS "port/src/touchscreen")
        if(CONFIG_MAIXPY_TOUCH_SCREEN_DRIVER_NS2009)
            list(APPEND ADD_INCLUDE "${mpy_port_dir}/src/touchscreen/ns2009/include")
            append_srcs_dir(ADD_SRCS "port/src/touchscreen/ns2009")
        endif()
        if(CONFIG_MAIXPY_TOUCH_SCREEN_DRIVER_FT52XX)
            list(APPEND ADD_INCLUDE "${mpy_port_dir}/src/touchscreen/ft52xx"
                                    "${mpy_port_dir}/src/touchscreen/ns2009/include")
            append_srcs_dir(ADD_SRCS "port/src/touchscreen/ft52xx")
            append_srcs_dir(ADD_SRCS "port/src/touchscreen/ns2009")
        endif()
    endif()

Hope that makes it easier!

Excited to see your stuff come down the pipeline; I'd love to see Krux (officially) running on multiple devices 😄

[odudex]

Nice, sure it will be easier!
I believe Amigo will bring more people on board.