volevo chiedere se era possibile di dotare l 'IDE di un comando che salva lo sketch + più le librerie in un file unico .hex
so già che lo "fa" da qualche parte quando si verifica lo sketch ma non so come fare ad aprire il file,
per aprire intendo semplicemente pronto a trasferirlo nell'arduino senza la possibilità di modificare nulla
so che è possibile farlo con programmi esterni si prende il file .hex e lo si carica direttamente nell'arduino
trovo questa cosa molto utile in caso di sketch del passato che l'ultima ide da problemi o "conflitti" con ultime versioni delle librerie usate
Ci sono le opzioni per la linea di comando. Che dovrebbe permetterti di muovere tutto il contenuto della cartella temporanea in un altra cartella. Eventualmente potrebbe esserci anche un comando che permette di compattare il tutto. Da windows si passa ai vari comandi batch.
(a me) sembra una cosa utile che ci siano dei pulsanti o menu nell'ide che fanno una cosa del genere che fa questo programmino xloader
purtroppo questo programma non e detto che verrà aggiornato a tutti gli arduino presenti o del futuro,
stesso le librerie "esterne" nessuno garantisce che l autore non le modifichi "troppo" o vengono abbandonate/smarrite,
e mi sembra un controsenso che a ogni progetto
bisogna salvarsi librerie versione dell'ide e forse qualcosaltro
il tutto per evitare di rimettere le "mani" su cose funzionanti fatte anni prima
elrospo:
volevo chiedere se era possibile di dotare l 'IDE di un comando che salva lo sketch + più le librerie in un file unico .hex
E' da più di un anno che è presente nel IDE il comando per ottenere l'hex compilato, menù "SKETCH->ESPORTA SKETCH COMPILATO", lo fa in due versioni una senza bootloader, una comprensiva di bootloader, quale usare dipende dall'uso finale.
astrobeed:
E' da più di un anno che è presente nel IDE il comando per ottenere l'hex compilato, menù "SKETCH->ESPORTA SKETCH COMPILATO", lo fa in due versioni una senza bootloader, una comprensiva di bootloader, quale usare dipende dall'uso finale.
si .... ma è il contrario che manca
ide che "apre"il file hex che ha creato, chiede (al massimo) su che arduino va caricato e lo carica,
Mi pare controverso.
Se avvii l' IDE, per caricare uno sketch nell' Arduino, basta che clicchi su verifica [CTRL+U da tastiera]. Quale altra complicazione vorresti ?
elrospo:
si .... ma è il contrario che manca
ide che "apre"il file hex che ha creato, chiede (al massimo) su che arduino va caricato e lo carica,
Manca perché non ha senso che ci sia visto che se hai lo sketch puoi programmare Arduino semplicemente cliccando sulla relativa icona.
Se devi fare un discorso di produzione, ovvero programmare n schede con lo stesso hex, lo puoi fare facilmente con i vari programmi di terze parti, p.e. Xloader se usi il bootloader oppure Avrdudess che ti permette di usare quasi tutti i modelli di programmatori hardware esistenti e di impostare, se necessario, i fuse.
Volendo anche con un banale file batch per Windows, o uno script per Linux, dove esegui la riga di comando per Avrdude per caricare l'hex sul micro come meglio preferisci.
La riga di comando per avrdude la puoi vedere dal IDE abilitando l'output dettagliato durante il caricamento da preferenze.
In alternativa puoi usare Atmel Studio, però devi avere un programmatore hardware supportato.
non vedo perché devono provvedere delle terze parti, nessuno "conosce" meglio arduino di chi lo fa.
Con un po di buona volontà si potrebbe aggiungere questa funzione che sarà sempre utile
con le cose digitali non si può mai sapere che piega prenderanno in futuro,
purtroppo non si può "ordinare" a nessuno di modificare le sue librerie "senza modificarle troppo"
e nemmeno si può "ordinare" a nessuno di restare sempre vivo
Sì, in fondo concordo che una funzione del genere sarebbe utile: visto che si può esportare l'hex, sarebbe perlomeno sensato poterlo anche utilizzare. Però:
Come dice gpb, tieni conto che puoi lanciare avrdude (programma incluso in Arduino che esso stesso usa per caricare gli sketch) a mano e fare da te quanto desiderato.
L'hex è caricabile solo sullo stesso Arduino per cui è stato creato, per cui non ha senso che dopo averlo aperto chieda su che Arduino caricarlo :).
Alla fine conviene usare Xloader. A prescindere che non ti assicura che stai caricando uno sketch relativo al tipo di Arduino. Non lo fa in automatico.
SukkoPera:
2. L'hex è caricabile solo sullo stesso Arduino per cui è stato creato, per cui non ha senso che dopo averlo aperto chieda su che Arduino caricarlo
L'hex, per sua natura, è un file ascii in formato esadecimale con una ben precisa codifica, contiene il binario dell'eseguibile e gli address dove caricarlo, non contiene nessuna informazione sul processore e/o tipo di Arduino, pertanto anche se l'IDE dovesse avere una funzione per caricarlo devi comunque specificare su quale board va messo.
L'IDE di Arduino non è pensato per la produzione, è pensato per lo sviluppo, se hai lo sketch non ti serve l'hex per caricarlo sulla board, se hai solo l'hex è perché devi fare produzione pertanto vanno usati altri sistemi quali script/batch per avrdude, Xloader, Avrdudess, Atmel Studio etc.
SukkoPera:
Sì, in fondo concordo che una funzione del genere sarebbe utile: visto che si può esportare l'hex, sarebbe perlomeno sensato poterlo anche utilizzare. Però:
ok il tutto e per il "futuro" che nel mondo dei computer arriva molto in fretta,
serve per facilitare il tutto in caso che tutto quello che c'e adesso sara obsoleto (ide librerie)
per il fatto di quale arduino va messo basta che nel nome di salvataggio sketch viene anche aggiunto il tipo di arduino es; ard_1_blink.hex ma questo e il minimo anzi forse superfluo,
perché in futuro rimettere mano a vecchi sketch per renderli ancora compatibili mi sembra un po troppo
@astrobeed: appunto, ma se carichi un hex di una Mega su una Uno, ho i miei dubbi che funzioni...
@elrospo: in realtà non dovrebbe mai succedere niente di troppo stravolgente, la retrocompatibilità dovrebbe essere sempre mantenuta. Può capitare che qualcosa vada sistemato (PROGMEM), ma raramente mi è successo di dover cambiare chissà cosa.
SukkoPera: @astrobeed: appunto, ma se carichi un hex di una Mega su una Uno, ho i miei dubbi che funzioni...
@elrospo: in realtà non dovrebbe mai succedere niente di troppo stravolgente, la retrocompatibilità dovrebbe essere sempre mantenuta. Può capitare che qualcosa vada sistemato (PROGMEM), ma raramente mi è successo di dover cambiare chissà cosa.
tutto dipende da come si evolve il settore, potrebbe rimanere più o meno cosi
oppure potrebbero arrivare sul "mercato" micro super a costo bassissimo
o che so potrebbero sostituire del tutto EEPROM.write con EEPROM.update
(che cosi su 2 piedi EEPROM.update fa la stessa cosa e forse meglio)
la sfera di cristallo non c è l'ho per indovinare il futuro
Può succedere per nuove board. Ad esempio sulla Due non c'è la EEPROM, quindi ovviamente non ci sono queste funzioni. Tuttavia, ad esempio, la Digistump ha creato un clone della Due con una EEPROM esterna a bordo (si chiama DigiX). Io stesso ho creato una libreria che lavora su questa EEPROM usando la stessa interfaccia della classe EEPROM classica, in modo che risulti famigliare e si possa riciclare codice già scritto per altre schede.
Se succede per una vecchia scheda, è perché viene introdotta una nuova alternativa a cui non costa troppo passare. Ma anche in questo caso, spesso vengono lasciare anche le funzioni vecchie per motivi di retrocompatibilità. Ad esempio, credo che oggi si potrebbero usare sempre EEPROM.put() e .get()), tuttavia esistono ancora .read() e .write(). Se vuoi un esempio ancora più radicale, in C (ma su Arduino non ha molto senso) esiste la funzione gets(), concepita male e ormai deprecata all'unanimità. Tuttavia è ancora presente in tutte le libc.
Tutto questo ovviamente accade perché è interesse di tutti far sì che il parco software preesistente continui a funzionare, almeno sulla stessa scheda, e che le interfacce consolidate mantengano la loro validità. Poi che ogni tanto si debba cambiare qualcosa può capitare, ma non sarà mai qualcosa da richiedere millenni di lavoro. Inoltre succede più spesso durante le fasi iniziali di una piattaforma, quando non si sa bene che pesci pigliare e capita di approcciare male qualcosa. Poi, man mano che si prendono le misure, le cose diventano più stabili.
che il mondo dei micro-controllori si evolverà è sicuro pure quello,
non perché non potrebbe andar bene cosi....
più che altro perché è un imposizione dall'esterno (mercato concorrenti etc)
e ritornando in tema non tutti scrivono sketc brevi o "comprensibili" anche dopo anni
quasi impossibile rimetterci le "mani" dopo qualche anno
quando si sono fatte le cose con la "certezza" che sono definitivi
Il mondo delle MCU si evolverà, ma questo non implica che quello che c'è oggi non continui a funzionare come funziona oggi.
Imparare a scrivere codice comprensibile anche a lunga distanza (che abbonda di commenti!) e riciclabile è parte del processo di apprendimento della materia. Il primo a beneficiarne sarai tu stesso, che potrai riutilizzare cose già fatte oggi anche tra anni, perché il C nel frattempo, anche se sarà evoluto, sarà ancora in grado di compilare quel che hai scritto oggi.
