Thoughts on integrating (full) ESP-IDF support into u8g2?

[v1993]

It's been over four years since my last attempt at doing this - needless to say, quite a bit has changed in the meantime. I think I'd like to give this another shot, without trying to change nearly as much stuff as my old attempt did (not sure if you even remember it, four years is quite a while).

Notably, C++ headers now (mostly?) #ifdef away arduino-specific stuff, making it much easier to port C++ parts of u8g2 to other MCUs supporting it, which is something I'm definitely going for with ESP-IDF port. I still have actual HAL code laying around, so adapting C parts to updated ESP-IDF and u8g2 shouldn't be overly hard - it also has an advantage over implementation linked in documentation in that it uses pins passed from u8g2 instead of introducing a separate function for this purpose - this also allows to control multiple displays at once.

One thing I'd like to discuss are names for HAL functions. Right now, C++ (U8G2 and U8X8) constructors all have a line like

u8g2_Setup_st7565_ea_dogm132_2(&u8g2, rotation, u8x8_byte_arduino_hw_spi, u8x8_gpio_and_delay_arduino);

While the entire block of constructors can be used as-is on an entirely different MCU platform (as long as U8X8_USE_PINS is defined), it would require naming HAL functions like they are on arduino, which barely makes sense. What do you think about changing their names from something_arduino_something to something_platform_something so that it stays reasonable even with a different HAL? I.e. u8x8_byte_platform_hw_spi, u8x8_gpio_and_delay_platform, etc.:

u8g2_Setup_st7565_ea_dogm132_2(&u8g2, rotation, u8x8_byte_platform_hw_spi, u8x8_gpio_and_delay_platform);

This still conveys that function in question is platform-specific - so someone seeing it in a linker error will have a clue what they're missing. I'm curious what your opinion on this would be here.

Also, just to be sure I'm getting this right: platform-specific things (build system aside) should go into sys/esp-idf, correct?

[olikraus]

Hi, yes very much remember our discussion and I am always happy seeing you as an u8g2 expert providing answers to the users here in issues or discussions blog. :-)

First... let me ask a basic question for my understanding:

Currenlty ESP can be used within Arduino IDE by using https://github.com/espressif/arduino-esp32
This approach should already work with u8g2.
Question: Your approach is to use u8g2 wiht https://github.com/espressif/esp-idf without the Arduino Core libraries, correct?

What do you think about changing their names from something_arduino_something to something_platform_something so that it stays reasonable even with a different HAL? I.e. u8x8_byte_platform_hw_spi, u8x8_gpio_and_delay_platform, etc.:

This i don't understand. From my perspective "Arduino" is one specific platform. Those Arduino specific platform functions are all included in the cppsrc folder:

u8g2/cppsrc/U8x8lib.h

Lines 157 to 167 in 74e379c

	extern "C" uint8_t u8x8_gpio_and_delay_arduino(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr);
	extern "C" uint8_t u8x8_byte_arduino_8bit_8080mode(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr);
	extern "C" uint8_t u8x8_byte_arduino_4wire_sw_spi(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr);
	extern "C" uint8_t u8x8_byte_arduino_3wire_sw_spi(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr);
	extern "C" uint8_t u8x8_byte_arduino_3wire_hw_spi(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr);
	extern "C" uint8_t u8x8_byte_arduino_hw_spi(u8x8_t *u8g2, uint8_t msg, uint8_t arg_int, void *arg_ptr);
	extern "C" uint8_t u8x8_byte_arduino_2nd_hw_spi(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr); /* #244 */
	extern "C" uint8_t u8x8_byte_arduino_sw_i2c(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr);
	extern "C" uint8_t u8x8_byte_arduino_hw_i2c(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr);
	extern "C" uint8_t u8x8_byte_arduino_2nd_hw_i2c(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr);
	extern "C" uint8_t u8x8_byte_arduino_ks0108(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr);

Of course it would be more consistent if that "cppsrc" would would be moved to "sys/arduino", but I guess thats more an historical thing.

So yes, using "someting_esp_idf_something" would make sense and also using "sys/esp-idf" should be fine.

For me U8g2 started to eat up too much of my spare time, so I am currently trying to reduce effort. Especially I try to focus on Arduino platform only.

[v1993]

Hi, yes very much remember our discussion and I am always happy seeing you as an u8g2 expert providing answers to the users here in issues or discussions blog. :-)

Really, it's just that I'm watching this repo to have a kind of positive filler content in my email and happen to remember a bit of u8g2 stuff from all the way back when I messed with embedded - which I'm happy to use to occasionally help others.

Question: Your approach is to use u8g2 wiht espressif/esp-idf without the Arduino Core libraries, correct?

Yes, that's exactly what my idea is. It's been a real while, but I'm pretty sure ESP-IDF implementation of HW SPI had a massive speed advantage over that of arduino compatibility layer. Plus it's just generally nice to avoid bringing in extra dependencies - especially massive ones like a whole compatibility layer that loves to interfere with other components.

Of course it would be more consistent if that "cppsrc" would would be moved to "sys/arduino", but I guess thats more an historical thing.

Interesting... What I'd very much like to see is full C++ support in ESP-IDF port since ESP-IDF has great - and I mean C++23 great - C++ support. This ideally should include autogenerated "constructors", which is where calls to platform-specific functions come in. Files in cppsrc already do a pretty good job at ifdefing away Arduino-specific stuff with those functions seemingly remaining the only big blocker to that.

What I'm proposing is to actually use names like u8x8_gpio_and_delay_platform - without substituting platform for platform name. Then just leave it to build system to link to files that implement those functions. It's worth noting that the header you've quoted does not hide those symbols behind #ifdef ARDUINO while its corresponding cpp file does - which means that all one needs to do on non-arduino platform is implement those functions with C linkage and they'd have full C++ support. Technically, it's already possible - as long as one calls their functions, well, u8x8_gpio_and_delay_arduino and such - but those names obviously make no sense on other platforms, thus my suggestion to standardize them as _platform functions instead.

This has a drawback of not being able to use two different HALs at once, but I'm not sure it that's something to worry about anyways. If it is, you can name functions in platform-specific ways and have #ifdefed block of wrappers/aliases that use just platform instead of platform name.

I'd like to know if you have a better idea in mind. Another possibility (I think, I've been living happily outside of preprocessor hell for a while) is to set platform name via macros - something like

#ifndef U8G2_PLATFORM
#define U8G2_PLATFORM arduino
#endif

#define U8X8_GPIO_AND_DELAY u8x8_gpio_and_delay_ ## U8G2_PLATFORM
#define U8X8_BYTE_HW_SPI u8x8_byte_ ## U8G2_PLATFORM ## _hw_spi
...

// In constructor
u8g2_Setup_st7565_ea_dogm132_2(&u8g2, rotation, U8X8_BYTE_HW_SPI, U8X8_GPIO_AND_DELAY);

Then it's up to platform's build system to define U8G2_PLATFORM - which should be easy enough. Although I'm not quite sure how to deal with possible (and even likely) absence of certain callbacks, especially software fallbacks (although, come to think of it, this applies to the other method as well).

[olikraus]

I would say most of my current time goes into JavaScript and SQL development :-p

I also somehow feel, that I skipped most of the latest C++ technology. So basically I am a child of the pre-C++ development, where inheritance and abstraction was implemented with callback functions. This is also where those plattform functions came from:
They are just there to isolate the hardware dependency. And of course it was the goal to get rid of the #ifdef nightmare, which was there in predecessor u8glib.

I think your idea is the question on how to implement a modern C++ API for different platforms.
The point is: I might not have the required knowledge for this. And even more worse, I don't have time to think in this direction.
Solving my own small embedded problems, currently brings me more towards MUI, the u8g2 integrated user interface. I mean, supporting multiple platforms is not a goal for me, instead I think more about the creation of a user interface in my embedded devices. Making the code more cleaner and flexible is great but it currently doesn't solve my needs ;-)

So... I somehow don't know what to answer here.

[v1993]

While modern C++ is great, the problem I'm facing is more about finding out how to nicely allow C++ interface to call different HAL implementations. If you don't have a strong opinion on this I'll probably go ahead and spend some time pondering possible solutions to see which one would work the best.

[cjones6108]

I know this might be kind of a dated discussion, but I just happen to be looking at the issue. I'm trying to use the U8g2 library on an ESP32 in the ESP-IDF environment, without using the Arduino component. I'd rather stay completely away from the Arduino stuff simply because that's a completely different micro-controller and not what I'm using. Looks like it shouldn't be that difficult to get it to compile, but alas, I've not had any success. It works fine in straight C, but I'm getting linker errors when I switch to C++. Anybody given this any more thought?

[olikraus]

The linker errors are probably caused by the fact, that a c++ compiler encodes the argument types into the function name (https://en.wikipedia.org/wiki/Name_mangling).

There are two solutions for this:

1. Compile EVERYTHING (.c and .cc files) with a C++ compiler
2. Compile the u8g2 .c files with a normal c compiler, but incapsulate the include statement into 'extern "C"' for your C++ code so that C++ knows that the u8g2 functions are compiled with a C compiler:

/* C++ Code */
extern "C" {
#include "u8g2.h"
}

See also: https://stackoverflow.com/questions/67894/why-do-we-need-extern-c-include-foo-h-in-c

[cjones6108]

Yes, that seemed to do it. I just wrapped the U8G2 includes in an extern block and it compiled and ran without complaint. Now if I could only get my head wrapped around all this C/C++ stuff. . .

Thanks