Notes

Notable gcc macros

• _ORDER_LITTLE_ENDIAN_ and _BYTE_ORDER_
• _AVR_MEGA_ - avr tiny vs mega
• _OPTIMIZE_
• _GXX_WEAK_ - does this mean that weak functions are ok?
• _DEPRECATED - does this tell that _debrecated is available?
• _AVR_IOXXX_H_
• _SFR* - macros in avr/io
  • _SFR_IO_REG_P will tell if sfr_ptr is in IO range (sbi and sbi works) * _SFR_MEM_ADDR(sfr) == ((uint16_t) &(sfr))
  • _MMIO_BYTE == _SFR_MEM8, _MMIO_WORD == _SFR_MEM16
  • compare to _SFR_IO_ADDR and _SFR_IO8, _SFR_IO16
  • _SFR_ADDR == _SFR_MEM_ADDR, _SFR_WORD

Using bootloader code in user application

• Some kind of API need to be published and known for user code linker

• Jump to bootloader:

  I've written a simple bootloader in ASM (avr-gcc -x assembler-with-cpp) and when It's finished receiving/writing data I thought that a 'rjmp 0' would jump to absolute address 0, but instead it jumps to address 0 of the current section. ... Which, in my case, is 0x1e00 .... The only solution that worked for me was the 'defsym' trick that Manison described (thanks !)

  So, instead of 'rjmp 0' I used 'rjmp homebase' and set homebase=0 in the linker stage ... : Code:

  .section .bootloader,"ax",@progbits main: ldi tempreg, lo8(RAMEND) out _SFR_IO_ADDR(SPL), tempreg ldi tempreg, hi8(RAMEND) out _SFR_IO_ADDR(SPH), tempreg

  rcall init_uart **** BOOTLOADER CODE **** rjmp homebase ; Do or die ...

  And built like this: Code:

  avr-gcc -Wall -c -x assembler-with-cpp -mmcu=atmega8 boot_avr.s -o boot_avr.obj

  avr-ld --section-start .bootloader=0x1E00 --defsym homebase=0x00 boot_avr.obj -o boot_avr.elf

  avr-objcopy -j .bootloader -j .constants -O ihex boot_avr.elf boot_avr.hex