Informatica per script kiddies 6 – Arduino, Raspberry Pi e quelle cose

Eccoci di nuovo la nostra rubrica mensile preferita. Ci siamo spostati sul blog di ItalyInformatica, dove prossimamente metterò in copia gli altri articoli per avere tutto insieme. L’episodio precedente era sul contact tracing, e da lì raggiungete i precedenti.

Oggi parliamo di cose che molti percepiscono come “schede piccole con cui fare cose strane”, e nemmeno a torto, ma che vengono di solito chiamati col nome piú tecnico di “sistemi embeded”.

Sarà un’introduzione un po’ generica, forse troppo, quindi mi aspetto domande 😛

Microcontrollori, microprocessori e system-on-a-chip

La prima cosa da capire su questo tipo di oggetti è che si dividono in due grandi famiglie, con finalità molto diverse, anche se con una grande sovrapposizione a livello di “cosa ci puoi fare”: esistono le schede basate su microcontrollori, e le schede basate su microprocessori (uso la parola “microprocessore” per intendere “microprocessore a uso generico”: a rigore altrimenti i microcontrollori non sono che degli strani microprocessori).

Un microcontrollore è un circuito integrato programmabile. L’idea che generalmente abbiamo di circuito è quella di un oggetto composto di fili, che a dati input (ci attacco una pila) risponde con dati output (si accende una lampadina). I microcontrollori sono un’idea molto simile, ma la relazione tra input e output non è fissa ma è scritta su un programma memorizzato nel circuito stesso (di solito su una memoria EPROM). Da fuori si presenterà come uno scatolino con diversi piedini numerati (alcuni con funzioni specifiche), e con la possibilità di scriverci dentro dei programmi che dicano cosa succede ad alcuni dei piedini quando succede qualcosa ad altri piedini.

Generalmente – ma non è detto – un microcontrollore si mette in attesa di un evento in ingresso, fa quello che deve fare, e si rimette poi in attesa. Esegue un solo programma, comportandosi come il programma stabilisce.

Anche un microprocessore è invece un circuito integrato capace di eseguire programmi, che però non risiedono al suo interno ma gli vengono dati in pasto da una struttura esterna piú o meno complessa. In genere un microprocessore, oggi, si trova ad eseguire un software complesso, il sistema operativo, che gli fa a sua volta eseguire altri programmi in base a logiche che il microprocessore non “conosce”.

Il microprocessore, insomma, è quello che sta nei nostri PC, e che esegue una marea di programmi diversi che il sistema operativo ci fa credere siano eseguiti in contemporanea. Si presenta in maniera simile al microcontrollore, uno scatolotto con tanti piedini, ma i piedini tendono ad essere dedicati a set di funzioni specifiche e al caricamento rapidissimo di software nelle memorie interne.

Talvolta, i microprocessori sono inclusi in degli oggetti piú complessi, con tutto quello che è necessario a far girare il sistema operativo e i software, e prendono il nome di system-on-a-chip, presentandosi con una piedinatura a quel punto molto simile a quella dei microcontrollori, a cui finiscono per somigliare: oggetti completi che non hanno bisogno di molto al di fuori di sé stessi, e capaci di prendere input ed elaborarli restituendo output direttamente utilizzabili.

Schede a microcontrollori

La scheda a microcontrollori che piú o meno tutti conoscono è l’Arduino Uno, che prenderò come esempio di tutta la categoria. Si tratta di un microcontrollore ATmega328P montato su una scheda di sviluppo e con preinstallato un software che rende comodo il caricamento e l’esecuzione di software scritto con un IDE abbinato. Il microcontrollore, di suo, sarebbe perfettamente capace di fare tutto quello che gli viene fatto fare: la scheda serve solo a fornire a chi lo usa un’interfaccia un po’ piú comoda e meno fulminabile di quella che forniscono i piedini del chip.

Oggetti come l’Arduino Uno hanno moltissimi punti di forza. Prima di tutto costano pochissimo (per motivi vari l’Arduino mica tanto, ma insomma): si trovano schede di sviluppo con integrati molto piú capaci dell’ATmega328P a prezzi veramente molto bassi. Poi, per la loro natura di microcontrollori li rende molto rapidi nelle risposte e poco soggetti a bug che non siano sotto il controllo di chi li programma, non essendoci un sistema operativo. Infine, tendono a consumare decisamente poco.

Sono insomma vantaggiosi in tutti i casi in cui siano sufficienti a fare ciò che si vuole fare. Qualsiasi progetto, ad esempio, faccia elaborazione non eccessivamente complessa di dati provenienti da sensori, che è un caso d’uso classico, rende di solito conveniente l’utilizzo di oggetti di questo tipo. Considerata l’elevata disponibilità di microcontrollori che integrano il necessario per effettuare connessioni via WiFi, le potenzialità sono davvero enormi.

Schede a microprocessori

Le schede a microprocessori, come la Raspberry Pi, sono generalmente basate su un system-on-a-chip, che contiene un microprocessore che di solito ha un’architettura ARM (è insomma del tipo di quelli “dei cellulari” e non di quelli “dei computer”). Come per le schede a microcontrollori, il system-on-a-chip è di solito montato su una scheda che contiene il necessario a utilizzarlo, dalla memoria di massa ad una serie di interfacce per utilizzarlo comodamente.

Una scheda a microprocessore è sostanzialmente un PC in miniatura. Il grande vantaggio rispetto alle schede a microprocessori è la possibilità di usarla appunto come un vero e proprio computer, con un sistema operativo a cui si è abituati (Linux, Windows) e a tutti gli strumenti di sviluppo e i software che ci girano sopra.

Tendono a consumare un po’ più dei microcontrollori (ma molto meno del PC medio) e riescono a coprirne il grosso dei casi d’uso, senza però la prontezza e l’affidabilità dei microcontrollori. Sono indispensabili quando è necessario far interagire software diversi tra loro, utilizzare hardware complesso (come ad esempio i monitor veri e propri), gestire interfacce grafiche complesse o utilizzare software già pronti che richiedano un sistema operativo, come i sistemi di cloud privato, o i sistemi di gestione della rete domestica.

Come si usano

Si tratta di un mondo molto vasto, e le schede a microprocessore possono essere di solito utilizzate anche come un normalissimo PC collegandoci monitor, mouse e tastiera, ma l’utilizzo avanzato è più o meno lo stesso in quasi tutti i casi.

Il GPIO

Una cosa comune a quasi tutti i kit di sviluppo è un’interfaccia chiamata GPIO. Si tratta di un insieme di pin che possono essere impostati come “pin di ingresso” o “pin di uscita” via software, e sono quindi utili a prendere in ingresso dati (da sensori, da pulsanti…) e a comunicare dati in uscita (da cose semplici come accendere lampadine o motori, a cose complesse come governare display).

Talvolta, una parte dei pin GPIO è dedicata all’input/output di dati analogici, sotto forma di tensione. Gli ingressi digitali invece possono essere o spenti (0 volt) o accesi (in genere 3.3 o 5 volt). Alcuni pin fanno da riferimento per gli zero volt, facendo quindi da “terra” e alcuni fanno da riferimento per la tensione dell’elettronica della scheda (quella che vale come “acceso”). A volte, le schede con elettronica a 3.3 volt hanno uno o più pin a 5 volt comodi per alimentare altri dispositivi (o, in ingresso, la scheda stessa).

In genere il software contenuto nella scheda – e in alcuni casi l’hardware stesso – dedicano alcuni pin a protocolli particolari, standard, utili a controllare sensori (come 1-wire) o periferiche (come SPI).

Gli shield

La diffusione di alcune famiglie di schede, tutte con interfaccia GPIO identica, ha spinto molti sviluppatori di hardware a creare delle schede, dette shield, che si possono attaccare direttamente sullo slot GPIO per aggiungere funzionalità alla scheda stessa. Ce ne sono di ogni genere, e sono spesso utilissimi ad aggiungere cose relativamente complesse e molto comuni, come display, sensori, memorie di massa, sistemi di alimentazione e quasi qualunque cosa possa venire in mente. Ovviamente, per essere poi utilizzati richiedono di studiarsi come governarli via software.

Ma quindi, cosa scegliere?

Dipende tantissimo dal progetto che si ha in mente e dalle proprie capacità. Le schede basate su microcontrollore sono solitamente programmabili con un piccolo set di linguaggi (C++ in massima parte), e richiedono quindi di conoscere il linguaggio con cui le si vuole usare, mentre per le schede a microprocessori le possibilità sono limitate solo dalla disponibilità di librerie (il linguaggio principe è Python, ma c’è di tutto). D’altra parte, però, per una buona quantità di progetti una scheda a microcontrollore è più che sufficiente, più economica (pensare di spendere 9 euro per una scheda che vai a dedicare a vita a una funzione è una cosa, pensare di spenderne 80 è un’altra) e più divertente.

Insomma va visto cosa si vuole fare e va fatta una valutazione di possibilità e praticità.

Cosa mi serve per iniziare?

Una parte delle cose dipende dal progetto: di sicuro serve la scheda, un alimentatore adatto, e tutte le periferiche che intendi utilizzare.

Altre cose, invece, sono molto generali.

Nessuno prende e si mette a saldare prima di vedere se le cose funzionano. La prima cosa che ci si trova a dover avere, quindi, sono delle schede di prototipazione (dette breadboard). Si tratta di oggetti di plastica con molti buchini. Sotto la plastica, i buchini sono collegati tra loro, di solito per mezze righe corte. In questo modo, inserire due piedini (uno del microcontrollore e uno di un led, per esempio) nella stessa mezza riga li mette in collegamento. A volte, per comodità, ad ogni lato lungo sono presenti due linee di pin collegati tra loro a cui attaccare l’alimentazione. Il mio consiglio è prendere più breadboard piccole, invece che una grande.

Per collegare parti di breadboard tra loro, così come per collegare breadboard e componenti vari tra loro, è comodo avere una buona quantità di cavetti appositi, che si chiamano jumper. Ne esistono sia di maschio-maschio, per collegare fori di breadboard (o di schede di sviluppo con GPIO femmina, come Arduino Uno), sia di maschio-femmina, per collegare la breadboard a schede con pin veri e propri (come quelli della Raspberry Pi).

Le schede pensate per essere saldate, invece che per sviluppare, tendono a non avere pin ma fori per saldatura. Se volete metterci dei pin, dovrete comprarne da saldare, si chiamano header e si vendono in strisce da ritagliare.

Quando il progetto è pronto, conviene passarlo su qualcosa di più solido di una breadboard. Si può decidere di saldarlo su una millefori, che è una scheda con tantissimi buchini rivestiti di metallo per saldarci sopra componenti. Ce ne sono sia di libere, sia di connesse per righe come le breadboard, e ce ne sono sia a faccia singola che doppia faccia (straconsiglio le seconde). Assieme alla millefori è bene comprare un bel rotolotto di filo. Esistono anche servizi per disegnare e farsi stampare veri e propri circuiti stampati, come quello offerto dal software, molto semplice, Fritzing, ma non sempre vale la pena.

Quando si decide di iniziare a saldare, servirà anche un saldatore a punta (sottile), ce ne sono per tutte le tasche e se state iniziando andateci non pianissimo ma piano, dello stagno da saldatura, un po’ di videotutorial e tanta pratica con filo e breadboard prima di andare a toccare gli integrati costosi.

Buon divertimento!

Informatica e COVID-19

Comprensibilmente, il tema di questi giorni su /r/ItalyInformatica è stato soprattutto il SARS-CoV-2, che sta costringendo tutti noi a casa. Fortunatamente, il virus non impatta direttamente sulle nostre professioni, che si possono spessissimo svolgere da casa senza troppo rischio di ammalarci di COVID, e quindi moltissimi di noi si sono dati da fare nel grande sforzo che si sta facendo per mitigare, e risolvere il prima possibile, questa crisi.

Il subreddit ha dato voce a tante di queste iniziative e volevo, nel primo di questi articoli digest, riassumerle un po’.

Intanto, l’analisi dei dati. La Protezione Civile, tra un bug e l’altro, rilascia quotidianamente i dati, e ne abbiamo parlato un po’, condividendo anche qualche sito di analisi, un paio sono anche qui, qui, qui e di qua. C’è chi semplicemente mostra i dati ufficiali, e chi tenta diversi tipi di modellazione, analisi e previsione. Qualche progetto è open source o lo è parzialmente, e diverse cose meritano un’occhiata.

Ci sono stati bandi, sia privati (un hackaton), che europei, che statali, per scrivere applicazioni utili a supportare la lotta al virus. Ormai è grossomodo tutto scaduto, ma si è parlato anche di quello. Di cose invece ancora fattibili, soprattutto il progetto Folding@Home (con le criticità che qualcuno ha sollevato) si è invece parlato qui e qui.

Diversi di noi si son trovati a dover fare videoconferenze o videolezioni di diverso tipo. Abbiamo parlato dei modi migliori per fare dirette in streaming, dei software che in videoconferenza permettono di condividere una lavagna e delle applicazioni per poter comunicare con i pazienti COVID isolati. Purtroppo non c’è nulla di ideale, e chissà che questa situazione non porti a concentrarsi piú sulle caratteristiche veramente utili che sulla marea di roba accessoria che le applicazioni di questo tipo offrono.

Qualcuno di noi è studente, e anche chi lavora sta spesso avendo avendo più tempo libero in questo periodo. E il tempo libero è sempre utile investirlo bene. Abbiamo quindi parlato di corsi online e di libri da leggere. Qualcun altro, invece, ha proposto di utilizzare il tempo per ripristinare hardware da destinare a chi ha bisogno di seguire videolezioni.

Anche governi e entità sovranazionali hanno preso, o stanno prendendo, diverse decisioni a forte contenuto informatico. Principalmente si è parlato di sorveglianza sui movimenti. Si è parlato dell’analisi che alcune regioni hanno fatto sui tabulati telefonici, ma anche di proposte e ipotesi un po’ più spinte, e dei tentativi regionali di mettere online qualcosa di utile. L’UE, invece, ha chiesto a un po’ di siti di streaming video di ridurre il traffico, e lo hanno fatto abbassando il bitrate, dicono.

Infine, la bufala: il 5G provoca il coronavirus, un po’ come, notoriamente, abbonarsi a Topolino provoca l’abbonamento a PornHub. Di 5G abbiamo anche parlato altrove.

Buona lettura, e tenete duro! Abbiamo aiutato parecchio a mitigare questa crisi che se fosse successa anche solo vent’anni fa sarebbe stata ben peggiore anche solo per motivi tecnologici, ma abbiamo ancora un sacco da fare. Buon lavoro a tutti!

La grafica in copertina è di Martin Sanchez, su Unsplash

Libmodule: libreria C per creare progetti modulari

Ciao a tutti! Sono u/nierro. Forse vi ricorderete di quando vi raccontai di un mio progetto proprio qui: https://tldr.italyinformatica.org/2017/05/clight-demone-utente-per-linux/.

Bene, libmodule nasce come “spin-off” di quel progetto: il codice di clight è molto modulare, e ha al suo interno tutta una serie di accorgimenti per gestire questi “moduli”.

Circa un mesetto fa mi resi conto che da un lato per clight questa gestione dei moduli era over-engineered, e dall’altro mi tornava utile in tanti progetti, personali e lavorativi.

Decisi quindi di mettermi al lavoro per creare una libreria come si deve, con lo scopo ultimo che dovesse essere semplice ed elegante.

Nasce così libmodule.

Cos’è libmodule?

È una libreria C, che ad oggi supporta linux, osx e BSD (tornerò su questo punto più in là), per scrivere progetti modulari e standardizzati.

L’approccio è piuttosto simile all’OOP; in particolare mi sono fortemente ispirato ad akka (https://akka.io/) e più in generale all’Actor Model per l’API.

Cos’è un modulo?

Un modulo è, manco a dirlo, l’entità chiave di libmodule; ogni modulo espone determinate callback che verranno usate per gestire il suo ciclo di vita.

Un modulo può inoltre reagire agli eventi, mettendosi in ascolto su dei File Descriptor.

Libmodule offre poi un loop interno che automaticamente ascolta su tutti gli eventi di tutti i moduli chiamando le callback corrette per ciascuno.

Supporta il mio OS?

Libmodule usa, per il suo loop interno, una struttura a compile-time-plugins; dipendentemente dalla piattaforma su cui viene compilato, seleziona il plugin corretto per implementare l’interfaccia di poll.
Ad oggi supporta epoll() su linux, e kqueue() su osx e bsd.

Lo svantaggio è che questi “plugins” dovranno avere una interfaccia simile a epoll.

Questa è una scelta specifica: l’ovvia soluzione portabile sarebbe stata usare poll(); trovo però l’API di kqueue/epoll molto più elegante e flessibile.

Esiste della documentazione?
Ovviamente: una libreria è completamente inutile se non esiste della documentazione.

La si può trovare qui: http://libmodule.readthedocs.io/en/latest/?badge=latest.

Tutto bello..ora però tira fuori il codice!

Mi sembra corretto ricompensare quei pochi coraggiosi giunti fin qui mostrando loro un breve esempio.


#include <module/modules.h>
#include <module/module.h>
#include 

MODULE("Test");

static void module_pre_start(void) {

}

static void init(void) {
     m_add_fd(STDIN_FILENO);
}

static int check(void) {
     return 1;
}

static int evaluate(void) {
     return 1;
}

static void receive (const msg_t *msg; const void *userdata) {
     if (!msg->msg) {
          char c;
          read(msg->fd,&c,sizeof(char));
               if (c=='q'){
               modules_quit();
          }
     }
}

int main () {
     modules_loop();
     return 0;
}

Per compilare, è sufficiente linkare libmodule tramite il linker flag “-lmodule” o usando lo script pkg-config installato.

Questo semplice programma crea un modulo, che si chiamerà “Test”, che ascolta su stdin.

Alla pressione di ‘q’, il programma uscirà.

Ben più utile, al fine di capire come funziona la libreria, è l’output generato (libreria compilata in debug, che la rende verbosa):

./sample.out Libmodule: Initializing libmodule 1.0.0. Libmodule: Creating context ‘default’. Libmodule: Registering module ‘Test’. a b c q Libmodule: Deregistering module ‘Test’. Libmodule: Destroying context ‘default’. Libmodule: Destroying libmodule.

 

Da qui appare ben chiaro lo scopo della macro MODULE(): registra un modulo in libmodule automaticamente all’avvio del programma, proprio come un ctor.

Il modulo viene poi de-registrato automaticamente da un dtor implicito.

Non mi dilungo su cosa sia un context, nella documentazione è ben spiegato.

Dall’esempio si possono evincere le caratteristiche principali di libmodule:

* Modularità (ovviamente)

* Semplicità

* Compattezza

Idealmente, ogni modulo costituisce un sorgente separato annotato dalla macro MODULE (anche se questa regola può essere aggirata utilizzando la “complex API”, che poi non è altro che l’API usata internamente dalla macro); forzando di fatto una standardizzazione del proprio progetto.

Hai citato gli actor, non vedo nulla però…

I moduli possono anche dialogare tra loro con un sistema PubSub: possono quindi inviare un messaggio a un altro modulo, o pubblicarlo su un “topic” che verrà ricevuto da tutti i moduli sottoscritti al suddetto topic.

Last, but not least (aka “la roba pallosa”)

Al momento mi sto concentrando sulla scrittura di unit test prima di rilasciare la prima versione stabile. Si noti che i test sono eseguiti automaticamente tramite travis sia su linux che su osx; inoltre su linux sono anche testati per la ricerca di memleak con valgrind.

L’API è in freeze in attesa della release; non ho comunque in mente alcun api break nel breve periodo.

Qualora per sbaglio dovessi aver stimolato il vostro interesse o la vostra curiosità, vi invito a farvi un giro al repo github: https://github.com/FedeDP/libmodule 🙂

La Forza Kinectica

Il sensore Kinect è ben famoso nella community videoludica, infatti era principalmente indirizzato ai giocatori quando Microsoft lo ha creato. La prima versione del dispositivo era per la console Xbox 360 e col suo sensore 3D ha introdotto un nuovo modo di giocare, cioè usare l’intero corpo o almeno le braccia dell’utente. Può facilmente tracciare l’intero corpo umano e dare in output una collezione completa di informazioni sulle posizioni e sui movimenti di ogni articolazione. Nella figura seguente si può vedere a cosa mi riferisco con articolazione, sono i ”Joints” che formano lo ”Skeleton” di un utente.

(altro…)

Alla scoperta di D: un completo linguaggio di programmazione

Negli ultimi anni abbiamo assistito all’ascesa di un gran numero di linguaggi di programmazione, in particolare [Go](2009), [Rust](2010), [Kotlin] (2011), [Elixir](2011), [Crystal] (2014), [Pony](2014).
Questa esplosione di nuovi linguaggi è dovuta, fra le molte motivazioni, alla necessità di adottare paradigmi di programmazione non immediatamente recenti come cittadini di primo tipo.
(altro…)

Mantieni la tua rete sotto controllo con Nidan

Buongiorno a tutti, sono o-zone1978, un sistemista informatico che lavora nel CED di un Ente pubblico toscano. Sono quasi 20 anni che lavoro nel settore informatico ed ho iniziato a programmare in C a 14 anni su un Amiga 600. Mi sono poi indirizzato verso lo sviluppo di applicativi web, in PHP, ed ultimamente ho ripreso a sviluppare in Python per la sua ampia disponibiltià anche su sistemi embedded. Grazie alla disponibilità dei ragazzi di /r/ItalyInformatica, oggi vi presento Nidan, un progetto a cui sto lavorando attivamente ormai da qualche mese. Ma andiamo con ordine… (altro…)

I testi generati ovvero le catene di Markov

Per chi non mi conoscesse, sono /u/timendum , il creatore di /u/italy_SS , cioè il /r/SubredditSimulator per i contenuti in Italiano.

In questo articolo cercherò di spiegarvi il meccanismo dietro la generazione di testi casuali usati in questi due subreddit.

(altro…)

Crackare password? Facciamolo!

Questo articolo sarà un po’ diverso dagli altri: oltre a parlarvi dell’argomento (Crackare password n.d.r.), voglio proporvi una piccola sfida.

Sappiamo che le password devono essere lunghe, devono essere complesse e solo una di queste due proprietà non basta: avere la stessa password per ogni sito web, sappiamo, non è cosa giusta. Tutte queste accortezze per cosa? Per non farsi rubare le password ovviamente: ma se volessi provarci? Vi è mai capitato di crackare password?

(altro…)

Entrare nella community di Envato? Difficile ma si può!

Envato, con oltre 1 milione di utenti, è sicuramente uno dei più grandi market mondiali per quanto riguarda la vendita di contenuti multimediali quali temi per ogni cms, plugins, addons, audio, video, app totalmente modificabili dall’utente finale se acquistati. In envato troviamo themeforest, videohive, graphicriver, audiojungle, 3docean, photodune, codecanyon. Se vuoi guadagnare qualcosa dal tuo codice, Envato è quello che fa per te (o quasi). In questo articolo vorrei raccontare la mia breve esperienza su cosa e come ho fatto per farmi accettare un plugin WooCommerce in Envato.

(altro…)

Progetti FOSS, anche tu puoi contribuire

Parlo di una realtà, che si può toccare con mano, una realtà che tutti usiamo ma che a nessuno (o quasi) interessa. Una realtà che riguarda tutti noi, non solo gli addetti ai lavori. La toccate quando usate sul vostro smartphone, la percepite quando inviate una mail, la notate quando acquistate online. Sono tutti (o quasi) strumenti, metodi e servizi basati su tecnologie FOSS (Free (and) Open Source Software ndr).

(altro…)