Re: [avr-libc-dev] 1.8.1?

[Weddington, Eric]

Hi Johann,

I'm understand your rant, but from my experience, I can't share in it.

More comments inline below.

> -----Original Message-----
> From: Georg-Johann Lay [mailto:address@hidden
> Sent: Thursday, November 29, 2012 4:55 PM
> To: Erik Walthinsen
> Cc: address@hidden; Weddington, Eric
> Subject: Re: [avr-libc-dev] 1.8.1?
> 
> Sorry to say that, but supporting each device in the compiler / binutils
> is bit of --censored--.

Y'know it's been this way for over 10 years. And other AVR toolchain developers 
before you have given a lot of thought about how to make it easier, with no 
good solution yet. If you have a better solution that will be accepted by the 
GCC project, where the cost of implementing the solution doesn't outweigh the 
benefits, then by all means, let us know.

 
> Will GCC ever support all 1000 or 2000 or how many thousands of ARM
> devices you find on the market? From different vendors, with different
> instruction sets, different packages, different voltages, different
> memory, different internal peripherals, different footprints -- you name
> it?
> 
> No.

First off, are you sure that it would be in the thousands of combinations? Or 
is that just exaggeration? Would the true number of combinations actually only 
reach the hundreds?

And even then, why not support it?

I am all for supporting the entire ARM / SAM family from Atmel. I can't speak 
for other manufacturers; professionally, I have no interest.


> Are professional developers that use ARM + GCC blocked wtherefore?
> 
> No.
> 
> They just add startup code, perhaps a linker script to describe memory
> on their boards and compile for their architecture.
> 
> That's it.

Sure. And you're speaking about those with a Linux background, who are capable 
and willing to build the toolchain from scratch. You have to remember that the 
vast majority of our users (and this is backed up by actual surveys) are from a 
Windows background, which from my 10 years of experience in this area:
1. Don't know how to build the GCC toolchain from scratch (even though 
instructions do exist)
2. Don't want to build the GCC toolchain from scratch
3. Don't really want to mess with understanding the source code of the toolchain
4. Don't want to even look at the toolchain source code much less change it
5. And they want one-stop-shopping: They don't want to have to get tools from 
all over the place. They want a working, full system, all in one place.

So even though you can rant about "professional developers", in reality, it 
just doesn't work like that.

 
> Of course, you can wait until the device pops up in the toolchain.  It's
> comfortable but slow, but as a professional you might consider the bit
> more work, bit less comfortable, but much fast approach explained in
> 
> http://gcc.gnu.org/wiki/avr-gcc#Supporting_.22unsupported.22_Devices
> 
> 99.9% of what you need is the device header, maybe readily available in
> AVR Libc, from the hardware vendor or by adjusting a sister device's
> header to your needs.
> 
> The remaining 0.01% is setting the right command line options.
> 
> And if you do not like that either, hey, it's all free software!
> 
> Contribute to the tools!

Joerg Wunsch and I have been trying to get people to help contribute to the 
open source toolchain for 10 years (or more, in the case of Joerg). Our 
experience has been that there are extremely few people who:
- Have the desire
- Have the skills
- Have the time
- And are willing to do it.

Those are the constraints, and not many people fit within it. You're one of 
those extremely few.

What's even more frustrating for me, is to see how successful the Arduino 
project is in attracting volunteers that actually do good work. I don't blame 
them really. They're building a system on top of the toolchain: a translator, 
many different libraries, etc. But, the skill set needed for Arduino is, 
arguably, not as difficult as it is to work on the toolchain itself. The 
toolchain can be very intimidating to a lot of people in the open source 
community. As a consequence many people shun the projects, wanting to leave it 
up to the "professionals".

 
> For GCC, a new device is a one-liner -- provided core support is
> available which is the case for XMEGA.  For Binutils, a new device is a
> one-liner.  I am not sure what's more expensive:  Hangin around for 3
> years or add 2 lines to the tools?

The fact that many people do it (i.e. wait around) should tell you something. 
Honestly, I'm not surprised. Still saddened, of course, that there aren't more 
volunteers to help with the toolchain.

> Björn Haase from Bosch contributed the complete relaxing framework so
> that they can use devices with more then 64KiWorks flash.
> 
> And other professionals do really wait 3 years or more for a one-liner?

Y'know, sometimes, yes. It's not the one-liner that is intimidating (though, 
honestly, all the crud you have to learn sometimes just to add one line is 
annoying), it's rebuilding the tools *for a Windows host* and making it all 
work. And even then, you have to deal with a dependency tree for building the 
tools. It's not just building GCC, it's building binutils, MPFR, MPC. It's 
setting up a build environment: learning MinGW/MSYS (which has gotten better 
over the years, but I still find it confusing sometimes). If you've never used 
Unix/Linux, learning bash and make. Learning a little about running configure 
scripts, and God forbid, learning some things about autotools. If you're 
dealing with patches, learning the diff and patch utilities and patch formats. 
Oh, and getting a build environment set up to build the documentation, if you 
really want to do it right. That can take a bit of doing too. I'm sure there 
are other things which I've forgotten...

You *have* to understand it from the perspective of an engineer who is mostly 
familiar with Windows, and not Unix/Linux. The learning curve is just too 
steep. Most people have other priorities for their own projects and work. They 
will happily use the open source tools, but getting involved any deeper is a 
completely different beast. And most people just won't do it. That's why we can 
probably count the number of volunteers that have contributed significantly to 
the open source AVR toolchain on barely two hands, and that's over 10 years.

Eric Weddington