Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32368

Re: 32 bits time_t and Y2038 issue

Show all headers | View raw

On 18/03/2025 09:21, pozz wrote:
> 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.

Install msys2 (and the mingw-64 version of gcc, if you want a native 
compiler too).  Make sure the relevant "bin" directory is on your path. 
Then gnu make will work perfectly, along with all the little *nix 
utilities such as touch, cp, mv, sed, etc., that makefiles sometimes use.

The only time I have seen problems with makefiles on Windows is when 
using ancient partial make implementations, such as from Borland, along 
with more advanced modern makefiles, or when someone mistakenly uses 
MS's not-make "nmake" program instead of "make".

Of course your builds will be slower on Windows than on Linux, since 
Windows is slow to start programs, slow to access files, and poor at 
doing it all in parallel, but there is nothing hindering makefiles in 
Windows.  My builds regularly work identically under Linux and Windows, 
with the same makefiles.

> 
> 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.
> 

That's why you still have a job.  Putting together embedded systems is 
not like making a Lego kit.  Running a pre-made demo can be easy - 
merging the right bits of different demos, samples and libraries into 
complete systems is hard work.  It is not easy whether you use an IDE 
for project and build management, or by manual makefiles.  Some aspects 
may be easier with one tool, other aspects will be harder.

> 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.
> 

Find the files you need from the SDK or libraries, copy them into your 
own project directories (keep them organised sensibly).

A good makefile picks up the new files automatically and handles all the 
dependencies, so often all you need is a new "make -j".  But you might 
have to set up include directories, or even particular flags or settings 
for different files.

> 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?
> 

Build your elf file with debugging information, open the elf file in the 
debugger.

You probably have a bit of setup to specify things like the exact 
microcontroller target, but mostly it works fine.

> 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?
> 

This has already been covered.  Most vendors now use standard toolchain 
builds from ARM.

What happens if the vendor has their own customized tool and you switch 
to a generic ARM tool depends on the customization and the tool 
versions.  Usually it means you get a new toolchain with better 
warnings, better optimisation, and newer language standard support.  But 
it might also mean vendor-supplied code with bugs no longer works as it 
did.  (You don't have any bugs in your own code, I presume :-) )

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-11 16:22 +0100
  Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-11 17:32 +0100
    Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-11 23:21 +0100
      Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-12 10:33 +0100
        Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-12 16:48 +0100
          Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-12 17:39 +0100
            Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-12 18:13 +0100
              Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-12 19:18 +0100
                Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-13 09:57 +0100
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-13 16:51 +0100
                Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-14 13:27 +0100
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-14 14:20 +0100
    Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-12 08:44 +0100
      Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-12 11:14 +0100
      Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-14 01:48 +0000
        Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-14 08:36 +0100
    Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-15 16:30 +0000
      Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-15 17:02 +0000
        Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-15 23:26 +0000
      Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-18 09:21 +0100
        Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-18 11:34 +0100
          Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-18 17:31 +0100
            Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-18 20:29 +0100
              Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-21 09:20 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-21 13:54 +0100
                Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-21 20:53 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-22 11:19 +0100
                Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-21 14:35 +0000
          Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-18 18:28 +0000
            Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-18 20:43 +0100
              Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-18 20:58 +0000
                Re: 32 bits time_t and Y2038 issue Hans-Bernhard Bröker <HBBroeker@gmail.com> - 2025-03-18 23:31 +0100
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-19 11:24 +0100
                Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-19 14:27 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-19 17:33 +0100
                Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-19 19:08 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-19 21:14 +0100
                Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-21 09:48 +0000
                Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-21 13:27 +0000
                Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-19 22:09 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-20 09:26 +0100
                Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-21 22:40 +0100
                Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-21 09:23 +0000
                Re: 32 bits time_t and Y2038 issue Hans-Bernhard Bröker <HBBroeker@gmail.com> - 2025-03-21 22:38 +0100
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-19 08:24 +0100
              Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-21 14:04 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-21 16:45 +0100
                Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-21 22:51 +0100
                Re: 32 bits time_t and Y2038 issue Hans-Bernhard Bröker <HBBroeker@gmail.com> - 2025-03-22 00:00 +0100
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-22 14:29 +0100
                Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-22 14:46 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-22 17:57 +0100
                Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-22 15:57 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-22 18:02 +0100
        Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-18 18:44 +0000

csiph-web