An interesting observation about AI and pin conflicts in #775838. I guess the learning behind AI’s suggestion is based on human written clock code that makes the same mistake, which is copied. Investigating how and why AI gets stuff wrong could be a whole new hobby.
Whether a set button is needed or not question is just ergonomics I think. Code can be written such that the RTC just counts from wherever the advance and retard buttons got to. Except, I, being human, am happier with a design that sets the time in a way that positively tells me it’s been done. As a good interface should never leave the user guessing, I’d have a set button!
Flashing LEDs together is a synchronisation problem. The answer to ‘Would splitting my new code into sections like this be likely to help the LEDs to flash at the same time, or at least more closely together?‘ is no. It’s the other way round – a combined flasher that meets the requirement: ‘There are pins to flash LEDs: once a second, once a minute, once an hour and once a day. It flashes another LED once, twice, thrice or four times on the quarters; and another on the hour, once, twice, thrice or more depending upon the hour.‘
The most accurate way is with one of the Arduino’s built-in hardware timers and an interrupt, but I think simpler to write ordinary code inside void loop(), and accept flashes could be wrong in the millisecond region.
The key is to not use the delay() function, or anything else that waits. delay() stops the program entirely, bad when we need the computer to handle seconds, minutes, hours, and quarters seamlessly. Instead, the flash is timed with millis(), and which LEDs are switched is controlled by setting a variable. This code establishes flash duration by testing millis() and doesn’t stop.
Clear as mud I expect, an example is needed! Off to a hospital appointment now, and then a haircut, but I’ll rough something out in the waiting room and report later.
Dave