Archivi categoria: Arduino
Primo Incontro Il Semaforo Arduino
Il primo incontro sull’Unità Didattica Il Semaforo Arduino si è tenuto con un gruppo ristretto di partecipanti dall’età prescolare, alle medie, alle superiori, a genitori ed appassionati.
Il bilancio è decisamente positivo e al centro dell’affermazione si può porre la piccola in età prescolare, che non sa ancora leggere e capace di seguire i discorsi introduttivi, ma nel momento di vivo laboratorio si è letteralmente scatenata nell’apprendere dalle immagini della guida stampata, a corredo del kit, come realizzare il Semaforo Arduino e vederlo funzionare. Non sapeva leggere numeri e parole quali GND, ma ha collocato i fili nel posto giusto, e nel momento di erogare energia alla scheda è rimasta visibilmente entusiasta: le luci colorate brillavano nella sequenza sperata. E’ stato un momento semplice, ma speciale vederla guardare soddisfatta per un bel po’ di tempo sua realizzazione.
I giovani, ma anche i genitori distratti da ben altri problemi, si sono rivolti all’esperienza con interesse vivo, ed alla fine un’affermazione di un genitore riassume l’intera esperienza: “non sapevo che fosse così interessante, adesso ho capito ed è importante“.
Quindi il gioco con i computer in miniatura per introdurre questioni realmente ostili, come la programmazione delle macchine calcolatrici, funziona ed alla grande.
Prevediamo di organizzare anche altri incontri allargati.
Commenti al Firmware Arduino 0.18.08
Revisione 0.03
La nuova versione 0.18.08 del Firmware Arduino permette di realizzare l’Unità Didattica Il Semaforo Arduino.
L’Unità Didattica prevede di realizzare un modello di semaforo con tre LED colorati rosso, giallo e verde, collegati ai pin 2, 4 e 6.
All’avvio, se la sezione SEMAFORO nello sketch è attivata e la variabile semaforo_stato è automatico, allora si avvia il ciclo continuo di accensione e spegnimento con dati ritardi delle luci.
Seguirà l’ implementazione del comando
semaforo automatico|disabilitato|rosso|giallo|verde
da utilizzare nel consueto modo da remoto mediante canale USB .
Il codice sorgente relativo all’Unità Didattica viene attivato con
#define SEMAFORO
In questo caso vengono definite ed inizializzate le seguenti variabili:
#if defined(SEMAFORO)
String semaforo_stato = “automatico”;
// manuale|automatico|disabilitato
String semaforo_luce = “rossa”; // rossa|gialla|verde
int semaforo_durata_rosso = 3; // in secondi
int semaforo_durata_giallo = 1; // in secondi
int semaforo_durata_verde = 3; // in secondi
int semaforo_pin_rosso = 2;
int semaforo_pin_giallo = 4;
int semaforo_pin_verde = 6;
#endif
Quindi nella funzione setup()
#if defined(SEMAFORO)
pinMode(semaforo_pin_rosso, OUTPUT);
pinMode(semaforo_pin_giallo, OUTPUT);
pinMode(semaforo_pin_verde, OUTPUT);
#endif
E nella funzione loop()
#if defined(SEMAFORO)
if(semaforo_stato == “automatico”)
{
while(true) {
digitalWrite(semaforo_pin_rosso, HIGH);
delay(1000 * semaforo_durata_rosso);
digitalWrite(semaforo_pin_rosso, LOW);
digitalWrite(semaforo_pin_giallo, HIGH);
delay(1000 * semaforo_durata_giallo);
digitalWrite(semaforo_pin_giallo, LOW);
digitalWrite(semaforo_pin_verde, HIGH);
delay(1000 * semaforo_durata_verde);
digitalWrite(semaforo_pin_verde, LOW);
}
}
#endif
Arduino Firmware 0.18.08
#define FIRMWARE_VERSION "0.18.08"
/*Language: Wiring/Arduino Serial Console 115200 baud \n ASCII 10 */
#define WATCH_DOG_ENABLED
#define LCD_ENABLED // pin 4,5,6,7,8,9 reserved
#define MACRO_01 // per utilizzi specifici
#define SEMAFORO
/* 001
Si osservi l'utilizzo del C preprocessor,
macro processor, per compilare il minor codice
possibile al fine di poter utilizzare
microcontroller con modeste risorse.
Il generatore codice sorgente firmware
provvederà a includere le opportune
righe di definizione variabili
per il prepocessor
*/
// #include <Wire.h>
#if defined(WATCH_DOG_ENABLED)
#include <avr/wdt.h>
#endif
/* 002
Importante predisposione dei microcontroller:
watch dog al livello hardware
che firmware successivi andranno a
implementare in modo migliore.
Dovranno tener conto anche del tipo di scheda
che esegue il firmware, infatti Uno e Mega
hanno gestione diverse del watch dog
a livello hardware
*/
#if defined(LCD_ENABLED)
#include <LiquidCrystal.h>
#endif
/* 003
La connessione LCD al controller
adottata lo standard DF-Robots
*/
#if defined(TEENSYDUINO)
/* 004
Riconoscimento della scheda
che esegue il Firmware
*/
// --------------- Teensy -----------------
#if defined(__AVR_ATmega32U4__)
#define BOARD "Teensy 2.0"
#elif defined(__AVR_AT90USB1286__)
#define BOARD "Teensy++ 2.0"
#elif defined(__MK20DX128__)
#define BOARD "Teensy 3.0"
#elif defined(__MK20DX256__)
#define BOARD "Teensy 3.2" // and Teensy 3.1 (obsolete)
#elif defined(__MKL26Z64__)
#define BOARD "Teensy LC"
#elif defined(__MK64FX512__)
#define BOARD "Teensy 3.5"
#elif defined(__MK66FX1M0__)
#define BOARD "Teensy 3.6"
#else
#error "Unknown board"
#endif
#else // --------------- Arduino ------------------
#if defined(ARDUINO_AVR_ADK)
#define BOARD "Mega Adk"
#elif defined(ARDUINO_AVR_BT) // Bluetooth
#define BOARD "Bt"
#elif defined(ARDUINO_AVR_DUEMILANOVE)
#define BOARD "Duemilanove"
#elif defined(ARDUINO_AVR_ESPLORA)
#define BOARD "Esplora"
#elif defined(ARDUINO_AVR_ETHERNET)
#define BOARD "Ethernet"
#elif defined(ARDUINO_AVR_FIO)
#define BOARD "Fio"
#elif defined(ARDUINO_AVR_GEMMA)
#define BOARD "Gemma"
#elif defined(ARDUINO_AVR_LEONARDO)
#define BOARD "Leonardo"
#elif defined(ARDUINO_AVR_LILYPAD)
#define BOARD "Lilypad"
#elif defined(ARDUINO_AVR_LILYPAD_USB)
#define BOARD "Lilypad Usb"
#elif defined(ARDUINO_AVR_MEGA)
#define BOARD "Mega"
#elif defined(ARDUINO_AVR_MEGA2560)
#define BOARD "Mega 2560"
#elif defined(ARDUINO_AVR_MICRO)
#define BOARD "Micro"
#elif defined(ARDUINO_AVR_MINI)
#define BOARD "Mini"
#elif defined(ARDUINO_AVR_NANO)
#define BOARD "Nano"
#elif defined(ARDUINO_AVR_NG)
#define BOARD "NG"
#elif defined(ARDUINO_AVR_PRO)
#define BOARD "Pro"
#elif defined(ARDUINO_AVR_ROBOT_CONTROL)
#define BOARD "Robot Ctrl"
#elif defined(ARDUINO_AVR_ROBOT_MOTOR)
#define BOARD "Robot Motor"
#elif defined(ARDUINO_AVR_UNO)
#define BOARD "Uno"
#elif defined(ARDUINO_AVR_YUN)
#define BOARD "Yun"
// These boards must be installed separately:
#elif defined(ARDUINO_SAM_DUE)
#define BOARD "Due"
#elif defined(ARDUINO_SAMD_ZERO)
#define BOARD "Zero"
#elif defined(ARDUINO_ARC32_TOOLS)
#define BOARD "101"
#else
#define BOARD "Unknown board"
#endif
#endif
boolean lcd_print_sec = true;
#if defined(LCD_ENABLED)
LiquidCrystal lcd(8, 9, 4, 5, 6, 7);
// lcd_print_sec = true;
#endif
#if defined(SEMAFORO)
String semaforo_stato = "automatico"; // manuale|automatico|disabilitato
String semaforo_luce = "rossa"; // rossa|gialla|verde
int semaforo_durata_rosso = 3; // in secondi
int semaforo_durata_giallo = 1; // in secondi
int semaforo_durata_verde = 3; // in secondi
int semaforo_pin_rosso = 2;
int semaforo_pin_giallo = 4;
int semaforo_pin_verde = 6;
#endif
boolean request_response = true;
String end_response = "Done ";
/* 006
Il protocollo sviluppato utilizza
lo schema naturale request / response
con stringhe di testo e terminate da capo riga
Il Firmware prevede di poter terminare
la risposta del controller con una riga
che inizia con Done ...
*/
// const int TIMEOUT_CICLE = 200;
int CYCLE_DELAY = 20;
/* 007
CYCLE_DELAY è il ritardo nel ciclo principale
che realizza il poll mediante porta USB
verrà gestito il comando che
permetterà di variare il contenuto
*/
byte portType[54];
/* 008
Matrice fondamentale che contiene la
configurazione dei PIN del microcontroller
che è assegnata dal comando CONFIG
*/
char incomingChar = '\0';
String incomingString = "";
String command = "";
String parameters = "";
String parameter = "";
String tempString = "";
String tempString1= "";
String tempString2= "";
int port = 0;
String portvalue = "";
String portname = "";
int pos = 0;
int pos1 = 0;
int pos2 = 0;
int pos3 = 0;
int tempInt = 0;
char tempChar = '\0';
int inPortMap[7];
int loop_100 = 0;
int loop_10000 = 0;
/* 009
variabili che realizzano due cicli
demoltiplicati rispetto al ciclo principale
ovvero loop_100 diventa vera ogni cento
cicli principali
*/
void setup()
{
#if defined(WATCH_DOG_ENABLED)
wdt_enable(WDTO_8S);
#endif
Serial.begin(115200);
delay(50);
#if defined(LCD_ENABLED)
lcd.begin(16, 2);
lcd.setCursor(0,0);
lcd.print("IoT ");
lcd.print(FIRMWARE_VERSION);
#endif
for (int i = 0; i <= 53; i++)
{
portType[i] = 0;
}
/* 010
La matrice portType contiene la configurazione
dei PIN del microcontroller
Le Schede Mega hanno
54 port digital, from 9 to 53
16 port AD, from 0 to 13
I valori in portType significano:
0 not defined
1 IN
2 OUT
3 PWM
4 LCD
5 I2C
6 SPI
7 SERIAL
*/
#if defined(LCD_ENABLED)
// 8, 9, 4, 5, 6, 7
portType[4] = 4;
portType[5] = 4;
portType[6] = 4;
portType[7] = 4;
portType[8] = 4;
portType[9] = 4;
#endif
#if defined(SEMAFORO)
pinMode(semaforo_pin_rosso, OUTPUT);
pinMode(semaforo_pin_giallo, OUTPUT);
pinMode(semaforo_pin_verde, OUTPUT);
#endif
// Wire.begin();
}
void loop()
{
loop_100 = loop_100 + 1;
if (loop_100 = 100)
{
loop_100 = 0;
loop_10000 = loop_10000 +1;
}
if (loop_10000 = 100)
{
loop_10000=0;
}
#if defined(WATCH_DOG_ENABLED)
wdt_reset();
#endif
#if defined(LCD_ENABLED)
if (lcd_print_sec)
{
lcd.setCursor(0,1);
lcd.print(millis()/1000);
}
#endif
#if defined(SEMAFORO)
if(semaforo_stato == “automatico”)
{
while(true) {
digitalWrite(semaforo_pin_rosso, HIGH);
delay(1000 * semaforo_durata_rosso);
digitalWrite(semaforo_pin_rosso, LOW);
digitalWrite(semaforo_pin_giallo, HIGH);
delay(1000 * semaforo_durata_giallo);
digitalWrite(semaforo_pin_giallo, LOW);
digitalWrite(semaforo_pin_verde, HIGH);
delay(1000 * semaforo_durata_verde);
digitalWrite(semaforo_pin_verde, LOW);
}
}
if (Serial.available() > 0)
{
incomingChar = Serial.read();
if (incomingChar == '\n')
{
execCommand();
incomingString = "";
}
else
{
incomingString += incomingChar;
if (incomingString.length() > 254)
{
Serial.print("Error: ");
Serial.println(incomingString);
incomingString = "";
}
}
}
}
void execCommand()
{
incomingString.trim();
command = incomingString;
if (incomingString.indexOf(" ")>0)
{
command = incomingString.substring(0,
incomingString.indexOf(" "));
command.trim();
parameters = incomingString.substring(pos);
parameters.trim();
}
command.toLowerCase();
if ((command == "version") || (command == "ver"))
{
Serial.println(FIRMWARE_VERSION);
}
else
if ((command == "board"))
{
Serial.println(BOARD);
}
else if ((command == "help"))
{
PrintHelp();
}
else if (command == "config")
{
configPort();
}
else if (command == "write" or command == "set")
{
writePort();
}
else if (command == "read" or command == "get")
{
readPort();
}
else if (command == "lcd")
{
#if defined(LCD_ENABLED)
lcdExecCommand();
#endif
}
else
{
Serial.println("command unknown");
}
};
void PrintHelp()
{
Serial.println( "--------------------------------------------------------");
Serial.println("");
Serial.println("Commands (case not sensitive)");
Serial.println("");
Serial.println("ver|version");
Serial.println("board");
Serial.println("config port 0..53 type unused|IN|OUT|PWM|LCD|I2C|SPI|SERIAL");
Serial.println("set|write port <n> value 0|low|1|high");
Serial.println("get|read port <n>");
Serial.println("lcd on|enable|off|disable");
Serial.println("lcd clear");
Serial.println("lcd clear row 1|2");
Serial.println("lcd print row 1|2 <string>");
Serial.println("lcd print seconds on|off");
Serial.println("request_response on|off");
Serial.println("");
Serial.println( "------------------------------------------------");
}
void configPort()
{
// CONFIG PORT n TYPE out
parameters = parameters.substring(parameters.indexOf("port") + 5);
parameters.trim();
pos = parameters.indexOf(" ");
String port_number = parameters.substring(0, pos);
port_number.trim();
String port_type = parameters.substring(parameters.indexOf("type")+4);
port_type.trim();
port_type.toLowerCase();
int int_port_number = -1;
if(port_number.length()>0)
{
int_port_number = port_number[0] - '0';
}
if(port_number.length()>1)
{
int_port_number = int_port_number * 10 + port_number[1] - '0';
}
if (int_port_number>=0 and (BOARD=="Mega" or (BOARD=="Uno" and int_port_number< 14)) )
{
if (port_type=="unused")
{
portType[int_port_number] = 0;
}
else if (port_type=="in" or port_type=="input")
{
portType[int_port_number] = 1;
pinMode(int_port_number, INPUT);
}
else if (port_type=="out" or port_type=="output")
{
portType[int_port_number] = 2;
pinMode(int_port_number, OUTPUT);
}
else if (port_type=="pwm")
{
portType[int_port_number] = 3;
pinMode(int_port_number, OUTPUT);
}
else if (port_type=="i2c")
{
portType[int_port_number] = 5;
}
else if (port_type=="spi")
{
portType[int_port_number] = 6;
}
else if (port_type=="serial")
{
portType[int_port_number] = 7;
}
else
{
incomingString = "not "+incomingString;
}
} else
{
incomingString = " not "+incomingString;
}
/* Mega
54 port digital, from 9 to 53
16 port AD, from 0 to 13
portType value
0 unused
1 IN
2 OUT
3 PWM
4 LCD
5 I2C
6 SPI
7 SERIAL
*/
if (request_response)
{
Serial.println(end_response+ incomingString);
}
}
void lcdExecCommand()
{
#if defined(LCD_ENABLED)
if (parameters.indexOf("clear")>0 or parameters.indexOf("CLEAR")>0 )
{
lcd_print_sec = false;
if (parameters.indexOf("row")>0 or parameters.indexOf("ROW")>0 )
{
if (parameters.indexOf("1")>0 )
{
lcd.setCursor(0,0);
lcd.print(" ");
}
if (parameters.indexOf("2")>0 )
{
lcd.setCursor(0,1);
lcd.print(" ");
}
}
else
{
lcd.setCursor(0,0);
lcd.print(" ");
lcd.setCursor(0,1);
lcd.print(" ");
}
if (request_response)
{
Serial.println(end_response+ incomingString);
}
} else if (parameters.indexOf("print")>0 and (parameters.indexOf("seconds")>0 or parameters.indexOf("second")>0 or parameters.indexOf("SECOND")>0 or parameters.indexOf("SECONDS")>0 ))
{
if (parameters.indexOf("off")>0 or parameters.indexOf("OFF")>0 )
lcd_print_sec = false;
else
lcd_print_sec = true;
if (request_response)
{
Serial.println(end_response+ incomingString);
}
} else if (parameters.indexOf("print")>0 and ( parameters.indexOf("row 1")>0) )
{
lcd.setCursor(0,0);
lcd.print(parameters.substring( parameters.indexOf("row") + 6 ) );
if (request_response)
{
Serial.println(end_response+ incomingString);
}
} else if (parameters.indexOf("print")>0 and (parameters.indexOf("row 1")>0) )
{
lcd.setCursor(0,0);
lcd.print(parameters.substring( parameters.indexOf("row") + 7 ) );
if (request_response)
{
Serial.println(end_response+ incomingString);
}
} else if (parameters.indexOf("print")>0 and (parameters.indexOf("row 2")>0) )
{
lcd.setCursor(0,1);
lcd.print(parameters.substring( parameters.indexOf("row") + 6 ) );
if (request_response)
{
Serial.println(end_response+ incomingString);
}
} else if (parameters.indexOf("print")>0 and (parameters.indexOf("row 2")>0) )
{
lcd.setCursor(0,1);
lcd.print(parameters.substring( parameters.indexOf("row") + 7 ) );
if (request_response)
{
Serial.println(end_response+ incomingString);
}
} else
{
Serial.println("lcd on");
}
#endif
}
void writePort()
{
// WRITE PORT n VALUE out
parameters = parameters.substring( parameters.indexOf("port") + 5);
parameters.trim();
pos = parameters.indexOf(" ");
String port_number = parameters.substring(0, pos);
port_number.trim();
String port_value = parameters.substring( parameters.indexOf("value")+5);
port_value.trim();
port_value.toLowerCase();
int int_port_number = -1;
if(port_number.length()>0)
{
int_port_number = port_number[0] - '0';
}
if(port_number.length()>1)
{
int_port_number = int_port_number * 10 + port_number[1] - '0';
}
if (int_port_number>=0 and (BOARD=="Mega" or (BOARD=="Uno" and int_port_number< 14) ) and portType[int_port_number]== 2 )
{
if (port_value=="1" or port_value=="true" or port_value=="high")
{
digitalWrite(int_port_number, HIGH);
}
else if (port_value=="0" or port_value=="false" or port_value=="low")
{
digitalWrite(int_port_number, LOW);
}
else
{
incomingString = " not "+incomingString;
}
} else
{
incomingString = " not "+incomingString;
}
if (request_response)
{
Serial.println(end_response+ incomingString);
}
}
void readPort()
{
// WRITE PORT n VALUE out
parameters = parameters.substring(parameters.indexOf("port") + 5);
parameters.trim();
pos = parameters.indexOf(" ");
String port_number = parameters.substring(0, pos);
port_number.trim();
int int_port_number = -1;
if(port_number.length()>0)
{
int_port_number = port_number[0] - '0';
}
if(port_number.length()>1)
{
int_port_number = int_port_number * 10 + port_number[1] - '0';
}
if (int_port_number>=0 and (BOARD=="Mega" or (BOARD=="Uno" and int_port_number< 14) ) and portType[int_port_number]== 1 )
{
Serial.println(digitalRead( int_port_number));
}
else
{
incomingString = " not "+incomingString;
}
if (request_response)
{
Serial.println(end_response+incomingString);
}
}
void getPort()
{
pos = parameters.indexOf(" ");
while ( pos > 0 )
{
parameter = parameters.substring(0, pos);
parameter.trim();
parameters = parameters.substring(pos);
parameters.trim();
if (parameter.length() == 1 )
{
parameter.setCharAt(1, tempChar);
tempChar = tempChar - 48;
if ((tempChar >= 0) && (tempChar <= 7))
{
port = tempChar + 22 ;
// digitalRead(port);
}
}
else
{
// Errore:
};
};
}
Unità Didattiche con Laboratorio di Tecnologia e Scienza.
Laboratorio di Informatica
Revisione 0.02
UNIX Linux
il Sistema Operativo liberamente utilizzabile, immune da virus ed estremamente robusto
- Linux Kernel
- Distribuzioni Linux
- Debian
- Red Hat
- Ubuntu
- Suse
- il computer per tutti
-
- LibreOffice
- Chrome e Firefox
- Oracle VirtualBox
- Gimp
- Programmi Multimediali
- immune da virus
- Open Source
- iniziativa Revisione Computer Dismessi
- recupero parco macchine obsoleto mediante allestimento Linux
- iniziativa che permette di utilizzare vecchie macchine
- a costo zero
- e contribuendo alla diminuzione del conferimento di inquinanti
-
RaspberryPi
il computer completo, di dimensioni e costo minimi
- un computer completo per la didattica dell’informatica
- computer ARM 32 e 64 bit
- Debian compilato ARM Rpi: Raspbian
- lo standard Python nella programmazione
- Catalogo dei Progetti Didatti Internazionali
- Istituti Scolastici con Gruppi di Interesse attivi
- Il Network Globale degli Appassionati e Gruppi di Interesse
- MagPi
- traduzione
- Allestimento di un Raspberry Pi Multimediale
- Ascolto Musica, Radio Internet, Netflix
- la comunicazione tra Raspberry Pi ed altri dispositvi
- rete
- WiFi
- RaspberryPi zero
- seriale
- USB
- il controllo da Raspberry Pi di Arduino attraverso porte USB
- Qt app
- Raspberry Pi GPIO
- Raspbian modulo kernel
- utilizzo da terminae
- Python sorgente
- Raspbian modulo kernel
Arduino
il computer miniaturizzato che interagisce con il mondo esterno
- laboratorio di didattica dell’informatica di base
- esperienze concrete di utilizzo
- Attuatori
- Sensori
- Principali tipi di schede
- Come alimentare le schede Arduino
- Porte I/O
- standard 5V e 3.3V
- I/O
- PWM
- AD
- DA
- seriale
- SPI
- I2C
- La programmazione di Arduino
- come programmare Arduino
- IDE e connessione USB
- configurazione
- Terminale Seriale
- Controllo remoto attraverso cavo USB
- Programmi Elementari
- allestimento ed utilizzo di un computer per programmare Arduino
- prime esperienze
- Accensione di un LED Colorato
- Accensione di due LED Colorati Intermittenti
- Il Semaforo
- come programmare Arduino
- La comunicazione mediante porte USB
- creazione di un linguaggio specifico per comunicare con Arduino
- UNIX Linux
- porta USB
- identificativi di produttore, modello e seriale
- udev
- P&P
- connessione
- questio reset alla connessione e, per certe schede, anche alla sconnessione
- firmware standard per controllo da dispositivo, per esempio computer o Raspberry Pi, attraverso USB
- Qt Poll App
- protocollo di comunicazione
- wrapper verso RDBMS
- PostgreSQL
- CEnni a codice Python
- porta USB
- Internet delle Cose
- interazione con un computer
- Raspberry Pi, Arduino, Sensori ed Attuatori
- esperienze introduttive
- esperienze con Opto Elettronica ed Illuminotecnica
- esperienze elementari con la Musica
- esperienze in ambito tessile: il vestito con equipaggiamento tecnologico
- Progetti Tecnologi
- Progetti Artistici
- Nozioni di Elettronica di Base
Informatica
- introduzione alla programmazione delle macchine calcolatrici
- UNIX Linux
- elementi di programmazione in
- C e C++
- Python
- elementi di programmazione in
- Programmazione WEB
- elementi di Yii2, Crud
- RDBMS
- PostgreSQL, pgSQL, PL Python3 Untrusted
- UNIX Linux
- Sistemi Operativi
- per processori Intel 32 bit, Intel ed AMD 64 bit, ARM 32 bit ed ARM 64 bit
- Il computer per uso domestico
- Il computer in ambito Aziendale
- Il server
- Sicurezza e prevenzione
- Monitoraggio
- Principi di Networking
- la rete domestica
- WiFi
- la rete Aziendale
- sistemi UTM e sicurezza aziendale
- Questioni Forensi
Internet of Things ed elettronica
- Processori
- Controller
- Sensori
- Attuatori
- Protocolli
- Linguaggi
- Standard I.o.T.
Scienza
- Introduzione alla Matematica
- il numero in natura
- matematica antica
- gli Elementi di Euclide
- l’eredità del mondo Greco Antico
- osservare lontano perchè non si capisce il vicino
- dall’astronomia alla geometria
- il pensiero geometrico che aumenta la complessità nel tramandare la cultura matematica
- notazioni per numeri che inibiscono il pensiero algebrico
- la nascita del sistema posizionale decimale
- algoritmi di calcolo moderni
- il Mondo Arabo nel Medio Evo
- Fibonacci
- il pensiero algebrico
- nozione moderna di insieme con struttura
- insiemi con operazioni
- algoritmo di calcolo
- notazione dei numeri diversa dalle lettere per l’alfabeto
- calcolo letterale: lettere al posto di un dato numero, lettere al posto di incognite
- nozione di equazione
- Newton e la nascita della scienza moderna
- la differenza nello spazio geometrico omogeno; la materia
- corrispondenza biunivoca tra numeri e realtà: il metodo delle coordinate
- definire numeri con approssimazioni
- denso e continuo
- Felix Klein e i Programmi di Erlangen
- nuova classificazione delle discipline scientifiche sui gruppi di trasformazioni
- Geometria Proiettiva nell’Ottocento
- Scienza Razionale: il metodo assiomatico
- Insiemi Numerici
- Naturali, Interi, Razionali, Reali e Complessi
- insieme ed operazioni
- il Teorema Fondamentale dell’Algebra per sancire l’esistenza di al più due tipi di operazione: additivo e moltiplicativo
- Linguaggio degli insiemi
- Corrispondenze tra Insiemi
- Fondamenti Di Matematica
- La visione della Matematica dopo Felix Klein
- La nuova concezione dello Spazio Geometrico
- Storia della Matematica
- Storia dei numeri
- Storia del Pensiero Geometrico
- Storia del Pensiero Algebrico
- La Matematica nel Mondo Greco Antico
- Il pensiero Geometrico che compromette lo sviluppo Algebrico e la Didattica
- Matematica Antica
- Matematica Moderna
- Metodo Assiomatico
- Algebra sul Concetto di Insieme ed Invarianza
- Fisica di base
- Lo Spazio della Fisica sullo Spazio Geometrico
- Materia
- Il metodo delle Coordinate
- la nozione di Misura
- Sistemi Inerziali
- Newton e La nascita della Scienza Moderna
- i Principi di Newton
create.arduino.cc
Automazione, parte terza: misura f.e.m.
La misura della forza elettromotrice è fondamentale per applicazioni quali il controllo del CED. Questioni strettamente connesse sono la gestione degli UPS ed il controllo di eccesso di calore nnell’ambiente.
Cominciamo utilizzando un accoppiatore ottico a doppio led che facciamo lavorare a pochi mA. Il produttore è Avago, il modello ACPL-824, che in questo contesto utilizziamo a metà.
Il funzionamento verso la soglia minima permette di non generare calore e proveremo essere sufficiente ai nostri fini.
In entrata sono collegate due o meglio quattro resistenze a film metallico, per ridurre i picchi di linea. Non usiamo condensatori di livellamento in uscita al fine di eseguire misure puntuali direttamente con il pin di entrata analogica.
Colleghiamo il collettore ai +5V e l’emettitore verso massa con una resistenza.
Fissati i valori opportuni abbiamo ottenuto il modulo di una sinusoide con picco sotto 1.5V DC, che andremo a campionare.
E’ indispendabile un piccolo oscilloscopio. Abbiamo utilizzato l’ottimo, per queste problematiche, Seeedstudio DSO Nano.
Sono da fissare il numero di misure da fare, la determinazione del massimo, quindi il calcolo diretto del valore medio moltiplicando per l’inverso della radice di due.
I test attualmente in corso mostrano stabilità e buon funzionamento.
La collocazione attuale del ACPL824 con resistenze è in una presa elettrica ed il cavo per il segnale da misurare è il cavo utilizzato per i sistemi di allarme, schermato con due cavi per l’alimentazione, nel nostro caso massa e +5VDC, e due cavi per i segnali, nel nostro caso un solo cavo. Procederemo con test di affidabilità e stabilità della lettura da Arduino con un cavi anche piuttosto lunghi.
Automazione, parte seconda: gestione LCD.
E’ facile valutare l’impatto di un LCD collegato alla scheda microcontroller: da un dispositivo muto, privo di riscontri, si passa ad una situazione nettamente migliore, sia in termini di controllo che di debug, infatti si possono visualizzare messaggi di stato, avvisi ed errori.
L’utilizzo di LED risulta meno vantaggioso per la richiesa di un pin per LED, la fatica di allestire, una densità informativa drammaticamente inferiore.
Dotati di fresa tipo Dremel, meglio se del traforo elettrico,
procediamo al taglio rettangolare sulla scatola di policarbonato ad uso elettrico, per l’incastro del display. Studieremo il miglior fissaggio.
Scegliamo un LCD di fattura minima, di ampia diffusione, con una libreria per Arduino pronta ed collaudata.
Potremmo scegliere tra dispositivi a caratteri, grafici, seriali, paralleli ed I2C. Optiamo per il classico due righe a caratteri con controllo parallelo ad 8 o 4 bit.
Scegliamo il fondo blu con scritta bianca, perchè più gradevole.
Il produttore Crystal Clear Technology propone il modello C216W01NBN00, 2 righe di 16 caratteri, Controller/Driver ST7066U-0A-B e ST7065C-B o equivalente, fondo blu con scritta bianca, costa poco, e per ora ci convince.
La libreria Arduino da utilizzare è la classica LiquidCrystal con il controllo del LCD 4-bit mode.
L’utilizzo è immediato, rimandiamo alle pagine di guida ufficiale del dsito Arduino per apprenderne l’utilizzo.
Per ora utilizziamo i pin in modo canonico, come proposto dalla libreria, riservarndoci ad una futura razionalizzazione.
Il potenziometro da 10K verrà sostituito, per compattezza, da una resistenza.
Per una corretta visualizzazione ricordarsi di collegare a massa ed a +5 VDC i pin di backlight del display.
In futuro utilizzeremo anche un LCD con luce di fondo RGB per potre cambiare i colori, per esempio verde o blu per funzionamento normale, arancio per avvisi, rosso per errori.
Integriamo il firmware con le variabili globali:
LCDpresent
LCDactive
LCDdebug
ed i primi comandi:
LCDactive on|off
LCDdebug on|off
LCDprint string
Naturalmente il programma per Arduino diventa piuttosto esteso, ma nella seconda fase verrà generato in automatico, e quindi il codice conterrà lo stretto necessario, raggiungendo la compattezza ideale.
Sensori GAS Grove
Olimex
Olimex è un’interessante industria con sede in Bulgaria specializzata in microcontroller.
Alcune proposte sono eccellenti, quali la revisione secondo standard industriali di Arduino e il bus UEXT.
Segnaliamo le pagine, realizzate in WordPress, che Olimex dedica alle novità.
Raspberry PI ed Arduino
L’articolo propone i due prodotti in coppia.
Precisiamo che i due prodotti non sono confrontabili soprattutto perchè Raspberry PI rimane un prototipo mentre Arduino, nel suo contesto, è un prodotto usabile in contesti professionali.
Nel nostro progetto LABijk infatti citiamo il microserver e non RPI.
RPI non è usabile in ambiti produttivi sostanzialmente per l’instabilità del file system a causa della memoria di massa disponibile. Comunque è un computer vero e proprio che può essere dotato del miglior repertorio software disponibile.
Allo stato attuale questo è il più grande limite delle schede ARM. Ma a breve saranno disponibili le nuove generazioni di schede che cambieranno radicalmente i termini della questione.
Arduino non è un computer nel senso usuale del termine, ha il più basso costo, consuma pochissimo, non scalda e regge a qualsiasi imprevisto. l’interfaccia di rete è realmente modesta e costosa. Nell’ambito PLC o microcontrollori per usi professionali è imbattibile.
LABijk e la comunicazione seriale tra i dispositivi i e j.
Riproponiamo alcune indicazioni sul protocollo, da definire, che permette la comunicazione seriale (per ora con RS485, ma potrebbe essere I2C od altro) tra i dispositivi a livello i e i loro figli ij:
1. un dispositivo (i fissato) è master dei suoi figli (di indirizzo ij) che quindi sono slave
2. il master è in pool con i suoi figli
3. la comunicazione è basata su stringhe intellegibili per favorire l’attività di debug
4. la stringa inviata dal master contiene il destinatario, per esempio:
to ij; comando:parametro1,parametro2 …
5. il figlio ij coinvolto risponde con una stringa del tipo:
from ij;risposta comando: valore1,valore2 …
6. le risposte, punto 5, contengono solo variazioni rispetto a valori già comunicati
7. rimane il problema di gestire un controllo di parità.
Altra questione da valutare se il pool viene indotto dal microserver o dai microcontroller al livello i.
La comunicazione seriale su Arduino è facilmente realizzabile.
La libreria MultiserialMega permette di utilizzare più di una seriale in contemporanea. In questo modo la prima seriale, ovvero la connessione USB, può essere gestite contemporaneamente con una seconda seriale.
Ricordiamo che la SoftwareSerial gestisce la seriale secondo uno stile superato e la nuova NewSoftSerial permette la gestione di più porte in contemporanea.
Arduino sketch: gestione automatica.
Il progetto LABijk ha alcuni aspetti molto ambiziosi. Uno di questi è archiviare nel database le caratteristiche di ogni dispositivo microcontrollere, sensore od attuatore per poter generare in automatico il firmware di ogni microcontrollore.
In ambito Debian ed Ubuntu cominciamo ad introdurre dalla compilazione all’upload a riga di comando del firmware nelle schede Arduino.
Si inizi aggiornando l’ambiente:
apt-get update
poi si proceda installando i primi programmi necessari allo scopo:
apt-get install arduino picom python-setuptools
in seguito si installi il gestore librerie di Python 2.7:
easy_install-2.7 pip
Infine si installi la libreria Python ino:
pip install ino
Controlliamo i moduli installati dal framework ino:
ino list-modules
Se la risposta è positiva allora possiamo cominciare con il primo esempio, che chiamiamo lab000.
Creiamo la cartella lab000 che svolge il compito di essere la cartella base:
mkdir lab000
ci posizioniamo nella cartella
cd lab000
Quindi creiamo il progetto per Arduino
ino init
Il precedente comando crea due cartelle: src che contiene gli sketch e lib che contiene le libreire.
Completiamo la sorgente sketch.ino ed infine compiliamo per l’Atmel
ino build
per caricare il nuovo firmware, collegare la scheda Arduino alla USB ed avviare
ino upload
In prossimi articoli cominceremo a creare la struttura dati e il programma che genera in automatico ogni sketch di una specifica applicazione LABijk.
LABijk: comunicazione seriale tra i moduli i e j.
Il bus di comunicazione tra i microcontroller al livello i e quello a livello j principale è RS-485.
Presentiamo un’ottima introduzione alla seriale RS.485 per poterlo espandere nel progetto.
Tinkerkit
Tinkerkit è la proposta italiana concorrente alla cinese Grove, per realizzare uno standard di interconnessione tra schede Arduino ed elettronica sotto la veste di sensori ed attuatori collegabili direttamente allo shield con cavi tipicamente a 4 fili: due dati e due alimentazioni.
Molto apprezzabili sono la presenza di morsetti e dip per specializzare le configurazioni.
Il prezzo è nettamente superiore ai concorrenti.
Nel progetto LABijk possono trovare spazio tutte e due le proposte.
Arduino Yún
Arduino Yun, grazie a Michele per la segnalazione, è un nuovo prodotto che potrebbe essere molto interessente nel progetto LABijk.
Infatti integra tre microntroller con schede di rete e wireless al prezzo di circa 50 €.
In pratica sono due computer: il tradizionale Arduino con il bus IO che lo caratterizza ed un Atheros AR9331 a 400MHz con Linux Linino direttamente mutuato dal grande progetto DD-WRT, ovvero distribuzione Linux per sostituire il firmware dei più diffusi router con un sistema operativo Linux.
DD-WRT è un progetto fondamentale che permette di migliorare nettamente la conoscenza sui router che usualmente si utilizzano. Infatti questi dispositivi non vengono più visti come indipendenti dalla realtà usuale, ma come computer con un loro os, in genere proprietario, che può essere sostituito con Linux. Questo nuovo punto di vista permette, tra i molti aspetti, di comparare dispositivi diversi.
L’integrazione con LABijk è in termini di nodi connessi al padre con ethernet. Infatti Arduino è molto debole sotto il profilo dello shield ethernet. Yun coniuga l’ottimo Arduino tradizionale con l’elettronica tipica di un brillante router moderno e un sistema operativo innovativo per router.
L’effetto è di poter costruire nodi con rete, wireless ed micro compact flash concorrenti e con le usuali caratteristiche, nel senso che la scheda di rete vista attraverso la libreria Arduiono è piuttosto debole, ma una cCPU da router con dd-wrt invece realizza un dispositivo eccellente. ARM board potrebbero competere: maggior potenza allo stesso prezzo, ma
- dimensioni non da frutto d’impianto elettrico
- instabilità date dalla SD
- carenza di un bus IO fortemente diffuso verso l’elettronica come quello di Arduino
- riscaldamenti inopportuni quali quelli di RPI in certe condizioni d’esercizio
sono punti a favore di Yun.
Bus a confronto: RS 485, CAN, I2C e SPI
Ringrazio Marco M. che riapre il diabattito proponendo CAN bus come alternativa al bus RS485.
CAN è il bus utilizzato nelle automobili moderne, negli apparecchi elettromedicali e nell’industria.
Sicuramente alza di molto il profilo e quindi va provato.
Ma il grande problema è nei costi alti, per esempio, la sicuramente ottima scheda della SparkFun CAN-BUS Shield DEV-10039 sarebbe un’eccellente scelta ma costa più del doppio della scheda microcontroller.
Un po’ di tempo fa volevo avviare dei test soprattutto verso il bus dell’automobile.
E’ interessante il post tratto dalla pagina del prodotto Sparkfun:
“If you are using this board to actually create a CAN bus system (as I am for a robotic drone vehicle) then the skpang (designer of this board) code is not that helpful and a bit of a mess. It is well and good to be able to read things from your vehicle and log them, but that’s not helpful when you are trying to create an actual bus.Also, I really find it difficult when sample code does every conceivable thing all at once, forcing you to piece out the parts/understanding you need.
To create a network of senders and receivers, I tried a few different libraries. I recommend using the CANDUINO one http://code.google.com/p/canduino). Although the boards are not exactly the same, it will work, and you can see a sender and receiver working. Other libraries I tried, such as the one from saeed studios, didn’t work for me, even though their boards are pin compatible. Might have something to do with their library using a CAN interrupt which, for me, was not reliable. Receiver would get only a single CAN message and then the interrupt would never fire again. Who knows why. Spent a number of hours on this.
So just want to save other folks some time if they are looking to build an actual bus system, and not just read data from their vehicles.”
La scheda utilizza il componente elettronico MCP2515 che si collega verso Arduino mediante SPI.
La porta SPI, che è una seriale molto veloce adatta per esempio per collegare CAM SPI, ma apre alcune problematiche spinose con Arduino: non rientra nel contesto usuale gestire più di una SPI, che viene utilizzata in modo esclusivo da atre periferiche quali lettore SD oppure (aut) dalla scheda ethernet. E’ noto che chi ha utilizzato l’ethernet shield, il programma che inserisce non può aprire contemporaneamente la scheda rete e un file in SD.
La gestione SPI su Arduino è piuttosto complessa.
L’alternativa è usare I2C o wire, bus molto più lento, creato dalla Philips come seriale veloce per interconnettere componenti elettronici, per esempio la scheda madre con i suoi sensori. Ma si aprono molte problematiche: le tensioni in gioco sono i 3.3 o i 5V e sono piuttosto delicate, è delicato convertire il segnale tra tensioni, il cavo non può superare grossomodo il metro e mezzo, un componente instabile sul bus può compromettere la comunicazione, …
Molti invece sono i motivi a favore del I2C: è il più diffuso bus tra componenti elettronici, quindi ci si apre alla comunicazione con l’elettronica, la libreria I2C per Arduino è abbastanza stabile, Grove ha un HUB per I2C per Arduino, ….
Arduino gestisce in origine la seriale usata per comunicare verso USB, PIN 2 e 3, con il secondo microcontroller a board (il vecchio chip FTDI è superato).
La libreria seriale poi è stata affiancata da una libreria migliore che permette di gestire più coppie di pin in contemporanea, quindi avere più seriali TTL. Il chip MAX485 incanala la coppia di PIN al bus RS485.
Il segnale è bilanciato, collaudatissimo, può arrivare a 1200 metri, richiede due resistenze di terminazione. Le velocità sono quelle della seriale. Il protocollo è da perfezionare.
LABijk: bus di comunicazione.
Il progetto LABijk, per la complessità strutturale che lo caratterizza, richiede un’attenta riflessione sulle sue scelte di fondo: il microserver, l’architettura di questo, i microcontroller, lo standard verso attuatori e sensori, i bus di comunicazione, i protocolli di sicurezza, e molto altro.
In uno sviluppo aperto andremo a classificare in modo ordinato ogni punto citato ed altri ritenuti indispensabili.
Continuiamo il nostro dibattito soffermandoci a riflettere sul/i bus di comunicazione da adottare tra il microserver e i dispositivi i al primo livello .
E’ ovvio pensare ad ethernet, ma pesano le seguenti argomentazioni
- impegnativo in termini infrastrutturali, switch POE, cablaggi strutturati, …
- in termini di microcontroller comporta costi ed elettronica non trascurabili
- Arduino in relazione alle porte ethernet e POE non è così interessante, anche per costi
- il codice TCPIP per Arduino è piuttosto debole
- i dispositivi del primo livello dovrebbero quindi essere schede ARM quali RaspberryPI
- RPI scalda, richiedono risorse memoria enormemente superiori di Arduino, quindi usa tecnologie fragili come SD
Quindi ethernet è solo per usi specifici e vedrebbe Arduino fuori gioco, precludendo tutta la gestione dell’elettronica in stile Arduino.
I vecchi bus seriali tipo RS232 sono lenti soprattutto se il dispositivo centrale, in questo caso il micorserver, fa pooling tra i periferici. Ricordiamo che una gestione ad eventi che parta dalle periferiche è esclusa perchè si perde il controllo delle periferiche stesse.
Consideriamo il bus USB:
- è stabilissimo, robustezza derivata dall’enorme impiego
- tutti lo usano a tutti i livelli
- è uno standard: chiunque sa quale sia un cavo USB
- Arduino con il suo primo microcontroller a bordo implementa la comunicazione USB in modo eccellente
- i costi sono praticamente abbattuti
- test di pooling per mesi da microserver verso Arduino via USB alla velocità massima hanno visto una precisione assoluta
- il microserver, centro stella, può non avere seriali, ma le macchine attuali abbondano di porte USB
- il cavo USB porta anche l’alimentazione, sufficiente per un Arduino Uno SMD con un po’ di elettronica, quindi abbiamo gratuitamente l’equivalente della POE
- la massima lunghezza del cavo USB è di circa 5 metri, ma si possono usare estensori USB via cavo tipo rete per lunghezze pari a 50 metri. Il costo di un’estensione è di circa una decina di euro e di cavo standard rete con RJ45, che è molto meno di uno splitter POE
Linux permette il controllo preciso delle porte USB, test verso Arduino, attraverso USB, mediante programma compilato C++ in pooling mostrano il funzionamento ininterrotto in mesi.
Un aspetto delicato da capire per bene è l’adozione, da parte del gruppo di progettazione Arduino, del reset in caso di perdita di connessione del BUS USB. Aspetto che si rivela invece estremamente utile per il recupero eventuale di una periferica fuori controllo: basta chiudere e riaprire la porta USB.
I microcontroller i di primo livello, connessi al microserver centrale tipicamente mediante USB, devono comunicare con gli altri ij del secondo livello.
Le seguenti osservazioni portano alla migliore scelta per queste tratte:
- serve un bus estremamente robusto
- che utilizzi cavi comuni, per dire quelli utilizzati dell’impiatistica per i sistemi di allarme, trasportando anche l’alimentazione
- che permetta tratte fino a 1200 metri
- che sia preciso, simmetrico
- che permetta di collegare allo stesso bus di pochi fili molte periferiche
- che apaprtenga ad uno standard ampiamente utilizzato.
Quindi la scelta è il bus RS485.
Le ultime considerazioni sono relativa all’ultima tratta ovvero dai dispositivi ij a quelli ijk, che sono sensori, attuatori ed elettronica varia:
- le schede prototipali sono da escludere, possono essere tollerate in particolari utilizzi
- rafforzando il punto precedente: le attività di saldatura di componenti, soprattutto se superficiali, sono, tranne in specifici casi, da escludere
- serve uno standard che porti i pin delle schede Arduino, tipicamente Uno SMD, ad insiemi di connettori, tra le molte proposte nel mercato, la forse più ricca è lo standard Grove
- Grove implementa bus a 4 fili: due alimentazioni e due pin di segnali
- il bus Grove è facilmente utilizzabile o mediante cavi patch già pronti oppure estendendo la connessione con cavo tipo quelli adottati nel sistema di sicurezza, ovvero lo stesso che abbiamo indicato per la connessione dei dispositivi i di primo livello i con i dispositivi ij di secondo livello.
Perchè Arduino SMD ai livelli “ij” nel progetto LABijk
Il progetto LABijk è ambizioso, ma fattibile. Le applicazioni nel mondo elettrico e non solo, per esempio nel condizionamento di ambienti, sono molteplici.
Il livello i è costituito dai microcontroller direttamente connessi al microserver.
Le connessioni previste sono USB od ethernet.
Una ARM board sarebbe nettamente migliore, ma
- scalda un po’ e se chiusa in una piccola scatola di policarbonato ci possono essere grandi problemi
- i costi che, escluso il caso ethernet, vede Arduino vincente; Raspberry PI sarebbe vincente, ma il filesystem su micro SD lo rende fragile; quindi le board ARM candidabili andrebbero sopra i 60€ a pezzo contro i 20€ circa di Uno SMD
- nel caso di collegamento USB è da preferirsi, per ora, Arduino UNO SMD per i costi e per la robustezza già testata in pooling su USB; in tecnologia SMD per lo stato dell’arte
- nel caso di ethernet è meglio un ARM non solo per i costi che diventano equivalenti, ma per la gestione ethernet molto debole su Arduino: poche connessioni e senza threading/forking controllabile
- in futuro è prevedibile, si veda Arduino Due, la convergenza ad ARM
Mel caso di livello j allora non vi è dubbio che l’Arduino SMD sia l’unica soluzione:
- 12 MHz garantiscono che non scalda anche se inscatolato
- è robustissimo, prodotto su tiratura mondiale in enormi quantità
- è Elettronica Aperta
- la comunità da sviluppatori ad adepti è enorme
- la documentazione, raggiungibile via internet, è la più vasta in assoluto
- si apre perfettamente ad ogni elettronica, si pensi che al tempo dell’esplosione di Fukushima entro pochi giorni erano già pronti shield Arduino per contatori Geiger anche reperibili dal mercato giapponese
- è perfetto per un centro stella seriale RS485
- permette l’utilizzo dei shield Groove creando uno standard imponente verso l’elettronica e l’elettricità, basti pensare che non serve più il saldatore, ci si muove con plug e senza crimpare
- il costo, sui venti euro, lo rendono imbattibile
- ultimo ma non ultimo il progetto è italiano e viene venduto in grandi numeri anche in Germania, Stati Uniti, Cina e Giappone.
Progetto automazione LABijk
Il progetto è ambizioso, fattibile e di qualità.
Estrapoliamo alcuni punti che rendano un certo profilo:
- l’utilizzo di un microserver, a livello di root, con CPU tipo AMD E350 (a bassi consumi, da sostituire, nel 2014, con ARM A53 o 57), un vero disco fisso, meglio RAID 1, e sistema operativo Linux fascia server, che permetta di realizzare comunicazioni professionali verso internet, dispositivi mobili …
- microserver con un vero RDBMS relazionale di fascia alta che contenga ogni informazione coinvolta, anche storica; stiamo valutando gli ottimi MariaDB oppure PostgreSQL
- microserver con infrastruttura software interamente sviluppata in C, compreso le applicazioni fastCGI per Apache e le app per i dispositivi mobili; quindi la pesante filiera HTML5 viene scalzata per intero, riducendo le richieste di potenze di processo anche di un ordine, aumentando enormemente l’affidabilità, acquistando velocità anche con CPU ridotte
- le tratte microserver – microprocessori livello i, sono realizzate collegamenti USB od ethernet, con comandi a stringa e, nel caso ethernet, in stile telnet; quindi connessioni veloci, molto collaudate, tradizionali ed estremamente affidabili
- i microcontroller a livello i sono Arduino, ma potranno diventare schede ARM quando il consumo sarà così ridotto da non surriscaldare uno spazio angusto sigillato; oppure se è richiesta una maggior potenza di calcolo con un Linux Embedded
- la tratta i – j viene realizzata con la solidissima RS 485
- i microprocessori di livello j sono Arduino quindi solidissimi, economi, a consumo minimo (alcuni watt) con lo shield Grove fantastico e, non trascurabile, frutto di menti capaci italiane
- le connessioni j – k sono preferibilmente Grove ovvero fantastiche per la semplicità di cablaggio
- la matrice (i,j,k) permette di individuare ogni elemento in relazione agli altri e quindi, se microcontroller Arduino, di fissare le caretteristiche in modo automatico nel firmware
- e molto altro
Home Automation con Arduino Raspberry PI ed altro
Segnaliiamo il suggestivo articolo per l’utilizzo di un router con Linux Embedded con CPU Cortex-A8 Allwinner A10 ad 1GHz, dotata di 1GB di DDR2 RAM e 2GB su SD.
I punti deboli sono l’assenza di storage, la fragilità del sistema operativo in SD, la mancaza di un vero e proprio archivio RDBMS, un framework molto articolato per un ARM A8, l’ottimo, ma produce una filiera forse lunga per l’Allwinner, Node.js per le app verso palmari …
Progetto automazione LABijk. Revisione 1.
Il progetto intende promuovere tecnologie open source ed open electronics.
Si supponga di voler gestire sensori ed attuatori.
Poniamo al centro un microserver, con sistema operativo Linux Server, eventualmente connesso ad internet ed a reti locali.
Questa macchina archivia un resoconto di tutto quello che viene fatto e comunica con tablet, telefoni ed altri sistemi anche attraverso internet. Abbiamo già dato alcune indicazioni sulle possibili scelte in articoli precedenti.
Distinguiamo tre livelli, per l’appunto i, j e k di aggregazione dispositivi.
Alla radice poniamo il microserver.
I primi nodi, di livello i, siano microcontroller Arduino SMD Uno o Ethernet, connessi al microserver via USB o ethernet. Le schede Arduino siano dotate dispositivi adattatori seriali RS485.
Il secondo livello, detto j, è costituito da dispositivi Arduino SMD UNO con shield Grove e connessi al padre mediante seriale.
Al terzo livello, detto k, poniamo attuatori e sensori connessi ai padre mediante cavi Grove, oppure cavi multipolari a 4 capi, schermati o non, telefonici o di rete. Lo standard Grove può essere convertito da adattatori nel formato RJ13 per cavi telefonici o RJ45 per usuali cavi ethernet.
Ogni dispositivo è individuato da coordinate i.0.0 oppure i.j.0 oppure i.j.k
I comandi sono del tipo i.j.k:<comando:valore,…>
Il microserver è dotato di servizio che interroga costantemente in pool i dispositivi di livello i, mediante USB. Un secondo servizio che è simile al precedente ma per i dispostivi connessi mediante rete.
I dispostivi Arduino di coordinate i sono in ascolto verso il microserver, quindi USB o socket, ed anche interrogano il pool dei figli connessi mediante seriale.
I dispositvi di livello j sono in ascolto verso i dispositivi padri ed eseguono l’interrogazione in pool dei sensori, o meglio le entrate, oppure cambiano lo stato delle uscite.
Nel microserver esiste un database “automazione” con le tabelle
- “comandi”, contenente record corrispondente a comandi da eseguire
- “stati” che contiene lo stato attuale di ogni dispositivo
- “cambio_stati” che contiene cambiamenti di stati eventualmente da elaborare
- “pianificazioni” che contiene operazioni pianificate
Il microserver esegue un servizio che interroga in pool i dispositivi di livello i e riporta comandi e cambiamenti di stato nelle tabelle corrispondenti.
Un secondo servizio legge i cambiamenti di stato, consulta le tabelle di correlazione e scrive i comandi da eseguire nella tabella comandi.
Un terzo legge la tabella comandi e instrada il comando nel ramo corretto.
Tutto è riportato in tabelle e viene a costituire in sistema three-tier architecture, con pilastri di appoggio quali PostgreSQL, Apache, OpenSSH, Postfix, …
Precisiamo che
- i cambiamenti di stato sono riportati nella tabella “cambio_stati”
- i comandi con destinazione di coordinate valide sono instradati verso i destinatari
- le risposte ritornano al microserver che chiude il comando ed aggiunge eventuali cambio stati.
Consideriamo un semplice esempio.
Supponiamo di avere un sistema di dimensione 5.3.5 ovvero al microserver sono connessi 5 dispositivi con il ruolo di HUB RS485, ad ognuno di questi sono connessi al più 3 dispositivi di livello j con HUB Grove, ad ognuno di questi al più 5 sensori o attuatori.
I dispositivi di livello j sono dotati di firmware che permette di sapere e gestire perfettamente i sensori od attuatori ad essi connessi. Inoltre questi dispositivi sono in pool rispetto i sensori ed attuatori.
Consideriamo il dispositivo di livello j di coordinate 3.2.
Supponiamo che abbia 2 attuatori ed un sensore di coordinate 3.2.3.
Il sensore sia un interrutore bistabile (entrata a due stati).
Ora se l’interrutore viene azionato e cambia stato, il dispositvo 3.2.0 costruisce il cambio stato 3.2.3:on (ma meglio introdurre la notazione definitiva 3.2.1:1 ) ed instrada il cambio stato al padre, il quale lo riporta al microserver che lo scrive nella tabella cambio stato.
Il servizio predisposto, nel microserver, rielabora secondo tabelle di correlazione il cambio stato, che viene elaborato, ovvero chiuso e crea gli opportuni comandi.
Mel nostro esempio il comando è 3.2.1:on ma meglio 3.2.1:1
Quindi il servizio legge il comando e lo instada al dispositivo 3.0.0 che lo gira a 3.2.0
A questo punto il dispositivo 3.2.0 elabora il comando alzando il livello all’uscita corrispondente.
Il progetto infine prevede la creazione di una GUI che gestisce le tabelle nel RDBMS del microserver.
La GUI permette di descrivere l’intero impianto mediante griglie di correlazione.
Quindi il programma prevede l’opzione di creare al volo ed in modo completamente automatico il firmware per ogni Arduino ed aggiornarlo via USB.
Perciò ogni Arduino deve venire correttamente etichettato mediante le coordinate i.j.k e connesso mediante USB al computer con la GUI di gestione per il travaso del firmware. L’operazione precedente deve essere rifatta nel caso che cambino i figli.
Il progetto si conclude con la realizzazione di App per Ubuntu Phone e Tablet, Android e iPhone di gestione ordinaria. L’obiettivo più ambizioso vorrebbe creare piante dei sistemi SVG e sovrapporre dei widgets dinamici visuali che rendano visuale il comportamento del sistema.
L’applicazione più importante sarà il controllo del CED quindi di una stanza con molti server. L’obiettivo è di controllare la linea di rete, le temperature, i tasti di accensione, reset di ogni server strategico. Le App mostreranno visualmente lo stato di ogni server e permetteranno operazioni quali spegnimento ed accesione “fisica”. Verranno gestiti i tempi di sostegno degli UPS e lo stato dei gateway verso l’esterno.
Progetto Misure d’inquinamento
Il progetto nasce con la finalità di allestire una stazione per cominciare a fare misure di inquinamento.
La prima versione utilizza una scheda Arduino Uno SMD con interfaccia Grove e sensori per misurare:
1. presenza di gas
2. presenza di polveri inquinanti
3. fumi
3. presenza di vapori d’alcool
3. rumore
4. elettrosmog
A complemento integreremo le misure con temperatura ed umidità
In questa fase invitiamo a valutare i collegamenti proposti.
Progetto Geiger
Inauguriamo le nuove categorie “progetti” che propongono e seguono delle idee che possono diventare veri e propri progetti.
Proponiamo la costruzione e l’utilizzo concreto di un contatore geiger per ora basato su Arduino.
Il progetto nasce per poter avviare un monitoraggio del tasso di radioattività indipendente al minor costo possibile.
Cominciamo proponendo il riferimento: Geiger Counter.
Quadrirotori con elettronica Arduino
Il nuovo comparto, tra il modellismo e, in alcuni casi, le attività professionali, dei quadricotteri compatti annovera alcuni modelli costruiti utilizzando l’elettronica Arduino.
Segnaliamo aeroquad.com
Arduino con Seeedstudio Grove
Stiamo valutando le possibili modalità di espansione della piattaforma Arduino.
In breve ci sono due versanti: a monte, ovvero un host di appoggio, ed a valle, ovvero sensori ed attuatori.
Il secondo aspetto, quello verso i sensori ed attuatori, porta alla grande questione di non poter sempre saldare ogni componente: serve uno shield che dia uno standard minimo verso l’elettronica finale.
Abbiamo deciso di valutare la proposta Grove della http://www.seeedstudio.com, dinamica azienda cinese, per integrarla nella progettualità futura. Forse la proposta più ampia.
I test sono orientati soprattutto alle esigenze di installatori ed integratori anche di piccole dimensioni. Imprese che non possono fare enormi investimenti in risorse economiche ed umane per attività di sviluppo su microcontroller ed altra elettronica, ma possono creare spazi virtuosi componendo tasselli di varie provenienze.