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?

When I try to compile the RTC example, in the M5StickC-Plus examples on github (https://github.com/m5stack/M5StickC-Plus/blob/f4f2ef8c3619fed4c430ce6e1f486c5c63f7c09e/examples/Basics/RTC/RTC.ino) I get:

RTCTest:38:12: error: 'class RTC' has no member named 'SetDate'; did you mean 'SetData'?
RTCTest:49:12: error: 'class RTC' has no member named 'GetDate'; did you mean 'GetData'?

Looks like the method is misspelled in

class RTC {
public:
RTC();
...
void SetData(RTC_DateTypeDef* RTC_DateStruct);
void GetData(RTC_DateTypeDef* RTC_DateStruct); //oops!

This typo isn't in the github repo, "Latest commit f4f2ef8 on Oct 1, 2022", but it hasn't been pushed to the IDE v0.0.8 M5StickCPlus library, which is the latest available for Arduno IDE 1.x.

Feature Request: I would be nice is the RTC methods used standard C++ struct tm, you wouldn't have to mess with swapping the struct members around when you get a standard struct tm back from the NTP library. Maybe I'll make some functions to convert the data types and post them on github.

Thanks! That workaround works.

You only see the brief flash when applying power or when the IDE uploads the code and hard resets via RTS.

If you do this:

#include <M5StickCPlus.h>
void setup() {
M5.begin();
digitalWrite (M5_LED, HIGH); // turn off the LED
pinMode(M5_LED, OUTPUT);
digitalWrite (M5_LED, HIGH); // off
}
void loop() {
delay(10);
ESP.restart();
}

the LED does not flash repeatedly.

(I'll go ahead and bump this. So sue me.)

Bear in mind that when you initialize the pin with:

M5.begin();
...
pinMode(M5_LED, OUTPUT);
digitalWrite (M5_LED, HIGH); // turn off the LED

The LED will blink briefly. I don't know of a workaround. I also know virtually nothing about ESP pin frobbing.