Gestire linee IO della Pico

La Pi Pico possiede 26 linee GPIO. Per poterle utilizzarle dobbiamo definirle come linee di ingresso o come linee di uscita, come avviene con Arduino con l’istruzione pinMode().

Realizziamo un semplice circuito come il seguente:

In questo caso le istruzioni da utilizzare fanno parte del modulo machine, quindi la prima istruzione da usare e l’importazione del modulo:

import machine

per definire un pin come uscita digitale utilizzeremo questa istruzione:

led = machine.Pin(15, machine.Pin.OUT)

L’oggetto led possiede il metodo value che permette di portare a livello alto o basso lo stato del pin:

led.value(1) # mette alto il pin 15
led.value(0) # mette basso il pin 15

Il classico blink del led si esegue con il seguente codice:

import machine
import utime

#definisco il pin gpio 15 come uscita
led = machine.Pin(15, machine.Pin.OUT)

while(1):
    led.value(1) # uscita a livello logico alto
    utime.sleep(1) # pausa di 1 secondo
    led.value(0) # uscita a livello logico basso
    utime.sleep(1) # pausa di 1 secondo
    

GPIO Speed Test

Dal codice precedente, eliminando l’istruzione sleep() possiamo misurare la velocita massima di commutazione del pin

import machine
import utime

#definisco il pin gpio 15 come uscita
led = machine.Pin(15, machine.Pin.OUT)

while(1):
    led.toggle() # mette l'uscita alta e poi bassa 

ottenendo una frequenza di commutazione di circa 60,5 KHz ma che presenta una continua variazione del livello alto dell’onda di circa  +- 1.3uS

Questo fenomeno e tipico in tutti i microcontrollori che eseguono codice interpretato, queste latenze sono intrinseche e tipicamente tollerate in questi sistemi. Per avere tempistiche certe nell’esecuzione dei programmi dobbiamo usare codici compilati e ottimizzati per l’architettura del microcontrollore.

Configurare un ingresso digitale

allo stesso modo delle istruzioni viste in precedenza possiamo definire un pin in ingresso con il seguente codice:

import machine
import utime

#definisco il pin gpio 15 come uscita
led = machine.Pin(15, machine.Pin.OUT)
#definisco il pin gpio 16 come ingresso
pulsante = machine.Pin(16, machine.Pin.IN)

while(1):
    if pulsante.value() == 0:
        print("pulsante premuto!")

        utime.sleep(0.2)
    
    # continuo a commutare il pin 15
    #la frequenza ora è di circa 26KHz
    led.toggle()

Utilizzare un thread

Lo svantaggio di avere delle latenze dovute alla presenza dell’interprete MicroPython può essere in parte compensato da un linguaggio ad alto livello che permette di scrivere il codice con un approccio moderno come quello dell’uso dei Thread.

Un thread è un processo che può essere eseguito in contemporanea (o quasi) con l’esecuzione di altro codice. Nell’esempio seguente il codice del thread controllerà quando premiamo il pulsante. Mentre il resto del programma continuerà a eseguirà le altre istruzioni.

import machine
import utime
import _thread

#creo una variabile globale che verrà usata in tutte le funzioni
global stato_pulsante
stato_pulsante = False

#definisco il pin gpio 15 come uscita
led = machine.Pin(15, machine.Pin.OUT)
#definisco il pin gpio 16 come ingresso
pulsante = machine.Pin(16, machine.Pin.IN)

#creo una funzione che verrà gestita dal thread
def leggi_stato_pulsante():
    global stato_pulsante
    while True:
        # se premo il pulsante cambio il valore della 
        # variabile globale
        if pulsante.value() == 0:
            stato_pulsante = True
            utime.sleep(0.2)

#creo un thread e lo associo alla funzione precedentemente creata
_thread.start_new_thread(leggi_stato_pulsante, ())

#questo è il codice del thread principale
while True:
    #controllo il valore della variabile globale
    if (stato_pulsante == True):
        print("pulsante premuto!")
        #reimposto la variabile globale a False
        global stato_pulsante
        stato_pulsante = False
    
    #continuo a eseguire la commutazione del pin 15
    led.toggle()

L’effetto di questo codice è uguale al precedente ma la scrittura del codice rimane qualitativamente migliore.

The post Come usare pin IO digitali della Pico appeared first on Esperimenti con logiche programmabili.

La MKR1000 è una scheda molto compatta, dal prezzo contenuto, che permette di realizzare interessanti progetti IoT. Questa scheda è basata sul SoC ATMEL ATSAMW25 (famiglia di dispositivi ATMEL Wireless) ed è l’insieme di questi moduli:

• MCU SAMD21 Cortex-M0+ 32bit operante alla frequenza di 48MHz
• Modulo Wi-Fi WINC1500 a basso consumo (2.4GHz IEEE® 802.11 b/g/n)
• Crittografia per comunicazioni sicure basate sul chip ECC508
• Antenna implementata sul PCB

La scheda possiede anche un caricabatterie per batterie Li-Po rendendola quindi adoperabile in ambienti dove non è presente una fonte di energia costante.
In questo articolo andremmo a misurare la velocità di commutazione di un pin digitale eseguendo lo stesso codice che ho usato per gli altri gpio speed test.

Questo test è puramente indicativo, è un metodo molto semplice che eseguo per fare un piccolo paragone tra le schede in mio possesso.

La figura seguente mostra lo schema elettrico che ho utilizzato:

Mentre il codice seguente è quello caricato sulla scheda MKR1000:

void setup()
{
  //pin5 in uscita
  pinMode(5, OUTPUT);
}
 
void loop()
{
  //ciclo infinito
  while(true)
  {
    //metto il pin5 alto
    digitalWrite(5, HIGH);
    //metto il pin5 basso
    digitalWrite(5, LOW);
  }
}

Il risultato ottenuto è di circa 310KHz:

Di seguito la tabella comparativa dei test di commutazione ottenuta eseguendo il medesimo codice:

The post MKR1000 gpio speed test appeared first on Esperimenti con logiche programmabili.

Anche per il modulo Flyporyt Ethernet ho realizzato lo speed test come quello per le schede Netduino, Arduino e GHI. Il test consiste nella commutazione continua di un singolo pin digitale, misurando con un oscilloscopio, la frequenza risultante.

Il circuito elettrico dei collegamenti è il seguente:

mentre questo è il risultato della misura:

Come si può osservare la frequenza e di ben 134.5KHz, un risultato che reputo molto soddisfacente, paragonato ai precedenti speed test.

La tabella seguente riepiloga i risultati misurati con le varie schede

Lo speed test è indicativo e non stabilisce certamente la scheda migliore. Ogni dispositivo possiede pro e contro a prescindere dal risultato dello speed test.

The post Flyport Ethernet Speed Test appeared first on Esperimenti con logiche programmabili.

Eccoci nuovamente al mio classico speed test per misurare la frequenza massima ottenibile dalla commutazione continua di un singolo pin.

La scheda in esame è il nuovo Netduino Plus 2 basato sulla cpu STmicro STM32F4 operante a 168Mhz. Sicuramente l’incremento di frequenza ha permesso maggiori prestazioni ma il risultato è ben lontano dai 125KHz ottenuti dall’Arduino UNO, infatti la frequenza misurata è di 44.27 KHz, che paragonata alla prima versione della scheda (quella basata sulla cpu AT91SAM7 operante a 48MHz), è comunque un ottimo risultato che fa ben sperare in evoluzioni future e miglioramenti prestazionali nell’archittetura .Net micro framework.

Di seguito la tabella aggiornata degli speed test delle board che ho provato

Questo invece lo screen shot della schermata dell’oscilloscopio

The post Netduino Plus 2 Speed Test appeared first on Esperimenti con logiche programmabili.

Ho acquistato di recente la nuova scheda Arduino Leonardo basata sul chip Atmel Mega32U4. Questo microcontrollore possiede un modulo usb integrato che sostituisce il modulo di conversione usb-ttl presente nella Arduino UNO, rendendo la scheda molto ‘snella’ visto l’esiguo numero di componenti che ospita.

La prima prova che voglio effettuare è il classico speed test che ho realizzato anche per le altre schede. Questa verifica consiste nel commutare un pin digitale in modo ripetitivo, utilizzando solamente le istruzioni che permettono di porre il pin digitale a livello alto e a livello basso e, avvalendomi di un oscilloscopio ,misurare la frequenza di commutazione.

Lo sketch caricato sulla Leonardo è il seguente:

void setup()
{
  //pin0 in uscita
  pinMode(0, OUTPUT);
}

void loop()
{
  //ciclo infinito
  while(true)
  {
    //metto il pin0 alto
    digitalWrite(0, HIGH);
    //metto il pin0 basso
    digitalWrite(0, LOW);
  }
}

mentre lo schema elettrico del test è il seguente

la frequenza misurata risulta pari a 106 Khz leggermente inferiore a quella ottenuta con la Arduino UNO(125Khz). Ho realizzato una semplice tabella riepilogativa con le varie frequenze delle diverse schede che ho sottoposto al test.

The post Arduino Leonardo speed test appeared first on Esperimenti con logiche programmabili.

Per eseguire una comparazione con Netduino ho eseguito lo stesso esperimento (Netduino speed test) anche per Arduino Uno. Il gpio speed test è molto semplice, basta definire un pin in uscita ed eseguire in modo ciclico un’istruzione che lo ponga a livello logico alto e poi basso.
Questa commutazione continua genera un segnale ad onda quadra misurabile con un oscilloscopio.

Il codice seguente mostra come effettuare questo test:

void setup()
{
  pinMode(0, OUTPUT); //Definisce il Pin0 come Uscita
}

void loop()
{
  while(true)
  {
    digitalWrite(0, HIGH); //Commuta l'uscita alta
    digitalWrite(0, LOW); //Commuta l'uscita bassa
  }
}

La frequenza ottenuta sul pin 0 è di ben 125 KHz decisamente superiore a quella ottenuta dal Netduino (8.4KHz) nonostante i suoi 48 Mhz di clock contro i 16Mhz dell’Arduino.

L’istruzione digitalWrite() impiega circa 4uS contro i 53uS della Write() eseguita dal Netduino.

Netduino impiega delle risorse per far girare il .Net micro framework ecco perché nello speed test contro Arduino esce perdente.
Arduino nonostante i sui 16Mhz di clock è capace di essere più veloce, perché il suo codice, accede direttamente alle funzioni a basso livello del microprocessore ATMEGA328.

The post Arduino Uno gpio Speed Test appeared first on Esperimenti con logiche programmabili.

Una delle domande che mi pongo quando lavoro con un dispositivo programmabile è quanto questo sia veloce. Non so se esistano procedure specifiche che indichino la potenza di calcolo effettiva, indicativamente il test che eseguo io è quello di commutare di continuo un’uscita digitale e verificare con un oscilloscopio il tempo della durata di una istruzione.
Il codice è il seguente:

//Netduino GPIO
OutputPort Test = new OutputPort(Pins.GPIO_PIN_D0, false);

while(true)
{
Test.Write(true);
Test.Write(false);
 }

Questo codice generare un onda quadra con una frequenza di circa 8.4 KHz; Il segnale positivo generato dalla Write(true) dura circa 53us mentre il segnale negativo dovuto alla funzione Write(false)dura circa 64us. Verosimilmente il segnale negativo dura qualche microsecondo in più poiché il processore deve eseguire anche l’istruzione While(true). Quindi l’istruzione While viene eseguita in circa 11us (64us – 53us)

Per verificare la correttezza di queste misure ho modificato il codice aggiungendo un’altra istruzione Write(false) per verificare che l’impulso negativo fosse di circa 117us (53us + 53us + 11us)

OutputPort Test = new OutputPort(Pins.GPIO_PIN_D0, false);

while(true)
{
Test.Write(true); //Questa istruzione dura 53us
Test.Write(false); //Questa istruzione dura 53us
Test.Write(false); //Questa istruzione dura 53us
 }

La misura con l’oscilloscopio è per l’impulso positivo di circa 53us (istruzione Write(true)) e di circa 117us per l’impulso negativo (53us più 64us, due istruzioni Write(false) e istruzione while(true)).

Queste prove sono state eseguite compilando in modalità Debug, mentre utilizzando la modalità Release i tempi migliorano grazie all’ottimizzazione del codice. Per l’impulso negativo abbiamo circa 53us e per l’impulso positivo abbiamo circa 52us. Quindi le istruzioni write() durano circa 52us mentre l’istruzione while(true) dura circa 1us.

Ogni istruzione impiega un certo tempo per essere eseguita; questo tempo dipende esclusivamente dalla potenza di calcolo del processore Atmel del Netduino. Non abbiamo quindi un controllo diretto sul tempo di esecuzione del programma, sappiamo che ogni istruzione impiega un certo tempo; per migliorare le prestazioni dei nostri programmi dobbiamo imparare a scrivere le istruzioni in modo che impieghino il minor tempo possibile.

In definitiva il Netduino non è velocissimo come un ad esempio un PicMicro; questo dipende sicuramente dal fatto che  il microprocessore Atmel deve far girare il .Net micro framework.
Certamente questo piccola perdita di prestazioni è trascurabile rispetto ai vantaggi nell’utilizzare un ambiente gestito dal .Net micro framework, che semplifica la creazione dei programmi e la gestione dell’hardware.

The post Netduino GPIO Speed Test appeared first on Esperimenti con logiche programmabili.