Re: [avr-gcc-list] Re: char to int promotion in bitwise operators

[Bernard Fouché]

Weddington, Eric wrote:
> I think, though, for the AVR community, we just need more people willing to 
> dive in and help. The sad thing is, is that there are a lot of places to help 
> that don't require arcane gcc knowledge. The avr-libc project is a great place 
> to learn, and there are lot of place to help, including just helping with 
> documentation. But sometimes it's hard enough to get people to submit a decent 
> bug report, much less building the software, learning to make a patch, fixing a 
> problem, submitting a patch, learning CVS/SVN, etc.
>
>
>   
Hi All.

One may also consider that the first interested party should be Atmel .

Have a look at what Renesas did in 2006: 
http://www.renesas.com/fmwk.jsp?cnt=press_release20061004.htm&fp=/company_info/news_and_events/press_releases. 
See also what is now available at http://www.kpitgnutools.com .

I never used yet Renesas chips so I can't tell if the KPIT GCC 
compilation chain is good or not, and I know that grass is always 
greener on the other side.

Even Microchip seems to have made some progress about providing GCC. The 
following link was given to me recently by a Microchip sale agent:  
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023073 
. (But I did not take time yet to download some of these files and check 
what's really available.)

Here we had to change a few times of AVR-GCC versions only to be able to 
process new AVR chips while keeping older ones up to date.  And each 
time, since GCC 3.4.6, I've seen code bloat with newer versions and had 
to spend time only to get the the same application fit in the same 
memory footprint for older chips using a newer GCC (we want to keep a 
single compiler version for all of our devices).

The time spent this way does not bring any improvement to the 
application, more sales, etc.. Atmel suffers of this, since customers 
that waste time like this don't place orders for their new devices, they 
have to work instead to keep older stuff going on.

While at the same time it's difficult to have a roadmap from Atmel (for 
instance we are currently looking for what could be a xmega with a CAN 
bus interface and we have heard rumors that eventually a new CAN chip 
would come out of Atmel but not based on the avr core), temptation to 
experiment with another founder is greater each day.

And on a less pragmatical point of view, I have great fun writing new 
drivers or improving our application, and zero fun when I have to spend 
time obscuring the code base with macros or tricks  needed only to 
overcome the latest avr-gcc 'improvements'.

   Bernard