Replies: 3 comments 5 replies
-
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 i don't understand. From my perspective "Arduino" is one specific platform. Those Arduino specific platform functions are all included in the cppsrc folder: Lines 157 to 167 in 74e379c 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. |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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 fromsomething_arduino_something
tosomething_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?Beta Was this translation helpful? Give feedback.
All reactions