Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: pozz <pozzugno@gmail.com>
Newsgroups: comp.arch.embedded
Subject: Re: 32 bits time_t and Y2038 issue
Date: Tue, 18 Mar 2025 09:21:13 +0100
Organization: A noiseless patient Spider
Lines: 66
Message-ID: <vrbado$2133a$1@dont-email.me>
References: <vqpkf9$1sbsa$1@dont-email.me> <vqpoi3$226ih$1@dont-email.me>
 <slrnvtbaot.sal.news-1513678000@a-tuin.ms.intern>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 18 Mar 2025 09:21:13 +0100 (CET)
Injection-Info: dont-email.me; posting-host="72382ab6454fc73aa33532361b073b5c";
	logging-data="2133098"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18P1zDh/NOOYVdBRqLF9+F2j6V2O2Q36vs="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:gRHnCVNYBzlALWNIOxs/E2rz6XU=
Content-Language: it
In-Reply-To: <slrnvtbaot.sal.news-1513678000@a-tuin.ms.intern>
Bytes: 4616

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.