Progetto Arduino

Progetti Arduino
apollokid
Messaggi: 74
Iscritto il: lun 27 lug 2020, 14:36

Re: Progetto Arduino

Messaggio da apollokid »

Senza polemica: per far fare una qualsiasi cosa ad arduino va programmato (così come qualunque computer), quindi venire a dirmi che "ti fa una pernacchia" o "hai voglia a mandare comandi senza programmarlo..." onestamente non l'ho trovato un tono consono da usare tra persone che non si conoscono.
Firmata è solo una libreria software di arduino così come ce ne sono a centinaia e non è che usando una libreria software i programmi si scrivano da soli, Processing invece è solo un ambiente in cui poter far girare un programma scritto in un linguaggio che è molto simile a quello che si usa già per programmare in arduino. Tutto qua, lato PC al posto di Processing si potrebbe usare quello che si vuole, C, C++, Java, Python,... si potrebbero anche inviare i messaggi a mano tramite un terminale seriale.
Il programma, anzi i programmi dato che uno deve girare su arduino ed uno sul PC, mi pare ovvio che siano da scrivere in ogni caso, questo a meno di non essere così fortunati da trovare su interent del codice scritto da altri che fa esattamente quello che serve (vanno comunque compilati e va anche fatto l'upload su Arduino).

Il cuore della domanda mi pare fosse incentrata su come interfacciare un PC con arduino ed io trovo di aver dato una risposta sia completa che corretta. Si potrebbe anche usare un adattatore bluetooth o una comunicazione wi-fi, ma usare lo stesso cavo USB che viene usato per l'upload del software per me è il modo più semplice.

Gli esempi inclusi nell'ambiente di sviluppo mostrano come fare per interfacciare arduino con il PC e si basano sull'uso di Processing lato PC ed usano solo le istruzioni read e write che sono ansi C (senza quindi nessuna libreria aggiuntiva).
Allo stesso modo esistono videoturorial come questo di Paolo Liverti: https://www.youtube.com/watch?v=eSmiAlBbG4s che guarda caso ha proprio lo scopo di accendere di far accendere dei led inviando dei messaggi ad Arduino tramite il PC.

Di come debbano comportarsi i semafori e come siano fatti gli incroci non è stato specificato ma ho dato per scontato che saranno questo il cuore del progetto ed non certo il come far comunicare Arduino col PC.
Tesla2.0
Messaggi: 50
Iscritto il: dom 19 ago 2018, 23:39

Re: Progetto Arduino

Messaggio da Tesla2.0 »

Grazie per i consigli 😁😁🙏
Avatar utente
pgv
Messaggi: 484
Iscritto il: gio 17 set 2020, 13:16
Località: Ginevra

Re: Progetto Arduino

Messaggio da pgv »

Risposta breve alla domanda originale: dipende.
Risposta lunga: dipende da un sacco di cose, ma soprattutto da:
1. gli scopi che ci proponiamo di ottenere (didattica, prototipazione veloce, prodotto "commerciale");
2. le risorse, umane e materiali, che siamo disposti ad investire (non ho assolutamente voglia di programmare lA'rduino e preferisco dedicarmi alla programmazione sul PC perche' sono un drago di C#; me la cavo bene sia con Arduino che col PC; programmo Arduino a livello professionale ma la suocera mi ha imposto di metterle su un'interfaccina da PC...);
3. la fattibilita' tecnica del progetto in vista dei due punti succitati.

Esistono soluzioni "triviali" da implementare, e per forza molto limitate nei risultati ottenibili. Probabilmente il migliore esempio e' Scratch for Arduino (http://s4a.cat/) che permette di limitare la parte di programmazione dell'Arduino a scaricare un progetto prefabbricato. Si tratta di un sistema di programmazione a blocchi come quelli che si stanno affermando sempre di piu' ogigiorno (per esempio Makecode per il micro:bit oppure UIflow per i prodotti della famiglia m5stack) con la fondamentale differenza che mentre i due prodotti a cui faccio riferimento servono per comporre programmi che eseguiranno SUL microcontrollore, Scratch esegue sul PC, ma le operazioni del programma vengono convertite in comandi, trasferite sulla pseudo-seriale al programma che abbiamo caricato preliminarmente su Arduino, ed eseguite su Arduino.
Ovviamente, la grande semplicita' viene a scapito della flessibilita', e se la lista di periferiche predefinite (6 ingressi analogici, 2 ingressi digitali, 3 uscite analogiche, 3 uscite digitali e 4 uscite per motorini servo specifici) non ci soddisfa tocca mettere mano al programma Arduino. Inoltre, e cito il sito di S4A, "S4A works with Arduino Diecimila, Duemilanove and Uno. Other boards haven't been tested, but they may also work.". D'altra parte, va molto bene per scopi didattici.

Soluzioni un pochino piu' complicate, e quindi anche piu' elastiche, si possono ottenere con un po' piu' di olio di gomito alla tastiera. Si puo' partire da una libreria affermata dal lato di Arduino, la famosa "Firmata" di cui ho parlato nel io primo post. Questa ha lo svantaggio di non essere un pacchetto pronto da scaricare e via (anche se sono sicuro che con un minimo di ricerca in rete si possono trovare progetti pronti per i modelli piu' comuni), ma (anche in virtu' di questo fatto) puo' essere utilizzata con qualsivoglia modello di Arduino (basato su ATMEL). Inoltre, implementa un protocollo conosciuto, e quindi sul lato PC e' possibile programmare la propria interfaccia in un autentico sfacelo di "linguaggi" diversi, che includono Processing (nche se onestamente mi sembra un po' moribondo, lo ho utilizzato anche io quando mi serviva un'interfaccia al volo per il debug di un sistema) ma non solo: Python, Perl, Ruby, Clojure, JavaScript, Jana, .NET e via dicendo come si vede dal repository su GitHub (https://github.com/firmata/arduino). Librerie applicative in ciascuno dei linguaggi citati sono disponibili, testate e anche documentate.

Chi non e' contento di usare protocolli standardizzati (ma attenzione!) puo' sempre scrivere un interprete di comandi testuali per l'Arduino e poi implemetrare l'interfaccia uomo macchina sul PC (Mac, etc) servendosi del linguaggio di sua scelta, ma secondo me e' invitare grane e bachi software inutilmente.

Esiste poi la possibilita' di scaricare sull'Arduino (o Arduinoide, di solito ci vogliono piu' risorse di quelle disponibili in un ATMEL a 8 bit, benche' non sia completamente vero - ho dei micro ST8 programmati con un interprete BASIC, dei PIC con un interprete FORTH e altre perversioni...) un interprete che permette di eseguire interattivamente dei programmi tramite una interfaccia piu' o meno complicata che gira sul PC. In questo caso e' vero che non e' esattamente il PC che comanda l'esecuzione su Arduino, ma poco ci manca. Un bellissimo esempio e' microPython, che accoppiato con Thonny (https://thonny.org/, che permette di gestire il firmware, ossia l'interprete che gira sul micro e i programmi che esegue l'interprete stesso) secondo me oggidi' e' uno dei sistemi di prototipazione rapida piu' validi. Richiede un po' piu' di risorse (FLASH in particolare, perche' crea un filesystem in flash che contiene i programmi da eseguire), ma permette di "costruire" un sistema indipendente che, una volta finiti i test, puo' essere abbandonato a se' stesso e messo in condizioni di eseguire il programma Python desiderato. Per chi Python non lo apprezza, esiste Lua e cercando cercando sono esistite implementazioni di macchine virtuali Java su microcontrollori del tipo di Arduino.

Ci sono poi protocolli industriali standardizzati che sono implementabili su Arduino (leggi: esistono le librerie, ma un po' di programmazione su Arduino ci vuole). Un esempio ragionevolmente facile da implementare risale agli anni '70 se non erro, e si chiama ModBus (per esempio vedi https://en.wikipedia.org/wiki/Modbus). Esistono tre tipi fondamentali di trasmissioni, possono essere ASCII (testo, per intenderci), RTU e TCP. I primi due avvengono su linee seriali (RS232 o RS485 - in questo caso sono possibili multipli dispositivi sulla stessa linea seriale), mentre il terzo e' basato su TCP/IP e Ethernet e non ne parliamo. In ModBus, ogni dispositivo "Slave" dispone di un certo numero di "coil", che oggi chiamiamo Uscite Digitali, di "discrete input", che oggi chiamiamo Ingressi digitali, di "input register" che sono parole a 16 bit (combinabili per formarne a 32 bit) che rappresentano ingressi analogici, parametri interi (o reali) o anche parole di stato formate da piu' bit, e infine "holding register" che sono il corrispondente degli "input register' ma in uscita. Coil e Holding Register possono essere letti e scritti, dicrete input e input register solamente letti. Uno "slave" implementa un certo numero di funzioni a seconda del tipo e numero di periferiche disponibili, per esempio "write single coil" o "read multiple input registers". Il "Master" (nel nostro caso il PC - esistono un certo numero di programmi master gratuiti per i test, ma ovviamente uno finisce per doversi scrivere il Master che meglio lo serve - invia un comando selezionando lo slave, la funzione e gli indirizzi (se necessario), e lo slave "obbedisce". Ci sono in commercio molte periferiche industriali (anche basate su Arduino internamente) che implementano questo protocollo, perche' e' semplice, e' compatto, e funziona. Nel caso di applicazioni un po' piu' "professionali" e' un ottima base di partenza, se le prestazioni sono sufficienti non vale la pena di soffrire ulteriormente.

Se pero' parliamo di strumenti un po' piu' "professionali", per applicazioni IoT, a questo punto uno dovrebbe prendere in considerazione anche dei microcontrollori non piu' ATMEL ma con periferiche Wireless incorporate, perche' tanto per cominciare Windows (ma non solo) sembra prendere un piacere perverso a randomizzare l'assegnazione delle porte pseudo-seriali, e inoltre l'acesso Wireless apre le porte anche (perche' no) alle applicazioni su smartphone. In questo caso gli esempi sono numerosi, ma in genere si tratta di selezionare un protocollo per le comunicazioni tra i microcontrollori e il "broker" (sistema intermediario che gestisce l'acesso alle periferiche che i microcontrollori, bonta' loro, rendono accessibili tramite opportuna programmazione), e i "pacchetti" software addizionali "di contorno" come archiviazione, visualizzazione e perche' no anche generazione di allarmi... Un esempio per tutti e' il protocollo MQTT, sviluppato per la trasmissione di dati da e verso gli impianti di estrazione petrolifera nei deserti, magari accompagnato da Node-RED. Ma questo mi sembra eccedere un pochino i propositi percepiti dell'Original Poster, e mi fermo qui all'aperitivo.
Rispondi