Path: ...!feeds.phibee-telecom.net!3.eu.feeder.erje.net!feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Michael Schwingen <news-1513678000@discworld.dascon.de>
Newsgroups: comp.arch.embedded
Subject: Re: 32 bits time_t and Y2038 issue
Date: 18 Mar 2025 18:44:16 GMT
Lines: 61
Message-ID: <slrnvtjfo0.566.news-1513678000@a-tuin.ms.intern>
References: <vqpkf9$1sbsa$1@dont-email.me> <vqpoi3$226ih$1@dont-email.me>
 <slrnvtbaot.sal.news-1513678000@a-tuin.ms.intern>
 <vrbado$2133a$1@dont-email.me>
X-Trace: individual.net 4A39w91aSbPqdd3iIRtAdA5mEXrsIF7b+6jdui7AT76wg8RNvI
Cancel-Lock: sha1:ajwemjo1SO2MM6TTJvw+YSuHDOI= sha256:A+5eakRNUkPl2V63UQ842j/vWlEOb62Eae39yPcstXA=
User-Agent: slrn/1.0.3 (Linux)
Bytes: 3757

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.