Frontend per avrdude; cerco consigli

Quando ho tempo lo dedico anche al frontend AvrDudeQui : https://gitorious.org/avrdudequi/avrdudequi
*** Il codice in sviluppo è diverso da quello nel link, devo ancora fare il push ***

Ho introdotto un editor binario usando questo progetto : GitHub - vilkov/qhexedit2: Fork of the original QHexEdit widget (http://code.google.com/p/qhexedit2).

Ora ho ancora da sistemare i dettagli:
avrdude cancella tutto il micro, EEprom inclusa, prima di ogni scrittura (default) per evitare ciò basta usare il flags -D.
Il flags -y o -Y value, per dire ad avrdude di leggere gli ultimi 4 byte di eeprom e riscriverli dopo una cancellazione del micro o una riscrittura della flash, di modo che gli ultimi 4 byte rappresentino il contatore di scritture in flash.

Non sono bene come comportarmi con questi flags, inizialmente ho pensato di inserirli nella GUI così che l'utente possa spuntare la checkbox corrispondente al flags, poi invece ho pensato che sarebbe meglio cercare una strada più semplice per l'utente.

Disabilito la cancellazione totale sempre usando -D, quando l'utente vuole cancellare la flash o eeprom clicca erase eeprom o erase flash, ciò che avviene internamente è la seguente:
Creo un file di dimensioni adatte alla flash o eeprom contenente tutte le celle inizializzate a 0xff e lo scrivo in flash o in eeprom, il risultato dovrebbe essere lo stesso, o ci sono controindicazioni?

Per il flag -y, il programma esegue una lettura in eeprom per vedere se gli ultimi quattro byte contengono un valore, in tal caso potrebbe trattarsi del contatore o anche di dati necessari all'applicazione. Come lo segnalo all'utente, come mi regolo con questi quattro byte e il flags -Y value ecc.

Di default avrdude cancella il micro prima di scriverci sopra, questo significa che ogni "flashatura" comporta la perdita di due cicli di vita?

Capisco che vi chiedo molto, ma ho solo bisogno di un piccolo aiuto. :stuck_out_tongue:

Ciao.

MauroTec:
Di default avrdude cancella il micro prima di scriverci sopra, questo significa che ogni "flashatura" comporta la perdita di due cicli di vita?

No, il ciclo di vita delle flash è sempre inteso come operazioni di cancellazione, che avviene per blocchi di n byte, e non di scrittura, spesso si tende a mischiare le due cose perché per poter scrivere prima è indispensabile cancellare.

x iscrizione

astrobeed:

MauroTec:
Di default avrdude cancella il micro prima di scriverci sopra, questo significa che ogni "flashatura" comporta la perdita di due cicli di vita?

No, il ciclo di vita delle flash è sempre inteso come operazioni di cancellazione, che avviene per blocchi di n byte, e non di scrittura, spesso si tende a mischiare le due cose perché per poter scrivere prima è indispensabile cancellare.

Non ho capito al cento per cento. Cosa conviene allora?
Uso avrdude senza il flags -D e lascio che sia l'utente a salvare il contenuto della eeprom per poi riscriverla, cosa mi consigli?

Ok allora è indispensabile cancellare prima di scrivere, ma perchè avrdude cancella anche la eeprom?

Intuisco che la cancellazione è una operazione di basso livello e non equivale a scrivere tutti i byte a 0xff, giusto?

Sono confuso. :roll_eyes:

Ciao.

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.

MauroTec:
Non ho capito al cento per cento. Cosa conviene allora?
Uso avrdude senza il flags -D e lascio che sia l'utente a salvare il contenuto della eeprom per poi riscriverla, cosa mi consigli?

La EEPROM è una cosa diversa dalla flash, se deve essere cancellata durante la programmazione è una cosa che deve poter scegliere l'utente, a volte fa comodo cancellarla perché deve essere reinizializzata dal programma al primo avvio oppure deve rimanere inalterata perché contiene dati di preset che devono essere conservati.

Ok allora è indispensabile cancellare prima di scrivere, ma perchè avrdude cancella anche la eeprom?

avrdude fa quello che gli dici tu, ha solo un certo comportamento di defualt imposto da chi l'ha realizzato, ma non è detto che sia la norma.

Intuisco che la cancellazione è una operazione di basso livello e non equivale a scrivere tutti i byte a 0xff, giusto?

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.
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.

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?

  1. chip erase:
    l'erase dovrebbe azzerare in toto il chip, compresi i fuse ed i lock bit.

c'è un fuse dei microcontrollori (EESAVE) che serve a preservare la Eeprom dalla cancellazione del chip.

Contatore di cancellazioni. Potresti prevedere una voce "inizializza chip" in modo da scrivere il contatore su un chip nuovo. Però se l'utente non sceglie di selezionare la voce per mantenere ed aggiornare questo contatore, diventa tutto inutile...

  1. chip erase:
    l'erase dovrebbe azzerare in toto il chip, compresi i fuse ed i lock bit.

E quindi avrdude fa la magia quando scrive in flash, visto che prima di scrivere fa fuori anche la eeprom penso esegua un chip erase. Per i fuse e i lock bit rimangono quelli, quindi li salva prima del chip erase e li riscrive dopo il chip erase.

c'è un fuse dei microcontrollori (EESAVE) che serve a preservare la Eeprom dalla cancellazione del chip.

Vero , quindi lascio al'utente il compito di salvare la eeprom in un file e uso sempre la modalità di avrdude senza -D.
Grazie a questa cosa non ci avevo pensato, molto più semplice.

Contatore di cancellazioni. Potresti prevedere una voce "inizializza chip" in modo da scrivere il contatore su un chip nuovo. Però se l'utente non sceglie di selezionare la voce per mantenere ed aggiornare questo contatore, diventa tutto inutile...

Per il contatore la cosa si complica un po, ma ho già deciso di mettere delle voci nel menu così l'utente deve andarle a cercare anziche trovarsi una o più voce di spunta. Con la voce del menu apro un a dialog che accompagna l'utente nell'inizializzazione e lettura ecc. Vedrò come fare qualcosa di sensato il meno astruso possibile.

Leo su che distrò hai provato a compilare? (arch linux forse?)
C'erano le Qt-devel installate?

Ciao.

MauroTec:
E quindi avrdude fa la magia quando scrive in flash, visto che prima di scrivere fa fuori anche la eeprom penso esegua un chip erase. Per i fuse e i lock bit rimangono quelli, quindi li salva prima del chip erase e li riscrive dopo il chip erase.

Attenzione a non confondere ciò che fa avrdude con quello che gli viene detto di fare dall'IDE di Arduino.
Leggendo il manuale di avrdude, si vede come quando viene scelta la scrittura su flash avrdude provveda a fare un chip erase. L'IDE invece spedisce il parametro -D che disabilita l'autoerase. In pratica, quindi, quando viene scritto uno sketch vengono sovrascritte soltanto le pagine interessate dal nuovo firmware, lasciando le altre con il loro contenuto.
Se quindi scrivi il programma CIAO sopra al programma BUONGIORNO la Flash dopo la scrittura conterrà CIAOGIORNO.
Il parametro "-e" invece esegue proprio una piallatura completa del contenuto, sempre il manuale di avrdude dice che con tale parametro vengono resettati a $FF flash, eeprom, lock e fuse bit.

Per il contatore la cosa si complica un po, ma ho già deciso di mettere delle voci nel menu così l'utente deve andarle a cercare anziche trovarsi una o più voce di spunta. Con la voce del menu apro un a dialog che accompagna l'utente nell'inizializzazione e lettura ecc. Vedrò come fare qualcosa di sensato il meno astruso possibile.

Tieni presente anche una cosa.
Il contatore deve essere selezionabile dall'utente, secondo me.
Se lo fai a sua insaputa, potresti imbatterti in un utente che usa la EEPROM per salvare qualcosa. E magari usare le ultime locazioni di EEPROM invece che le prime, per cui poi avrdude potrebbe incasinare quei valori se li va a gestire come contatore quando invece sono dati.

Leo su che distrò hai provato a compilare? (arch linux forse?)
C'erano le Qt-devel installate?

Arch Linux. Ho il pacchetto qt4 installato che dovrebbe comprendere tutto. Altri programmi con le Qt li compilo quindi ti risponderei di sì.

Arch Linux. Ho il pacchetto qt4 installato che dovrebbe comprendere tutto. Altri programmi con le Qt li compilo quindi ti risponderei di sì.

Ho guardato su AUR e c'è il pacchetto hal :AUR (en) - hal

Per saperne di più sull'errore mi serve tutto l'output dell'errore, sembra non trovi alcuni header file.

Tieni presente anche una cosa.
Il contatore deve essere selezionabile dall'utente, secondo me.
Se lo fai a sua insaputa, potresti imbatterti in un utente che usa la EEPROM per salvare qualcosa. E magari usare le ultime locazioni di EEPROM invece che le prime, per cui poi avrdude potrebbe incasinare quei valori se li va a gestire come contatore quando invece sono dati.

Ho inserito un checkbox con il relativo whatsthis che si vede in nero sotto la checkbox. Per la visualizzazione del contatore l'utente deve leggere la eeprom e vedere gli ultimi 4 byte, e in più c'è una voce del menu che apre una dialog che mostra il valore del contatore. Un'altra voce del menu apre una dialog con un campo editabile per inserire il valore del contatore manualmente.

Ciao.

Ho riscaricato i sorgenti proprio adesso ma ora, lanciando la compilazione (qmake) ottengo solo questo:

WARNING: Found potential symbol conflict of avrdudequi.cpp (avrdudequi.cpp) in SOURCES
WARNING: Found potential symbol conflict of avrdudequi.h (avrdudequi.h) in HEADERS

Questo ultimo errore mi fa pensare che ci sia installata la versione 3 di Qt forse insieme alla versione 4 che hanno un Qmake entrambe l'uno diverso dall'altro.

Non puoi postare tutti i comandi che dai e l'output conseguente?

Hai usato qmake, se vuoi puoi provare ad installare QtCreator e caricare il file di progetto avrdudequi.pro e poi click sul triangolo verde a sinistra.

Ciao.

Ho sia le Qt3 che le Qt4 installate sul sistema.
L'output è solo quello :sweat_smile:

[leo@desktop-hp avrdudequi-avrdudequi]$ qmake
WARNING: Found potential symbol conflict of avrdudequi.cpp (avrdudequi.cpp) in SOURCES
WARNING: Found potential symbol conflict of avrdudequi.h (avrdudequi.h) in HEADERS
[leo@desktop-hp avrdudequi-avrdudequi]$

PS.
ho provato ad installare QtCreator ma mi ha scaricato le Qt5 :stuck_out_tongue_closed_eyes:
Ora ho un nuovo messaggio di errore:

Project WARNING: CONFIG+=uitools is deprecated. Use QT+=uitools instead.

Anche l'apertura del progetto da QtCreator non mi riesce... mai usato quello strumento.. mi dice che non gli piacciono le configurazioni che ha trovato e poi durante la compilazione, che manca il file main.cpp nel progetto.

leo72:
PS.
ho provato ad installare QtCreator ma mi ha scaricato le Qt5 :stuck_out_tongue_closed_eyes:
Ora ho un nuovo messaggio di errore:

Project WARNING: CONFIG+=uitools is deprecated. Use QT+=uitools instead.

Anche l'apertura del progetto da QtCreator non mi riesce... mai usato quello strumento.. mi dice che non gli piacciono le configurazioni che ha trovato e poi durante la compilazione, che manca il file main.cpp nel progetto.

hi hi hi, facile no.

Qt5 è richiesto perchè hanno compilato qtcreator con le qt5 anziche con le qt4, molto probabilmente perchè con le qt4 non avrebbe neanche compilato.
Sembra che CONFIG sia deprecato, fosse solo questo basta aprire con un editor il file di progetto avrdudequi.pro e cambiare manualmente il CONFIG con quello suggerito, cioè QT+=uitools.

Ora hai sul sistema qt3, qt4, e qt5, e ogni versione usa un qmake specifico, qt3 usa qmake, qt4 usa qmake-qt4 e qt5 probabilmente userà qmake-qt5, ma per qt5 era previsto l'uso di un sistema diverso da qmake quindi probabile che il comando qmake-qt5 non c'è più.

Comunque per compilare codice usando le qt4 devi usare qmake-qt4 altrimenti non funge, infatti usando "qmake" di default usi quello delle qt3.

Se avessi banda internet mi scaricherei volentieri arch linux, così per vedere qt5 che non ho, al massimo su fedora17 ho qt4.8erotti e con questa compila.

Segue un pezzo di avrdudequi.pro modificato per la tua versione di qtcreator.

# aggiunto uitools a QT
QT          += core gui xml dbus uitools

# questo è un commento e anche quello che segue lo è
#CONFIG      += uitools       
TARGET      = avrdudequi
TEMPLATE    = app

contains(CONFIG, debug) {
DEFINES += _DEBUG_MODE_
}

SOURCES +=  main.cpp\
            avrdudequi.cpp \
            programmer.cpp \
            global.cpp \
            mcu.cpp \
    mtfusearray.cpp \

Ciao.

Domani lo proverò (ora non sono a casa). Grazie delle modifiche :wink:

Tempo fa volevo fare un frontend anch'io per avrdude usando Gambas. Il problema erano pero i file xml da dove prelevare i dati dei fuse dei chip. Se non ho capito male, questi sarebbero contenuti dentro AvrStudio, però ora mi pare esagerato tirar giù questo software per prelevare quei file... tu come hai risolto?

Non li posso usare i file di avr studio c'è la licenza di mezzo, dovrei chiedere ad atmel il permesso. I file non li posso usare ma i dati si, prova ad aprire il file atmega328.ui con qt4designer, vedrai la gui del 328, oltre ai widget posso creare anche delle proprietà.

proprietà di oggetto gBoxLfuse default = 0x62

Poi da codice C++ carico la gui a run-time e leggo le proprietà, gestisco i widget ecc. Quando l'utente cambia MCU cancello la gui corrente e carico l'altro file .ui e così via.

Apri una gui ".ui" di quelle che si trovano sotto avrdudequi/Hardware/Mcu e dal menu "Form" scegli "Preview", potrai giocare con la gui funzionante solo in parte.

Ciao.

  1. Non posso fare test perché, come detto, non sono a casa al mio computer.
  2. il sito dove c'è il Fuse Calculator online dice espressamente che usa i file XML. Quindi ha chiesto una licenza, secondo te?
  3. Ma col tuo metodo sei legato al fatto che devi prima procurarti le info sui chip e se vuoi introdurre una nuova MCU devi crearti un nuovo form ad essa dedicato, o sbaglio?

No non sbagli devo copiare un micro es il 328 e rinominarlo il es 644 e poi introdurre le modifiche, comunque non sono tante, in due ore si risolve nel dettaglio il nuovo micro.

Non è detto che non si possa creare un programmino in python per leggere il file xml e creare le gui, che sono anch'esse xml standard.

Per il punto 2, non so risponderti, ma credo basti chiedere e poi decidono se concederti l'uso degli xml. Comunque non perdo tempo con le licenze propietarie, se volevano potevano rilasciare il file sotto GPL, se non l'hanno fatto avranno un motivo e a me non iteressa sapere di cosa si tratta.

Se vuoi i file xml di atmella te li posso spedire in email, a me li ha mandati aggiornati qualcuno del forum, forse astro o forse brainbooster.

Si avevo capito che stai a fuori casa, scrivevo appunto per quando ritorni all'ovile.

Ciao.