Solo quiero corregirme una cosa en AVR-LIBC el archivo de startup/c_init o como se le quiera llamar, que es el que esta ubicado en el vector de reset se llama:
crt0.S o crt1.S
Este archivo lo que hace es como ya dije inicializar el stack, copiar los valores de una tabla desde la flash a la RAM, para inicializar las variables de la seccion .data (variables inicializadas), inicializa registros para los saltos indirectos. y creo que nada masi.
La aplicación también usa I2C. No tiene sentido que duplique el código. Lo mejor es utilizar la misma rutina que ya tiene el bootloader, llamándola desde la aplicación.
Así ahorro espacio.
El problema es llamar a una función del bootloader desde otro código fuente distinto. Hay que ponerse de acuerdo en dónde van a estar las variables (el buffer por ejemplo).
Hay muchas soluciones y no sé cual será la mejor. Creo que me voy a decantar por los punteros, que parece más sencillo que la memoria global fija.
Nuevamente si tenes funciones en C, compiladas desde C, apenas entra el ASM generado va a guardar los datos al stack y van a tratar de utilizar todas las variables inicializadas como si ahi estuvieran, si vos quitas el esa inicializacion del vector de reset entonces no hay ciencia cierta de que pueda salir de esa funcion, aunque podrias llamarlo luego desde tu bootloader, pero deberias modificar ese codigo ASM. Asi que estas un poco como obligado a hacerlo. En ves de llamar a tu bootloader desde el vector de reset, usas esta funcion, usas el main() para tu bootloader, ya que ahi salta siempre estos codigos.
#ifdef __AVR_ASM_ONLY__
XJMP main
#else /* !__AVR_ASM_ONLY__ */
XCALL main
#endif /* __AVR_ASM_ONLY__ */
; .endfunc
La ubicacion esta a tu gusto, veras los pros/cons de cada uno.
El main(bootloader) ubicado al comienzo, todo lo demas apartir de la proxima pagina, I2C, todo tu programa. Sus ventajas es que esta todo juntito no hay problemas, las desventajas es que no podes reescribir los vectores de interrupcion, a no ser que crees una tabla aparte poniendole todos saltos y ubicandola en otro lugar.
La otra es ponerlo al final de la flash. Lo bueno de esto es que se podria reescribir, ya que una ves ejecutado la inicializacion ya no te importa mas esa rutina de crt0.S y podes trabajar en C tranquilo, desventajas perder algo mas de espacio.
Con respecto a la ubicacion de los I2C, creo que hay 2 opciones.
- Una es como decis, la de poner punteros a la funcion en valores de memoria fijos ( tal ves al comienzo del todo el codigo ), tomar ese valor y llamarlas.
- La otra es poner la funcion de I2C junto con el bootloader si es que entra en una pagina todo. Suponiendo que no vuelva a cambiarse (por que funciona perfectamente) y ademas todo va a depender si hay espacio para eso E imagino que vas a tener que realizar lo mismo con punteros pero ahora para tu programa.
No entiendo por que tendrias problemas con el buffer, simplemente crealo en C, que lo acomode solo el linker y lo llamas desde ahi. Total esta en la RAM. Si queres utilizar el I2C en C entonces ya va a estar creado todo lo de las variables
4. La recuperación ante errores es otro tema que estoy estudiando. Quiero combinarlo con una comprobación de memoria.
El bootloader se inicia primero. Comprueba la Flash. Si el checksum no es correcto, no inicia la aplicación y se queda en modo bootloader.
Normalmente tenes 2 comprobaciones de memoria, una en el envio de datos, por ejemplo cada 4 bytes , enviar 1 byte de cheksum. y la otra es cuando grabas y comprobas lo grabado.
Lo que si hay que ingeniarsela que ante un corte de corriente etc que haga que se resetee mientras grababa las primeras posiciones no afecte en nada. Esto es lo mas complicado. Ya que como minimo necesitarias de esos algunos bytes como para tener la rutina de inicializacion + vectores de interrupcion (todo por el I2C en C), sino con que grabara unicamente el vector de reset ya no habia forma de errarlo, no creo que justo falle en el primer byte .
Igual esto puede pasar casi nunca. pero mejor intentar prevenir que curar.
7. En cuanto al RC4, el problema no es implementarlo, que es muy fácil.
Lo que quiero sabe es si es mejor opción que el XTEA.
XTEA es mas seguro. Si es que a eso vamos. No importa tanto lo eficiente, si esto se va a ejecutar solo cuando vayas a grabarlo.
. La solución Python no me gusta porque supone que el cliente tendrá Python instalado o que lo va descargar en formato portable.
En cualquier caso ocupa mucho. Preferiría utilizar LUA o una aplicación compilada (VisualBasic o similar)
No entiendo por que debe tener python instalado el cliente, vos provees con el archivo encryptado con la extension que quieras, se envia encryptado al micro y en el micro antes de grabarlo se desencripta. Y una clave que solo tengas vos y este dentro del integrado nomas.
Sino no tiene sentido.
Es vulnerable si el programa "cliente" lo desencripta y luego envia sin encriptar
Y menos que menos si se lo das desencriptado y que el programa lo encripte para que el micro lo desencripte.
