8000 < sketch.length() < 8192
Qui cadiamo nell'ambiguità perché la "k" è sì il prefisso delle migliaia però riferita alle misure di capacità delle memorie io tendo ad intenderla come KB, quindi anche per me 8K=8192 byte
dalubar:
[quote author=Michele Menniti link=topic=96135.msg839806#msg839806 date=1340734871]
oltre 8 k come faccio a caricarlo su un tiny84?
8000 < sketch.length() < 8192
[/quote]
furbastro XD ma avrei da obiettare 
e però non obietto, basandomi su un ragionamento logico: se questo sketch attualmente risiede e lavora su un tiny84 vuol dire che sta tutto nella flash, quindi, a prescindere dal dato reale, funziona. Ovvio che il ragionamento era stato fatto prima, ma io non potevo perdermi la battuta 
Nei prox giorni ti faccio avere risultati seri sulle prove, visto che ho ampia gamma di installazione
@ Leo: io gliel'avevo risparmiata.... tu sei peggio del "moralizzatore" 
Non è colpa mia! E' il task superCriticism che ho impostato con un intervallo troppo breve e non avendo il mio leOS il metodo removeTask non riesco a fermarlo 
leo72:
[quote author=Michele Menniti link=topic=96135.msg839858#msg839858 date=1340737989]
@ Leo: io gliel'avevo risparmiata.... tu sei peggio del "moralizzatore"
Non è colpa mia! E' il task superCriticism che ho impostato con un intervallo troppo breve e non avendo il mio leOS il metodo removeTask non riesco a fermarlo
[/quote]
Siete in palese ERRORE entrambi, anzi Leo più di Mike!
Anche se, OVE MAI, e per assurdo, si fosse assegnata alla lettera "k" l'interpretazione di "misura di capacità della memoria: 2^10", allora questo avrebbe anche implicato l'impossibilità di poter caricare tale sketch sulla MCU specificata, e questo è ASSURDO, in quanto lo sketch è stato fornito proprio per testare la corretta funzionalità del trasferimento (a meno di non mettere in dubbio l'ipotesi iniziale, ovvero Hp:"ho uno sketch >8k che funziona e puoi provare").
Quindi ne segue che l'UNICA interpretazione possibile era k=1000, come giustamente aveva già capito il buon menny dicendo:
...però non obietto, basandomi su un ragionamento logico: se questo sketch attualmente risiede e lavora su un tiny84 vuol dire che sta tutto nella flash, quindi, a prescindere dal dato reale, funziona.
Quindi, rifiuto la mozione e vado avanti. 8)
spettacolari! amo queste disquisizioni che vanno avanti a colpi di neuroni! Quanta bella intelligenza c'è in giro, mi sento davvero onorato di potermi dichiarare vostro amico, GRANDI! XD
Riapro questo Topic di un paio di anni fa a motivo delle mie recenti prove con i due più importanti core TINY; qualche post fa in questo Topic manifestavo perplessità circa la soluzione di Dalubar, perché non mi convinceva la logica, oggi posso dare una risposta certa a quanti avessero i problemi segnalati qui e che parzialmente si sovrappone a quella di Dalubar.
1° problema: a fine compilazione di qualsiasi sketch esce un errore:
avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtinyXX
avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtinyXXy
SOLUZIONE: aprire il file AVRDUDE.CONF, localizzare le MCU TINY di interesse, sotto la riga:
chip_erase_delay = 4500;
aggiungere:
pagel = 0xB3;
bs2 = 0xB4;
2° problema: compilando sui tiny 8xx file maggiori di 4 kByte esce questo errore:
c:/myPath/arduino_1.0.5/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr25/crttn8X.o:(.init9+0x0): relocation truncated to fit: R_AVR_13_PCREL against symbol…….
Tale problema si presenta sicuramente fino alla versione di compilatore 4.5.1, non ho ancora provato l'attuale 4.8.1.
SOLUZIONE:
il core utilizzato, se prevede la problematica, fornisce una patch del file ld.exe che sostituisce l'originale nel percorso MyPath\hardware\tools\avr\avr\bin e che risolve istantaneamente il problema.
Naturalmente se ci sono obiezioni parliamone perché a queste conclusioni sono arrivato facendo svariate prove e controprove, ma una distrazione ci sta sempre.....