Compiling with btree module support

All ESP32 boards running MicroPython.
Target audience: MicroPython users with an ESP32 board.
User avatar
RobH
Posts: 91
Joined: Fri Mar 23, 2018 3:37 pm
Location: Netherlands
Contact:

Re: Compiling with btree module support

Post by RobH » Sat Apr 10, 2021 5:51 pm

When I run make (for the generic esp32) with the current sources I get the following message:

Code: Select all

/home/rob/micropython/extmod/modbtree.c:37:10: fatal error: db.h: No such file or directory
 #include <db.h>
          ^~~~~~
compilation terminated.
I didn't see that before. Could it be related to the btree module (changes)?

marcidy
Posts: 133
Joined: Sat Dec 12, 2020 11:07 pm

Re: Compiling with btree module support

Post by marcidy » Sat Apr 10, 2021 6:23 pm

yeah, it is. Did you make clean before hand? which commit are you using?

User avatar
RobH
Posts: 91
Joined: Fri Mar 23, 2018 3:37 pm
Location: Netherlands
Contact:

Re: Compiling with btree module support

Post by RobH » Sat Apr 10, 2021 7:21 pm

No, I didn't make clean. But even after that I got the same error message.
I'm not sure what you mean by 'which commit'! I just did a git pull which reports 'already up to date'.
And makes for PyBoard 1.1 and Blackpill run flawlessly: "v1.14-152-g6f06dcaee"

marcidy
Posts: 133
Joined: Sat Dec 12, 2020 11:07 pm

Re: Compiling with btree module support

Post by marcidy » Sat Apr 10, 2021 8:05 pm

"a commit" in git terms is a identifier which points to a specific snapshot of the git history.

For example, master always is the most recent commit, but if I pulled master yesterday and you pulled today, you'd have an updated version of the code. We can speak about the exact same version of the code on git by referencing commits.

To see it, you can use the git log function. Here's an example.

Code: Select all

$ git log

commit 6f06dcaee57cc6f36a4121b4797942200b2d7281 (HEAD -> master, origin/master, origin/HEAD)
Author: robert-hh <robert@hammelrath.com>
Date:   Wed Mar 17 07:57:27 2021 +0100

    rp2/moduos: Implement uos.urandom().
    
    The implementation samples rosc.randombits at a frequency lower than the
    oscillator frequency.  This gives better random values.  In addition, for
    an 8-bit value 8 samples are taken and fed through a 8-bit CRC,
    distributing the sampling over the byte.  The resulting sampling rate is
    about 120k/sec.
    
    The RNG does not include testing of error conditions, like the ROSC being
    in sync with the sampling or completely failing.  Making the interim value
    static causes it to perform a little bit better in short sync or drop-out
    situations.
    
    The output of uos.urandom() performs well with the NIST800-22 test suite.
    In my trial it passed all tests of the sts 2.1.2 test suite.  I also ran a
    test of the random data with the Common Criteria test suite AIS 31, and it
    passed all tests too.

commit 2c9af1c1d7398bb340f7c78601be6ed2d79ee0b8
Author: Damien George <damien@micropython.org>
Date:   Mon Mar 15 16:42:58 2021 +1100

    rp2/rp2_pio: Validate state machine frequency in constructor.
    
    Fixes issue #7025.
    
    Signed-off-by: Damien George <damien@micropython.org>

commit 42035e5eded531d41319ffde999fa5a97478c872
Author: Santeri Paavolainen <santtu@iki.fi>
Date:   Wed Feb 24 10:33:26 2021 +0200

    examples/embedding: Fix example so it compiles again.
    
    There were a few changes that had broken this example, specifically
    2cdf1d25f59409b6130c0e8b6cf50300aed2d7e6 removed file.c from ports/unix.
    And (at least for MacOS) mp_state_ctx must be placed in the BSS with
    -fno-common so it is visible to the linker.
    
    Signed-off-by: Santeri Paavolainen <santtu@iki.fi>
Note the (long) identifier after the word "commit", These identifiers can be shorted to a few characters, e.g. "commit 6f06dc" is short hand for "commit 6f06dcaee57cc6f36a4121b4797942200b2d7281"

It's possible to check out that specific commit and look at that specific version of the repo with "git checkout 42035e".


I just checked out master @ 6f06dc (latest as of this post), and build the firmware for esp32 with "make", it worked OK for me, the firmware built fine and i was able to use btree.

I suggest completely remove any directory starting with "build" (including "build") in the port/esp32 directory, and try using make again. Since I cannot reproduce the issue, it's most likely something on your local machine.

edit: My git refs were off, making the entire point of my example confusing. Sorry, updated them.

User avatar
RobH
Posts: 91
Joined: Fri Mar 23, 2018 3:37 pm
Location: Netherlands
Contact:

Re: Compiling with btree module support

Post by RobH » Sun Apr 11, 2021 8:31 am

Thank you for the explanation of 'commit'!

Following your suggestion I removed the build-GENERIC directory (the only one in micropython/ports/esp32 with leading 'build'), but still the same error.

Then I had a closer look at the console log and noticed the following:
Git submodule components/bt/controller/lib is out of date. Run 'git
submodule update --init --recursive' to fix.
That resulted in a lot of cloning activity, and these warnings were gone.
But the make still produces the same error (missing <db.h>). Where is this file supposed to reside?

EDIT:Last line: not true, but now other errors:
Linking CXX executable micropython.elf
... esp-idf/esp_wifi/libesp_wifi.a(phy_init.c.obj):(.literal.esp_phy_disable+0x10): undefined reference to `phy_dig_reg_backup'
... esp-idf/esp_wifi/libesp_wifi.a(phy_init.c.obj): in function `phy_digital_regs_store':
/home/rob/esp/esp-idf/components/esp_wifi/src/phy_init.c:207: undefined reference to `phy_dig_reg_backup'
... esp-idf/esp_wifi/libesp_wifi.a(phy_init.c.obj): in function `esp_phy_enable':
/home/rob/esp/esp-idf/components/esp_wifi/src/phy_init.c:240: undefined reference to `phy_dig_reg_backup'

marcidy
Posts: 133
Joined: Sat Dec 12, 2020 11:07 pm

Re: Compiling with btree module support

Post by marcidy » Sun Apr 11, 2021 3:14 pm

well, that's not due to btree. Did you update esp-idf to a compatible version? see this thread:

viewtopic.php?f=18&t=9820

If you don't have any local modifications, you might want to just delete esp-idf and micropython and restart from scratch. Sometimes that's the fastest way to a clean build.

User avatar
RobH
Posts: 91
Joined: Fri Mar 23, 2018 3:37 pm
Location: Netherlands
Contact:

Re: Compiling with btree module support

Post by RobH » Sun Apr 11, 2021 6:37 pm

OK! I removed esp-idf, re-installed it and now the make runs without errors and apparently produces a working firmware.bin!
Maybe I have a different IDF version now than before which might be the reason for the link-problem.
Thanks for your prompt help!

Post Reply