Re: 32 bits time_t and Y2038 issue

On 2025-03-18, pozz <pozzugno@gmail.com> wrote:

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.

If you are not invested in existing makefiles, have a look at cmake instead
of make.

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.

It is not that big a task, and you learn what kind of compiler flags,
include paths etc. you really need - that helps a lot when you want to
integrate those libraries into your own project in the next step.

My cmake files have functions like
  target_add_HAL_LL_STM32F0(target)
or
  target_add_freertos(target)
that take care of adding the right source files, include parameters etc. -
it take a bit to set this up, but makes it easy to maintain multiple
projects.

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?

Sure.  I have two targets in my makefiles - one starts openocd (needed once
per debug session, keeps running), and one fires up the debugger (ddd) with
the correct ELF file.  That works a lot faster than firing up the debug
session in any vendor eclipse I have seen.

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?

Depends on what patches the vendor included, so I would suggest to do the
switch early in the development cycle.  I have not yet used vendor-patched
ARM gcc versions - the upstream gcc versions worked just fine for STM32,
SamD11, LPC8, LPC17xx, MM32, GD32, Luminary (now TI), TI TM4, TI MSPM0.

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.

The RTC I used is a MicroCrystal RV3029 - low drift, low power, canned part,
works great for this one-off project, and the ESP32 (I wanted NTP for time
updates) would use too much power to run on battery, so I can live with the
register interface using seconds/minutes/...

cu
Michael
--
Some people have no respect of age unless it is bottled.