leo72:
Ho provato a compilare i sorgenti, ma ottengo questi errori:
avrdudequi.cpp: In constructor ‘AvrDudeQui::AvrDudeQui(QWidget*)’:
avrdudequi.cpp:32:5: error: class ‘AvrDudeQui’ does not have any field named ‘currentPath’
avrdudequi.cpp: In member function ‘void AvrDudeQui::loadHex()’:
avrdudequi.cpp:91:31: error: ‘currentPath’ was not declared in this scope
avrdudequi.cpp: In member function ‘void AvrDudeQui::writeData()’:
avrdudequi.cpp:204:9: warning: unused variable ‘result’ [-Wunused-variable]
make: *** [avrdudequi.o] Errore 1
Ho prelevato la versione attualmente online.
Leo apprezzo il fatto che ti sia scaricato la versione dal repo, purtroppo anche sistemando quell'errore ti ritroveresti con altri problemi di compilazione seri
che so già come affrontarli ma non sono di immediata soluzione.
Andiamo per gradi:
L'errore dice che "currentPath" non è membro della classe avrdudequi e invece lo è, e aprendo il file avrdudequi.h si vede che currentPath è membro publico, per cui potrebbe trattarsi di corruzione del pacchetto che hai scaricato (a me è già capitato).
Altro problema, serio e che il programma necessità come dipendenza HAL che non è più un pacchetto incluso di default nelle distrò, non so neanche se questo pacchetto sia presente sul repo delle distrò. Oltre ad HAL serve DBUS. Le distrò ora hanno migrato verso libudev e anche libudev non sarà più un pacchetto disponibile separatamente, ma inglobato in systemd che come intuisci è un demone di sistema, l'obbiettivo delle distrò è molteplice uno di questi obbiettivi sembra essere la gestione di servizi ad applicazioni un user space, cioè scrivo codice semplice nel sorgente della mia applicazione per ottenere qualcosa di simile a:
é stato inserito un dispositivo usb e mi risulta che tu volevi essere avvisato.
Il dispositivo xxx è stato rimosso dal sistema.
ecc.
Quindi al momento è roba per sviluppatori, non ti impelagare con queste cose, sarà mia premura sistemare il problema usando libudev, so già da dove prendere il codice " arduIDE", che gestisce la cosa sia tramite DBUS-HAL che tramite libudev.
Lasciamo perdere queste cose, mi interessa prendere una decisione in merito alla logica di funzionamento del programma.
@Astrobeed:
La cancellazione della flash ha come effetto portare tutti i bit a 1, quindi il singolo byte vale 0xff, però non è la stessa cosa di scrivere questo valore nei byte, la cancellazione avviene tramite un apposito processo, gestito internamento dal micro, che è diverso da quello utilizzato per la scrittura.
Io ho dato uno sguardo al sorgente di avrdude e ho trovato:
#define CMD_CHIP_ERASE_ISP 0x12
Che è il comando da inviare ad ISP per effettuare la cacellazione, quindi sembra la conferma che si tratta di una funzione speciale che poco a che vedere con l'impostazione di tutti i byte a 0xff.
Ora ho pensato di lasciare agire avrdude nel modo consueto, cioè esegue un CMD_CHIP_ERASE prima della scrittura in flash, allora posso inserire nella GUI una checkbox: (x preserva contenuto EEProm), preservo la eeprom in questo modo:
Prima di avviare avrdude per scrivere in flash, avvio avrdude per salvare la eeprom in un file, poi avvio avrdude per scrivere in flash, e alla fine avvio avrdude per scrivere la eeprom leggendo il contenuto dal file salvato prima.
Ora mi chiedo? ma il comando chip erase cancella tutto il chip incluso i lock bit, i fuse ma a rimettere le cose apposto ci pensa avrdude, oppure i fuse e lock bit non vengono cancellati da un chip erase. Nel manuale di avrdude c'è scritto che con l'opzione -e si esegue un chip erase che cancella tutto.
Comunque che ne dite di quella checkbox?
La EEPROM, funziona in modo diverso dalla flash, non richiede la cancellazione preventiva delle celle per poterle riscrivere, o meglio l'operazione di cancellazione viene fatta contestualmente durante la scrittura della cella, infatti puoi modificare a piacere un singolo byte quante volte vuoi (entro i limiti previsti dall'endurance), con la flash questo non è possibile, prima devi cancellare l'intero blocco dove si trova quel byte, o gruppo di byte, e solo dopo averlo fatto puoi scrivere.
Ok questo lo avevo letto, ma.... cosa accade se il programma presente in flash è più grande del programma che sto scrivendo? Se cancello tutto con chip erase è tutto nella norma, se invece riuscissi a cancella solo il/i blocco/cchi necessari a contenere il programma che sto scrivendo rimarrebbe traccia del programma precedente. E visto che la eeprom ha una vita più lunga della flash eseguire un chip erase non ha controindicazioni hardware.
Mentre con il contatore di scrittura come mi comporto, non c'è modo di sapere se gli ultimi 4 byte sono il contatore di flash o servono all'applicazione, questo lo può solo sapere l'utente, quindi penso che mettero una voce nel menu a tendina "leggi il contatore della vita flash" o qualcosa di simile e un'altra voce "inizializza contatore di vita flash", o simile, a proprosito si accettano suggerimenti.
Che ne pensate?