I want to make a “clock” with a ds1307 module, where I can adjust time/date using buttons, like in a normal clock, so I need a display as feedback for the new settings.
While the ds1307-rtc-write works ok on its own and allows updating the date/time on the ds1307 if used alone in a patch, when I try to use it together with the text-lcd-16x2-i2c, I don’t get errors but the new data doesn’t get retained by the rtc. When I run the ds1307-rtc-read I get the old data instead of the one I just updated.
I suspect a clash on the i2c bus (all nodes and modules work fine separately, the i2c addresses are correct).
Any hints?
Hi, sure.
Just to give more info, I am using a ds3231 module as rtc (which seems to be just “a better” 1307 and shares the same i2c address). It is used on a Proto Shield Plus from Gtronics which has a i2c LCD module and the typical buttonpad that you find on LCD shields connected to A3.
I am trying to attach the xodball of the project (I want to make a clock as a demo for a tutorial on XOD). In the project the first two patches just read the time/date from the rtc and show it on the LCD. This works fine. The third patch is the suggested way to update data on the rtc. This works fine as well. The fourth one is my attempt at an interactive setup of the clock. This doesn’t work. It seems to upload data ok. I tested this by checking the DONE and ERR outputs of the ds1307-rtc-write node (I also had a multifunction shield attached for leds, but I rechecked without it and there is no difference, so we can exclude interference from this shield). I thought something was wrong with some of my nodes (btw, they are in my library uploaded in XOD.io/libs ), so I made the simple patch 5 with only the rtc and the lcd and this patch seems to work, i.e. compiles and uploads ok, but then when I use read the data again it shows the old data, as if the operation completed but no update happened.
I have no 1-to-1 hardware to repeat the problem, but from what I see I can make a few assumptions.
ds1307-rtc-write and text-lcd-16x2-i2c has no graph dependency between them. What if LCD tries to invalidate in the middle of RTC communication or there’s not enough time for RTC to release I2C bus properly?
For a quick experiment, try to UPD your LCD with a clock pulsing once per second? Does it “fixes” the problem? If not, am I understand correctly that simply removing the text-lcd-16x2-i2c node from the 4-th patch makes RTC work even you’re required to operate blindly?
No, it works with a non-continuous UPD’ates but the pulses should be delivered at the right moments, that is when the content on display should actually be updated.
Take a look at xod/core/pulse-on-change. It currently works only with numbers, but it should easy for you to create own analog which will take a string. Then place two such nodes right behind the L1 and L2 of text-lcd-16x2-i2c and link their outputs to UPD.
HI gabbapeople.
Join is just a “smart” concat that saves re-entering the delimitation char. Without formatting dates and times would not be shown correctly. For instance if the date is the 5th of April 2018, the displayed date (with both concat and join and “/” as delimiter) would be 5.00/4.00/2018.00. The format-number node can be used to bring this to 5/4/2018, which is also not really what one wants for a date (I want 05/04/2018). That’s why I wrote a little node that does it…
The pulse from the rtc-write IS when the content on the display needs to be updated, because it is when the rtc-write tells that the operation went ok. The data in input to the LCD node is always present and I was expecting the pulse form the rtc-write to trigger the update on the display. It is like in your suggestion of clocking the LCD with an external clock. Every now and then we send a pulse to the display in order to update it… but it doesn’t work. More explicitly the display is illuminated but shows nothing.
Incidentally, using the DONE signal from the rtc-READ to trigger the LCD works fine, I attach an example.
Sorry, I did not realize that the successful RTC write is the moment when the display should be refreshed. You did everything right.
@gabbapeople, thanks for the effort, however, I’m pretty sure the true problem is this:
Sketch uses 30772 bytes (95%) of program storage space. Maximum is 32256 bytes.
Global variables use 1963 bytes (95%) of dynamic memory, leaving 85 bytes for local variables. Maximum is 2048 bytes.
That’s what I see when deploying. The compiler is not able to precisely analyze how much RAM will be consumed at a peak, but given that global vars alone take 95% we’re definitely in trouble.
I’m not sure if the problem has a quick solution, but looks like you’ve hit XOD+Arduino limits. We’ll make a comprehensive review to narrow down who eats all RAM and what we can do with it. Meanwhile, the most adequate solution (sadly) is upgrading to Arduino Mega/Due/M0.
Thanks for sharing the patch, I’ll use it as a reference of a memory hog.
@gabbapeople I will check the proposed new patch as soon as I can (obviously the delay and watches were not the culprits, they were there only to try to analyze the timings and possible problems).
@nkrkv …yes I knew it was getting to the limit, in fact just adding one link between the rtc-write and the lcd would bring me beyond the memory of the Arduino Uno I am using and I had to remove the LEDs… …but I didn’t want to mention it for fear of mixing two different issues in the same thread… So essentially you are saying that the patch actually runs out of memory (RAM) while running… that makes sense, I should have thought of it… Well done! Now… let’s go and grab a Mega…
Writing and immediately reading back from the RTC and then show on an LCD (without formatting) works. I tested this by using a counter to increment day and seconds, write to RTC, read it back and visualizing days and seconds on different rows . Everything works fine. So it really is the memory thing! The patch goes like this:
@gabbapeople sorry but your modification doesn’t really work. In your patch you are forcing 0 for the seconds (the first added 0h), then setting the control register to zero (0h inserted after the year byte), while the seconds are lost (actually they are written in the first byte of RAM).
It seems to work only if it is on continuous UPD…
