Appunti su programmazione ATTINY85 su piattaforma Digistump Digispark
L’attiny85 è un minuscolo microcontrollore con soli 6 pin con una minuscola memoria di 8 KB e una frequenza di lavoro di 16MHz, ma per alcuni progetti può benissimo sostituire una ben più costosa e ingombrante Arduino o Raspberry; per esempio per leggere semplicemente i valori di un dispositivo con interfaccia I2C.
L’unico problema è superare alcuni “scogli” per riuscire a programmarla tramite il normale IDE di Arduino; in giro c’è una moltpelicità di guide che spiegano trucchi e schemi elettrici vari per riuscire a programmare il modulo Digispark con l’arduino IDE usando una Arduino Uno come “ponte”…. ma sono obsoleti, non ce n’è più bisogno, ora si può semplicemente collegare il dispositivo al PC e caricarci direttamente lo sketch. Però bisogna seguire alcuni accorgimenti:
- Il problema dei driver
- Il problema del LED
- Il problema del mancato riconoscimento USB (suono continuo di connessione/disconnessione)
- Il problema della porta seriale
I driver
Servono dei driver specifici, che potrebbero non venire installati automaticamente quando si installa Arduino IDE, quindi ecco il link per scaricarli
Il LED
Esistono diverse varianti della board (rev2, rev3, rev4,…); sono identiche tranne per il pin a cui è collegato il LED: a volte 0, a volte 1; se è collegato al pin 0, non è possibile comunicare con dispositivi I2C, quindi va scollegato.
Mancato riconoscimento USB (suono continuo di connessione/disconnessione)
Connettendo il dispositivo a una porta USB, si sente inizialmente il classico suono di disconnessione, ma dopo 5 secondi si sente quello di disconnessione, poi di nuovo quello di connessione, e così via all’infinito.
Il problema è che… va bene così, è così che deve funzionare, non è rotto. E’ solo che va programmato in modo diverso da Arduino: prima di connettere il Digispark, bisogna avviare l’upload dello sketch, e solo dopo, quando è l’IDE stesso a chiederlo, bisogna collegare il dispositivo, e lo sketch verrà caricato. E una volta caricato il primo sketch, non ci sarà più il problema di connessione/disconnessione continua.
Dal manuale ufficiale:
You do not need to plug in your Digispark before invoking upload. Hit the upload button. The bottom status box will now ask you to plug in your Digispark – at this point you need to plug it in – or unplug and replug it. You’ll see the upload progress and then it will immediately run your code on the Digispark. If you unplug the Digispark and plug it back in or attach it to another power source there will be a delay of 5 seconds before the code you programmed will run. This 5 second delay is the Digispark Pro checking to see if you are trying to program it.
La porta seriale
Il problema della porta seriale… è che non c’è porta seriale, quindi il comando Serial.print() non è implementato e il Serial Monitor dell’IDE non si può usare.
Si può ovviare al problema installando una libreria a parte:
- http://digistump.com/wiki/digispark/tutorials/digicdc (servono driver particolari per la porta seriale virtuale che viene creata; consuma moltissima RAM)
- http://digistump.com/wiki/digispark/tutorials/digiusb (obsoleta) – mettendo all’inizio dello sketch un #include <DigiUSB.h> si può poi usare l’istruzione DigiUSB.println()
Altri metodi di debugging: link
Sensori I2C
Il digispark può leggere dati da sensori digitali tramite protocollo I2C (pin SDA e SLK):
- SDA: pin 0
- SCL: pin 2
Installando la scheda nell’IDE Arduino si rende disponibile uno sketch per la scansione di tutti i dispositivi I2C collegati (i2cscanner.ino)
Emulazione tastiera
Fortunatamente il Digispark non ha solo problemi, ma anche vantaggi; per esempio, nonostante le minuscole dimensioni, poichè gira a 16MHz e va a 5V, a differenza di altre board è in grado di emulare dispositivi HID (joystick, tastiere, mouse,…)
Connessione Android USB
Essendo in grado di emulare una tastiera, il Digispark può essere anche connesso via USB a uno smartphone che supporti l’OTG; il che significa che in sostanza si può usare per collegare a un dispositivo Android un qualunque sensore dotato di interfaccia I2C. Sorgenti di esempio.
Hacking Icaro – centralina GSM – il logger seriale
Questo primo sketch di prova utilizza una board ESP32 per leggere i dati scambiati tra il microcontrollore e il modem della scheda GSM/GPS della Icaro: vengono letti contemporaneamente i due canali in modo da mantenere la sincronia tra messaggi inviati e ricevuti, e poter meglio ricostruire il dialogo.
Al momento la “registrazione” viene effettuata solo inviando l’output al serial monitor dell’Arduino IDE; una successiva versione memorizzerà i dati o in una SD card, o su un server remoto, in modo che il logger possa essere montato direttamente sul veicolo senza necessità di un PC.
Trattandosi di un generico logger seriale a due canali, può in realtà essere usato per “sniffare” qualunque altra comunicazione seriale tra due dispositivi, o anche per loggare un singolo dispositivo.
Il numero a inizio linea identifica il canale cui si riferisce la linea stessa.
// Greengo/Zhidou/Xindayang GSM logger
// Read data from GSM/GPS logger, from both MCU and MODEM outputs and same time
// using ESP32 board.
// V. 0.1.0 - First working version; logs only to USB/serial port (PC needed).String tempVal = ""; String row0 = ""; String row1 = ""; int MAXLEN = 50;
void setup() {
// initialize serial:
// Recommendation: use Serial0 and 1 for your duplex devices and serial2 for your debug messages.
// https://github.com/espressif/arduino-esp32/issues/1314
//
// Standard serial pinouts:
// https://circuits4you.com/2018/12/31/esp32-hardware-serial2-example/
// UART RX TX CTS RTS
// UART0 GPIO3 GPIO1 N/A N/A
// UART1 GPIO9 GPIO10 GPIO6 GPIO11
// UART2 GPIO16 GPIO17 GPIO8 GPIO7
// But all 3 HW UARTs can be remapped to any pin.
Serial.begin(9600,SERIAL_8N1, 16, 17); // Input 1 (16 = RX)
Serial1.begin(9600,SERIAL_8N1, 4, 2); // Input 2 (4 = RX)
Serial2.begin(9600,SERIAL_8N1, 3,1); // Standard USB-serial port
Serial2.println("Free heap:");
Serial.println(ESP.getFreeHeap());
Serial2.println("--------------------");
}
void loop() {
// read from port 0, send to port 2:
if (Serial.available()) {
int inByte = Serial.read();
/*
Serial2.print("\t0\t0x");
Serial2.print(inByte,HEX);
Serial2.print("\t");
Serial2.print(inByte,DEC);
if (inByte>31) {
Serial2.print("\t");
Serial2.write(inByte);
}
Serial2.println();
*/
tempVal = String(inByte);
row0 += "\t" + tempVal;
if (row0.length() > MAXLEN) {
Serial2.print("0\t");
Serial2.println(row0);
row0="";
}
}
// read from port 1, send to port 2:
if (Serial1.available()) {
int inByte = Serial1.read();
/*
Serial2.print("\t1\t0x");
Serial2.print(inByte,HEX);
Serial2.print("\t");
Serial2.print(inByte,DEC);
if (inByte>31) {
Serial2.print("\t");
Serial2.write(inByte);
}
Serial2.println();
*/
tempVal = String(inByte);
row1 += "\t" + tempVal;
if (row1.length() > MAXLEN) {
Serial2.print("1\t");
Serial2.println(row1);
row1="";
}
}
}
Diario elettrico GreenGo Icaro: il CAN-BUS
La centralina della mia Icaro ha il CAN-BUS abilitato (notare che l’abilitazione fa lievitare il costo di 80 euro su 800 al momento dell’ordine), il che significa che è possibile collegarsi con un paio di fili alla centralina per leggere molti dati interessanti.
Pare che dalla KHB72701 sia possibile leggere questi dati:
Pin del connettore J1:
- 5, 7, 13: GND/RTN
- 10: CAN bus high
- 11: CAN bus low
Per leggere i dati tramite una Arduino o simili è sufficiente un apposito shield:
- SeedStudio CAN-BUS Shield V2 – $25
- Elecfreaks CAN-BUS Shield – $12
- Sparkfun CANBUS shield – Robotitaly 713262 (Italia) – €25,00
- CAN BUS Shield For Arduino – Robotitaly 120370 (Italia) – €25,00
- Seedstudio CAN-BUS Shield V2 – Robotitaly 809151 (Italia) – €27,00
- Robotics3d SF-DEV-10039 (Italia) – €38,00
- AptoFun CAN-BUS Shield MCP2515 with TJA1050 – €9,00
In realtà è anche possibile che da qualche parte sia nascosto un connettore standard OBD, devo cercare bene sotto il cruscotto prima di avventurarmi nell’impresa.
Appunti ESP8266 – Come risolvere problemi di stabilità
Sembra che l’ESP8266 sia famoso per la sua instabilità, cioè la facilità con cui perde la connessione WiFi si resetta; queste ottime pagine spiegano come ovviare al problema: link1, link2.
Riassumendo:
- Il comando “delay()” resetta il WatchDog Timer (WD o WT); si tratta di un contatore che, se raggiunge un valore troppo alto (maggiore di 5 secondi e non modificabile), fa riavviare il dispositivo; è un sistema di sicurezza per evitare che il sistema, se si blocca, resti bloccato indefinitamente: in “sottofondo” è infatti sempre attivo un controllo hardware sul watchdog, anche quando uno sketch si blocca; se rimane bloccato per troppo tempo, il processore va in autoreset e quindi lo sketch si riavvia; quindi lo sketch deve essere predisposto per potersi riavviare da solo senza l’intervento dell’utente.
- Forse anche il comando wdt_feed() resetta il watchdog, ma probabilmente è un comando dell’SDK di ESP, quindi per utenti evoluti.
- Utilizzando l’ESP8266 come access point (ossia come router o come sever), bisogna evitare di gestire l’attesa dei comandi web durante alla funzione standard loop(), perchè sembra che la loop() interferisca con i meccanismi del wifi; bisogna invece implementare una funzione di callback che viene chiamata quando il client connesso all’ESP gli invia un comando (sketch di esempio: link).
- La connessione WiFi può spesso cadere senza motivo, quindi uno sketch deve sempre prevedere nella funzione loop() un monitoraggio della connessione, per ristabilirla se cade.
Queste righe servono a verificare se è attiva la connessione tra l’ESP e un router, non tra un dispositivo e l’ESP:
while (WiFi.status() != WL_CONNECTED) {
Serial.print(“.”);
delay(500);
}
Quindi vanno dopo la riga:
WiFi.begin(ssid, password);
Dove “ssid” è il nome del router.
Invece, per rilevare la connessione di un dispositivo bisogna usare questo codice:
#include <ESP8266WiFi.h>
WiFi.disconnect(true); // Più che disconnettere, cancella dalla PROM i parametri di connessione usati finora;
WiFi.persistent(false); // Evita che tali parametri vengano poi memorizzati
WiFi.mode(WIFI_AP); // Imposta la modalità di connessione su Access Point
WiFi.softAP(ssid); // Imposta il nome della rete e accende l’access point (senza password)
delay(1000); // Ritardo per azzerare il watchdog
WiFi.onEvent(WiFiEvent); // Rileva tutti gli eventi WiFi nella funzione “WiFiEvent(WiFiEvent_t event); - Quando usa il WiFi, l’ESP8266 ha bisogno di molta più corrente dei 500 mA che può fornire la porta USB di un PC, quindi va alimentato con un trasformatore.
- Anche utilizzare un adattatore USB/seriale può causare interferenze nel WiFi e perdita di connessione, quindi una volta terminate le prove, usare sempre un alimentatore per alimentare l’ESP.
- Ad ogni richiesta http GET proveniente da un client, l’ESP “perde un po’ di memoria (heap)”, per liberarla solo “dopo un po’ “, quindi non si può inondare l’ESP di richieste http GET, bisogna aspettare almeno due minuti tra l’una e l’altra (fonte).
- Un “bug noto” impedisce a SoftAP() di funzionare (cioè di impostare l’ESP come accesspoint) se l’ESP non è anche connesso a un router.
Esiste anche una libreria WiFi specifica che effettua la riconnessione automatica in caso di disconnessione, ma è per una Arduino collegata a un ESP:
https://github.com/ekstrand/ESP8266wifi
Programmare l’ESP8266 con Arduino IDE
Brevissimo tutorial su come rendere il NodeMCU Amica con ESP8266 ESP12 a bordo programmabile tramite IDE Arduino.
- Scaricare esp8266_flasher.exe.
- Scaricare i file del firmware ESP_Easy (*).
- Collegare il NodeMCU (ad esempio Amica o Lolin) al PC tramite USB
- Avviare l’IDE arduino per verificare quale porta sia stata associata al dispositivo (menu Strumenti –> Porta)
- Aprire il monitor seriale di Arduino
- Premere e rilasciare il tasto reset sul NodeMCU per verificare se effettivamente il dispositivo comunica con l’IDE attraverso quella porta
- Chiudere l’IDE
- Avviare esp8266_flasher.exe
- Impostare il numero di porta
- Caricare il file .bin corretto, che dipende dalle dimensioni della flash a bordo del dispositivo (4MB o 4096 kbyte sull’ESP12, montato su Huzzah Adafruit, NodeMCU Lolin, NodeMCU Amica)
- Tenere premuto il tasto FLASH sul dispositivo, premere il tasto reset, rilasciare reset e rilasciare il tasto FLASH: in questo modo il dispositivo si predispone per la riprogrammazione (re-flashing)
- Cliccare DOWNLOAD: in realtà non verrà scaricato un file DA internet, ma inviato il firmware al dispositivo
- Attendere il completamento dell’operazione.
- Riaprire l’IDE di Arduino
- Ripetere il punto 11
- Caricare sul dispositivo uno sketch di esempio che stampi qualcosa sul monitor seriale
Metodo alternativo:
Per flashare il firmware è possibile usare direttamente anche il file eseguibile presente nel pacchetto ESP_Easy (*), che però è un po’ meno intuitivo. Una volta nota la porta a cui è collegato il dispositivo (v. punto 4 sopra) e la memoria disponibile (v. punto 10 sopra), mettere il dispositivo in modalità FLASH (punto 11 sopra), avviare esptool e indicare in sequenza il numero di porta, la dimensione della flash e la versione del fimware, cioè il numero dopo la “R” nel nome del file; ad esempio, ESPEasy_R108_4096.bin è la versione 108 per l’ESP da 4096 kbyte.
Nota: per scoprire quant’è grande la Flash RAM sul dispositivo si potrebbe usare questo comando:
esptool.py flash_id
Ma la cosa richiede di preinstallare e configurare un interprete python, che è una noia e una rogna, sto cercando un modo più semplice e alla portata di tutti.
(*) Il file .zip contiene vari file .bin, che sono firmware adatti a moduli ESP con Flash RAM di dimensioni diverse: 512 kbyte, 1924 kbyte, 4096 kbyte; ad esempio, il file ESPEasy_R108_1024.bin è per un ESP da 1024 kbyte (1Mbit); R108 è il numero di “build”, cioè di versione.
Collegamento di un CellLog8S/8m ad Arduino o a ESP8266
L’utente pa.hioficr sul forum https://endless-sphere.com/forums/viewtopic.php?f=14&t=20142 ha scoperto che è possibile leggere in tempo reale i dati di log di un CellLog (sia 8S con memoria che 8S senza memoria) semplicemente “agganciandosi” al pin TX dell’Atmel montato sul CellLog.
Questo significa che invece di spendere 40-50 euro per comprare un CellLog8S con memoria e infilarlo nel sottosella per poi aspettare di arrivare a casa per scaricare i dati letti, è in linea di principio possibile collegare al CellLog8M da 15 euro un ESP8266 da 8 euro che tramite Wifi invia dati a uno smartphone che li mostra in tempo reale sullo schermo durante la marcia; probabilmente è anche possibile scrivere un SW che legge i dati da più di un celllog contemporaneamente, sfruttando l’emulatore di porte seriali.
Questo è lo schema elettrico originale dell’autore:
Questa è una sua successiva modifica per implementare anche avvio del logging e reset del CellLog:
Di seguito la spiegazione del funzionamento che ho dedotto io dallo schema, inserita anche nella seconda edizione del mio libro “Guida alla costruzione di una batteria al litio per mezzi elettrici”, di imminente pubblicazione:
R1 = R4 = R6 = R7 = 220 ohm
R2 = R5 = 330 ohm
R3 = 4700 ohm
U1 = U2 = optocoupler/fotoaccoppiatore a 2 canali, 5V, 8 pin, uscita a fototransistor di tipo NPN (es. Vishay ILD615, Fairchild MCT61, Isocom ISP827,… )
Figura 127 – Rilevamento accensione
2. Passerà una corrente nel fotodiodo 1-2
3. Si accenderà il fototransistor 7-8
Il “cervello” del CellLog, un microcontrollore ATMEL, è dotato di un piedino di reset, che possiamo controllare tramite il nostro microcontrollore esterno; per farlo, al pin di reset colleghiamo il collettore del fototransistor 5-6 del secondo fotoaccoppiatore (pin 5); controlliamo questo fototransistor tramite il rispettivo fotodiodo 3-4, collegato al pin MCU_CL8.1_RESET del nostro microcontrollore esterno; basterà quindi mettere alto questo pin per mettere in conduzione il fotodiodo e il fototransistor e quindi resettare il CellLog.
Per far partire il logging è necessario premere per 3 secondi il pulsante 2 del CellLog (SW2); possiamo farlo fare al nostro microcontrollore esterno collegando l’interruttore in parallelo a un’uscita del secondo fotoaccoppiatore: quando sull’ingresso ci sarà una tensione di 5V (impostata via software), il fototransistor di uscita entrerà in conduzione chiudendo l’interruttore e avviando così il logging.
Datalogger per regolatori di carica EPSolar Tracer MPPT
Mi appunto un paio di link interessanti su come costruire o dove comprare cavi/interfacce per collegare un regolatore di carica EPSolar a un PC o a un logger standalone, invece che semplicemente al display “istantaneo” fornito di serie, che non memorizza niente:
monitoraggio mppt ep solar 40A
Datalogger Arduino per regolatore EP Solar
Questo sarebbe interessante se vendessero anche la sola interfaccia seriale:
GWL/Power Solar Controller Monitor for Tracer series (RS-232/USB)
Così si potrebbe collegare alla nuovissima versione (marzo 2014) di Ardulog, che ora oltre ad avere la SD Card incorporata ha anche l’RTC incorporato:
http://www.hobbytronics.co.uk/ardulog-rtc
Da notare che, nonostante serva un cavo di rete per collegare display e regolatore, NON è un interfaccia di rete ma un’interfaccia seriale a 12V, e collegare il cavo al regolatore e al PC significherebbe probabilmente bruciare la scheda di rete, che lavora a 3 o 5 V e con tutt’altro protocollo!
Ecco “Displog”, il DISPlay che LOGga!
Una volta domato il bastardo Ardulog, crearci nuove applicazioni è solo questione di fantasia!
Ecco quindi nascere DISPLOG, il primo display con logger incorporato, o logger con display incorporato, fate vobis:
DISPLOG – DISPLAY + LOGGER on SD card
La faccenda è molto semplice: il display grafico/alfanumerico 3110/5110 (aka Philips PCD8544) può essere pilotato tramite 5 soli pin (addirittura 4 in casi particolari), e su Ardulog ci sono 4 pin analogici disponibili (A1, A3, A4 e A5), più RX e TX (D0 e D1); quindi si tratta solo di giocherellare un po’ con le impostazioni di un banale sorgente di esempio sul playground, fare 5 saldature, ed ecco ottenuto un display che supporta le micro SD card!
Tutto quello che cè da fare è modificare le prime linee di codice in questo modo:
#define PIN_SCE 0
#define PIN_RESET 1
#define PIN_DC A3
#define PIN_SDIN A4
#define PIN_SCLK A5
Manca un PIN libero per accendere la retroilluminazione, ma Hobbytronics ha previdentemente predisposto due piazzole libere vicino ai due LED, quindi si può facilmente utilizzare il pin 5 o 13 per comandare la retroilluminazione.
Il pin analogico A1 rimane disponibile per collegare un qualunque sensore analogico.
Prima uscita pubblica per PowerDuino standalone ad Arduino day 2013
Oggi c’e’ stata la presentazione ufficiale al pubblico del progetto PowerDuino Standalone. Nato dopo lunghe vicissitudini durate addirittura un anno, e’ diventato possibile grazie a un Arduino Uno originale (al posto del clone Luigino usato per le innumerevoli prove fallite) e ad un Ardulog, successore dell’OpenLog. I numerosi visitatori, dapprima solo un po’ incuriositi, poi decisamente colpiti, hanno mostrato la validita’ dell’idea di un cosino largo 2 ceentimetri in grado di monitorare I consumi di tutta casa senza bisogno di nessuna conoscenza di elettronica: basta un rotolo di nastro adesivo, e PowerDuino Standalone e’ operativo! Il nastro serve ad attaccare la fotoresistenza al led presente sui normali contatori elettronici; 30 secondi per effettuare la calibrazione (da farsi solo la prima volta, poi verra’ mantenuta anche staccando la batteria), e poi il logger inizia a registrare. Presto I sorgenti saranno disponibili sul blog per chiunque desideri costruire l’apparecchio in proprio. Per chi non ama il fai da te, il modello standalone costera’ 30 euro e il modello da quadro 65.
Appunti su OpenLog – il file di configurazione config.txt
La documentazione di questo pur utile, minuscolo cosino in grado di registrare miliardi di dati in 4 cm2 lascia molto a desiderare a causa delle molteplici versioni succedutesi nel tempo.
Ecco quindi una breve spiegazione del file di configurazione di OpenLog:
- si deve chiamare CONFIG.TXT (tutto maiuscolo)
- il file deve contenere un’unica riga, non sono ammesse righe di commento
- la riga contiene numeri separati da virgole, senza nessun identificativo; è cioè un file di configurazione POSIZIONALE
Parametri ammessi:
Versione 1:
- baudrate (max 230400), carattere di escape, numero di ripetizioni necessarie del carattere di escape, tipo di logging
Esempio:
- 115200,103,14,0 = 115200 bps, escape char of ASCII(103), 14 times, new log mode
Versione 2:
- Come versione 1 (ma baud max=115200)
Versione 3:
- baudrate (max=115200), carattere di escape, numero di ripetizioni necessarie del carattere di escape, tipo di logging, modalità prolissa on/off, echo on/off
Esempio:
- 115200,103,14,0,1,1 = 115200 bps, escape char of ASCII(103), 14 times, new log mode, verbose on, echo on.
Spiegazione parametri:
- 9600: The communication baud rate. 9600bps is default. Acceptable values are 2400, 4800, 9600, 19200, 38400, 57600, 115200.
- 26: The ASCII value (in decimal form) for the escape character. 26 is ctrl+z and is default. 36 is ‘$’ and is a commonly used escape character.
- 3: The number of escape characters required. By default it is three so you must hit ctrl+z three time to drop to command mode.
- 0: System mode. OpenLog starts in newlog mode (0) by default. Acceptable values are 0 = New Log, 1 = Sequential Log, or 2 = Command mode.
- 1: Verbose mode. Extended (verbose) error messages are turned on by default. Setting this to 1 turns on verbose error messages such as unknown command: remove !. Setting this to 0 turns off verbose errors but will respond with a ‘!’ if there is an error. Turning off verbose mode is handy if you are trying to handle errors from an embedded system.
- 1: Echo mode. While in command prompt characters are echoed by default. Setting this to 0 turns off character echo. Turning off echo is handy if you are trying to handle errors and don’t want to have the sent commands echoing back to the sender.
Nota: nessuna versione di firmware consente al momento di registrare letture dei PIN piuttosto che dei dati seriali, sebbene TX e RX possano teoricamente essere configurati come input digitali; non sono presenti pin analogici sulla board, sebbene A0, A1, A3, A4 e A5 siano disponibili sul chip (A2 non è disponibile).
Nota2: su ArduLog, una variante di OpenLog, sono presenti anche 4 piedini analogici, ma poichè usa lo stesso firmware di OpenLog, non è comunque possibile registrare nessun input!
Nota3: SDLogger, altra variante di OpenLog, utilizza versioni leggermente modificate del firmware di OpenLog, e utilizza SD Card grandi invece che mircoSD. Ha 4 pin analogici (oltre a una porta seriale aggiuntiva), ma non può comunque registrare dati letti dai pin.
leave a comment