Re: 32 bits time_t and Y2038 issue

Il 15/03/2025 17:30, Michael Schwingen ha scritto:

On 2025-03-11, David Brown <david.brown@hesbynett.no> wrote:

package as-is.  For anything other than a quick demo, my preferred setup
is using makefiles for the build along with an ARM gcc toolchain.  That
way I can always build my software, from any system, and archive the
toolchain.  (One day, I will also try using clang with these packages,
but I haven't done so yet.)

 Same here.  I just switched to ARM gcc + picolibc for all my ARM projects -
this required some changes in the way my makefiles generate linker scripts
and startup code, and now I am quite happy with that setup.

One day or another I will try to move from my actual build system (that depends on silicon vendor IDE, libraries, middleware, drivers, and so on) to a generic makefile and generic toolchain.
Sincerely I tried in the past with some issues. First of all, I use a Windows machine for development and writing makefiles that work on Windows is not simple. Maybe next time I will try with WSL, writing makefiles that work directly in Unix.
Another problem that I see is the complexity of actual projects: TCP/IP stack, cripto libraries, drivers, RTOS, and so on. Silicon vendors usually give you several example projects that just works with one click, using their IDE, libraries, debuggers, and so on. Moving from this complex build system to custom makefiles and toolchain isn't so simple.
Suppose you make the job to "transform" the example project into a makefile. You start working with your preferred IDE/text editor/toolchain, you are happy.
After some months the requirements change and you need to add a driver for a new peripheral or a complex library. You know there are ready-to-use example projects in the original IDE from silicon vendor that use exactly what you need (mbedtls, DMA, ADC...), but you can't use them because you changed your build system.
Another problem is debugging: launch a debug sessions that means download the binary through a USB debugger/probe and SWD port, add some breakpoints, see the actual values of some variables and so on. All this works very well without big issues if using original IDE. Are you able to configure *your* custom development system to launch debug sessions?
Eventually another question. Silicon vendors usually provide custom toolchains that often are a customized version of arm-gcc toolchian (yes, here I'm talking about Cortex-M MCUs only, otherwise it would be much more complex).
What happens if I move to the generic arm-gcc?

I have one project where I needed custom time functions: a nixie clock that
has both a RTC (with seconds/minutes/... registers), and NTP to get current
time. NTP time is seconds since 1.1.1900 and UTC.
 The sane approach to handling timezones and DST is the unix way: keep
everything in UTC internally and convert to localtime when displaying the
time.  To set the RTC, that requires a version of mktime that does *not* do
timezone conversion - I simply pulled mktime from the newlib sources and
removed the timezone stuff - done.  You could write that stuff yourself, but
getting all the corner cases right will take some time.  The existing code
is there and works fine.

This is exactly what I do. I don't use RTC with registers (seconds, minutes...) anymore, only a 32.768kHz oscillator (present in many MCUs) that increments a counter.