Con un passaggio intermedio: dall'ethernet si scrive un file sulla sd e il bootloader poi leggerà questo file per scriverlo nella flash. Non si può fare?

Quando la funzione per richiamare il bootloader si attiva non fa altro che resettare a software, jump a 0, il micro in modo da cedere il controllo al bootloader che per un certo tempo, qualche decimo di secondo......

Non sono sicuro che un jump a 0 vada bene. Non so se, in presenza di bootloader, la prima istruzione eseguita è alla locazione 0 o alla prima locazione di memoria del bootloader.

Lo sai che mi ha fatto venire il dubbio? Sono tornato a vedere nei miei post passati perché lo avevo sempre chiamato astrobeed... 

Ho cambiato la licenza del progetto. Ho messo la GNU GPL v3 (così come è l'optiboot iniziale) con la Common Creative BY (attribuzione) + SA (share alike - condividi allo stesso modo).

Non c'è nessun altro che vuol partecipare al progetto?

Mi sembra più seria di quella che ho trovato io... 

@astrobeed
Lo so che va modificato il bootloader. E' l'unico modo per modificare in sicurezza il programma. Scriverlo da zero mi sembra eccessivo, dovrebbe bastare modificare l'attuale.

@leo
effettivamente bisogna prevedere un sistema di criptazione dei dati, ma per il momento non credo che sia necessario. In futuro magari prevederemo che il file da caricare sia prima decriptato. Potremmo ad esempio utilizzare questo: http://www.literatecode.com/aes256

Ma così è esattamente quello che fa adesso... In pratica stai suggerendo che ci sia un pc collegato all'arduino, il quale lo si comanda da remoto con teamviewer per eseguire l'aggiornamento... Dov'è la novità? Noi stiamo cercando di rendere arduino indipendente in modo tale che sia programmabile direttamente mediante una rete ethernet (e di conseguenza internet).

Bellissima!!! Non sapevo esistessero... =)

@kattivik76
Puoi cambiare il titolo del topic in uno più consono? Altrimenti molte persone che potrebbero essere interessate all'idea non entrano nel progetto...

@leo
Lo so che il programma può scrivere nella flash ma bisogna stare attenti a dove si andrà a scrivere.... Poiché non si può sapere a priori in quali aree della flash saranno collocate le varie parti del programma si rischia di fare un macello. Bisognerebbe creare un secondo bootloader, ovvero un'area di memoria dedicata alla parte del programma che dovrebbe prendere i dati dalla sd per caricarli nella application, ma non è possibile.

@pablos
La EEPROM può contenere qualunque cosa, ma sono quello che è presente sulla flash può essere eseguito. Potenzialmente si potrebbe copiare lo schetck sulla EEPROM per poi copiarlo sulla flash, ma ha pochissimo spazio...

Comunque per entrare nel bootloader non è necessario scomodare il watchdog, si può prevedere (in asm) un jump alla prima locazione di memoria del bootloader stesso (si guardi la pag. 294 del datasheet http://www.atmel.com/dyn/resources/prod_documents/doc8271.pdf). Adesso non so a quanto è impostata la dimensione dell'area destinata al bootloader ma, per esempio, se fosse 2048 words per entrare nel bootloader basta una:

Code:

asm volatile ("jmp 0x3800"::);

Piccolo chiarimento per chi (non so) non sapesse come è strutturata la flash e il bootloader. Il micro ha una sola flash, nella quale sono scritte le istruzioni che deve eseguire. Questa può essere divisa in due parti: una per il bootloader e l'altra per il programma utente. Lo scopo per primo e appunto di rendere disponibile una procedura semplice per caricare un programma nell'application.
Un programma può modificare la flash attraverso due istruzioni, LPM e SPM (lettura e scrittura). Tornando al dubbio che ho esposto prima, i lock bits sono corretti perché impediscono che il bootloader venga modificato dal programma mediante la SPM.

@Pablos71
Come dice leo, non credo proprio che un programma possa modificare se stesso perché dovrebbe scrivere nell'application, che però è attualmente in esecuzione. Diventerebbe un cane che si morde la coda... Secondo me è necessario modificare il bootloader.

Più che la banda penso che il problema sia nel numero di post che sono memorizzati nel database. Secondo me è proprio il database che fa da collo di bottiglia...

Vediamo se è possibile... Se si può fare tanto meglio...

Mi sfugge una cosa: con un programmatore sto guardando i lock bits del mio mega2560 e sono come l'immagine allegata. Se le istruzione SPM e LPM sono bloccate nell'area di boot, com'è possibile che il bootloader scriva nella flash lo scketch in arrivo dalla seriale?

Premetto che non ho esperienza con l'ethernet, ma non converrebbe partire con l'arduino ethernet direttamente invece che utilizzare l'uno e montare lo shield sopra?

Se posso unirmi sarei interessato anche io. Conosco "abbastanza" bene gli AVR perché all'università c'hanno fatto un corso sull'atmega32 e per il mio progetto di tesi (che fra l'altro discuterò il 16 dicembre...   )ho utilizzato un Arduino Mega2560.

Solo non ho esperienza di come si porti avanti un progetto su google-code...  

P.S. Proporrei di cambiare il nome al Topic...