DS3231 + 2 Boards

Hey guys, so, last week I received my ESP32 Dev Board, which I was planning to use with a DS3231 RTC and a RGB Led Panel to make a big clock in my wall with internet sync. The problem is, the library used to the LED Panel don’t compile in the ESP32 ( IDK why, actually I didn’t try to discover too), just on Arduino Mega 2560. So I had an idea, why not use the Mega to make the communication with the led panel and the ESP32 just to sync the RTC ? Simplifying, the idea is connect both boards via I2C with the RTC, Mega would get the information from the RTC and ESP32 would send the correct time to the same I2C lane to the RTC.
If the text isn’t enough, I’ve uploaded an image to make it easy.
Thanks.

It looks like you plan to have multiple masters on the bus. As I understood you plan to read the RTC by the Mega2560 and to send commands from the ESP to the Mega2560. In this setup the ESP will be master for the communication with the Mega2560 and the Mega2560 is master for the communication with the RTC. This won't work reliable.

There's another problem. The Mega2560 has on-board pull-ups for the I2C signals, so the voltage level on these lines is 5V. The ESP won't be happy about this.

pylon: It looks like you plan to have multiple masters on the bus. As I understood you plan to read the RTC by the Mega2560 and to send commands from the ESP to the Mega2560. In this setup the ESP will be master for the communication with the Mega2560 and the Mega2560 is master for the communication with the RTC. This won't work reliable.

There's another problem. The Mega2560 has on-board pull-ups for the I2C signals, so the voltage level on these lines is 5V. The ESP won't be happy about this.

Actually I don't want direct communication between the ESP32 and Mega, the idea is send the correct time to the RTC and then by some way tell the mega that the clock is updated, so then the Mega will read the RTC to adjust the time.

Your ESP32 can just as easily get a more accurate time over NTP. Then you can even have the Mega get the time info from the ESP32 (and indeed the RTC becomes obsolete).

wvmarle: Your ESP32 can just as easily get a more accurate time over NTP. Then you can even have the Mega get the time info from the ESP32 (and indeed the RTC becomes obsolete).

Yeah, I'm using NTP, the question is, will the ESP32 keep the right time offline and maybe even powered off? Cause the think is update the time from NTP every some minutes and if there's no internet avaliable for the update it keeps running even if with some seconds of delay compared to the updated.

Not only does the Arduino Mega have on board i2c pullups to 5v but the RTC module in the photo has pullups to I2C VCC as well. When using the Mega the VCC on the RTC module will be 5v and you will need to use a a bi-directional logic level converter to allow the ESP to work on the 5v bus

If you eliminated the Mega and used 3v for vcc on the RTC module you wouldn't need a voltage level converter and could hook the RTC directly to the ESP.

I'd fix the LED library and get rid of the Mega as that will keep things much simpler. What LED library are you using that isn't working on the ESP?

Also keep in mind that the RTC module shown in the photo was designed to use a LIR2032 which is a rechargeable battery. If you want to use a standard 2032, the you will need to modify the RTC module by cutting a trace to disable the charging circuit.

-- bill

Caits: Yeah, I'm using NTP, the question is, will the ESP32 keep the right time offline and maybe even powered off? Cause the think is update the time from NTP every some minutes and if there's no internet avaliable for the update it keeps running even if with some seconds of delay compared to the updated.

Normal update intervals are like once a day or so. No more than once an hour. The ESP8266 will keep time reasonably accurate, never actually done a free running experiment with them, just have the NTP update the time. It does NOT keep the time when powered off - not even the last registered time. When powered on you need to update the internal timekeeping. Quite sure the ESP32 will be the same in this regard.

wvmarle: Normal update intervals are like once a day or so. No more than once an hour. The ESP8266 will keep time reasonably accurate, never actually done a free running experiment with them, just have the NTP update the time. It does NOT keep the time when powered off - not even the last registered time. When powered on you need to update the internal timekeeping. Quite sure the ESP32 will be the same in this regard.

Yeah, well, the update frequency will be reduced, once an hour should be enough.

bperrybap: Not only does the Arduino Mega have on board i2c pullups to 5v but the RTC module in the photo has pullups to I2C VCC as well. When using the Mega the VCC on the RTC module will be 5v and you will need to use a a bi-directional logic level converter to allow the ESP to work on the 5v bus

If you eliminated the Mega and used 3v for vcc on the RTC module you wouldn't need a voltage level converter and could hook the RTC directly to the ESP.

I'd fix the LED library and get rid of the Mega as that will keep things much simpler. What LED library are you using that isn't working on the ESP?

Also keep in mind that the RTC module shown in the photo was designed to use a LIR2032 which is a rechargeable battery. If you want to use a standard 2032, the you will need to modify the RTC module by cutting a trace to disable the charging circuit.

-- bill

The idea was use just the ESP32 with the RTC but the library for the LED is not compatible, I'm using Adafruit LED library (https://github.com/adafruit/RGB-matrix-Panel) and also the Adafruit GFX(https://github.com/adafruit/Adafruit-GFX-Library), i was trying to find another library for the LED panel so I could use with the ESP32. About the battery for the RTC, the charging circuit is new for me, I've never seen anything about this, I'll search for it and if necessary change the battery or the charge circuit...

Caits: About the battery for the RTC, the charging circuit is new for me, I've never seen anything about this, I'll search for it and if necessary change the battery or the charge circuit...

The charge circuit is a very simple circuit - too simplistic. All it is a trace/wire from VCC to a series resistor that feeds a diode that is connect to the battery positive. You can just cut the trace on either side of the diode to disable it.

--- bill

I would think the esp32 would keep very good time over 24hrs. Sync with ntp once per day and it will be the most accurate clock in your house. Save the rtc and mega for another project. To be honest, I think an esp32 will be wasted on this project. An esp8266 will be more than adequate. One of my home made clocks is built from a Wemos Mini and a 60 led (ws2812b) ring. It also has a DFPlayer mini to play sampled chimes through a small speaker. It keeps perfect time and chimes exactly as the time signal on BBC radio 4.

1 Like

The main issue seems to be the RGB matrix library. The code isn't portable to the ESP core(s). The library .properties file says it is for all architectures,

architectures=*

but the code in RGBmatrixPanel.cpp uses and depends on AVR specific raw port i/o. That code will only work on certain AVR processors.

Doing that is just plain sloppy/wrong.

I filed an an issue against the library: https://github.com/adafruit/RGB-matrix-Panel/issues/34

--- bill

This gives me an opportunity to ask a question I have wondered about before, regarding these RGB panels.

The reason, I think, why AdaFruit have resorted to using avr specific code to drive the panels, is for performance reasons. They did not use hardware SPI, but instead opted to "bit-bang" the data out to these panels. Because they did this, they needed to use direct port manipulation to achieve a sufficiently high data output rate.

But why did they bit-bang instead of using hardware SPI? My initial thought was as follows. The panel has 3 data inputs (a, b, c) and shared clock and latch lines. But the hardware SPI has only one data output (MOSI). So, instead, they used bit-banging to simulate an SPI-like interface with 3 data channels, so that red, green and blue data bits could be shifted out in parallel.

But wait. The panel has an output connector to allow chaining of multiple panels. This connector has a, b & c outputs. So why not use hardware SPI? Connect MOSI to the "a" input. Connect the "a" output back to the "b" input. Connect the "b" output back to the "c" input. The data would need to be sent in a different order, but the hardware SPI could be used. This would dramatically improve performance and remove the need for architecture-specific bit-banging code.

So my question is: why was this not done by AdaFruit ? Is there a flaw in my idea that I have not thought of?

I guess I was a bit vague in my "just plain sloppy/wrong" comment. I was referring to the .properties saying it worked on all architectures not the using AVR specific code.

I haven't looked at the details of how the h/w works, so I can't really comment why they chose to use a bit-banged methodology vs some thing more h/w driven like hardware SPI.

Although bit banging on a chip like the ESP8266 using digitalWrite() can actually be faster than the AVR h/w SPI and is for sure faster than doing s/w bit banging on the AVR even when AVR raw port i/o is used.

--- bill

I think hardware SPI on the esp8266 can clock all the way up to 80MHz. Even 160MHz if you increase the CPU clock. That will outpace most displays with SPI interface!

AFAIK both SPI and I2C are pure software based on the ESP8266.

Definitely correct on i2c. But for SPI, I understood it to be hardware. You cannot change which pins it uses, for example, like you can with i2c. I looked for a reference that indicates it's definitely hardware, but could not find a good one.

Mmm... For lack of proper documentation of the processor that may be hard to find indeed. Gotta try and look it up myself.

Well, yesterday, looking for another LED library I found this one (https://github.com/VGottselig/ESP32-RGB-Matrix-Display) Which allows me even to choose the connection pins, so I guess now the LED problem is solved, about the waste of resources with boards, yes, I probably could use a board not so powerful as the ESP32, but I bought just for this project, there's no other use for it now, so I'll keep using it and if in the future becomes necessary I'll change. Finally, I discovered that the ESP32 install process creates a "hardware" folder with a lot of demo projects, including one which get the time via NTP and keeps it running without internet connection until the board turns off, then, when the power returns it connects again and update. So now, I'll just adapt all the requirements to one project and I hope it works fine.