Re: [avr-gcc-list] uisp is now on savannah.gnu.org

[Marek Michalkiewicz]

> I've just completed setting up the uisp project on savannah.gnu.org. The 
> new home for the project is here: 
> 
>   http://savannah.gnu.org/projects/uisp/

Thanks.  Another related project I'd like to mention:

  http://www.openh.org/projects/pavr/

and, as I've just discovered, Jason independently came to the same
conclusion that I did: design the new programmer hardware based on
ATmega8 in TQFP32 - see TODO in uisp :) (second pin-compatible choice
could be the 4433, cheaper and easier to get, no boot loader though).

> Hopefully, this new home will allow others to help with the maintenance of 
> uisp and leave Marek more time to work on avr-gcc and avr-binutils.

Speaking of which, I've just fixed a few GCC bugs that appeared while
I was asleep (moving, overworked, underpaid, no permanent Internet access
at home, etc.).  Please test the latest sources from CVS, which should be
released as GCC 3.2 in a few months.  But your good old stable branches
are not abandoned yet - a few fixes will be in 3.0.5 and 3.1.1 as well...

I'd recommend to start with upgrading binutils to the version from CVS.
Nothing should break (GCC 3.0, 3.1 and "soon 3.2" CVS should all work),
and if you have ideas what should be changed in the new linker scripts,
now is good time to tell me.  Things I already know of:

 - C++ support (section for constructor list)
 - .init0 ... .init7 code sections so make it easier for the user to
   insert code to execute early on startup
 - .noinitdata section, like BSS but not cleared after reset, for data
   in SRAM with battery backup, use __attribute__((section(".noinitdata")))
   in C declarations of such variables
 - __heap_start and __heap_end symbols for use by malloc (heap end might
   not always be below the stack as is assumed now - for example, ATmega161
   errata requires stack in internal SRAM if external SRAM is used, and
   internal SRAM is faster so it's a good idea anyway).

ATmega128 support is almost done now, support for a few other new devices
will need writing new io*.h include files.

Marek

avr-gcc-list at http://avr1.org