Closed udo-munk closed 1 month ago
Try the dev branch. I made some changes the the RTC stuff yesterday. I'm unable to test it though, since I haven't received a pico2 yet.
How are you checking the date of created/modified files? I've noticed that Windows and Linux deal with those timestamps differently. Linux seems to assume that the timestamps are in GMT (or UTC) time and applies a timezone conversion to local time. Windows, I think, assumes they are in local time already.
On Windows and OSX the timestamp show the same, excately like my wall clock, which I use to set the time in the Pico. Not dealing with the timezones yet in the Pico, also don't know if it even is implemented in all the time/date conversion functions.
OK, will try out the dev branch tomorrow and let you know if it changes something.
Tried with the dev branch, but the date of the filestamps still is 20 years - 1 month in the future.
The one month low probably is because tm_mon contains 0-11 for the month and not 1-12. No idea where the 20 years difference come from, I set tm_year to current year - 1900, convert struct tm with mktime() and start the AON timer with this. On the RP2040 boards I am still using lib version v2.3.2 with the datetime RTC. Timestamps with this are OK.
Hi, Just a small addition: I'm using v3.3.0 on the original Pico (RP2040), and the same thing is happening here.
Yep, something definitely wrong with the rtc.c/my_rtc.c source. I just modfied my_rtc.c from the dev branch so:
// bit31:25
// Year origin from the 1980 (0..127, e.g. 37 for 2017)
//uint8_t yr = t.tm_year - 1980;
uint8_t yr = t.tm_year - 1900;
fattime |= (0b01111111 & yr) << 25;
// bit24:21
// Month (1..12)
//uint8_t mo = t.tm_mon;
uint8_t mo = t.tm_mon + 1;
Now the month is correct because tm_mon is not 1-12, but year is 1996, hum, 28 years to low now.
Now it is working correct with:
// bit31:25
// Year origin from the 1980 (0..127, e.g. 37 for 2017)
//uint8_t yr = t.tm_year - 1980;
uint8_t yr = t.tm_year + 1900 - 1980;
fattime |= (0b01111111 & yr) << 25;
// bit24:21
// Month (1..12)
//uint8_t mo = t.tm_mon;
uint8_t mo = t.tm_mon + 1;
fattime |= (0b00001111 & mo) << 21;
Yep, I just started typing that -80 would be the correct number, and you were running into and integer underflow situation with the -1900/-1980.
OK, thanks for the corrections. I have pushed an update to the dev branch.
You are welcome. Got latest update of the dev branch and can confirm that it is working OK on rp2350.
I got my first Pico 2 boards the other day and found that the datetime RTC is not available anymore. So I modified the application to use the AON timer and that works ok. But with this the date of created/modified files on SD card is wrong. When I set todays date 10.09.2024 files on the SD card show 10.08.2044, so totally off. The time is correct though.