Posts made by casascius

The LCD support in M5Stack Arduino is itself a derivative of TFT_eSPI available on GitHub. If it's not specifically for an M5Stack Core/Basic/Gray, start with TFT_eSPI and work with its templates for the LCD of your choice.

I had the same problem and was able to resolve it. I'm using a made-up CA certificate, which in turn was used to sign a server key for my MQTT server. I found all of these steps to be necessary to get WiFiClientSecure to talk to it without needing to call setInsecure().

• Provide that CA certificate to the WiFiClientSecure class by calling setCACert()
• Access the remote host through its DNS name, not an IP address. (It looks like ESP32 can find it either through traditional a DNS server, or by multicast mDNS such as yourhostname.local if it's on the same network)
• The DNS name must be listed as a "DNS" entry in Subject Alternative Name section of the certificate on the remote host. (I was able to use ChatGPT4 to walk me through creating the openssl "conf" file needed to generate a Certificate Signing Request and then ultimately the Certificate that met this criterion).

I am surprised that Grove level shifters are not part of the M5Stack hardware offering.

Just today I went onto JLCPCB and designed myself a PCB that can fit in shrink tube and has a Grove socket on each side, the board has a level shifter that converts a Grove (5V power + 3.3V logic) to pure 5V power + 5V logic. (it's a level shifter board that generates its own 3.3V reference with an LDO). I made an order of 90 boards at a shipped cost of $135, so a little over a buck a board. I am just surprised nobody seems to sell this, least of all M5Stack with a core offering of 5V power + 3.3V logic on just about everything.

By the same process I could quickly make a set of boards that takes 5V power 3.3V logic from one side, and gives 3.3V power 3.3V logic on the other (just by duplicating the design, rearranging the components and deleting the level shifter). I'll probably do it the day I need it. Or maybe sooner.

At a glance I would say commenting out noInterrupts() and interrupts() is the correct thing to do. Can anyone tell us why are they even there?

The purpose of noInterrupts() is to prevent interrupt handlers from running in the middle of a critical section of code. But this makes no sense -- we are already in an interrupt handler here, where protection from other interrupts is already in effect until the function returns. At least that's the case for other Arduino microcontrollers -- admittedly, I haven't coded much for ESP32. Someone say something if I misunderstand this here.

Furthermore, setting a byte size variable to a constant value like 1 isn't the sort of thing that counts as a critical section of code that would ever need noInterrupts() in the first place.

I say it's safe to comment these two lines out and then I raise the question why were they ever there.

I'm coming in a bit late, but fought with this a little bit.

For me, shutdown() wouldn't wake up at all. The ultimate cause was that the i2c bus wasn't getting properly initialized (another issue for another post -- touchpanel related) so the command to the clock chip was never getting sent.

Once it got sent, doing a shutdown(10) to wake up after 10 seconds worked properly for me... in fact, so properly, you couldn't turn the device off because the alarm persists until deactivated. shutdown(-1) in setup() (after initializing i2c) is necessary to clear the timer alarm upon sketch restart (which I determined by inspecting the library source).

Also by inspecting the source and datasheet, overload 4 that Jop says isn't working, I am guessing is because he only advanced the day of month. It looks as though the clock chip compares not just hour/minute/day, but also the day of week (e.g. Thursday) and, reviewing the source code, it doesn't ever consider the month or year at all, nor does the chip even have registers to alarm on these. But it has one for the weekday, so if you don't advance the weekday, the comparison will fail per the datasheet.