Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32372

Re: 32 bits time_t and Y2038 issue

Show key headers only | View raw

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

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