I want to use the AV231 bootloader (version ported to gcc), except send the data over a wireless interface (Nordic NRF24L01) instead of a UART.
Instead of sending data one byte at a time, I think performance would be much better if I use the maximum RRF24L01 frame size of 32 bytes to send 32 bytes at a time at 1 Mbs.
So, that means I'll have to modify the pc code that creates the encrypted flash/eeprom records from Intel hex code format, the pc code that sends that data to the Atmega328p, and the bootloader code that receives the data and writes the flash/eeprom.
The pc code calculates a maximum frame size based on the page size of the target device. For an Atmega328p, it's 75--larger than the maximum NRF24L01 frame size. 16 byte records are added to the frame until the frame (including overhead) would exceed 75 bytes. When that happens, the frame is sent and a new frame is created.
So, I could do hack something like encapsulate the frame data in something that allows reassembling the frame from 32 byte chunks. That way, frames could be reconstructed to look exactly like they would have looked after reception by UART and reconstruction.
But, a simpler implementation might set the maximum frame to 32 in OutputWriter::OutputWriter (outputwrite.cpp line 391).
I'll keep studying the code, but there's a lot to digest. I was hoping someone who's already familiar with the bootloader could tell me if I'm going down the wrong path. For example, maybe the instructions in the AVR that program the flash only work on an entire 64 byte page instead of the 16 byte encrypted records that the frames contain.
In other words, is the maximum frame size just a maximum set for optimal performance and smaller frame sizes would work at the expense of some performance?