Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch.embedded
Subject: Re: Improving build system
Date: Fri, 16 May 2025 15:30:55 +0200
Organization: A noiseless patient Spider
Lines: 197
Message-ID: <1007emf$3penh$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>
 <100752v$3kivm$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 15:30:55 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="73d891a72f05717b4fcf9043c40a17ba";
	logging-data="3980017"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+smbqr0j5uDaEwbZoG3SeSrZgcg/GIFno="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:1cxbBz6aCJH4Eodgmjf0ru6P8Hc=
In-Reply-To: <100752v$3kivm$1@dont-email.me>
Content-Language: en-GB

On 16/05/2025 12:46, pozz wrote:
> 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?
> 

Certainly C programming with avr-gcc is closer to normal C than C 
programming with PIC's and other 8-bit devices.

But I don't want to work with "the most normal C considering the 
limitations of the processor" - I want to work with normal C and C++.

I don't want to have to think about using "uint8_t" instead of "int" 
because of processor efficiency.  I don't want to be limited in my 
pointer usage because the processor can't handle pointers well.  I don't 
want to have a non-linear memory, where pointers to flash are different 
to pointers to ram and bigger devices have a mess of address spaces and 
linker complications if you have large blocks of read-only data.  I 
don't want my C++ restricted because of severely limited calling 
conventions, pointer usage, and limited registers.

ARM core microcontrollers these days are significantly smaller, cheaper 
and lower power than AVRs in most categories.  There's a few situations 
in which AVRs might still be the best choice in a new product, but I 
consider them legacy devices, with development only for minor updates to 
existing products.

(I'll be happy to switch to RISC-V to replace or complement ARM.)

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

Neither.  It was independent, based on voluntary work, with Atmel making 
half-hearted support on occasion.

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

The Arduino IDE and libraries are great for quick tests, getting 
familiar with hardware, hobby projects, and proofs-of-concept, but 
terrible for serious work.

But yes, you can do real work with AVRs without Microchip or Atmel's IDE's.

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

Ah, okay.  Many programs that come with Windows /are/ happy with forward 
slashes for paths - because the relevant Windows API's are happy with 
forward slashes.  But the old stuff, especially the commands built into 
the old command shell, can't handle them.  There will also be trouble 
for commands that use forward slashes for flags and other parameters.  I 
meant that there is no problem with utilities compiled on Windows that 
run natively (as distinct from under WSL, or restricted to a bash shell, 
or something like that).

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

Yes, exactly.

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

I too like Usenet as the non-social social network :-)

I suppose some day I will join reddit.  The comp.lang.c and 
comp.lang.c++ newsgroups are quite active, and might be of interest to 
you.  comp.arch has some interesting conversations too sometimes.  (And 
there is always sci.electronics.design, if you want a somewhat 
anti-social newsgroup that occasionally talks about electronics.)

>>
>> It looks like you don't have the 32-bit static libraries included in 
>> your msys2/mingw64 installation - these things are often optional.  
>> (It might be referred to as "multi-lib support".)  I haven't used gcc 
>> on Windows for a long time - most of my work is on Linux.  But I'm 
>> sure that you'll find the answer easily now you know it is the 32-bit 
========== REMAINDER OF ARTICLE TRUNCATED ==========