-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support using the bitmap device in the Arduino library #2486
base: master
Are you sure you want to change the base?
Support using the bitmap device in the Arduino library #2486
Conversation
This moves the TGA export code into a new file called u8x8_d_bitmap_tga.c, which removes the stdio.h dependency from u8x8_d_bitmap.c (making that file compilable on microcontroller targets as well). This slightly reworks the TGA export code so it uses the external bitmap device API instead of reading directly from the global u8x8_bitmap struct. This also moves u8x8_d_bitmap.c into csrc, so it is included in all builds (including the Arduino build).
This prevents warnings when directories already exist and creates parent directories as needed.
nice idea, so you just output the bitmap as a x/blank ASCII art, correct? |
hmmm isn't this very similar to https://github.com/olikraus/u8g2/wiki/u8g2reference#writebufferxbm |
Yeah, that's just a way to actually do something with the pixel data, but the point of the example is to show how to access the raw pixels.
In a way, but that outputs XBM format, without accessing the pixels programmatically. However, reading onwards, I see: https://github.com/olikraus/u8g2/wiki/u8g2reference#direct-access-buffer-api Which is an API to directly access the rendering buffer tiles/pixels, which would actually also work perfectly for my usecase. Thinking on this a bit more, I actually wonder what the point of the "bitmap" device is - u8g2 already keeps a buffer containing all pixels, which is then copied to another buffer inside the "bitmap" device, but there does not really seem to be any point (and it needs twice the memory). I would say this could just as well use a "dummy" device (that just throws away pixels) and then use the above buffer API to access the upper buffer directly - for this example, but also for the non-arduino examples that use the bitmap device currently for TGA output (there could also be a simple TGA output function that reads from the buffer like writeBufferXBM does). I wonder if/why we did not think about this when we worked on the bitmap device a few years ago... |
hmmm... you have removed the TGA write procedures, but those are needed for the automatic image generation. |
They are not removed, but split off from the bitmap backend. They are still here: https://github.com/matthijskooijman/u8g2/blob/509954977b2d40c34dfc6f7a9a696910b93d88cd/sys/bitmap/common/u8x8_d_bitmap_tga.c This does mean that TGA generation is not available in the Arduino version, but TGA is probably not relevant there anyway (and this particular implementation relies on stdio.h, which is not available in all architectures IIRC.
The hello_world and cimg_annotate_screenshot examples still work for me. Is there something else that you think will break? |
I will move this topic... |
The header files in
csrc
andcppsrc
contained various declarations related to the bitmap device backend (e..g theu8g2_SetupBitmap
function and theU8G2_BITMAP
class), but the definitions of those were insys/bitmap/u8x8_d_bitmap.c
and thus not included in default builds and in particular not the Arduino library.This moves this code into
csrc
, leaving behind the TGA export code that relies on stdio.h, to make this bitmap backend usable in the Arduino library. It also adds an example for how to use this code in the Arduino library.I tested:
Makefile.184.uno
, an unpacked Arduino 1.8.4 tarball and an offical Uno R3.arduino-cli
, thearduino:avr
core version 1.8.5 after generating an Arduino library withtools/release/arduino/create_release.sh
sys/bitmap
The Arduino example sketch outputs the following: