[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Bernard Fouché
Subject: Re: [avr-gcc-list] Re: char to int promotion in bitwise operators
Date: Tue, 25 Aug 2009 12:30:42 +0200
User-agent: Thunderbird (Windows/20090812)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]