New version of my guide to program the ATtiny MCUs from Atmel with the last version of the new Arduino IDE 1.5.x branch. This new release of the guide has its roots into the Arduino forum and was possible due to the help of the user PaoloP. The guide illustrates how to program the ATtiny chips supported by the Tiny core (at the moment, the chips ATtiny25/45/85, ATtiny24/44/84, ATtiny2313/4313 are supported) with the IDE 1.5.4.
How to use the tinyAVR MCUs with the Arduino IDE 1.5.x
Leonardo Miliani
Appassionato di computer e programmazione da sempre. Altre passioni sono la fotografia, l'astronomia, il trekking, le scienze naturali, la bicicletta, i fuoristrada.
You may also like...
12 Responses
Leave a Reply
You must be logged in to post a comment.
This site uses Akismet to reduce spam. Learn how your comment data is processed.
salve, ho un po di problemi con questa libreria… caricata sull’attiny, precisamente attiny84, mi trovo con i “pin arduino” completamete al contrario, il “10” (dobrebbe essere PB0) è 1 e viceversa, in pratica l’opposto di questo :
http://blog.protoneer.co.nz/wp-content/uploads/2013/05/attiny_44_84_Pinout.png
e in + non riesco ad attivare la Aref Esterna, rimane sempre a 1.1V
Avresti qualche suggerimento in merito?
con l’85 non ho avuto problema alcuno, non ho provato la Aref esterna in quanto non mi serviva, ma i pin erano corrispondenti.
Stiamo parlando del core Tiny, non di una libreria fatta da me. La piedinatura è quella utilizzata dal core stesso:
// ATMEL ATTINY84 / ARDUINO
//
// +-\/-+
// VCC 1| |14 GND
// (D 0) PB0 2| |13 AREF (D 10)
// (D 1) PB1 3| |12 PA1 (D 9)
// PB3 4| |11 PA2 (D 8)
// PWM INT0 (D 2) PB2 5| |10 PA3 (D 7)
// PWM (D 3) PA7 6| |9 PA4 (D 6)
// PWM (D 4) PA6 7| |8 PA5 (D 5) PWM
// +----+
Purtroppo quella riportata sulla scheda di Pighixxx che hai linkato non corrisponde a questa, per cui è normale che tu veda i pin invertiti. Sull’Aref devo fare dei test (come detto il core non è mio, io ho provveduto solo a creare tutto il pacchetto con i file di supporto all’IDE) ma in caso fosse come dici tu andrebbe segnalata la cosa al link che ti ho segnalato all’inizio di questo reply.
grazie della risposta. so che il core non è “tuo” ma da qui l’ho scaricato, per quello ho chiesto qui 🙂
la cosa dei pin “invertiti”, vabbe non è un dramma, alla fine in qualche modo ci sono arrivato e mi son corretto da me l’immagine x usi futuri, quello dell’AREF invece non la capisco..non ci arrivo proprio..
ho provato persino a spulciare nel “wiring.c” e negli altri file che richiama, ma non ho “esperienza” per beccare un eventuale errore.
ho comunque provato a commentare nel file core_adc.h la riga qui sotto,
ADMUX = (ADMUX & ~MASK2(REFS1,REFS0)) | (((vr & B11) >> 0) << REFS0);
e sostituirla ignorantemente con
ADMUX = (ADMUX & 0x7F) | 0x40; (dal datasheet se ho capito qualcosa dobrebbe dire, usa riferimento Esterno)
risultato.. 0 non cambia nulla
nel codice ho provato a dichiarare usando vari "metodi" dall' "analogReference(EXTERNAL)" al dichiarare proprio ignorantemente "ADMUX = (ADMUX & 0x7F) | 0x40;" ma anche qui… nulla, il fatto è che qualsiasi cosa dichiaro… non cambia il risultato.
provo magari a descriverti meglio "il problema" e dove devo arrivare, magari sbaglio io qualcosa…ma premetto che il "giochino" ha funzionato perfettamente con Arduino Nano.. presumo che con i dovuti "aggiustamenti" debba funzionare anche qui.
in pratica.. ho un Attiny84A (SMD), che mi gestisce (correttamente) un modulino WTV20SD16, quindi in soldoni l'attini mi serve per dire al modulo quale degli MP3 eseguire, e uso L'analogico per la gestione di 3 pulsanti, la lettura dell'analogico la richiamo tramite "timer interrupt".
alla prova ho notato che.. nella gestione dei pulsanti non funzionava un tubo… quindi ho provato a farmi un "software" ignorantissimo per testare l'analogica.. con un set di 4 " if " ho provato a "vedere" come si comportava l'analogica, sfruttando 3 led x identificare un range di letture.. in pratica … 0-300 accendo il led 1, 300-600 il 2, 600-900 il 3, 900-1023 tutti e 3 i led…
applicando un potenziometro al pin in questione (il 9)…in pratica … ho tutta la gamma di valori in 1V circa… da 5 a 4 piu o meno… da qui il fatto che credo non venga attivato il Ref esterno..
che ne pensi? sbaglio qualcosa io ?
Salve. ieri sera…per me, si è un po evoluta la cosa….e diciamo che è +/- risolta (almeno a livello funzionale)…ma è una cosa un pò strana..(almeno per me).
se uso nell’istruzione di lettura porta analogica (come ho sempre fatto, analogRead(pin) ) mi fa quello scherzo sulla lettura di assegnare la totalità dei valori in circa 1V.. se uso invece analogRead(A1) o analogRead(PA1) funziona normalmente su tutto il range dei 5V di REF.
Any Idea?
ciao.
Ieri non ho fatto in tempo a fare dei test, troppo incasinato. Oggi controllo. Quindi secondo quanto mi dici, se fai analogRead(1) o analorRead(A1) ottieni nel primo caso il problema mentre nel secondo no.
ciao leonardo
mmm io richiamo la lettura non con analogRead(1) ma con analogRead(9)… vuoi dire che il mio errore sta tutto li?
quello che mi fa strano è che comunque legge, ma sbagliato..
ora come ora mi viene il dubbio (ho fatto 1000 prove quando cercavo di trovare i pin)….ma mi pare che con 1 non leggesse.
io la richiamo con analorRead(9) se al posto di 9 metto A1 o PA1 allora va..
stasera per curiosità appena torno a casa provo… nel caso.. mi son rincitrullito completamente…
ok, grazie dell’aiuto leonardo.
son io che sono andato in confusione coi pin. con 1 funziona…
consideo tutto risolto 🙂
Perfetto. Il problema penso sia nato proprio dalla scheda di Pighi perché le numerazioni dei pin analogici seguono un ordine inverso, cioè PA0 è A0 ma D10, PA1 è A1 ma D9 ecc..
ciao leonardo, si ma anche un po mio 🙂 normalmente finora sull’arduino, difficilmente ho usato le analogiche come digitali dove comunque proseguono in senso logico rispetto alle digitali, cioè a0 è 14, a1 15 e via discorrendo.. qui me le son trovate “ribaltate” e sono andato anche un po’ in pappa io..visto che lo richiamavo con il pin digitale e non analogico. ora non so quanto sia errato, nel senso che onestamente ora come ora, non so se richiamando analogRead(14) sull’arduino crei problemi o meno..
quello che mi fa comunque “specie” è che dandogli il pin Digitale (per quanto sbagliato)…. leggesse comunque dalla porta chiamata ma con valori… alquanto strani.
vabbe comuqnue diciamo che “va bene cosi” 😀
mi piacerebbe solo capire se e come si puo “ribaltare” la numerazione….che avrebbe un pochino di senso logico in +
Alla numerazione per semplicità tendono a farle rispettare quella dei pin sulle porte.
Siccome la priorità la danno ai pin digitali, si parte sempre con D0 sul 1° pin usabile dopo il piedino n° 1 del chip. Nel caso dell’Attiny84 è PB0. E via a salire. Nel caso dei pin analogici sull’Arduino hanno usato la numerazione per gli analogici a seguire di quella per i pin digitali. Qui non potevano farlo perché la porta, come vedi dallo schema che ti ho riportato qui sopra, va al contrario, ossia invece di mettere PA0 sul 6° pin ce l’abbiamo sul penultimo piedino. Quindi a livello di codice hanno seguito questo schema, che è più facile da gestire nel core ma che può creare qualche incomprensione. E’ così anche sui Mega644/1284, anche lì i pin analogici vanno a ritroso. Non so perché, andrebbe chiesto a “mamma Atmel” 🙂
Ciao Leonardo,
in questo momento utilizzo l’IDE 1.5.7 per provare a programmare il ATTiny84A-PU. (il tutto con arduino uno r3)
caricato arduinoISP (OK)
ho caricato il blink nel seguente modo:
void setup() {
pinMode(a0, OUTPUT);
}
void loop() {
digitalWrite(0, HIGH);
delay(1000);
digitalWrite(0, LOW);
delay(1000);
}
connesso
PIN.arduino – 10 al ATtiny84A – 4
PIN.arduino – 11 al ATtiny84A – 7
PIN.arduino – 12 al ATtiny84A – 8
PIN.arduino – 13 al ATtiny84A – 9
ho eseguito scrittura (bootloader) OK
ma il LED sul piedino 13 non si accende.
dove sbaglio … o ATtiny84-PU non è compatibile !?!
nb: ho provato sia a caricare a 1 Mhz che a 8 Mhz.
Non ho capito il problema