Add Adafruit GFX support for drawing a BMP from RAM

[rtwfroody]

I'm using this to draw icons in my application. Compiling them in is simpler than putting them on an SD card (which I don't have in my current hardware, although there is a slot for one).

Note that this change includes #43 as well, under the assumption that that will be merged first. If changes need to be made to that PR, I'll rebase this one.

[ImpulseAdventure]

This is great, Tim! Note that it may be next weekend before I get an opportunity to test it out & merge.
For reference, what devices were you targeting with this implementation? thx

[rtwfroody]

I'm using an Adafruit Feather HUZZAH 8266 with the 2.4" TFT touch screen (STMPE610 plus ILI9341).

[ImpulseAdventure]

Hi Tim -- I'd be interested in integrating this PR as it would be really useful.

However, it looks like it will break compilation for Arduino targets (eg. ATmega2560) due to the use of FS.h (which is presumably only available in the ESP8266 arduino core). I'll continue to see if I can find a way that would support the same functionality with the libraries available on Arduino targets.

It does look like one could probably create a simple RAM/FLASH based version of the DrvRead#SD(), seek() and read() routines without much overhead. I'll take a look. Thanks again for the contribution.

[rtwfroody]

Thanks for taking a look at it. I didn't realize FS.h only exists for the ESP cores. I might find some time in the future to figure out an alternative. Relatedly, you might want to set up your repo to enable travis builds (using eg. https://github.com/adafruit/travis-ci-arduino). That way this would have been flagged as soon as I created the PR, and you wouldn't have to spend your time running the build.

…

On Sat, Apr 14, 2018 at 11:56 PM, Calvin Hass ***@***.***> wrote: Hi Tim -- I'd be interested in integrating this PR as it would be really useful. However, unfortunately I noticed that it will break compilation for Arduino targets (eg. *ATmega2560*) due to the use of FS.h (which is presumably only available in the *ESP8266* arduino core). I'll continue to see if I can find a way that would support the same functionality with the libraries available on Arduino targets. It does look like one could probably create a simple RAM/FLASH based version of the DrvRead#SD(), seek() and read() routines without much overhead. I'll take a look. Thanks again for the contribution. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#44 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC9X31LC5hOP-DM7hWpYlIM0Zt2yIsNqks5tou8KgaJpZM4TFk4u> .

[ImpulseAdventure]

@rtwfroody - BTW, it looks like I had missed your travis-ci comment until now. Thanks for the good recommendation! I had actually integrated travis for the AVR targets (UNO, ATMEGA2560) earlier this year but it seems like the option to test the PRs wasn't active. I have updated the config now, so future pull requests should also flag any compilation issues. Will add other targets as well soon.

Thanks for the recommendation. Now back from vacation, I should have more time now to explore your BMP RAM-based draw proposal (using native implementation versus FS).

[ImpulseAdventure]

Once again, thank you very much Tim for implementing the initial cut of this feature for the ESP8266 platform. I have combined your work with Paul's commit to produce #101, enabling us to support both platforms without needing a platform-dependent include. Therefore, I am closing this pull request as the functionality should now be incorporated by the new PR. For reference, you can see the new example ex28_ard_btn_img_flash as guidance on the API. Thanks!