Re: 32 bits time_t and Y2038 issue

On 18/03/2025 17:31, pozz wrote:

Il 18/03/2025 11:34, David Brown ha scritto:

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.

 Do you run <msys>\usr\bin\make.exe directly from a cmd.exe shell? Or do you open a msys specific shell?
 

Either works fine.
So does running "make" from whatever IDE, editor or other tool you want to 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.

 I tried to use make for Windows some time ago, but it was a mess. Maybe msys2 system is much more straightforward.
 

I have been using "make" on DOS, 16-bit Windows, OS/2, Windows of many flavours, and Linux of all sorts for several decades.  I really can't understand why some people feel it is difficult.  (Older makes on DOS and Windows were more limited in their features, but worked well enough.)
These days I happily use it on Windows with recursive make (done /carefully/, as all recursive makes should be), automatic dependency generation, multiple makefiles, automatic file discovery, parallel builds, host-specific code (for things like the toolchain installation directory), and all sorts of other bits and pieces.

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.

 You're right.
 

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.

 What do you mean with "open the elf file in the debugger"?
 

A generated elf file contains all the debug information, including symbol maps and pointers to source code, as well as the binary. Debuggers work with elf files - whether the debugger is included in an IDE or is stand-alone.

 

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 :-) )

 :-)