The Vcc on the "Grove" interface is actually stepped up from the 3.3V supply by a tiny SGM6603 chip (on a StickC-Plus). This chip can only supply about 1A, 1.5 absolute max. So this peripheral may or may not be suitable for all M5 devices.

I've "semi-bricked" a Core2 a few times, mostly by uploading code with the wrong board type selected. But also by subtle memory errors uploaded programs. Reinstalling the "BIOS" with the burner has always brought it back to life.

Late reply, but you can just create your own buttons using the untransformed coordinate system and the generic Button interface as a workaround. Use negative-Y values to let you specify the areas where the Core2 "buttons" are painted on (the origin point is about -40 Y.) For example, the following creates three buttons roughly where the Core2 "buttons" are:

Button BtnFreeze = Button(10, -40, 87, 40);
Button BtnCal = Button(117, -40, 87, 40);
Button BtnBright = Button(224, -40, 87, 40);

if you #include <M5Core2.h> you will get the generic Button interface as above.

That being said, I'm finding the Core2 touch screen to be somewhat flaky. Sometimes I have to tap over and over again to get a response, other times it just works.

You want UNbuckled "Grove" connectors to fit all M5Stack devices. For example, the M5StickC-Plus will accept both unbuckled and bucked connectors, but the Core2 will only accept an unbuckled connector. If you have the buckled type, you can always cut the clip off so it will fit.

Generically, these connectors are called "HY2.0-4P" although nearly all vendors sell them as "Grove".

There's no standard for the Vcc and logic levels! So make sure your devices match. M5Stack devices supply 5V on the red conductor, but the logic levels are 3.3V.

I notice that the default partitioning of the Core2 in the Arduino IDE 1.8.19 is "2 x 6.5 MB app, 3.6 MB SPIFFS".

Can someone point me to info about how to take advantage of a second app partition on the Core2, if possible?

I have a sketch that calls M5.Lcd.setRotation(3). After I do this, the Core2 touch buttons no longer work. Actually, they still work, but they have moved down about 50 pixels into the visible area of the screen (with setRotation(3) the buttons etched on the faceplate are at the top of the screen.) Is this a known issue?

Unless you need to control the speed and direction, you can control a non-stepper motor with just a transistor and diode, for one speed, on-off type operation.

Also bear in mind that the range of the RFID 2 Unit (WS1850S) is only about 20mm. The UHF RFID Unit (JRD-4035) had a longer range, but is expensive. There may be longer range 13.56 Mhz sensors available from other vendors.

If you run the following trivial program, you will notice that the screen "flashes" with uninitialized data at startup.

#include <M5StickCPlus.h>
// DANGER WILL ROBINSON: This sketch turns the device off. To upload,
// turn the device on as soon as you see "Connecting..." in the IDE.
// Otherwise the device isn't on when you try to upload to it!
void setup() {
M5.begin();
// This does not minimize the beightness of the "flash"
// M5.Axp.ScreenBreath(7);
M5.Lcd.fillScreen(BLACK);
}
void loop() {
M5.Lcd.setTextSize(3);
M5.Lcd.println("BYE");
delay(5000);
M5.Axp.PowerOff();
}

Is there a way to avoid this "flash"? This is probably a bug in M5.begin(), one would want to initialize the screen memory before turning the LCD on.

@wsanders At least with respect to the LCD library: The only function implemented so far to manipulate whole images is drawBitmap. drawJpg and drawJpgFile are commented out in https://github.com/m5stack/M5StickC-Plus/blob/master/src/M5Display.h so I assume they aren't working yet.

So my workflow for now is:

1. Save the image from gimp in gimp's ".h" format. This is smaller than a xpm or bmp. You will get a static char *data structure of all the pixels in the image. The .h file includes a macro to extract the pixels:

#define HEADER_PIXEL(data,pixel) {
pixel[0] = (((data[0] - 33) << 2) | ((data[1] - 33) >> 4));
pixel[1] = ((((data[1] - 33) & 0xF) << 4) | ((data[2] - 33) >> 2));
pixel[2] = ((((data[2] - 33) & 0x3) << 6) | ((data[3] - 33)));
data += 4;
}

2. Write your own function rgb888to565 to compress the pixels into a uint16_t.

3. Draw a bitmap of the image as fast as you can:

#include <M5StickCPlus.h>
#include "1.h"
int pixel[3];
// pointer fu to preserve the start of .h data
char *datastart;
uint16_t *bitmap;

void setup() {
M5.begin();
M5.Lcd.setRotation(3);
bitmap = (uint16_t *)malloc(height * width * 2);
}

void loop() {
M5.Lcd.fillScreen(GREEN);
datastart = data;
for (int16_t y=0; y < height; y++) {
for (int16_t x=0; x < width; x++) {
HEADER_PIXEL(data, pixel);
bitmap[60*y + x] = rgb888to565(pixel[0], pixel[1], pixel[2]);
}
}
M5.Lcd.drawBitmap(0,0,width,height,bitmap);
data = datastart;
}

Or you can use the Sprite library, which works well.

I am trying to test SPIFFS and display a jpg file using the drawJPGFile method desribed in https://docs.m5stack.com/en/api/core/lcd:

#include <M5Stack.h>
#include <M5StickCPlus.h>
#include <SPIFFS.h>
void setup() {
M5.begin(); //Initialize M5Stack
M5.Lcd.drawJpgFile(SPIFFS, "1.jpg",10,10);
}
void loop(){
}

When I compile the above, I get the error "M5Stack.h: No such file or directory". If I try to compile with only M5StickCPlus.h included, I get 'class M5Display' has no member named 'drawJpgFile'.

I thought M5StickCPlus.h would include M5Stack.h? (I've never had to include M5Stack.h before in any of my sketches.)

Are SPIFFS and drawJpgFile not yet supported on the M5StickCPlus?

Is there another way to display images? I suppose I could always make bitmaps and write new code to load them from PROGMEM?