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 17:31:18 +0100
Organization: A noiseless patient Spider
Lines: 117
Message-ID: <vrc74l$2133a$2@dont-email.me>
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> <vrbi79$2a30t$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 18 Mar 2025 17:31:18 +0100 (CET)
Injection-Info: dont-email.me; posting-host="72382ab6454fc73aa33532361b073b5c";
	logging-data="2133098"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18mYH+7Rq8Kx8kwsxRTxk6i+Sieou1DHKY="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:fFZ7HGGSR1rI5H80lK8p2mUe060=
Content-Language: it
In-Reply-To: <vrbi79$2a30t$1@dont-email.me>
Bytes: 6836

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?


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

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


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

:-)