In the GAP8 firmware, in test.c, there are printf statements used. How can one see the printf logging? In particular, is this possible using the Olimex JTAG adapter or is some other adapter needed?
In the ESP32 firmware, logging also has been used, e.g., ESP_LOGI(...). How can one see those messages? What hardware (if not the Olimex) is required?
For the ESP32 the only option right now is to get the UART on IO1 on the expansion connector, unfortunately we haven't had the time to re-implement the path ESP32->CF21->CF client console yet.
For the GAP8 there's more options. The quickest is to get the UART on UART1 RX on the expansion connector or to use the semi-hosting via JTAG. The semi-hosting can be enabled by setting
Code: Select all
Code: Select all
The ESP is compiled with the maximum level of DEBUG and you can set the levels for each module in the code (link to code). Note that having a lot of printouts will effect the performance noticable (the uart is pretty slow).
The current idea is to implement a way for both the ESP32 and the GAP8 to print to the client console, but we haven't gotten there yet.
Thanks again, especially for all the details.
I've also been trying to debug NINA and just noticed the latest commit to the examples: https://github.com/bitcraze/aideck-esp- ... c0e4caa7e3 in which console printing is removed
What was the reason for this? Incompatability with the new CPX routing?
The change was made because we needed a clean commit for production. We're currently finalizing a new batch of AI-decks where we've replaced the old WiFi streamer example with the new code (for both ESP32 and GAP8). Having the UART output on IO1 would risk creating incompatibilities with other decks.
The goal is to do the logging via CPX (using the target CF and function LOG) which will print information on the Crazyflie console. But this functionality doesn't exist yet so I think being able to log via IO1 is still needed (we use it while developing). I'll revert back the change for now and then figure out a good way to have this configurable instead.
I agree that using CPX-based console logging is the optimal way for production, but being able to use the UART can still be useful for debugging/developing (at least for now). Maybe having this configurable as well as the logging levels as a Kconfig option would be a nice-to-have
I will try flashing the latest version and see if i can manage to debug the NINA and will let you know how it goes!