> I have no idea why the Xmega should be so slow other than your choice of
> the checksum/CRC algorithm.
Right now I'm using the AVR-LibC XMODEM-CRC, for historical reasons
rather than mathematical reasons.
Make file snippet:
mv $(OBJDIR)/$@ $(OBJDIR)/$(TARGET).org.hex
srec_cat $(OBJDIR)/$(TARGET).org.hex -Intel -Little_Endian_CRC16 -max
$(OBJDIR)/$(TARGET).org.hex -Intel -Cyclic_Redundancy_Check_16_XMODEM
-Fill 0xFF -OVER $(OBJDIR)/$(TARGET).org.hex -Intel -Output
$(OBJDIR)/$(TARGET).hex -Intel
Program Snippet (Don't have the newer _u32 sources at hand right now):
for( crc_u16 = i = 0; i < flash_end_u16; i++)
{
byte_u8 = pgm_read_byte( i );
crc_u16 = _crc_xmodem_update( crc_u16, byte_u8 );
}
> If it *is* the speed of reading flash, I
> would be, well, surprised. After all, you *run* from that flash, right?
Not exactly in the case of the XMega.
The XMega has a separate memory controller for the different
categories of memories to access read or write from them, which is
different than running from Flash.
--
http://blog.softwaresafety.net/
http://www.designer-iii.com/
http://www.wearablesmartsensors.com/
_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
