A chi non è capitato almeno una volta di notare quel bellissimo effetto led presente su alcuni dispositivi elettronici, il cosiddetto breathing led ovvero “led che respira”?
In rete ci sono makers da ogni parte del mondo che muniti di oscilloscopio hanno provato a fare reverse engingering per riprodurre l’algoritmo in questione e trasformarlo in uno sketch per Arduino.
Il problema sta nel fatto che la maggior parte dei codici trovati in rete hanno due difetti: il primo è che tali algoritmi non contengono una funzione ma una serie di valori precalcolati che non rendono continuato e preciso l’effetto, mentre il secondo risiede nel fatto che spesso questi codici sono bloccanti, ovvero fanno uso di delay e non permettono quindi la corretta continuazione del restante codice all’interno dello sketch.
Prendendo spunto dal codice pubblicato da Sean Voisen che ha trovato la funzione che definisce i valori PWM per pilotare il led, ho fatto delle modifiche e dei test per renderlo non bloccante, ovvero per farlo lavorare in background e permettere l’esecuzione di altro codice.
Il risultato finale è il seguente:
Il collegamento avviene ovviamente come per qualsiasi altro led e il sistema è in grado di pilotare anche led di potenza o led strip, tramite opportuno transistor o mosfet (Vedi: Pilotare una led strip con Arduino)
Il codice per Arduino è il seguente:
/*
NonBlockingBreathingLed 0.1
by Luca Soltoggio - 2015
12 May 2015
http://www.arduinoelettronica.com/
http://arduinoelectronics.wordpress.com/
http://minibianpi.wodpress.com/
Use a exp + sin function to recreate a
non-blocking breathing led effect
Released under GPL v.2 license
*/
#include <math.h>
#define ledPin 11
int i=0;
int breathe_delay = 15; // delay between loops
unsigned long breathe_time = millis();
void setup()
{
}
void loop()
{
nonBlockingBreath(); // call the nonblocking function
// yourOtherCodeHere();
}
void nonBlockingBreath()
{
if( (breathe_time + breathe_delay) < millis() ){
breathe_time = millis();
float val = (exp(sin(i/2000.0*PI*10)) - 0.36787944)*108.0;
// this is the math function recreating the effect
analogWrite(ledPin, val); // PWM
i=i+1;
}
}
Il titolo non poteva essere più azzeccato: Arduino Yún è infatti il capostipite di una serie di prodotti che sta già rivoluzionando il mondo dei Makers.
Non voglio esaminare in questa sede le caratteristiche tecniche (che sono già state ampiamente discusse in vari blog e che sono riassunte sul sito ufficiale), ma vorrei invece analizzare il modo di funzionamento di questa piattaforma, nonché evidenziare quelli che possono essere i possibili sviluppi.
Il presupposto di partenza, è che l’ambiente Arduino, ha avuto una diffusione esponenziale dalla sua nascita, diventando uno standard di fatto e alimentando in un circolo virtuoso, il movimento mondiale dei Makers.
Da Arduino sono scaturiti infatti centinaia di progetti, di board simili, di idee nuove, tanto che ad oggi sono veramente poche le innovazioni tecnologiche che non hanno a che fare con questa board (basti pensare all’avvento delle stampanti 3D).
Ad Arduino mancava però ancora una cosa, di importanza sempre più fondamentale per poter partecipare all’Internet dell Cose: la capacità di scambiare ed elaborare metadati complessi con il resto del mondo (utilizzando ad esempio il web semantico).
A questa carenza il mondo degli artigiani digitali ha cercato di porre rimedio con soluzioni più o meno riuscite basate solitamente sull’unione di Arduino con sistemi linux embedded, come il Raspberry Pi, che sono molto web-oriented e predisposti all’elaborazione dati, ma che mancano di connessioni fisiche con il mondo reale (nel mio piccolo, ho fatto anche io qualche tentativo: vedi Ardudome).
I creatori di Arduino hanno reagito a questa esigenza sempre più impellente con un prodotto veramente unico: Arduino Yún.
La sua unicità è dovuta a diverse novità:
– la capacità di unire in un unica board, entrambe le cose, un linux embedded a basso consumo e un Arduino Leonardo
– il Wifi onboard che permette di connettersi alla rete e che rende possibile il caricamento degli sketch senza fili
– l’interazione con le più svariate API possibili (Google, Youtube, Twitter, ecc.)
– il sistema linux on board basato su OpenWrt, leggero e allo stesso tempo potente
– interfaccia web e REST API che permettono direttamente la comunicazione tra le pagine web ed Arduino
– il form factor compatibile con le precedenti board Arduino
Ma la novità che secondo me sopra ogni altra cosa è il fulcro di tutto il funzionamento, è la libreria Bridge, ovvero il software che permette a questi due mondi di comunicare l’uno con l’altro in maniera semplice e veloce.
Come primo impatto, leggendo i vari esempi, sembrava tutto abbastanza incomprensibile, ma utilizzando e sperimentando la libreria, ci si rende subito conto dell’enorme potenzialità e della genialità di questo prodotto: la connessione tra le due anime dello Yún avviene tramite una comunicazione seriale che permette in maniera diretta lo scambio di dati in maniera bidirezionale utilizzando delle semplici funzioni dedicate. E’ possibile perciò ad esempio accedere direttamente dal lato linux ai dati dei sensori di Arduino o viceversa dal microcontrollore accedere direttamente all’output di un comando linux.
Questa modalità di comunicazione semplifica il tutto e amplia in maniera incredibile le potenzialità delle vecchie board Arduino, ma anche quelle di una “banale” board linux embedded.
Possiamo ad esempio in maniera molto semplice accendere un led quando ci arriva un email, piuttosto che monitorare il consumo elettrico della nostra casa e salvare i dati su un documento Google Spreadsheet, oppure ancora costruire una sveglia che in base alle condizioni del traffico cercate su internet decida se è ancora presto o troppo tardi per svegliarci.
I risvolti pratici di questa tecnologia sono veramente avvenieristici e infiniti e c’è da immaginare che tale libreria sarà il motore della prossima rivoluzione arduiniana: Arduino Tre, che promette prestazioni da urlo rispetto ad Arduino Yún, soprattutto per quanto riguarda il lato Linux. Avrà infatti una potenza maggiore, un’uscita HDMI e sarà basato sul sistema Beagleboard.
In questi giorni sto finendo di preparare il mio primo progetto che verrà pubblicato non appena sarà ultimato.
Sottotitolo: Controllo e gestione remota bidirezionale basata su Arduino Multipiattaforma, multibrowser e opensource (ottimizzata per smartphone)
Eccomi con il progetto forse più interessante fin’ora presentato.
Cercavo su internet un sistema per controllare Arduino via web, il tutto però doveva essere estrememanete flessibile, semplice, adattabile ad uno smartphone ma soprattutto doveva avere una comunicazione bidirezionale e un refresh automatico. Non ho trovato nulla che avesse tutte queste caratteristiche messe insieme, ecco perchè ho deciso di realizzare questo progetto.
La maggior parte dei progetti simili, hanno a mio avviso delle caratteristiche incomplete: quelli specifici per domotica solitamente hanno un’applicazione da scaricare e quindi non sono multipiattaforma, quelli basati via web o hanno un interfaccia graficamente scarsa oppure richiedono il refresh della pagina per aggiornare lo stato delle uscite, oppure ancora hanno la possibilità di leggere sensori, ma non di modificare le uscite…
L’esigenza che avevo io in particolare era che se modificavo lo stato di un uscita non da remoto, ma localmente (tramite un pulsante per esempio), l’interfaccia doveva presentarmi quasi in tempo reale tale modifica esattamente sul tasto di accensione o spegnimento dell’ interfaccia senza dover “refreshare” nulla.
Per fare ciò avevo l’esigenza di utilizzare un’interfaccia web un po’ più complessa di quella gestibile dall’ethernet shield di Arduino, ho quindi optato per utilizzare il Raspberry Pi lato web (ma può essere utilizzato qualsiasi PC con Linux, o con qualche modifica anche Windows), collegato via USB (quindi seriale) con Arduino.
In questo modo ho potuto implementare alcune tecnologie, in particolar modo PHP e jQuery, che mi hanno permesso di realizzare il tutto.
Il funzionamento finale è quindi molto semplice:
L’interfaccia visibile nella foto sopra è una semplice pagina web (ottimizzata come si vede per smartphone). Cliccando sullo slide abilito o disabilito un’uscita (che viene azionata in tempo reale) ed ogni 5 secondi ho il refresh automatico delle uscite e anche degli ingressi anlalogici (nell’esempio sopra ho abilitato solo quattro uscite ed un ingresso).
L’interfaccia completa contiene le 13 uscite di Arduino (escluse la 0 e la 1 che servono per la comunicazione seriale), e i 6 ingressi analogici.
Il collegamento e la configurazione sono semplicissimi: Il Raspberry Pi o il nostro PC va collegato via USB alla board Arduino sulla quale avremo caricato lo sketch, dopodichè caricheremo l’interfaccia e gli script sul Raspberry Pi et voilà, il gioco è fatto. NOTA IMPORTANTE: Affinchè il tutto funzioni, dobbiamo disabilitare l’autoreset di Arduino. Questo può essere fatto collegando un condensatore da 10uF tra RESET e GND. Se non si fa questo la comunicazione seriale non funzionerà correttamente!
Ma vediamo ora il principio di funzionamento: Lo sketch di Arduinosi preoccupa principalmente di ricevere un comando via seriale. Tale comando deve essere di 7 caratteri, cominciare con *CMD e terminare con /.
Tra “*CMD” e “/”, va inserito il numero del pin seguito dall’azione: V = value (read) – legge il valore dell’input analogico S = status (read) – legge lo stato dell’uscita digitale H = high (write) – porta il PIN digitale su “ON” L = low (write) – porta il PIN digitale su “OFF” T = toggle (write) – inverte il PIN digitale
Ovviamente tale sketch pur essendo nato per funzionare con il suo script PHP associato, può essere utilizzato per altre applicazioni.
Lo script PHP invece si occupa di fare da ponte tra l’interfaccia web e Arduino tramite seriale (USB).
Se lanciato senza parametri, restituisce una stringa JSON con lo stato delle uscite digitali e i valori delle porte analogiche.
Per esempio: {“02″:0,”03″:0,”04″:0,”05″:0,”06″:0,”07″:0,”08″:0,”09″:0,”10″:0,”11″:0,”12″:0,”13″:0,”14″:756,”15″:745,”16″:722,”17″:679,”18″:634,”19”:494}
Se lanciato con il metodo GET, usa due parametri: “pin” (da P02 a P013) e “cmd” (0 oppure 1).
Esempio:http://raspberrypi/ardudome.php?pin=P13&cmd=1, manderà il comando *CMD13H/ ad Arduino, che porterà il PIN13 su HIGH.
Anche qui, pur essando nato per funzionare con la sua interfaccia web, può essere adattato ad altre applicazioni.
L’interfaccia web infine, basata su HTML, jQuery ed AJAX, non fa altro che chiamare ogni 5 secondi lo script PHP e aggiornare la pagine HTML con i valori corretti presi da Arduino. Se uno slider viene clickato, cambiando il suo valore, lo script chiamerà immediatamente lo script PHP passandogli il parametro del PIN da modificare e il VALORE da settare.
Come si può vedere il tutto è semplice ed intuitivo.
Veniamo ora alla fine alla modalità di installazione:
1 – Scaricare tutti i file da github (https://github.com/toggio/ardudome/)
2 – Caricare lo sketch ArduDome.ino sulla board Arduino UNO
3 – Inserire un condensatore da 10uF tra GND e RESET
4 – Connettere Arduino tramite la porta USB al Raspberry PI (o qualsiasi altro PC Linux) con apache e php preinstallato
5 – Caricare tutti i files (eccetto Ardudome.ino e functions.ino) nella directory www (normalmente /var/www)
6 – Verificare il nome della porta USB (normalmente /dev/ttyACM0) e modificarla nel file ardudome.php ($serial->deviceSet(“/dev/ttyACM0”);)
7 – Dare a www-data il permesso per usare la seriale (usermod -a -G dialout www-data)
8 – Verificare la connessione (lanciando il file ardudome.php)
9 – Aprire il browser dello smartphone o del PC su http://yourraspberryip/ardudome.html
Buon divertimento e ci vediamo al prossimo progetto!!!
In questi ultimi mesi sono stato occupato in un progetto che sto portando avanti con alcuni amici: lanciare un pallone sonda nella stratosfera (a oltre 38km di altutudine).
Sebbene non sia un progetto nuovo a livello mondiale, e nemmeno in italia (vedi il progetto Stratospera), crediamo vi sia una novità rispetto ad altri progetti simili.
In primo luogo il progetto è interamente Open Source, sia per quanto riguarda l’hardware che per quanto riguarda il software: ogni aspetto che man mano verrà fuori, sarà pubblicato sul sito ufficiale.
In secondo luogo, il “computer di bordo”, è realizzato interamente con Arduino, che si occuperà quindi della gestione della posizione, dei dati meteorologici, del datalogging, di una parte di comunicazione, e della gestione del “cut-off” di emergenza. Android si occuperà prevalentemente invece della gestione della posizione e dell’invio tramite rete cellulare dei dati in tempo reale (ovviamente quando sarà sotto copertura di rete, cioè realisticamente fino a 5-6km di altitudine).
Come terza novità c’è in previsione, non dal primo lancio ovviamente, la possibilità di recuperare il payload (contenente tutta l’attrezzatura elettronica), tramite un drone aliante, che dovrebbe autonomamente riportare il tutto al punto di lancio…
Dal punto di vista dello studio di fattibilità abbiamo finito, stiamo elaborando in questo momento il software per Arduino, e stiamo procedendo alla richiesta delle varie autorizzazioni, nonchè ad una raccolta fondi per le varie spese…
Siamo alla ricerca anche di persone che vogliano contribuire al progetto, non solo economicamente ma anche umanamente al progetto.
Inoltre se qualche azienda volesse sponsorizzarci con del materiale che può servire al progetto, saremo ben lieti.
Vi terrò aggiornati!!!
Non ho ancora avuto modo di averla tra le mani, ma prendendo spunto qua e la ed in particolare dal sito ufficiale, volevo con questo articolo evidenziare le principali novità di questa sistema rispetto al suo predecessore Arduino UNO.
Beh, che dire!
Sulla carta effettivamente le novità sono tante e tutte partono dal nuovo microcontrollore Atmel SAM3X8E con CPU Cortex M3 e architettura ARM a 32bit che va a sostituire il vecchio AVR a 8bit:
1 – velocità di clock di 84Mhz (rispetto ai 16Mhz della versione precedente)
2 – 96Kb di RAM (contro i 2Kb di Arduino UNO)
3 – 512Kb di Flash (la UNO ne aveva 32Kb)
4 – PWM e ingressi analogici a 12bit (contro gli 8 precedenti)
5 – Uscite DAC – Novità assoluta per Arduino
6 – Maggior numero di PIN
7 – Host USB
Tutto questo significa una velocità di elaborazione estremamente maggiore, una precisione decisamente migliorata e nuove possibilità grazie al DAC e all’host USB.
Le performance sono legate soprattutto alla velocità di clock unita ai 32bit (oltre che ovviamente alla maggiore quantità di RAM).
Con 32bit siamo in grado di eseguire un’operazione di 4byte (8 x 4 = 32) con una singola CPU clock. Questo significa in maniera empirica, che Arduino DUE potrebbe eseguire le operazioni circa 20 volte più veloce rispetto ad Arduino UNO.
La maggior precisione risiede nel fatto che avendo gli ingressi analogici e le uscite PWM a 12bit, abbiamo una risoluzione moltiplicate per 16, cioè abbiamo 4096 livelli di conversione analogico-digitale e viceversa rispetto ai 256 della versione precedente. Questo permette una densità maggiore di dati in ingresso e un maggiore controllo sui PWM in uscita.
Le nuove funzionalità riguardano invece soprattutto i pin DAC (uscite realmente analogiche, cioè lineari da 0 a 3,3V) che permettono ad esempio di eseguire un file Mp3 e sentirlo sulle casse collegate a queste uscite.
Uniche note negative a mio avviso (bisogna essere proprio pignoli però!!!), sono la mancanza di una porta ethernet – oggi indispensabile in qualuque applicazione, e il fatto che la logica TTL è a 3,3V e non compatibile con i 5V, pena la frittura del pin o del microcontrollore stesso. Questo porta ad una incompleta compatibilità con le shield esistenti o con hardware di terze parti.
Per quanto riguarda i consumi teoricamente dovrebbero essere simili all’Arduino Mega anche se non ho trovato nulla di preciso al riguardo.
La programmazione invece avviene sempre tramite il nostro Arduino IDE, aggiornato alla versione 1.5 per l’occasione, che contiene le librerie aggiuntive per la gestione delle nuove capacità della board. La modalità di programmazione è molto simile alla vecchie procedura.
Ovviamente abbiamo parlato in questo articolo di una versione uscita da pochissimi giorni e ancora in fase di testing. Il tempo ci dirà se questa scheda andrà completamente a sostituire le vecchie Arduino, o se ci sarà un mercato parallelo che si modulerà a seconda dell’applicazione finale. Certamente i progressi fatti, portano un’ulteriore innovazione in questo campo, tali da far pensare che ormai il prodotto Arduino possa sconfinare ulteriormente dal mondo degli “smanettoni casalinghi” a quello dell’elettronica professionale.
Certamente un prodotto come Arduino DUE, in termini di prestazioni e precisione è un prodotto che ben si presta per applicazioni che vanno oltre lo svago domestico, ad un prezzo estremamente competivo (dimenticavo: prezzo ufficiale Arduino Store: 39 Euro).
Dall’altro lato, questa piattaforma, permetterà con più difficoltà (o non permetterà del tutto) la creazioni di progetti embedded simili a quelli realizzabili con Attiny85 a Atmega328 standalone, ma si potrà ovviamente continuare a utilizzare i vecchi AVR: come dicevo prima a secondo dell’applicazione finale, si troverà la soluzione più adatta.
Ed ora un’altro interessante progettino.
Dopo aver visto vari progetti in rete, soprattutto basati sui microcontroller PIC, ho deciso di realizzare un caricabatterie per batterie NiMh gestito da un’Attiny85.
Per quale motivo, penserà qualcuno, serve un microcontrollore per gestire la carica di una batteria. La risposta è molto semplice… La maggior parte dei caricabatterie economici che ci sono in commercio, regolano la carica basandosi su un timer, cioè se devo caricare una batteria da 2500mAh, forniscono una corrente di carica ad esempio di 250mAh, continuando la carica per ad esempio 14 ore (una parte dell’energia se ne va a quel paese, 10 ore non sarebbero sufficienti).
Questo modo di caricare le batterie al Nichel (Mh o Cd), non è tanto funzionale. In primo luogo è un processo lento, e poi non garantisce la corretta carica precisa al 100% delle celle, oltre a presentare rischi di sovrraccarica.
I caricabatterie di tipo “smart” in commercio invece, caricano le batterie correttamente, ma oltre ad essere abbastanza costosi, hanno solitamente correnti di carica non elevatissime, con tempi quindi non sempre sopportabili.
Da qui, oltre che la curiosità e la voglia di creare qualcosa di mio, nasce questo progetto…
Ma andiamo con ordine, e cominciamo con il il video che mostra il progetto finito ed in funzione:
Cerchiamo ora di capire un’attimo il funzionamento.
Innanzitutto le batterie al Nichel necessitano di una corrente costante per essere caricate correttamente. In questo caso si è utilizzato un generatore di corrente costante basato su transistor, derivato da quello che abbiamo visto in un post precedente, e fin qui niente di particolare, ma come facciamo a capire quando la batteria è carica?
Dobbiamo leggere continuamente la tensione della batteria sotto carica, e quando questa presenterà dopo un picco massimo di tensione, una discesa repentina di circa 20mv, la batteria potrà considerarsi carica. Tale fenomeno (chiamato Negative Delta V) è legato alla chimica di questa tipologia di batteria, e permette di stabilire con precisione il momento corretto per terminare la carica.
Vediamo quindi lo schema del circuito:
Lo schema è abbastanza semplice. Il transistor dalington Q1 (TIP127), tramite il LED1 (che deve essere assolutamente ROSSO) e la resistenza R3 da 0,3Ω, crea una corrente costante che scorre in direzione della batteria a 6 celle (7.2V), mentre il diodo Schottky 1N5822 da 3A, serve per proteggere tutto il circuito nel caso che venga a mancare la tensione di ingresso con la batteria connessa. Il partitore di tensione R4-R5, serve per portare alla porta 7 dell’Attiny (A1) il voltaggio della batteria diminuito a circa 1/3, in maniera tale che possa funzionare con tensioni sino a 15V (l’ingresso analogico dell’Attiny non può superare i 5V). Il transistor Q2, pilotato dalla porta 5 dell’Attiny (D0), serve come interrutore per attivare o disattivare il LED1 e il transistor Q1. E’ fondamentale che il LED sia ROSSO, e questo non per una questione di estetica, ma perchè la potenza uscita è data dal rapporto tra la tensione del LED (nei led rossi è di circa 1,8-2,2V) e la resistenza R3. Usando un LED verde, la tensione di riferimento si alza, e di conseguenza anche la corrente si alza (e non di poco).
Il circuito così fornito, può erogare circa 1,5-2,5A, dovete eventualmente fare un po’ di prove con vari tipi di LED rosso, oppure variare la resistenza, che deve essere da 2W. Nel caso non abbiate a disposizione o non riusciate a trovare resistenze di valori così bassi, potete utilizzare 3 o 4 resistenze da 1Ω in parallelo.
Altra cosa da tenere in conto, è la potenza dissipata dal TIP127, che può arrivare anche a 20Watt (dipende dalla corrente e dalla differenza di tensione tra l’ingresso e la batteria), quindi va montato un dissipatore adeguato. Nel mio caso ho usato il case di alluminio che risulta essere sufficiente.
Ultimo appunto è il voltaggio di ingresso, che non deve essere troppo alto altrimenti si rischia di far bruciare il transistor, ma non deve essere nemmeno troppo basso, perchè altrimenti il dropout indotto dai vari componenti fa scendere troppo la corrente di carica. Consiglio all’incirca una differenza di circa 5V tra la tensione di ingresso ed il valore nominale della batteria. Ad esempio con 6 celle, il voltaggio consigliato è di 12,2V (va bene anche 12). Ovviamente si possono caricare anche meno celle, regolando opportunamente la tensione in ingresso. Per una cella, dovremmo alimentare il tutto con una tensione di circa 1,2+5 = 6,2V (va bene anche 6 o 7).
Vediamo ora il circuito stampato:
Da notare le due chicche che non erano visibili nello schema. Il connettore ICSP (quindi la possibilità di aggiornare il firmware sull’Attiny (via programmatore ad esempio UsbTinyISP), e il connettore debug, da collegare ad un convertitore TTL per potere leggere il voltaggio della batteria durante la carica.
Il connettore J1 invece è un jumper che deve essere sempre chiuso, tranne quando aggiorniamo il firmware dell’Attiny85.
A proposito di firmware… Il codice sorgente del firmware è il seguente:
/*
NiMh Charger 0.9
con AtTiny85 @ 1Mhz
by Luca Soltoggio
10/03/2012 - 20/04/2012
Usa il -dT per determinare la fine carica.
Funziona con batteerie NiMh e NiCd.
I valori di default sono per pacchi da 6 celle e 2500mAh
Necessita di qualche aggiustamento hardware/software per parametri differenti.
Vedi https://arduinoelettronica.wordpress.com/
*/
const int inputPin = A1;
const int outputPin = 0;
const int numReadings = 30; // numero di letture analogiche prima di fare il check della batteria
const int multi = 1614; // coefficiente di moltiplica per ottenere il voltaggio corretto dall'analogread
long interval = 1000; // intevallo del pulse charge - non modificare
long interval2 = 250; // intervalle pulse off - modificabile. Utlizzare 100 per 2-4Ah, 500 per 1-2Ah
long interval2b=interval2;
long previousMillis,currentMillis,currentMillis2,trickleMillis = 0;
unsigned int readingtemp;
unsigned int total = 0;
unsigned int average,medium,maxmedium = 0;
boolean executed,endcharge,trickle=false; // variabili di controllo
unsigned int myarray [7]; // arrray che memorizza le ultime 7 letture
int index,i = 0;
void setup()
{
Serial.begin(9600);
pinMode(0,OUTPUT);
// Alcune letture per un controllo iniziale
for (i=0;i<10;i++) {
readingtemp = analogRead(inputPin);
total=total+readingtemp;
}
average = (((float)total / 1023.0) * (float)multi) / 10.0 + 0.5;
if (average<=70) endcharge=true; // Se la batteria non è presente, termina la carica
Serial.println(average);
total=0;
average=0;
}
void pusharray() {
// push dell'array
for (i=0;i<=5;++i) {
myarray[i]=myarray[i+1];
}
myarray[6]=average;
}
void voltread() {
readingtemp = analogRead(inputPin); // legge l'input analogico
total= total + readingtemp;
index++;
// se è stato raggiunto "numReadings" calcola la media
if (index==numReadings) {
index=0;
average = (((float)total / 1023.0) * (float)multi) / numReadings + 0.5;
if (average<=70) endcharge=true; // termina la carica se la batteria viene scollegata
total=0;
pusharray(); // inserisce la nuova media nell'array
// calcola la media delle ultime 7 letture
medium=(float)(myarray[6]+myarray[5]+myarray[4]+myarray[3]+myarray[2]+myarray[1]+myarray[0])/7.0+0.5;
if (medium>maxmedium) maxmedium=medium; // salva il valore della media più alta in "maxmedium"
Serial.print(medium);
Serial.print(",");
Serial.print(maxmedium);
Serial.print(",");
Serial.println(myarray[6]);
// se la batteria è carica (la media dei voltaggi è scesa di 0.02v), ma non nei primi 11 minuti
if ( ((medium+1) < maxmedium) && ((millis()/60000)>=11) ) {
if (!trickle) trickleMillis=millis(); // parte il timer per la "trickle charge" finale
trickle=true; // parte la "trickle charge" finale
// se la batteria si è caricata nei primi 15 minuti, non utilizzare la "trickle charge" finale
// (probabilmente la batteria era già carica)
if ((millis()/60000)<=15) endcharge=true;
}
}
}
void loop() {
currentMillis = millis();
// esegui ogni "interval" millis
if(currentMillis - previousMillis > interval) {
voltread(); // chiama la funzione di lettura e controllo
digitalWrite(outputPin,LOW); // ferma temporaneamente la carica
previousMillis = currentMillis;
executed=false; // variabile per controlloare se è già stata riattivata la carica
// nei primi 10 minuti e negli utlimi 15 minuti effettua una "trickle charge"
// (modifica il tempo di OFF)
if ( ( (trickle) && (((millis()-trickleMillis)/60000)<15) ) || ((millis()/60000)<10) ) {
interval2=(interval-(interval-interval2b)/5);
// dopo la carica iniziale ripristina il valore corretto di interval2
} else if ((millis()/60000)>=10) interval2=interval2b;
// alla fine dell'ultima "trickle charge" termina la carica
if ( (trickle) && (((millis()-trickleMillis)/60000)>=15) ) endcharge=true;
}
currentMillis2 = millis();
// esegui "interval2" millis dopo aver fermato la carica
if ((currentMillis2 - previousMillis > interval2) && (!executed)) {
executed=true;
if (!endcharge) {
digitalWrite(outputPin,HIGH); // se la batteria non è carica, riabilita la carica
}
}
}
Alcuni miei post passati che parlavano di LED Driver, hanno generato un po’ di confusione in qualcuno… Volevo quindi fare un po’ di chiarezza.
In particolare in un commento mi è stato chiesto se tali driver andavano bene per pilotare delle LED Strip.
La risposta è ovviamente: ASSOLUTAMENTE NO!
Non c’entra niente. Le LED Strip dobbiamo considerarle come se fossero delle lampadine o dei motori a 12V: non necessitano di particolari driver per essere pilotate, ma vanno semplicemente alimentate con una tensione adeguata (normalmente appunto 12V).
Questo perchè le LED strip non sono dei semplici LED, ma contengono al loro interno un circuito di led serie-parallelo dotato di resistenze adeguate, e viene quindi gestito come un normale utizzatore a 12V.
Diverso è il caso del LED singolo, che non ha un voltaggio vero e proprio di funzionamento, ma ha bisogno di una corrente fissa e costante per poter funzionare.
Il circuito corretto per pilotare un LED strip con Arduino è quindi il seguente:
Dove VCC rappresenta ovviamente un’uscita di Arduino (digitale o analogica) e X1 rappresenta la mia LED strip (o motore o qualsiasi altra utlizzatore in 12V).
Q1 è un TIP120, ma qualsiasi transistor NPN o darlington NPN va bene, purchè sia adeguato alla potenza del carico.
Spero che questo articolo possa aver fatto un po’ di chiarezza.
A presto!
Finalmente dopo una lunga assenza, in cui ero immerso nella realizzazione finale di questo mio progetto, CE L’HO FATTA!!!
Dopo mesi di progettazione, studi, ricerche e ostacoli vari, la RGB LED Lamp 1.0 by Toggio è realtà.
Posto subito il video che mostra il risultato definitivo ottenuto:
Ed ora una breve cronistoria.
Una delle cose che mi ha attirato di più quando ho sentito parlare di Arduino, era la luce, e in particolar modo ho sempre avuto il sogno di realizzare una lampada a LED RGB.
Niente di difficile, si potrebbe pensare… Solo che lungo questo percorso ho trovato diversi ostacoli.
Innanzitutto non ho trovato progetti completi in rete… Si trova qualcosa, ma, a mio avviso, con algoritmi fatti male, con poche spiegazioni, con metodi elaborati.
Io volevo una cosa semplice da regalare alla persona che amo e che mi ha dato una bellissima figlia…
Volevo qualcosa che avesse una luce abbastanza potente, senza però scaldare troppo. Volevo qualcosa che avesse la possibilità di scegliere il colore e non una semplice “color cycler”. Volevo qualcosa che fungesse anche da lampada standard. Ed infine volevo qualcosa che fosse modulare e upgradabile in futuro.
Dopo queste riflessioni, ho cominciato a studiare innanzitutto l’hardware. Non volevo usare l’Arduino UNO perchè mi sembrava eccessivamente grande per il mio progetto. Ho deciso quindi (e qui si potrebbe aprire un’enorme parentesi) di utilizzare una board non tanto diffusa ma a mio avviso eccezionale (tant’è che ne ho comprate 4 o 5): la Arduino Mini Pro.
(Resta inteso che nel progetto di questo post, può essere tranquillamente sostituita con una UNO o qualsiasi altra Arduino board.)
E’ una board estremamente piccola (18mm x 33mm), compatibile al 100% con Arduino Dumilanove, e a basso consumo. Esiste in quattro versioni: con Atmega328 a 3.3V e 5V e con Atmega168 a 3.3 e 5V.
Ho quindi optato per questo progetto per la versione a 5V con Atmega168. In definitiva si tratta di una soluzione molto economica (costa circa la metà dell’Arduino UNO), alquanto compatta e bella da vedere.
Ho poi pensato di utilizzare delle comodissime Strip LED RGB, che offrono numerosi vantaggi rispetto ad utilizzare led di potenza a 1W o a 3W: non scaldano, si alimentano a 12V e offrono una potenza fino a 13-14W per metro lineare.
Ogni canale può essere alimentato da un’uscita PWM di Arduino tramite un semplice transistor (nel mio caso ho usato dei BC337, ma per potenze superiori si possono usare altri transistor o addirittura dei Mosfet).
Ho quindi provveduto a costruire una specie di shield per la mia board. In pratica ho realizzato un circuito in cui la Arduino Mini Pro possa inserirsi con dei connettori strip ed essere eventualmente rimossa per aggiornare il firmware. Il tutto è stato progettato con Fritzing e realizzato da Fritzing Fab.
Il risultato finale del circuito stampato è il seguente:
Si possono notare le due file di fori dove andrà montata la Mini Pro… Praticamente è una shield al contrario 🙂
Ma facciamo un passo indietro e vediamo lo schema di circuito:
Spero sia abbastanza chiaro anche se non l’ho disegnato proprio benissimo!
In ogni caso il funzionamento è il seguente: I due potenziometri da 10k posti tra i +5V e la massa, sono i due input analogici che permettono di regolare la luminosità e altri parametri stabiliti dal software. Il deviatore a 3 posizioni SW2, permette di selezionare tre funzioni diverse per la lampada. Le uscite digitali 3,5,6 vanno a pilotare tramite un resistore i 3 transistori BC337 che andranno a dare corrente alle 3 uscite negative R,G,B della striscia a LED. Il positivo comune va ai +12V, mentre l’Arduino è alimentato tramite porta RAW (ingresso da 7V a 13V) tramite un diodo che oltre a fornire protezione da eventuale inversione di polarità, abbassa leggermente la tensione. SW1 è semplicemente il ponte dove andrà collegato un normalissimo interuttore di accensione.
Una volta saldati i vari componenti, connettori e potenziometri, montato il circuito, incapsulata la board Arduino, e montato il tutto dentro una scatola da elettricista, il risultato è quello della foto seguente:
La dimensione della scatola è di circa 10cmx10cmx7cm.
Per la parte superiore, ho utilizzato circa 70cm di striscia led RGB, per una potenza totale di circa 10W. Per farla stare tutta l’ho arrotolata intorno al perno di supporto di una campana da CD. Ho tagliato con un taglierino tale perno e l’ho incollato con dei distanziatori sopra la scatola. Ho poi incollato con della colla a caldo la striscia a led avvolgendola sul perno… Insomma un lavoro un po’ artigianale ma il risultato alla fine è il seguente:
Il vetro che si vede sulla scrivania leggermente spostato rispetto alla lampada, è il pezzo finale che manca: la copertura in vetro di una lampada IKEA, opportunamente fatta tagliare da un vetraio locale, affinché rimanga vuota sui due lati. Questa coperturà verrà infine appoggiata sopra la scatola da elettricista ed incollata, ottenendo il seguento risultato:
Mica male vero?
Ovviamente manca ancora la ciliegina sulla torta, una parte non meno importante: il software.
Il codice autoesplicativo è il seguente:
/*
RGB Led Lamp 1.0a
by Luca Soltoggio
15/03/2012
https://arduinoelettronica.wordpress.com/
*/
int rpin = 3; // pin RED
int gpin = 5; // pin GREEN
int bpin = 6; // pin BLU
unsigned int r=0, g=0, b=0,bm=0; // valori rgb e coefficiente divisore del blu
unsigned int valh=0, vals=0, valv=0; // hue, saturation, value
unsigned int sensorValue; // variabile che memorizza il valore dei potenziometri
const int analogInPin = A0; // pin dei potenziometri
const int analogInPin2 = A1;
const int digitalInPin = 10; // pin del deviatore
const int digitalInPin2= 11;
int red[]={255,255,135}; // array con i valori RGB della funzione "Bianco"
int green[]={157,255,158};
int blue[]={51,255,255};
boolean DIG1, DIG2;
long previousMillis = 0;
int i=0,j=0;
int dl=0; // delay
void setup()
{
pinMode(digitalInPin,INPUT);
pinMode(digitalInPin2,INPUT);
}
void loop()
{
DIG1=digitalRead(digitalInPin);
DIG2=digitalRead(digitalInPin2);
if (DIG1) {
bm=1.1;
HSV_Game();
}
else if (DIG2) {
bm=1.9;
RAINBOW_Game();
}
else {
bm=2.4;
LIGHT_Game();
}
analogWrite(rpin, r/1.09); // ROSSO
analogWrite(gpin, g/1); // VERDE
analogWrite(bpin, b/bm); // BLUE
}
// funzione di armonizzazione dei valori analogici tramite media aritmetica
int SensorSmooth (int pin) {
sensorValue=0;
for (int i = 0; i<10; i++) { sensorValue+= analogRead(pin); } return int ((float)sensorValue/10+0.5); } // prima funzione: selezione del colore e della luminosità tramite potenziometri void HSV_Game() { valh = SensorSmooth(analogInPin); vals = 255; valv = SensorSmooth(analogInPin2); valh = map(valh,0,1023,0,359); valv = map(valv,0,1023,32,255); hsv2rgb(valh,vals,valv,r,g,b); } // seconda funzione: selezione di bianco caldo, bianco neutro e bianco freddo, oltre alla luminosità void LIGHT_Game() { valv = SensorSmooth(analogInPin2); valv = map(valv,0,1023,16,255); valh = SensorSmooth(analogInPin); if (valh=742) valh=2; if (valh>2) valh=1;
r=red[valh]*valv/255;
g=green[valh]*valv/255;
b=blue[valh]*valv/255;
}
// terza funzione: selezione della velocità di rotazione tra tutti i colori e della luminosità
void RAINBOW_Game() {
dl = SensorSmooth(analogInPin); // tempo di pausa
dl = map(dl,0,1023,1,100);
valv = SensorSmooth(analogInPin2);
valv = map(valv,0,1023,64,255);
unsigned long currentMillis = millis();
switch (j) {
case 0:
r=255*valv/255;
g=i*valv/255;
b=0*valv/255;
break;
case 1:
r=(255-i)*valv/255;
g=255*valv/255;
b=0*valv/255;
break;
case 2:
r=0*valv/255;
g=255*valv/255;
b=i*valv/255;
break;
case 3:
r=0*valv/255;
g=(255-i)*valv/255;
b=255*valv/255;
break;
case 4:
r=i*valv/255;
g=0*valv/255;
b=255*valv/255;
break;
case 5:
r=255*valv/255;
g=0*valv/255;
b=(255-i)*valv/255;
}
if (currentMillis-previousMillis > (long)(100-dl)) { // usa millis invece che delay
previousMillis=currentMillis;
i=i+1;
if (i==256) {
i=1;
j=j+1;
if (j==6) j=0;
}
}
}
/* Funzione che trasforma HSV in RGB
(c) Elco Jacobs, E-atelier Industrial Design TU/e, July 2011
http://code.google.com/p/shiftpwm/source/browse/trunk/examples/ShiftPWM_Example1/hsv2rgb.cpp?r=3
*/
void hsv2rgb(int hue, int sat, int val, unsigned int& r, unsigned int& g, unsigned int& b)
{
int H_accent = hue/60;
int bottom = ((255 - sat) * val)>>8;
int top = val;
int rising = ((top-bottom) *(hue%60 ) ) / 60 + bottom;
int falling = ((top-bottom) *(60-hue%60) ) / 60 + bottom;
switch(H_accent) {
case 0:
r = top;
g = rising;
b = bottom;
break;
case 1:
r = falling;
g = top;
b = bottom;
break;
case 2:
r = bottom;
g = top;
b = rising;
break;
case 3:
r = bottom;
g = falling;
b = top;
break;
case 4:
r = rising;
g = bottom;
b = top;
break;
case 5:
r = top;
g = bottom;
b = falling;
break;
}
}
Ecco qui un semplice inseguitore solare, realizzato con Arduino…
E’ solo una bozza, uno spunto da migliorare per creare nuovi progetti.
L’idea è molto semplice. Utilizzando due fotoresistenze (LDR), una che punta leggermente verso destra e l’altra leggermente verso sinistra, andiamo a leggerne i valori e muoviamo un servo a rotazione continua nella direzione della fotoresistenza che riceve più luce, finchè la luminosità non è circa uguale.
Il risultato finale è quello che vediamo nel seguente video:
Come potete vedere ho utilizzato Arduino Mini Pro come piattaforma, ma non cambia assolutamente nulla rispetto all’utlizzo con Arduino UNO. L’unica differenza è che nell’alimentare l’Arduino Pro Mini ho dovuto usare un regolatore esterno, perchè quello interno non è sufficiente per pilotare il servo.
Ma veniamo all’elenco dei materiali necessari:
1 – Una board Arduino UNO (o Duemilanove o qualsiasi altra board compatibile)
2 – Due fotoresistenze LDR da 20K (eventualmente con pochi aggiustamenti possono andare bene anche di altri valori)
3 – Due resistenze da 4.7K (eventualmente con condizione di luce differenti si possono usare valori differenti)
4 – Un servo a rotazione continua. (Difficili e/o costosi da trovare, ho modificato un servo standard seguendo le indicazioni che trovate a uno di questo link (http://www.gioblu.com/tutorials/azionamenti/188-modifica-rotazione-continua-microservi oppure http://robodroid.wordpress.com/2011/12/29/micro-servo-a-rotazione-continua/ oppure ancora http://www.robot-italy.com/article_info.php?articles_id=1)
5 – Una batteria da 9V, una breadboard, dei supporti di plastica e poco altro
I componenti vanno collegati nel seguente modo ad Arduino:
/*
ISArduino 0.1
Inseguitore Solare con Arduino
by Luca Soltoggio - 2012
https://arduinoelettronica.wordpress.com
*/
#include <Servo.h>
#include <Narcoleptic.h>
/*
Libreria che permette di mandare in standby il microcontrollore
nei momenti di inattività (delay), risparmiando parecchia energia.
Si può eventualmente anche non utilizzare (in tal caso va sostituita
l'ultima istruzione Narcoleptic.delay(15) con delay(15).
*/
Servo myservo;
int Value;
int Center=105;
/*
La variabile Center rappresenta il valore di centratatura
del servo a rotazione continua. Nel mio caso è 105, di solito è 90.
Con questo valore il servo deve restare fermo.
*/
void setup() {
Serial.begin(9600);
myservo.attach(9); // Collega il servo al PIN 9
}
void loop() {
int sensorValue = analogRead(A0); // Legge il valore del sensore LDR di sinistra
int sensorValue2 = analogRead(A1); // Legge il valore del sensore LDR di destra
Value=(sensorValue-sensorValue2)/10;
/*
Calcola la differenza tra i due sensori e li divide per 10,
in questo modo una differenza di 10 equivale a 1, una differenza
di 53 equivale a 5 e cosi via
*/
if (Value==0) myservo.detach(); else myservo.attach(9);
/*
Se la differenza è uguale a 0 scollega il servo altrimenti lo
collega (serve per risparmiare energia)
*/
if (Value>10) Value=10;
if (Value<-10) Value=-10;
/*
Limita la differenza massima tra -10 e + 10
(per evitare una velocità eccessiva)
*/
Serial.println(Value); // Debug - Visualizza il valore sulla seriale
myservo.write(Center+Value);
/*
Se il valore di Value è positivo, sposta il Servo a DX, se è negativo a SX.
La velocità è direttamente proporzionale al valore assoluto di Value
*/
Narcoleptic.delay(15);
/*
Invece che usare un semplice delay, usiamo questo, così risparmiamo energia.
Si può eventualmente sostituire con delay(15).
*/
}
Eccoci dunque a questo tanto atteso post.
In questo articolo vedremo come programmare alcuni Atmel della famiglia Attiny, in particolare quelli evidenziati nel titolo, utlizzando le librerie Arduino e Arduino Uno come ISP. Ovviamente il tutto può essere fatto anche utilizzando un programmatore dedicato, ma qui non mi soffermo su questo argomento più di tanto in quanto le differenze sono minime.
Partiamo da una premessa: sull’Attiny non andiamo a caricare il bootloader, ma procediamo ad un caricamento degli sketch direttamente nella memoria del microcontrollore. Quindi questa è una prima differenza rispetto agli Atmega328. Esistono forse cercando qua e là alcuni bootlaoder anche per Attiny, ma non ha molto senso montarli per diversi motivi. Il primo è l’esigua memoria che hanno questi microcontrollori (8kb per l’Attiny85 rispetto ai 32kb dell’Atmega328). In secondo luogo la maggior parte degli Attiny non hanno la seriale hardware, quindi non avrebbe senso montare un bootloader se poi non ci serve a fare l’upload via seriale.
Vediamo ora i vantaggi dell’Attiny85 rispetto all’Atmega328:
1 – minore consumo elettrico (quindi adatto per progetti a batteria)
2 – minore dimensione (l’Atmega328 ha 28 piedini, mentre l’Attiny85 ne ha solo 8)
3 – minor costo
Ovviamente presenta lo svantaggio che avendo meno piedini abbiamo un numero limitato di I/O rispetto ai fratelli maggiori.
Per quanto riguarda la programmazione è molto simile a quella vista nel post precedente e in quello prima ancora.
Vediamo innanzitutto la piedinatura dell’Attiny85 che useremo come esempio in questo articolo:
Quindi se voglio usare il PIN6 come uscita digitale userò pinMode(1,output) e se volessi leggere l’ingresso analogico dal PIN3 userò analogRead(A2).
Ovviamente anche qui come in arduino possiamo usare gli ingressi analogici come uscite digitali.
La seriale hardware non esiste come dicevamo, ma possiamo utlizzare il PIN2 (PB3) come seriale software monodirezionale. Praticamente usando i comandi standard di arduino tipo Serial.begin(9600), sul PIN2 abbiamo il segnale di TX, collegabile all’RX di un convertitore USB-SERIALE per comunicare dall’Attiny verso il PC, quindi è come se avessimo una “seriale in sola lettura”.
Ma veniamo alla pratica: rispetto alla programmazione dell’Atmega328, la programmazione dell’Attiny richiede la modifica e/o l’aggiunta di alcune librerie all’IDE. Consiglio di usare la versione 0023 dell’IDE, scaricabile dal sito di Arduino (con altre versioni non sono riuscito), e di creare una cartella apposita separata da usare unicamente per la programmazione degli Attiny.
Quindi se abbiamo già Arduino (ad esempio sotto la cartella c:\Arduino), andremo a creare una nuova cartella che chiameremo ad esempio c:\Arduino-Tiny.
Fatto questo dobbiamo andare a scaricare il core arduino-tiny-0022-0009.zip, che trovate qui, poi dobbiamo scaricare la libreria PinChangeInterrupt-0001.zip che troviamo qui e infine la libreria TinyTuner-0003.zip che trovate qui. Il primo files lo scompattate così com’è dentro la cartella hardware (es.: c:\Arduino-Tiny\hardware). Vi chiederà di sovrascrivere alcuni files. Ditegli di si senza problemi. Le altre due librerie le scompattate sotto la cartella libraries (es.: c:\Arduino-Tiny\libraries). A questo punto dovrebbe essere tutto apposto. Potete eseguire l’upload dei vostri esempi usando il seguente schema:
Praticamente è come per l’Atmega328. Il pin 10 va collegato al RESET, e i pin 11, 12, 13 ai pin MOSI, MISO, SCK (cioè in questo caso 5, 6, 7), più ovviamente l’alimentazione. Ricordatevi come sempre di inserire il condensatore da 22uF tra GND e RESET dell’Arduino UNO altrimenti la board si resetterà e l’upload non funzionarà generando un errore di sincronizzazione!!!
A questo punto aprendo dil nostro IDE, e aprendo uno sketch di esempio possiamo selezionando Tools –> Boards –> Attiny85 @1Mhz e poi File –> Upload to I/O Board.
Vi darà un errore di tipo “PAGEL”, ma si può ignorare. Vedrete il messaggio “Done Uploading” che vi avviserà che tutto è andato a buon fine.
Come vedete è molto semplice.
Gli Attiny escono di fabbrica con i fuse impostati in maniera tale che il microcontrollore utilizzi l’oscillatore interno a 1Mhz. E’ l’opzione migliore per la maggior parte dei progetti, ma se aveste bisogno di una velocità maggiore si può programmare l’Attiny in maniera tale che utilizzi il proprio oscillatore interno a 8Mhz oppure utlizzando un oscillatore esterno a 16Mhz (vedi post precedenti). Se vogliamo cambiare velocità al nostro Attiny, utlizzando as esempio l’oscillatore interno a 8Mhz, dobbiamo settare i fuse, facendo un’upload di un bootloader vuoto, contenente solo i settaggi che ci interessano. Per fare ciò è sufficiente selezionare da Tools –> Boards il settaggio che ci interessa (ad esempio Attiny85 @ 8Mhz), e poi Tools –> Burn bootloader —> w/Arduino as ISP.
A questo punto probabilmente vi darà il seguente errore:
avr_read(): error reading address 0x0000
read operation not supported for memory "lock"
avrdude: failed to read all of lock memory, rc=-2
Errore dovuto al fatto che manca nel file c:\Arduino-Tiny\hardware\tools\avr\etc\avrdude.conf la riga che riguarda l’operazione memory lock.
Quindi andiamo ad editare tale file e aggiugiamo la seguente riga:
read = "0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0",
"0 0 0 0 0 0 0 0 o o o o o o o o";
Nella sezione dell’Attiny85 sotto la riga memory “lock” che dovrebbe apparire così dopo la modifica:
# ATtiny85 has Signature Bytes: 0x1E 0x93 0x08.
memory "signature"
size = 3;
read = "0 0 1 1 0 0 0 0 0 0 0 x x x x x",
"x x x x x x a1 a0 o o o o o o o o";
;
memory "lock"
size = 1;
write = "1 0 1 0 1 1 0 0 1 1 1 x x x x x",
"x x x x x x x x 1 1 i i i i i i";
read = "0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0",
"0 0 0 0 0 0 0 0 o o o o o o o o";
min_write_delay = 9000;
max_write_delay = 9000;
;
Ora eseguendo l’operazione di bootloader dovrebbe andare.
Se vogliamo possiamo andare a sistemare anche il problema del messaggio “PAGEL” aggiungeno le seguenti righe:
pagel = 0xB3;
bs2 = 0xB4;
Sotto la riga chip_erase_delay = 4500; nella sezione relativa all’Attiny85. In questo modo dovrebbe apparire così dopo le modifiche:
#------------------------------------------------------------
# ATtiny85
#------------------------------------------------------------
part
id = "t85";
desc = "ATtiny85";
has_debugwire = yes;
flash_instr = 0xB4, 0x02, 0x12;
eeprom_instr = 0xBB, 0xFF, 0xBB, 0xEE, 0xBB, 0xCC, 0xB2, 0x0D,
0xBC, 0x02, 0xB4, 0x02, 0xBA, 0x0D, 0xBB, 0xBC,
0x99, 0xE1, 0xBB, 0xAC;
## no STK500 devcode in XML file, use the ATtiny45 one
stk500_devcode = 0x14;
## avr910_devcode = ?;
## Try the AT90S2313 devcode:
avr910_devcode = 0x20;
signature = 0x1e 0x93 0x0b;
reset = io;
chip_erase_delay = 4500;
pagel = 0xB3;
bs2 = 0xB4;
pgm_enable = "1 0 1 0 1 1 0 0 0 1 0 1 0 0 1 1",
"x x x x x x x x x x x x x x x x";
In questo modo l’errore è corretto ma solo sull’Attiny85. Per risolvere il problema anche per gli altri microcontroller, qui vi ho dato uno spunto. Fate eventualmente una ricerca su google con l’errore che vi è apparso durante l’upload del bootloader.
Potrebbe verificarsi un’ulteriore errore (non ricordo la dicitura) quando fate l’upload di sketch molto grossi.
In questo caso so che era legato ad un bug dell’avr-gcc, e per risolvero bisogna scaricare il tools Winavr, installarlo, e copiare il contenuto della cartella c:\WinAvr\tools\ in c:\Arduino-Tiny\hardware\tools\ sostituendo tutti i files presenti (eccetto il file avrdude.conf precedentemente modificato).
Questa ultima parte è un po’ più complessa, ma vedrete che se seguirete tutto alla lettera non sarà difficile.
Al prossimo post allora!!!