I have a spooky story to share, and it is all true. To be truthful though, there has to be some seldom documented feature in Kitty that made this possible, but since I tested repeatedly sending the required data to the example sketch without success, I have no idea how it was done.
Confused? Well so am I... still!
I was running a sketch on a STM32F103C8T6 Blue Pill clone board that sets up the RTC, takes serial input in the form of ASCII to set it, and outputs the results every second with an interrupt. Since I noticed the code that reads the serial port, I tried using it with no results, or erratic results. I ended up just banging characters in frustration. And yes, a control and alt character or two was sent for sure. I got up and ate, watched a little baseball, and came back to the scrolling times on my Kitty terminal, and found that the date and time was only about 10 seconds off from my PC. HOW???
The board is not connected to anything online except a ESP8266 that uses TELNET to patch serial communication through it's IP and into the STM32 board, and back again. There is no serial automation as of yet. I just type and the STM32 sends stuff back. It is a wireless way to serial communicate with the board and works well. I have been using it for a few months now.
My guess is that somehow, I triggered a feature that sent the data based on the timestamp from my PC, but my searches reveal no such feature. The STM32 must have received it, parsed it, and set the RTC to the correct time and date. The 10 second drift must have been something in the processing. I have not been able to recreate the anomaly either. This is by far the strangest thing I have seen doing this sort of thing.
Anyone have any ideas? It's spooky. Like the STM32 code reached out and did an NTP server read and acted on it, but there is nothing in the code to suggest it.
A Software Development Ghost Story - And it is True
3 months 2 weeks ago #18069
I think I figured it out. It was clever programming from the example author, but not sure how it ended up updating itself. The firmware update __DATE__ and __TIME__ macros played a role. At least I have a partial reason now. Weird.