Ah, ora ho capito; io imposto i valori per 1024-2048 word (2-4KB) e però carico il bootloader dell'UNO, quindi i restanti 1,5-3,5KB sono persi.
Devo specificare allora che, se qualcuno decide di creare un chip con qusta tecnica ed avere a bordo il bootloader del 2009, deve impostare il valore per 1024word e il nome del bootloader 2009.
Però a questo punto c'è da dire questa cosa, ragionamoci su bene perché mi serve una risposta certa: con la tecnica ISP che ormai abbiamo collaudato, io sono riuscito a mandare al chip vergine uno sketch, senza precaricare il bootloader; però visto che comunque dichiaro una board UNO, l'impostazione dei fuses in ogni caso riserva lo spazio, o no? A me sembra di sì, e se è così non è più vero che avremmo a disposizione tutti i 32K per gli sketch, in ogni caso l'area riservata non si tocca, a prescindere che sia o meno usata dal bootloader. =(
Apro un nuovo topic, mi serve un'anima buona che mi mandi un pde da 32K tondi tondi, altrimenti non potrò mai saperlo!
Se tu imposti l'area per il bootloader, questa viene riservata a prescindere dal fatto che tu la usi oppure no. La tecnica ISP permette di programmare il chip con o senza bootloader, lo spazio per quest'ultimo è gestito dai fuse. Quindi devi prevedere le 2 possibilità per ogni voce nel menu: Atmega328 con/senza bootloader 2009; Atmega con/senza bootloader Optiboot (UNO).
Poi, una cosa che non so se hai notato. Esiste anche un altro parametro da inserire nel file boards.txt durante la dichiarazione di una nuova CPU, nome_micro.upload.maximum_size: impostandolo, informi l'IDE sulla dimensione massima dello sketch che il micro può ricevere, valore calcolato dalla capacità massima della Flash meno lo spazio occupato dall'area del bootloader.
Esempio:
Atmega328 con bootloader 2009: 32768-2048=30720
Atmega328 con bootloader Optiboot: 32768-512=32256
Quindi con Atmega328 con bootloader 2009: 30720
Ma Atmega328 SENZA bootloader: 32768 (puoi inviare uno sketch che consumi fino all'ultimo byte).
Aspetta, aspetta, altrimenti mi incasino
il problema diventa enorme, se per ogni board devo prevedere le due possibilità, diventano 12: UNO, UNO 1MHz, UNO 8MHz, 2009, 2009 1MHz, 2009 8MHz, per ognuna con e senza bootloader, anche se UNO e 2009 con bl esistono già, ne restano sempre 10!
Allora faccio una cosa più semplice, creo una bella tabella e prevedo tutte le possibilità con i vari valori, poi ognuno si crea la boards che gli serve.
=( =( =( L'ho detto io, questo lavoro è come la tela di Penelope, il giorno lo fai, la sera lo disfai; pazienza
Riepilogando: i 3 fuses settano la board per quella velocità e per lo spazio da riservare al bootloader, il parametro che mi hai indicato, se portato al massimo 32768 invece sfrutta anche il reserved space; devo rispiegare tutto =(
Ora comincio a fare le prove col valore a 1000000 per vedere se il delay e millis si sistemano.... A dopo per gli aggiornamenti.
Difatti per gli Attiny io ho inserito solo il caso "senza bootloader", proprio per eliminare l'area riservata e poter usare tutto lo spazio della Flash.
PS:
dei 3 fuse solo quello alto (high byte) agisce sulla dimensione dell'area da riservare al bootloader.
PPS:
ricordati del bit BOOTRST. Esso serve a dire al micro se, dopo un reset, deve eseguire l'applicazione dell'utente (indirizzo $0000) oppure andare prima ad eseguire il bootloader.
] una goccia alla volta, questa è una tortura cinese, scherzo, grazie delle molte info, però voglio orientare la cosa in questo modo;
del fuse high avevo capito, visto che era l'unico a cambiare variando lo spazio per il bl....
visto che in precedenza si è risolta la questione del caricamento del bootloader nei chip vergini, forse ora conviene concentrare le azioni sullo stand alone, a questo punto a me il bootloader che mi serve? Quindi faccio una tabela di possbili combinazioni, tutte rigorosamente senza bootloader, con start a $0000 e maximum size a 32768; semmai riepilogo tutte queste info per chi vuole andare oltre...
D'altra parte chi vuole mettere un bootloader su un chip lo fa per faro funzionare con Arduino, a quel punto usa la sua bella board e poi opera in locale.
Ora però finalmente capisco perché dopo aver programmato un chip in stand alone, anche col bootloader, su Arduino non funziona più, questo valore non lo avevo mai settato.
Grazie ancora.
EDIT:
con la boards a 1MHz e il valore f a 1000000 il delay(1000) ha un tempo di circa 4 secondi, ho notato però che molta influenza ha l'alimentazione; infatti ho rilevato questo valore a 3,3V; inoltre se lascio il chip collegato al quarzo da 16MHz, il delay è influenzato dal clock esterno, il famoso blink lampeggia molto rapidamente. Tutte correzioni da fare
sì, effettivamente il bootloader è una "comodità" per chi usa il chip nella scheda Arduino oppure che usa questa per programmare tramite metodo RX/TX. Se si ricorre al metodo ISP (quindi se si ha a che fare con un utente un po' più esperto), tenere il bootloader è un inutile spreco di Flash. Tanto, con l'ISP, non lo usi neanche...
Alla luce del punto 1), concordo con te che prevedere tutti i casi è inutile.
Effettivamente questi microcontrollori sono un po' "rognosi". Sembra abbiano dei comportamenti illogici, influenzati da un sacco di parametri. Però non vorrei che fosse tutto "nero su bianco" e la mia fosse solo ignoranza: d'altronde TUTTO il datasheet io non l'ho mai letto (566 pagine!! ), attingo ad esso a "pizzichi e bocconi", come si dice, quando mi serve qualcosa di specifico
OK,
c'è un altro valore nel calc, "clock out", da quanto ho capito serve per averesul pin14 di ATmega (8 di Arduino) la frequenza di clock; mi sarebbe utilissima per misurare le varie combinazioni, visto che ci sono alcuni punti oscuri col delay.
Ho impostato il fuse, ho messo il pin8 in output, e mo?
No, la mia domanda era diversa, ho rilevato la frequenza sul pin 8 e non c'è un bel niente! Quindi serve un comando (penso) per farla uscire "allo scoperto"; le applicazioni possibili sono miriadi; tanto per cominciare avevo realizzato un circuito, pilotato da Arduino, in cui mi serviva un clock, se funzionasse questo comando mi basterebbe collegare questo pin al circuito invece di mettere (come ho fatto) un IC+quarzo+RC. $)
Idee?
Torniamo a bomba: ho scoperto che il delay e affini cambia completamente comportamento in stand alone, non solo in base alla frequenza ma anche se sul chip è caricato o meno il bootloader, sono uscito pazzo fino a che non ho capito questa cosa. Sto approfondendo....
Secondo me tu... sbagli candeggio XD
A parte gli scherzi, c'è qualcosa che non va. Io uso gli Atmega328 sia su Arduino che in standalone su breadboard o simili e non ho mai rilevato questi problemi.
Le cose son due: o hai manipolato qualcosa che ha alterato i timing del micro oppure esso lavorare a frequenze così basse modifica il funzionamento di qualcosa.
Ma parlianmo delle stesse prove? io mi sto riferendo alle frequenze a 1MHz e 8MHz, non alla standard con quarzo a 16MHz; se abbasso le frequenze il delay cambia i tempi; per capirci:
stand alone clock esterno con quarzo: delay(1000) è 1 secondo
stand alone clock interno 8MHz senza quarzo: il delay(1000) del blink ha un tempo di 30 secondi circa
stand alone clock interno 8MHz/8 (1MHz) senza quarzo: il delay(1000) del blink ha un tempo di 2,5 secondi circa
Il chip dovrebbe essere a posto, visto che se gli rimetto l'optiboot e lo piazzo su Arduino o in stand alone con quarzo funziona regolarmente. Però non posso ora impazzire per capire perché, prendo atto, scrivo e vado avanti.
Apro un topic per avere uno skecth da 32K ed uno per questa cosa del clock esterno. Tu hai altre info? ora o mai più XD da stasera mi metto a completare, prove non ne faccio più
Ad 1 e 8 MHz, a dir la verità, ho usato solo gli Attiny ma, ripeto, problemi con i delay non ne ho avuti.
Vabbé che l'oscillatore interno è dato per essere molto impreciso e con... "oscillazioni" dipendenti dalla temperatura (il datasheet ha dei grafici esplicativi) però salti come i tuoi mi sembrano esagerati.
Ma fai le prove con 1 solo Atmega o con diversi ed hai riscontrato lo stesso comportamento anche cambiando il micro?
ho usato sempre lo stesso, non volevo ripetere la strage degli innocenti, comunque ho quasi finito il circuito per riportare in vita i chip brickati, fra poco carico lo sketch e premo il pulsante , se rivive posso fare qualche altra prova con questo chip.
andando a modificare il prescaler e/o il Timer TCCRoB influenzi sia le funzioni delay() e millis() che la frequenza del PWM.
Continuano a funzionare ma con parametri diversi.
Per lavorare a 8 Mhz senza far modifiche puoi provare ad usare il bootloader delle arduino che vanno a 8 mhz tipo la Pro.
Sì, mi era stato segnalato (tu stesso, forse?), non ho avuto modo di fare le prove. intanto sono riuscito con FuseCalc ad impostare un chip per lavorare a 128KHz, ma mi diventa poco gestibile, meglio insistere sullo "sleep" per mettere a dormire il chip quando non si usa.
menniti:
[intanto sono riuscito con FuseCalc ad impostare un chip per lavorare a 128KHz, ma mi diventa poco gestibile, meglio insistere sullo "sleep" per mettere a dormire il chip quando non si usa.
Non riesco a capire perché continui a complicarti la vita quando per ottenere il risultato desiderato basta che setti l'oscillatore RC interno a 8 MHz e usi il prescaler per ottenere la frequenza che vuoi, col vantaggio che se è necessario puoi mandare il micro veloce, cosa impossibile da fare con il clock in ingresso a solo 128kHz.
Ovviamente se si varia il clock del micro tutte le funzioni di wiring legate a temporizzazioni cambiano, il che include baud rate, millis, delay, pwm, campionamento adc etc.
Da boards.txt puoi impostare il valore di clock che il compilatore usa per settare i vari parametri in modo da ottenere temporizzazioni congruenti con quanto richiesto, però se usi il prescaler per rallentare il micro tutti i vari valori devono essere scalati di conseguenza da software.
Scenario tipico, clock RC a 8 MHz, prescaler 1/128 clock reale 62500 Hz, in questa condizione a basso consumo fai solo il polling di ciò che vuoi controllare, non appena si verifica la condizione di avvio riporti il micro a 8MHz fai le dovute elaborazioni ed evenutali trasmissioni di dati consapevole del fatto che tutti i parametri legati alle temporizzazioni sono corretti, alla fine riporti il micro a 62500 Hz e ricominci il polling.
Ovviamente la soluzione migliore dal punto di vista consumi è tenere il micro in sleep, il consumo dipende dalla modalità che scegli, con risveglio da cambio stato su pin logico riesci a consumare meno di 1uA, quando si verifica l'evento il micro parte al clock standard, RC 8MHz, elabori/trasmetti, spegni periferiche, torni in sleep.
Per lo sleep ti consiglio la modalità "power down" che ti permette il minimo consumo possibile e hai il risveglio tramite int0, int1 o cambio stato sui relativi pin.
Per minimizzare ulteriormente il consumo e scendere sotto il micro Ampere devi anche utilizzare il registro "PRR – Power Reduction Register" che ti permette di fermare tutte le periferiche attive in sleep.
C'è una Application Note di Atmel che spiega molto bene come gestire lo sleep per ottenere il consumo minimo possibile, 100 nA, probabilmente a te non serve scendere così in basso.
scusate l'intromissione.
io avevo il problema opposto al tuo menniti cioè avare la massima frequenza con un attiny85
dopo miriadi di prove ho rinuciato a usare il clock esterno perchè dopo quanche reset per mancata alimimentazione (stacca attacca il filo della corrente) il micro andava in crisi e non voleva più saperne di accendersi! bisognava attendere circa 5 minuti che ripartisse, o meno a volte subito altre niente. non sono riscito a venire a capo della questione nemmeno variando i tempi di accensione e tutti i parametri configurabili.
cmq tutto sto preambolo per dire hce alla fine ho impostato il clock interno a 8 e il divisore a 1 anzichè 8 che è il default per il micro.
impostando il prescaler non danno nessun problema rispetto a modificare il clock esterno.
secondo me la soluzione di astrobeed è la migliore
menniti:
[intanto sono riuscito con FuseCalc ad impostare un chip per lavorare a 128KHz, ma mi diventa poco gestibile, meglio insistere sullo "sleep" per mettere a dormire il chip quando non si usa.
Non riesco a capire perché continui a complicarti la vita quando per ottenere il risultato desiderato basta che setti l'oscillatore RC interno a 8 MHz e usi il prescaler per ottenere la frequenza che vuoi, col vantaggio che se è necessario puoi mandare il micro veloce, cosa impossibile da fare con il clock in ingresso a solo 128kHz.
Ovviamente se si varia il clock del micro tutte le funzioni di wiring legate a temporizzazioni cambiano, il che include baud rate, millis, delay, pwm, campionamento adc etc.
Da boards.txt puoi impostare il valore di clock che il compilatore usa per settare i vari parametri in modo da ottenere temporizzazioni congruenti con quanto richiesto, però se usi il prescaler per rallentare il micro tutti i vari valori devono essere scalati di conseguenza da software.
Scenario tipico, clock RC a 8 MHz, prescaler 1/128 clock reale 62500 Hz, in questa condizione a basso consumo fai solo il polling di ciò che vuoi controllare, non appena si verifica la condizione di avvio riporti il micro a 8MHz fai le dovute elaborazioni ed evenutali trasmissioni di dati consapevole del fatto che tutti i parametri legati alle temporizzazioni sono corretti, alla fine riporti il micro a 62500 Hz e ricominci il polling.
Infatti ho rinunciato a tutto ciò e come dicevo voglio applicare appunto lo sleep mode.
Ovviamente la soluzione migliore dal punto di vista consumi è tenere il micro in sleep, il consumo dipende dalla modalità che scegli, con risveglio da cambio stato su pin logico riesci a consumare meno di 1uA, quando si verifica l'evento il micro parte al clock standard, RC 8MHz, elabori/trasmetti, spegni periferiche, torni in sleep.
Per lo sleep ti consiglio la modalità "power down" che ti permette il minimo consumo possibile e hai il risveglio tramite int0, int1 o cambio stato sui relativi pin.
Per minimizzare ulteriormente il consumo e scendere sotto il micro Ampere devi anche utilizzare il registro "PRR – Power Reduction Register" che ti permette di fermare tutte le periferiche attive in sleep.
C'è una Application Note di Atmel che spiega molto bene come gestire lo sleep per ottenere il consumo minimo possibile, 100 nA, probabilmente a te non serve scendere così in basso.
Ho il riferimento della libreria di sleep che mi pare mi abbia dato proprio tu; ieri ho finito di realizzare il circuito (funziona) per il recupero dei chip bricked, domani mi dedico appunto a questa modalità, se hai qualche applicazione fatta mi sarebbe utile come spunto /difficoltà con l'inglese), in ogni caso 1µA di consumo mi risolverebbe il problema finché campo, considerando che alimento il circuito con una batteria da 3,6V di circa 1000mA!
Grazie astrobeed.
garinus:
scusate l'intromissione.
io avevo il problema opposto al tuo menniti cioè avare la massima frequenza con un attiny85
dopo miriadi di prove ho rinuciato a usare il clock esterno perchè dopo quanche reset per mancata alimimentazione (stacca attacca il filo della corrente) il micro andava in crisi e non voleva più saperne di accendersi! bisognava attendere circa 5 minuti che ripartisse, o meno a volte subito altre niente. non sono riscito a venire a capo della questione nemmeno variando i tempi di accensione e tutti i parametri configurabili.
cmq tutto sto preambolo per dire hce alla fine ho impostato il clock interno a 8 e il divisore a 1 anzichè 8 che è il default per il micro.
impostando il prescaler non danno nessun problema rispetto a modificare il clock esterno.
secondo me la soluzione di astrobeed è la migliore
Quale intromissione? è un topic mica un club privato, ogni aiuto è straben accetto! chiedo anche a te se puoi postare un esempio di code per il prescaler, ma soprattutto per lo sleep; in realtà il circuito lavora per pochi secondi 2-3 volte al giorno, quindi posso permettermi la velocità di 8MHz o al limite di 1MHz (cosa ormai fatta con i fuses opportuni); poterlo tenere in sleep mode a 1µA o qualcosa in più per tutte le 24 ore significa che la batteria manco se ne accorge che sta fornendo energia.
Grazie anche a te.
una goccia alla volta, questa è una tortura cinese, scherzo, grazie delle molte info, però voglio orientare la cosa in questo modo;
), attingo ad esso a "pizzichi e bocconi", come si dice, quando mi serve qualcosa di specifico 
, se rivive posso fare qualche altra prova con questo chip.