Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!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: Improving build system
Date: Fri, 16 May 2025 12:46:56 +0200
Organization: A noiseless patient Spider
Lines: 355
Message-ID: <100752v$3kivm$1@dont-email.me>
References: <vvvq5j$1lml0$1@dont-email.me> <1001m9t$2drv1$1@dont-email.me>
 <100338u$2c42e$1@dont-email.me> <1004all$3218k$1@dont-email.me>
 <1005m3f$3aqfb$1@dont-email.me> <1006vho$3miqf$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 16 May 2025 12:46:58 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b1ab8f7032ac741dfc92317180d6ca90";
	logging-data="3820534"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19CulNpOjOLMCUPGZf1SD821J6DGJelOfk="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:FPhvcJsIw6/34gpBzdSkTjnJGHw=
In-Reply-To: <1006vho$3miqf$1@dont-email.me>
Content-Language: it
Bytes: 16624

Il 16/05/2025 11:12, David Brown ha scritto:
> On 15/05/2025 23:25, pozz wrote:
>> Il 15/05/2025 11:03, David Brown ha scritto:
>>> On 14/05/2025 23:51, pozz wrote:
>>>> Il 14/05/2025 11:03, David Brown ha scritto:
>>>>> On 13/05/2025 17:57, pozz wrote:
>>>> [...]
>>
> 
>> I worked on PIC8 and AVR8 and IMHO AVR8 is much better then PIC8.
>> Regarding Cortex-M, SAM devices are fine for me.
> 
> The 8-bit PIC's are extraordinarily robust microcontrollers - I've seen 
> devices rated for 85 °C happily running at 180 °C, and tolerating 
> short-circuits, over-current, and many types of abuse.  But the 
> processor core is very limited, and the development tools have always 
> been horrendous.  The AVR is a much nicer core - it is one of the best 
> 8-bit cores around.  But you are still stuck working in a highly 
> device-specific form of coding instead of normal C or C++.  

Why do you write "highly device-specific form of coding"? Considering 
they are 8-bits (and C is at-least-16-bits integer), it seems to me an 
acceptable C language when you coimpile with avr-gcc.

You can use int variables without any problems (they will be 16-bits). 
You can use function calls passing paramters. You can return complex 
data from functions.

Of course flash memory is in a different address space, so you need 
specific API to access data from flash.

Do you know of other 8-bits cores supported better by a C compiler?


> And you are 
> still stuck with Microchip's attitude to development tools.  (You can 
> probably tell that I find this very frustrating - I would like to be 
> able to use more of Microchip / Atmel's devices.)

Maybe we already talked in the past about this. I don't know if avr-gcc 
was developed by Atmel or Arduino community. Anyway, for AVR8 you have 
the possibility to use gcc tools for compiling and debugging. There are 
many open source tools. I think you could avoid completely 
Microchip/Atmel IDE for AVR8 without any problems. Arduino IDE is a good 
example.


>>>>> 2.
>>>>>
>>>>> You don't need to use bash or other *nix shells for makefile or 
>>>>> other tools if you don't want to.  When I do builds on Windows, I 
>>>>> run "make" from a normal command line (or from an editor / IDE).  
>>>>> It is helpful to have msys2's usr/bin on your path so that make can 
>>>>> use *nix command-line utilities like cp, mv, sed, etc.  But if you 
>>>>> want to make a minimal build system, you don't need a full msys2 
>>>>> installation - you only need the utilities you want to use, and 
>>>>> they can be copied directly (unlike with Cygwin or WSL).
>>>>>
>>>>> Of course you /can/ use fuller shells if you want.  But don't make 
>>>>> your makefiles depend on that, as it will be harder to use them 
>>>>> from IDEs, editors, or any other automation.
>>>>
>>>> In the beginning (some years ago) I started installing GNU Make for 
>>>> Windows, putting it in c:\tools\make.  Then I created a simple 
>>>> Makefile and tried to process it on a standard Windows command line. 
>>>> It was a mess!  I remember there were many issues regarding: 
>>>> slash/backslash on file paths, lack of Unix commands (rm, mv, ...) 
>>>> and so on.  Native Windows tools need backslash in the paths, but 
>>>> some unix tools need slash.  It was a mess to transform the paths 
>>>> between the two forms.
>>>>
>>>
>>> Most tools on Windows are happy with forward slash for path 
>>> separators as well. 
>>
>> mkdir, just to name one?  And you need mkdir in a Makefile.
> 
> Don't use the crappy Windows-native one - use msys2's mkdir.  As I said:
> 
> bin_path :=
> RM := $(bin_path) rm
> MKDIR := $(bin_path) mkdir
> 
> and so on.
> 
> Now your makefile can use "mkdir" happily - with forward slashes, with 
> "-p" to make a whole chain of directories, and so on.

Yes, sure, now I know.  I was responding to your "Most tools on Windows 
are happy with forward slash". I thought your "tools on Windows" were 
native Windows commands.

I think your suggestion is: explicitly call msys tools (rm, mkdir, gcc) 
in normal Windows CMD shell, without insisting in using directly the 
msys shell. Maybe this will help in integration with third-parties 
IDE/editors (such as VSCode, C::B, and so on).


> Once you have left the limitations of the Windows default command shell 
> builtins behind, it is all much easier.  For utilities like "cp" and 
> "rm" it is a little more obvious since the names are different from the 
> DOS leftovers "copy" and "del" - unfortunately "mkdir" is the same name 
> in both cases.

Indeed.


>>> Certainly everything that is originally a *nix tool will be fine with 
>>> that.
>>>
>>> Of course if you have a makefile that uses commands like "rm" and you 
>>> don't have them on your path, and don't specify the path in the 
>>> makefile, then it won't work.  This is why the norm in advanced 
>>> makefiles is to use macros for these things :
>>>
>>> # Put this in the host-specific file, with blank for no path needed
>>> bin_path :=
>>>
>>> # Use this instead of "rm".
>>> RM := $(bin_path) rm
>>
>> Initially I insisted using native Windows commands: DEL, MKDIR, COPY 
>> and so on.  Finally I gave up.
>>
> 
> Excellent decision.
> 
>>
>>
>>>> After this attempt, I gave up.  I thought it was much better to use 
>>>> the IDE and build system suggested by the MCU manufacturer.
>>>>
>>>
>>> For most IDEs, the build system is "make".  But the IDE generates the 
>>> makefiles - slowly for big projects, and usually overly simplistic 
>>> with far too limited options.
>>>
>>> But IDE's are certainly much easier for getting started.  On new 
>>> projects, or new devices, I will often use the IDE to get going and 
>>> then move it over to an independent makefile.  (And I'll often 
>>> continue to use the IDE after that as a solid editor and debugger - 
>>> IDE's are generally happy with external makefiles.)
>>
>> I'm going to create a new post regarding editors and debugger... stay 
>> tuned :-D
> 
> You are keeping this group alive almost single-handedly :-)  Many of us 
> read and answer posts, but few start new threads.

I'm the student, your are the teachers, so it is normal I make the 
questions :-D

[OT] I like newsgroups for chatting with others on specific topics. 
Nowadays unfortunately newsgroups are dying in favor of other social 
platforms: Facebook, reddit, blogs.... Do you know of some other active 
platforms about embedded?


>>>> Now I'm trying a Unix shell in Windows (msys, WSL or even the bash 
>>>> installed with git) and it seems many issues I had are disappearing.
>>>>
>>>>
>>>>> And of course you will want an msys2/mingw64 (/not/ old mingw32) 
>>>>> for native gcc compilation. 
>>>>
>>>> The goal of the simulator is to detect problems on the software that 
>>>> runs directly on Windows, without flashing, debug probes and so on. 
>>>> I increased my productivity a lot when I started this approach.
>>>>
>>>> Obviously, the software running on Windows (the simulator) should be 
>>>> very similar to the sofware running on the embedded target.  
>>>> Cortex-M MCUs are 32-bits so I thought it should be better to use a 
>>>> 32-bits compiler even for the simulator.
>>>>
>>>
>>> mingw-w64 can happily generate 32-bit Windows executables.  IIRC you 
>>> just use the "-m32" flag.  It is significantly better than old mingw 
========== REMAINDER OF ARTICLE TRUNCATED ==========