Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32434

Re: Improving build system

Show all headers | View raw

Il 16/05/2025 15:30, David Brown ha scritto:
> 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.

We were comparing 8-bits cores.  Obviously ARM Cortex-M MCUs are much 
nicer to program.  Anyway I disagree on the "cheaper".

Digikey sells 1000pcs of ATmega328PB-AU at 1.17€ in tray.
ATSAMD20E14B-AUT at 1.76€ as a cut-tape. This MCU has only 16kB of Flash.


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

I usually read the first.


> comp.arch has some interesting conversations too sometimes.  

Subscribed.


> (And 
> there is always sci.electronics.design, if you want a somewhat 
> anti-social newsgroup that occasionally talks about electronics.)

:-D


>>> 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 
>>> static libraries (libmingw32.a) that you are missing.
>>
>> On many places they suggest to use msys2/mingw32 for generating 
>> 32-bits Windows binaries. For example here[1].
>>
>> [1] 
>> https://superuser.com/questions/1473717/compile-in-msys2-mingw64-with-m32-option
>>
> 
> Try looking in other places :-)
> 
> To be honest, I have not looked at this - I don't need to use gcc on 
> Windows myself.  And neither my Windows nor my msys2 / mingw64 
> installation have been updated in many years - the tools I need don't 
> change much.  But I have no doubt that mingw64 /can/ generate 32-bit 
> Windows binaries, that your problem is the missing static libraries, and 
> that it is a significantly superior toolchain to the older mingw - 
> primarily because that uses the slow, outdated and limited external MS 
> DLL's for standard C library functions.

Anyway I'm not able to fix the error I have. I will look in some other 
places.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Improving build system pozz <pozzugno@gmail.com> - 2025-05-13 17:57 +0200
  Re: Improving build system Nicolas Paul Colin de Glocester <Spamassassin@irrt.De> - 2025-05-13 22:48 +0200
  Re: Improving build system David Brown <david.brown@hesbynett.no> - 2025-05-14 11:03 +0200
    Re: Improving build system George Neuner <gneuner2@comcast.net> - 2025-05-14 15:21 -0400
      Re: Improving build system David Brown <david.brown@hesbynett.no> - 2025-05-15 09:48 +0200
      Re: Improving build system Nioclás Pól Caileán de Ghloucester <Spamassassin@irrt.De> - 2025-07-04 18:38 +0200
    Re: Improving build system pozz <pozzugno@gmail.com> - 2025-05-14 23:51 +0200
      Re: Improving build system Nicolas Paul Colin de Glocester <Spamassassin@irrt.De> - 2025-05-15 01:00 +0200
        Re: Improving build system David Brown <david.brown@hesbynett.no> - 2025-05-15 11:17 +0200
          Re: Improving build system Nicolas Paul Colin de Glocester <Spamassassin@irrt.De> - 2025-05-16 12:21 +0200
            Re: Improving build system David Brown <david.brown@hesbynett.no> - 2025-05-16 14:42 +0200
      Re: Improving build system David Brown <david.brown@hesbynett.no> - 2025-05-15 11:03 +0200
        Re: Improving build system pozz <pozzugno@gmail.com> - 2025-05-15 23:25 +0200
          Re: Improving build system David Brown <david.brown@hesbynett.no> - 2025-05-16 11:12 +0200
            Re: Improving build system pozz <pozzugno@gmail.com> - 2025-05-16 12:46 +0200
              Re: Improving build system David Brown <david.brown@hesbynett.no> - 2025-05-16 15:30 +0200
                Re: Improving build system pozz <pozzugno@gmail.com> - 2025-05-16 16:17 +0200
    Re: Improving build system pozz <pozzugno@gmail.com> - 2025-05-16 15:45 +0200
      Re: Improving build system David Brown <david.brown@hesbynett.no> - 2025-05-16 17:20 +0200
        Re: Improving build system pozz <pozzugno@gmail.com> - 2025-05-17 10:56 +0200
  Re: Improving build system Stefan Reuther <stefan.news@arcor.de> - 2025-05-14 18:06 +0200

csiph-web