A mi consideracion:
Si, crear una tabla alternativa son 40 bytes extra (20 instrucciones si implementas todos los vectores), lamentablemente no se puede reposicionar. Pero pienso que te solucionaría la vida. Haciendo lo que dije esto no seria necesario:
- 20 bytes Comprobar la dirección de escritura en flash (cambio de vector de reset y no escribir páginas de bootloader)
Por que directamente comenzas de cierta pagina. Haciendo que C crea que tiene el mismo integrado pero esta ves con 6 paginas menos de memoria.
Es algo facil de modificar en el archivo de linker. y solo tendrias 20 bytes mas, tal ves gracias a eso tengas otro ahorro. Obviamente tu programa solo requiere una modificacion en el linker que seria la direccion final o el largo de la flash.
Otra ventaja que tendrias es que NUNCA pero NUNCA ante un corte de luz mientras estes programando vas a perder el bootloader, en tu caso aunque sea pequeña la ventana entre borrado de esa pagina de flash + grabacion tenes posiblidades de que ocurra. Si ocurre ¿como pensas "arreglarlo", enviandole el bootloader para que lo grabe la otra persona? ¿un bootloader desencriptado con las llaves a la vista? No serviria de nada tener un bootloader asi a mi parecer, ya que nunca deberia caer en las manos de los demas. Como vos dijiste, creer que te enfrentas al usuario mas bruto posible.
Sino como bien decis tenes que reducir 11 instrucciones. Aunque parezca poco si observas es casi uno de los items mas grandes de tu bootloader y a no ser que saques ( externalizes o quites) uno de esos items no lo veo factible. Y conviene ocupar toda la pagina, completando las 6.
Un posible ahorro seria. Estas usando CALLs/PUSH/POP ? o simplemente son JMP ? si solo usas JMP y no usas el stack podrias evitar iniciarlo.
O si lo usas crear un stack en un punto que no moleste y sea mas facil de cargar, ejemplo que solo la parte alta del stack se cargue. en el registro del espacio I/O y no ambos, son 2 nstrucciones menos.
No se que mas decirte, imagino que lo tenes bien programado y que reducir esos 22 bytes van a doler y mucho. Asi que queda en vos si ves como achicarlo en 5 paginas si es posible o irte por las 6.
Imagino que los vectores del Attiny al estar implementados con saltos relativos, no van a tener problema con el desplazamiento.
Pero eso significa desplazar todo el código. Todo el código debe ser relativo, sin saltos absolutos... (por ejemplo icall Z)
Son todos RJMP, que si ocupas 6 paginas , son 384 bytes y la "nueva tabla" ( tabla del verdadero programa ) comenzaria desde 385, los RJMP ( ocupan 1 palabra ) y acepta valores entre -2K y 2k
El programa en C se manejara como quiera, con RJMP k , con RCALL k, ICALL Z, es decir de forma indirecta o relativa, eso por que cambies las dimensiones de las FLASH no vas a tener control o no va a cambiar.
Tu bootloader lo haces todos RJMP y RCALL ( que ocupan menos cantidad de memoria ) ya que estas dentro del posible direccionamiento de los mismos que es 2K. Y como nombre en la primer oracion, tu maximo objetivo es llegar a la pagina 7 y que esta al alcance por demasia.
Una cosa mas que estas mas al tanto vos del Attiny y tal ves estamos divagando demasiado.
La proteccion contra lectura de la FLASH ¿como funciona?,¿es un bit como en el caso de los PIC ?, ¿hay sectores no protegidos?.
Cuando necesitas grabar en la flash, ¿tenes que deshabilitar la proteccion ?
Si la ultima pregunta es correcta entonces estas ante uno de los agujeros de seguridad que buscas, cualquier persona podria darle actualizar el Attiny y a mitad de programacion desconectarlo, luego leer y con un poco de suerte, si se estaba escribiendo o borrando en ese momento va a tener acceso a toda la FLASH incluido tu bootloader con las Keys. ya que va a estar desprotegido.
