need your help with esp logging

[h-milz]

I would like to (mis-) use this fork to add WPA2 Enterprise to Micropython. This basically involves implementing and exposing the esp_eap_client functions. I added the code to lib/micropython/ports/esp32/network_wlan.c and wpa_supplicant to the IDF_COMPONENTS.

Connecting to the university eduroam network works fine in EAP-PWD mode with the username and password only, similar to the proposed setting for Android smartphones:

Connecting to eduroam using proto "EAP-PWD"
..
Connected:
('10.183.110.103', '255.255.240.0', '10.183.111.254', '10.156.33.53')

Insofar, works for me. But I would also like to get EAP-PEAP to work which involves using the supplied CA certificate and the anonymous identity. This is is how our laptops are usually configured using the CAT installer (https://cat.eduroam.org/). The supplied configuration works on Ubuntu 24.04 using Networkmanager or wpa_supplicant.

However, on my Micropython build, I get STAT_WRONG_PASSWORD consistently, and I need to switch on wpa_supplicant debugging and monitor the stuff in order to find where the handshake breaks. And this I can't seem to get going.

esp_log_level_set("wpa_supplicant", ESP_LOG_DEBUG);

is set in my code, and I also set

CONFIG_WPA_SUPPLICANT_DEBUG=y
CONFIG_WPA_SUPPLICANT_DEBUG_LEVEL=0

in sdkconfig.board.

Question: how do I see the esp logs on the Micropython level? Or do I need to write a custom C program in order to access the low level stuff?

TIA!

[h-milz]

Update: I'm now using the esp-idf wifi example, don't bother.

[h-milz]

OK, EAP-PEAP works with the example code. Now I've got to see how I use this in my patch mentioned above :-)

[kdschlosser]

as far as the ESP32 compilation is concerned. You do not need to add anything to the sdkconfig file. all of the config settings are able to be set at the command line. If you add --debug to the build command this will turn on debugging for the ESP32 and you can add the additional CONFIG_* parameters to the build command as well.

The build scripts do quite a bit of "hot patching" of the MicroPython source and header files. so you need to take care as to what you are modifying because it can potentially break the build system. I know I am not specifically doing anything to the source files for the wlan stuff what you might consider doing is creating a module that you add to the build system that hot patches the MicroPython files with the changes that you want. This will make it easier for you when updating the binding to a more recent version of it because you will not have to go in and make all of the modifications again, You can simply copy the one python source file and edit the esp32 build script to include your file. The build system is written so that if a file is modified a backup of the original gets made and once the build has finished that backup gets restored keeping the state of micropython as original. The "readfile" and "writefile" functions are what handle doing that. I recommend that you use those to keep the state original. This is done because not all changes made are universal across all MCU's so if you wanted to compile for a different MCU you know you will be starting off with unaltered source files for that MCU.

[h-milz]

Ah, thank your for pointing this out. I'll try this tomorrow.

In fact I'm trying to get EAP stable enough to take a PR upstream. ATM I use your build system as an extremely helpful test bed for building the image because I failed miserably to build an image from vanilla Micropython. :-(

[kdschlosser]

Yeah it took me a while to figure out how to compile vanilla MicroPython.

I tried to handle most of it in that build script. If you need me to I can tear the script down so it will only compile for vanilla MicroPython without making changes that are specific to LVGL.

[kdschlosser]

I also highly doubt that any form of my build system would be added to MicroPython. They are pretty resistant to any kind of a change to their current build system even with their current build system is not user friendly and it is not cross platform.

The folks over at espressif have been working on getting the ESP-IDF so it is easier to use under Windows. If they manage to get rid of the need to use mingw then they can integrate into VS and VSCode without having all kinds of crazy setup that needs to be done.

The problem with MicroPython's build system is it's reliance on makefile and makefile is NOT cross platform. I have tried all of the windows binaries that have been compiled for makefile and none of them are 100% compatible with the posix binaries, That is the one thing that cmake does a far better job of. cmake can still be a headache to use cross platform because the compiler commands are not the same and changes need to be made based on the platform being compiled on.

[h-milz]

By the way I finally found the root cause of my problem. It is described in my follow-up to https://github.com/orgs/micropython/discussions/16456, resulting in my pull request to add WPA2 Enterprise wifi. Whohoo!

[h-milz]

Well then the blame is theirs. In this case I'll set it up as a user C module documented how to use it. It's what people have been asking for for years. The project will have to explain why they don't do it.

If I had an stm32 board and more savvy of the SDK I might actually see if I could get this done. Don't think it's rocket science either.

[kdschlosser]

when dealing with the STM32 it is damned close to rocket science. There isn't much in the way of an SDK. It's mostly macros that you have to use to bit shift with to control registers and aspects of the hardware. It's all really low level kind of stuff. No real user friendly API so to speak. And trying to use their "SDK/IDE" is a joke. It is made of of a bunch of different applications that are kind of hodgepodged together and make zero sense trying to use it.

[h-milz]

Yep. As far as wifi, there is no in-house solution anyway. Most boards seem to use CYW43 or even ESP32 daughter boards connected with SPI or SDIO - not exactly the best performance idea. For neither of these, there appears to be any WPA2 Enterprise API (as opposed to ESP-IDF which is very straightforward). So - the STM32 and Pico W crowds have nothing unless someone "ports" ESP32's esp_eap_client.c. The biggest scam is esp_hosted. It brags about various enterprise and wpa3 features by exposing the corresponding constants but looking at the source code for 5 seconds tells you that there is nothing - look at https://github.com/micropython/micropython/blob/master/drivers%2Fesp-hosted%2Fesp_hosted_wifi.c :538. The security arg is explicitly not used, and there are no args for the relevant parameters of wpa2 enterprise.

For a connected IoT application, I'd choose ESP32 anytime.

[kdschlosser]

there is a downside to using the ESP-IDF, it's fat. it uses up a lot of extra resources to run. It comes at a cost of both RAM and flash. Flash is not so much of an issue with the ESP32 but RAM is. SPIRAM helps but the reality is it is vastly slower than internal memory. The other downside is processor overhead. While the ESP32 does have dual cores which can alleviate some of that issue using both cores adds a very large amount of code complexity especially when dealing with ISR's. That is one of the things I have had to deal with in the RGB driver.

[kdschlosser]

I have a display sitting here on my desk that uses the I8080 bus and is a really off the wall kind of a design. It uses an RA8876 IC. That IC is design I believe is going to become more commonplace. It's is not just a bridge IC with GRAM like most of the ILI and ST type IC's. It is a bridge and also a 2D accelerator. It is able to do the rendering. There is another piece thrown into the mix. There is an MIPI to RGB bridge in there as well and that has to be set up using 3wire SPI. So what you have is the 2D accelerator which allows for connection to the MCU as I8080 or SPI. That IC sends out data to the display using MIPI and there is an MIPI to RGB bridge that takes the MIPI data and handles the actual panel sending the RGB data.

I would love to be able to use the 2D accelerator portion of the display IC as that would really offload a lot of work from the MCU. Problem is LVGL is not written in a manner that makes it extensible so adding a new renderer to it means I would need to make a custom version of LVGL. This is less than ideal. LVGL should have been written in a manner where the rendered functions got pointed to using macros. Those macros would be overridden by a custom renderer. As an example, the IC I am working with doesn't support all types of rendering functions. So I would want to fill the gaps with the software renderer. So I would need to get the software renderer added and then the functions that the IC does cover I would have to override the software renderers functions. That is what is not able to be done currently. So in order to make it work I would need to make copies of the software functions to make a complete renderer and that is plain silly to do.

I am able to still use the display without using the 2D accelerator portions but doing that means I lose the ability to rotate. So currently I am stripping the software rotation out of the RGB driver and adding it so it is able to be used by any bus type. doing this requires a lot of careful planning because unlike the RGB Bus the other busses need to send commands to the display and the bus drivers in the ESP-IDF are not thread safe. Having commands sending from one core at the same time as pixel data is being sent from the other can cause issues.