@macsbug Thanks for the tip I will give it a shot. The short demo video looks promising as I see a gauge that looks great. I have similar results with the Sprite library but fall short on compositing sprites past pushRotated.

Thanks

Hi all, I have been using the M5Stack library which incorporates the TFT_eSPI library to some degree to allow sprites to be easily used in graphics. I have noticed that not all commands are available, specifically "pushToSprite" to allow me to composite multiple sprites past the "pushRotated" command.

General Question: Has anyone successfully updated the M5Stack Sprite.h and Sprite.cpp to include more current version of the TFT_eSPI library?

I have tried to add these from the TFT_eSPI Sprite.cpp and Sprite.h but am falling a bit short on my knowledge on how to handle the errors I get compiling. When I copy the needed code over to the M5Stack library I am not able to compile and get errors surrounding other commands which I didn't touch. For example when I copy over the code for pushToSprite and created i then get errors with the number of arguments it is looking for as well as errors with other calls such as pushImage, which were fine before.

These are the libraries I want to use(update some commands in M5Stack).

https://github.com/Bodmer/TFT_eSPI/blob/master/Extensions/Sprite.h
https://github.com/Bodmer/TFT_eSPI/blob/master/Extensions/Sprite.cpp

Rather than post my hack attempt I was hoping someone could offer some guidance on how to update these libraries used in M5Stack and maybe why not all of the library was included in the first place?

Thanks!

I was looking for info about updated the Sprite.h and Sprite.cpp in the M5stack library to include more commands in the TFT_eSPI library. did you ever play with this rather than defining the TFT_eSPI library?

Well if you got as far as you did you have already installed the ESP32 boards so you can pick the correct one. I assume the core basic does still use the "M5Stack-Core-ESP32" board.

https://github.com/m5stack/m5stack

This link shows the documentation for the Grey(which I am using) and the Basic.

I can't translate all the warnings you got but the last part seems to indicate it isn't pointing to the correct config.h(or it can't find it). Config.h, i believe, is the library that is handling defining all the pins used in the stack. So without it the board has no idea what is going on.

Are you able to open other sample arduino sketches and select something like an UNO and compile just fine?

I wish I could help more. The only thing I can suggest is to step through the setup once again.

https://docs.m5stack.com/en/quick_start/m5core/arduino

I am not entirely sure with those warnings but I would start by going into the library manager in the arduino IDE and make sure the M5 stack library is updated along with all other libraries it needs.

Is this true with all examples? Try the Factory Test example to see if it compiles or just HelloWorld.

What are you trying to do? There are loads of examples but if you are trying to build something specific that might help. I did a beginner 3.5hr video on doing a gps based speedo and talk about some basic graphics, text display and getting GPS using the TinyGPS++ library. not sure if that is what you are looking for. https://youtu.be/xlb7FGKBp3Q

@ajb2k3 Sure, I am still learning and figuring a few things out so I want to explore all options first before I write anything other than a forum reply. I plan to make a few videos of it on my YT channel. I cover mostly CAD topics but have a GPS speedo using sprites and was exploring using BMPs. https://youtu.be/SUAqVUN9AuQ

@f3l1x I know this is an OLD topic listed as solved but I came across it having the same issue. I didn't feel it was actually solved so I wanted to chime in with what I found.

First in the M5Stack.h it lists an RGBBitmap function but that isn't actually available. You can push an RGB bitmap just using M5.Lcd.drawBitmap though.

Getting a BMP converted to the appropriate code took a bit of work to find a format that made the Ardunio ide happy but here is what I found.
If you are using a monochrome image and image2cpp you want to use the Arduino code output format and the draw mode as Horizontal - 2 bytes per pixel(565). The 565 is the RGB format that is required. If you use that format the image will be defined using a const uint16_t which will work just fine.
https://javl.github.io/image2cpp/

For a color image you will need to use something else. I ended up going with https://sourceforge.net/projects/lcd-image-converter/ but do a search and find something that is right for you. The trick here again comes down to the options and format. I used Color scanning from Top to Bottom and in the forward direction. Again it is important to use the R5G6B5 preset to make sure the hex is proper for the code. Also make sure to use 16bit block size. 16bit isn't needed for BW or monochrome images but still can be used at the expensive of more memory. If you are using 16bit for BW images you will see this 0x0000, 0xffff. 8 bit would suffice for those leaving you with 2 less characters.

When you are using a color bmp then 16 bit is needed. You will still have the same number of characters but will see something more like this 0xf7be, 0xef7d, 0xdefc, Each represents a color and I found that 16bit was needed for what I was doing.

Some other points of contention. Some of the image converters and examples will use different variable types. For the drawBitmap I found that it wanted the file as a "short" (as per some of the examples) or uint16_t. If you get an error just look at what the function is expecting to see.

The image you displayed with the funky colors I found to happen when the width and height values in drawBitmap don't match the actual bitmap. If your image is 32 x 32 (1024 pixels), then your call to drawBitmap should match that. If it doesn't you will see the result you are looking for. I haven't found a good way to scale things in the code but hopefully that will get someone else who comes across this ancient thread a point in the right direction.

Also for whatever its worth it is much easier to call the images from SD than to go through all this hassle unless you have a good reason for it. This process took way longer to figure out than I would have liked which is why I wanted to respond. I have done this before on monochrome displays without issues but the color bmp on the M5 gave me a headache:)

hope it helps.

I mistaking posted this in core2, but wanted to chime back in as I have it working. Still not sure how to get the right port with my gray but if someone finds this I wanted to link the solution.

https://127.0.0.1:6060/topic/3217/hardwareserial-ss-2-uart-connection-on-16-17-for-a-gps-antenna

Ok, here is the simple program I came up with using the TinyGPS++ library. Hopefully It will help someone else who comes across this same problem. I still don't know what I can do to access the correct GROOVE port since the M5 base is for Core2, but at least I have a temp solution to keep developing my project.

The complete program below works on my Core Gray with pins connecting my AT6550 to 5v, gnd, 16 and 17 on the core. This uses lat, long and speed on a simple display that is easy to read.

#include <M5Stack.h>
#include <TinyGPS++.h>

static const uint32_t GPSBaud = 9600;

TinyGPSPlus gps;

HardwareSerial ss(2);

void setup() {
M5.begin();
M5.Power.begin();
ss.begin(GPSBaud, SERIAL_8N1, 16, 17);
M5.Lcd.setTextSize(4);
M5.Lcd.setCursor(40,10);
M5.Lcd.println("Simple GPS");
M5.Lcd.println("_____________");

}

void loop() {

while (ss.available() > 0)
gps.encode(ss.read());

M5.Lcd.setTextSize(3);

M5.Lcd.setCursor(0,100);
M5.Lcd.printf("Lat: ");
M5.Lcd.setCursor(100,100);
M5.Lcd.print(gps.location.lat(), 6);

M5.Lcd.setCursor(0,150);
M5.Lcd.printf("Lon: ");
M5.Lcd.setCursor(100,150);
M5.Lcd.print(gps.location.lng(), 6);

M5.Lcd.setCursor(0,200);
M5.Lcd.printf("MPH ");
M5.Lcd.setCursor(100,200);
M5.Lcd.print(gps.speed.mph());

}