Posts made by Shift1313

@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());

}

@felmue said in HardwareSerial ss(2)? UART connection on 16/17 for a GPS Antenna:

Hello @Shift1313

I think you are very close, just get rid of the Serial.begin(115200); when you add M5.begin() and M5.Power.begin().

There is another Serial.begin() inside M5.begin() and ESP32 doesn't like it when the same serial port is initialized twice.

Good luck!

Thanks
Felix

Thanks Felix! I did get it working yesterday without the serial.begin like you said but didn't understand why that was the case. I thought this would be the simple part!

I'm going to work on a simple example I hope and post it back here.

Thanks again!

Slight update. On a hunch I ran the code over the serial monitor and I am pulling in data. The same code that is giving me results in the serial monitor is having issues when i try to initialize the M5Stack display.

The code i grabbed was the "KitchenSink" from the TinyGPS++ library. This was originally setup for SoftwareSerial so I tweaked it to this.

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

static const uint32_t GPSBaud = 9600;
#define RX_PIN 16
#define TX_PIN 17

// The TinyGPS++ object
TinyGPSPlus gps;

HardwareSerial ss(2);

// For stats that happen every 5 seconds
unsigned long last = 0UL;

void setup()
{
Serial.begin(115200);
ss.begin(GPSBaud, SERIAL_8N1, RX_PIN, TX_PIN);**

Something happens when i try to initialize the M5stack though. If i put M5.begin, or M5.Power.begin() in the code it doesn't seem to work.

So what "wires" are getting crossed here? It is reading data and showing on the serial monitor without .begin() on the M5 just fine, but i can't get it to initialize and show me the location on the display.

Thanks.

I still haven't had any luck cracking this one. Does anyone know if there is a difference from the way the M5GO bottom accesses 16/17 for RxTx vs just connecting to those pins that are open? I can't imaging there would be some difference to the way those pins are defined. I assumed the HardwareSerial ss(2) is calling those pins.

I am hoping someone can clear up some confusion for me about the way to access/use pins 16/17 on my Grey.

Simple Question: How do I use HardwareSerial with pins 16/17 to communicate with a GPS antenna?

More about what I am doing and have tried:

I am trying to use the AT6558 GPS Unit with my grey realizing that it doesn't have the correct GROOVE port without the M5GO Bottom 2. So I have hooked it up to 5v/GND and pins 16/17, but I am still not getting any data transfer. I believe the issue might be with the approach.

Using the sample code as a guide I am declaring HardwareSerial ss(2). I haven't found documentation on what (0) and (2) are but I assume they are for the different GROOVE ports, 2 being "C", and 0 being "A". Is that correct?

In my setup() I have tried various things to initialize including
Serial2.begin(19200, SERIAL_8N1, RX_PIN, TX_PIN) //I defined the rx and tx pins earlier as 16/17
ss.begin(GPSBaud, SERIAL_8N1, RX_PIN, TX_PIN) // I tried this based on some forum posts I found. the GPSBaud is9600 per the Unit's product page.
ss.begin(GPSBaud)

I have tried both Serial2.begin and ss.begin(GPSBaud) in the same sketch, tried just the ss.begin with the additional info and also just the ss.begin(GPSBaud). Nothing seems to make any difference. The rest of my code is just trying to pull Lat/lon and if tried using the TinyGPS++ examples to pull just the basics as well as some other methods with TinyGPS sending some NMEA data pulling RMCONLY which i have used in the past on other GPS modules and projects.

So I believe my issue comes down to actually declaring pin 16/17. I thought using HardwareSerial(2) would automatically declare those pins, but when i dug into some of the libraries, specifically M5LoRa i found that the default SS pin is 6 and is declared in the SPISettings.

I know that was long winded but hopefully makes sense.

Thanks for any and all feedback!

Thanks for the reply ajb2k3!

The gray i have is standard, no additional base/modules. It had everything i needed except GPS which is why I got the Unit before noticing the GROOVE connector wasn't UART. 16/17 are clearly marked on the base I was just hoping for a clean/durable connection between the GPS Unit and the Core that the dupont connectors wouldn't provide.

Ill give the unit a test jumpering it to 16/17/5v/gnd on the dupont connectors.

I haven't tried this but in the .h file there is something called Speaker.setBeep . That might just work.

in the M5Stack.h file there is this.

Speaker:
    M5.Speaker.tone(uint32_t freq);
    M5.Speaker.tone(freq, time);
    M5.Speaker.beep();
    M5.Speaker.setBeep(uint16_t frequency, uint16_t duration);
    M5.Speaker.mute();

And if you open up the example "FactoryTest" there is a section in the code that uses dacWrite to the speaker pin.

void startupLogo() {
static uint8_t brightness, pre_brightness;
uint32_t length = strlen((char*)m5stack_startup_music);
M5.Lcd.setBrightness(0);
M5.Lcd.pushImage(0, 0, 320, 240, (uint16_t *)gImage_logoM5);
for(int i=0; i<length; i++) {
dacWrite(SPEAKER_PIN, m5stack_startup_music[i]>>2);
delayMicroseconds(40);
brightness = (i/157);
if(pre_brightness != brightness) {
pre_brightness = brightness;
M5.Lcd.setBrightness(brightness);
}
}

The startup_music.c is found on another tab when you open the example code.

// SAMPLES: 40000,
// BITSPERSAMPLE: 8,
// CHANNELS: 1,
// SAMPLERATE: 20000,
// NORMALIZED: FALSE,
const unsigned char m5stack_startup_music[] = {

Lots of HEX here*

Hi all, this is my first post here as I haven't been able to find this info anywhere else. I recently purchase a Core2 Gray for use with a GPS/IMU project. I also purchased the AT6558 GPS unit because it appeared to just plug right in(or so I thought).

Documentation on the GPS shows a pinmap with GROVE C on the M5Core which is RX(16), TX(17), 5V and GND. It has that lining up with TX,RX,5v, GND on the GPS. https://docs.m5stack.com/#/en/unit/gps

So my GROVE port is red so A? The documentation when I bought this said "You can plug it into the Grove port C on an M5 Core. I guess I am/was confused as to whether or not this should work. Specs on the M5Core Gray list the "Port" as TypeC which says I2C+I/O+UART. I think the Type C threw me off as it was somehow configurable

So can someone clear up this confusion for me as to what M5PORT EXPLAIN is on the site showing

• Port-A(Red) G21/22 I2C

• Port-B(Black) G26/36 DAC/ADC

• Port-C(Blue) G16/17 UART

So out of all that :)

1. Am I correct to assume that my Core Grey GROOVE connector is fixed I2C?
2. Can I communicate with the GPS unit via I2C? I know there are some gps modules with special firmware that makes it possible but don't know about this GPS module. I was thinking maybe i just missed a setting.

I am thinking at this point my only option to use this GPS Unit is to hook it up to 16/17 UART on the M5 or go back to one of my UBLOX modules.

Thanks in advance!
Matt