[avr-gcc-list] Re: bootloader / flash coding / avr

[Reza Naima]

> 1. I would seriously consider NOT licensing it under GPL unless you have to. 
> The BSD license is
> less restrictive, and that way other people can use it freely in commercial 
> products without
> having to give away other parts of their code.

Sounds good to me.

> 2. All the functions that are called in your bootloader() need to have 
> BOOTLOADER_SECTION placed
> after their prototypes. This means you need to write prototypes for TxChar, 
> RxChar, flushUSB.
> Also, any variables that are needed for the bootloader, also need to placed 
> under
> BOOTLOADER_SECTION, such as usb_boot_dev. Everything in the bootloader must be 
> "self-contained"
> and put into the "bootloader memory" (NRWW); you shouldn't make any calls that 
> reference the RWW
> memory that you're trying to modify. Sorry that this really isn't documented 
> anywhere yet.

I considered this.  The functions were originally declared 'static 
inline', but to be on the safe side, I also tried making them macros or 
coping the code directly into the bootloader function.  With regards to 
the variable declaged global (usb_boot_dev), it's a pointer to the 
externally mapped memory, which is how I talk to the USB device.  
Someone else posted about making this an 'auto' variable -- I'm not sure 
what that entails exactly.  I'm wondering if this is the problem I'm 
having.. Any thoughts?

> 3. sbi will be deprecated soon. Use direct access instead: MCUCR |= SRE; As 
> long as you have
> optimization turned on, GCC will generate the correct instructions.

Good to know, thnx.  I was reading somwhere that bitwise operations seen 
to be cast, or else the compiler casts themt to 16 bit values.  Would it 
be true with the above?  Should I do MCUCR |= (unsigned char) SRE;  
instead, or does it not apply here?

> 4. boot_mem_read() will not be a part of the final bootloader support API. 
> There is a new
> pgmspace.h API in the avr-libc CVS that provides better read functionality. 
> Replace it with
> pgm_read_byte().
>  

I noticed pgm_read_byte in your demo code.  It took me a bit to realize 
it's in CVS now.  I'll wait till the code gets pushed out to an rpm, 
then I'll change.

> 5. Try testing just writing to the flash first, without doing the 
> communications, using some
> test data and getting just that part working. Then adding the comms stuff. I 
> have gotten a
> bootloader working at 0x1E000 with a mega128.
>  

Well,  I thought doing the communication would be easier.   I'm still 
wondering about the stack.  If that function lives in 0x1E000 only, then 
on a reset, the stack/etc.. are not initialized.  Will the function 
still work?   Also, why does it fail to work when I just relocate the 
function to, say, 0x500 (when called as a function)? 

One last question, A friend suggested using the NORETURN attribute to 
optimze the code (so it will not save the registers from the calling 
function), yet it didn't do anything.  Does the back-end of gcc ignore 
this?   

Thanks,
Reza