Channel9 : bus SPI ed il .Net Micro Framework su Coding4Fun 

Posted by Paolo Patierno Friday, January 24, 2014 3:50:14 PM
Rate this Content 0 Votes

channel9

Citando le parole di Greg Duncan sono ormai un “friend of the blog” !

L’appuntamento settimanale del venerdì nel blog Coding4Fun su Channel9 fa riferimento al mio articolo sul bus SPI ed il suo utilizzo attraverso il .Net Micro Framework (su una board Netduino).

E’ un piacere esserci !

A bocca aperta

uNFC library : NFC con le piattaforme Windows Embedded 

Posted by Paolo Patierno Friday, January 24, 2014 9:11:53 AM
Rate this Content 0 Votes

Dopo i due articoli precedenti che descrivevano il bus SPI ed I2C ed il loro utilizzo nel .Net Micro Framework, è giunto finalmente il momento di vederne un’applicazione pratica con il mio ultimo progetto disponibile su CodePlex : uNFC – NFC library for .Net platforms !

Introduzione : supporto software ed hardware

Questa libreria permette di utilizzare un chip NFC collegato al nostro PC (via seriale) oppure ad un qualsiasi sistema embedded che sia basato su Windows Embedded Compact / Windows Embedded Standard o .Net Micro Framework.

Essa supporta tutti le piattaforme .Net Framework disponibili :

  • .Net Framework 4.0 per PC con Windows 7/8 oppure sistemi embedded basati su Windows Embedded Standard 7 e Windows Embedded 8 Standard;
  • .Net Compact Framework 3.5 / 3.9 per sistemi embedded basati su Windows Embedded Compact 7 e Windows Embedded Compact 2013;
  • .Net Micro Framework 4.2 e 4.3 per sistemi embedded come le board Netduino e .Net Gadgeteer;

Per quanto riguarda l’hardware, essa attualmente supporta il chip NFC PN532 della NXP ma definisce un “piccolo framework” grazie al quale è possibile sviluppare un managed driver per un chip differente senza modificare tutti i livelli superiori che si interfacciano con l’applicazione utente. Il supporto al chip PN532 è garantito con tutti e tre i possibili canali di comunicazione previsti per esso : I2C, SPI ed HSU.

Tipicamente il canale HSU (High Speed UART) viene utilizzato per il collegamento alla porta seriale di un PC o di un sistema basato su Windows Embedded Compact. Le connessioni I2C ed SPI rappresentano le soluzioni migliori nel caso di board basate su .Net Micro Framework.

Lo sviluppo ed il testing è stato effettuato mediante la breakout board RFID/NFC della Elecfreaks e disponibile al seguente link, così come il datasheet ufficiale di riferimento del chip NXP PN532 è disponibile qui. Per il collegamento ad un PC è ovviamente necessario un convertitore USB – Seriale TTL (come questi della FTDI) con i relativi driver, in modo da interfacciarsi al lettore sempre attraverso una porta seriale (in questo caso virtuale).

NFC-Module

Architettura software

Il managed driver per il chip PN532 è implementato dalla classe PN532 che ha un riferimento ad un’istanza del layer di comunicazione che deve implementare l’interfaccia IPN532CommunicationLayer. In questo modo, abbiamo la possibilità di scegliere il canale da utilizzare fornendo l’istanza di una classe concreta che implementa questa interfaccia al costruttore della classe PN532. Le classe disponibili sono le seguenti :

  • PN532CommunicationI2C : canale I2C;
  • PN532CommunicationSPI : canale SPI;
  • PN532CommunicationHSU : canale HSU;

Il lettore basato su questo chip è implementato attraverso la classe NfcPN532Reader che ha un riferimento all’istanza della PN532. Questo classe implementa l’interfaccia INfcReader. Ciò vuol dire che se vogliamo utilizzare un altro chip, dobbiamo seguire questi passi :

  • Realizzare una classe per il driver (come la PN532);
  • Realizzare una classe relativa al lettore che ha un riferimento al driver suddetto ed implementa l’interfaccia INfcReader;

L’esistenza di più classi nell’implementazione per il chip PN532 è strettamente legata al fatto che quest’ultimo disponga di più canali di comunicazione per l’interfacciamento.

ClassDiagram1

In primo luogo va creata un’istanza di una delle classi relative al canale di comunicazione e ciascuna di esse è strettamente legata alla board sulla quale stiamo lavorando. Successivamente tale istanza va fornita al costruttore della classe PN532 e quest’ultima va passata al costruttore della classe del lettore NfcPN532Reader.

L’interfaccia INfcReader, che essa implementa, espone :

  • il metodo Open() per l’inizializzazione del lettore, specificando il tipo di tag NFC che ci aspettiamo di poter riconoscere;
  • il metodo Close() per chiudere la connessione al lettore;
  • il metodo WriteRead() per scrivere e leggere verso/da il lettore;
  • l’evento TadDetected che viene sollevato quando un tag è riconosciuto dal lettore;
  • l’evento TagLost che viene sollevato quando il lettore perder la connessione con il tag riconosciuto;

Utilizzando gli ultimi due eventi, è possibile registrare un event handler per ciascuno di essi in modo da poter gestire il riconoscimento di un tag da parte del lettore e la disconnessione del tag stesso.

IMG_20140104_093307

Di seguito, un esempio di applicazione per la board Netduino Plus sulla quale possiamo utilizzare tutti i canali di comunicazione disponibili nel PN532 ma è ovviamente possibile istanziare ed utilizzare un solo canale alla volta (nella foto in alto oltre al Netduino Plus ed alla board dell’NFC, c’è anche un analizzatore logico usato durante lo sviluppo).

   1: static private INfcReader nfc;
   2:  
   3: public static void Main()
   4: {
   5:     // write your code here
   6:  
   7:     
   8:     // HSU Communication layer
   9:     // MOSI/SDA (TX) --> DIGITAL 0 (RX COM1)
  10:     // SCL/RX (RX) --> DIGITAL 1 (TX COM1)
  11:     IPN532CommunicationLayer commLayer = new PN532CommunicationHSU(SerialPorts.COM1);
  12:  
  13:     // SPI Communication layer
  14:     // SCK --> DIGITAL 13
  15:     // MISO --> DIGITAL 12
  16:     // MOSI/SDA --> DIGITAL 11
  17:     // SCL/RX -> DIGITAL 10
  18:     // IRQ --> DIGITAL 8
  19:     //IPN532CommunicationLayer commLayer = new PN532CommunicationSPI(SPI.SPI_module.SPI1, Pins.GPIO_PIN_D10, Pins.GPIO_PIN_D8);
  20:  
  21:     // I2C Communication layer
  22:     // MOSI/SDA --> ANALOG 4 (SDA)
  23:     // SCL/RS --> ANALOG 5 (SCL)
  24:     // IRQ --> DIGITAL 8
  25:     //IPN532CommunicationLayer commLayer = new PN532CommunicationI2C(Pins.GPIO_PIN_D8);
  26:                 
  27:     nfc = new NfcPN532Reader(commLayer);
  28:     nfc.TagDetected += nfc_TagDetected;
  29:     nfc.TagLost += nfc_TagLost;
  30:     nfc.Open(NfcTagType.MifareUltralight);
  31:  
  32:     InterruptPort button = new InterruptPort(Pins.ONBOARD_SW1, true, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeHigh);
  33:     button.OnInterrupt += button_OnInterrupt;
  34:     
  35:     Thread.Sleep(Timeout.Infinite);
  36: }
  37:  
  38: static void button_OnInterrupt(uint data1, uint data2, DateTime time)
  39: {
  40:     nfc.Close();
  41: }

In entrambi gli eventi, l’istanza NfcTagEventArgs espone alcune informazioni sul tag riconosciuto (il tipo) ed un riferimento alla connessione al tag. Tale connessione è rappresentata da un’istanza di una classe che deriva dalla classe astratta NfcTagConnection. Attualmente sono disponibili le classi NfcMifareTagConnection e NfcMifareUITagConnection per la gestione rispettivamente del tag Mifare Classic e Mifare Ultralight.

La classe astratta ha a disposizione :

  • la property ID, ossia l’NFC ID del tag;
  • un riferimento all’interfaccia INfcReader che punterà all’istanza NfcPN532Reader utilizzata per attivare il lettore. Attraverso questa istanza, l’oggetto relativo alla connection è in grado di utilizzare il metodo WriteRead() visto prima per scrivere e leggere verso/da il lettore;

ClassDiagram2

Tornando all’esempio precedente, attraverso i due event handler possiamo mostrare l’ID del tag riconosciuto e magari effettuare delle operazioni di lettura scrittura sulla base del tipo riconosciuto grazie al corrispondente oggetto NfcTagConnection.

L’esempio mostra che è necessaria una distinzione tra i tipi di tag (anche se entrambi Mifare), in quanto il Mifare Classic prevede un’operazione di autenticazione sul blocco a cui accedere (blocco 8 nell’esempio) che non è prevista dal Mifare Ultralight; i due tag sono diversi anche in termini di struttura della memoria interna.

   1: static void nfc_TagLost(object sender, NfcTagEventArgs e)
   2: {
   3:     Debug.Print("LOST " + HexToString(e.Connection.ID));
   4: }
   5:  
   6: static void nfc_TagDetected(object sender, NfcTagEventArgs e)
   7: {
   8:     Debug.Print("DETECTED " + HexToString(e.Connection.ID));
   9:  
  10:     byte[] data;
  11:  
  12:     switch (e.NfcTagType)
  13:     {
  14:         case NfcTagType.MifareClassic1k:
  15:             
  16:             NfcMifareTagConnection mifareConn = (NfcMifareTagConnection)e.Connection;
  17:             mifareConn.Authenticate(MifareKeyAuth.KeyA, 0x08, new byte[] { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF });
  18:             mifareConn.Read(0x08);
  19:  
  20:             data = new byte[16];
  21:             for (byte i = 0; i < data.Length; i++)
  22:                 data[i] = i;
  23:  
  24:             mifareConn.Write(0x08, data);
  25:  
  26:             mifareConn.Read(0x08);
  27:             break;
  28:  
  29:         case NfcTagType.MifareUltralight:
  30:  
  31:             NfcMifareUlTagConnection mifareUlConn = (NfcMifareUlTagConnection)e.Connection;
  32:  
  33:             for (byte i = 0; i < 16; i++)
  34:             {
  35:                 byte[] read = mifareUlConn.Read(i);
  36:             }
  37:  
  38:             mifareUlConn.Read(0x08);
  39:  
  40:             data = new byte[4];
  41:             for (byte i = 0; i < data.Length; i++)
  42:                 data[i] = i;
  43:  
  44:             mifareUlConn.Write(0x08, data);
  45:  
  46:             mifareUlConn.Read(0x08);
  47:             break;
  48:  
  49:         default:
  50:             break;
  51:     }
  52: }

Conclusioni

Il progetto è appena all’inizio e spero di avere numerosi feedback da coloro che lo utilizzeranno per poterlo migliorare. La possibilità di realizzare un driver per un chip NFC differente ed integrarlo nell’architettura senza alterare i livelli superiori, può essere un punto di forza.

La lettura e la scrittura dei tag NFC è di tipo “raw” e non c’è supporto per NDEF (NFC Data Exchange Format) ma non c’è da preoccuparsi ! Il team di Mopius mi ha aggiunto come developer al progetto NDEF Library ed il mio obiettivo è quello di realizzarne il porting anche su .Net Micro Framework.

Netduino, port expander con PCF8574AP 

Posted by Marco Lai Thursday, January 23, 2014 6:52:00 PM
Rate this Content 0 Votes

Quando le porte del nostro amato Netduino risultano numericamente inferiori rispetto a quelle previste per il nostro progetto potremmo optare per un port expander. Tramite il bus I2C possiamo gestire l’integrato PCF8574AP che mette a disposizione 8 porte IO.

Per imparare ad utilizzarlo ho scritto una breve guida disponibile a questo indirizzo.

.Net Micro Framework : usiamo il bus I2C ! 

Posted by Paolo Patierno Tuesday, January 21, 2014 2:15:42 PM
Rate this Content 0 Votes

Alla pari dell’SPI, analizzato in un articolo precedente, l’I2C (Inter-Integrated Circuit) è un bus di comunicazione sincrono utilizzato per la connessione e lo scambio dati tra un microprocessore e le periferiche esterne; sviluppato dalla Philips, oggi NXP, è diventato uno standard “de facto”.

Descrizione del bus

l’I2C è anche noto come bus two-wire in quanto è caratterizzato a tutti gli effetti da due soli “fili” :

  • SDA (Serial Data Line) : linea per il trasferimento dati;
  • SCL (Serial CLock) : clock per il sincronismo nello scambio dati;

Le linee suddette sono sempre caratterizzate da una resistenza di pull-up che ha il compito di mantenere il segnale “alto” (1 logico) in condizioni di idle mentre i componenti interconnessi (master e slave) hanno il compito di abbassarne il livello per trasferire uno 0 logico e di rilasciarlo per riportarlo in idle e trasferire un 1 logico; questo comportamento è tipico delle linee open-drain.

425px-I2C_svg

Analogamente all’SPI, è possibile avere più slave connessi al bus ed un unico master con cui comunicare; la differenza principale è che non esiste un segnale di SS (Slave Select) ma il master seleziona lo slave con cui comunicare attraverso un indirizzamento. Infatti, il master trasmette l’indirizzo dello slave sulla linea SDA prima di iniziare il trasferimento dei dati veri e propri; tale indirizzo è tipicamente a 7 bit (fino a 128 slave) ma è prevista un’estensione fino a 10 bit (fino a 1024 slave).

Una caratteristiche fondamentale dell’I2C è che permette la presenza di più master sul bus a differenza dell’SPI (modalità multi master).

Il protocollo di comunicazione

Il protocollo di comunicazione è caratterizzato dai seguenti passi :

  1. START Condition : il master abbassa l’SDA tenendo ancora alto l’SCL per indicare la condizione di START allo slave e quindi l’inizio di una trasmissione;
  2. Indirizzamento : il master invia un byte (MSB first) sul bus, in cui i primi 7 bit rappresentano l’indirizzo dello slave con cui comunicare e l’ultimo bit indica il tipo di operazione da voler effettuare (0 = write, 1, = read);
  3. Slave acknowledge : se sul bus esiste uno slave con tale indirizzo, esso risponde con un bit di ACK (0 logico);
  4. Comunicazione : a questo punto, il master può inviare e/o ricevere dati dallo slave in maniera sincrona grazie al movimento dell’SCL. Per ogni byte scambiato è sempre previsto un ACK dalla controparte;
  5. STOP Condition : il master alza l’SCL tenendo ancora basso l’SDA per indicare la STOP condition allo slave e quindi il termine della trasmissione;

798px-I2C_data_transfer_svg

Il clock è sempre pilotato dal master ma in alcuni casi lo slave può mantenerne il valore basso per introdurre del delay ed evitare che il master gli invii altri dati (magari ha bisogno di più tempo per elaborare i dati già ricevuti) : questa funzionalità si chiama “clock stretching”.

.Net Micro Framework : le classi per utilizzare il bus

Il .Net Micro Framework semplifica notevolmente l’utilizzo del bus I2C mediante la classe I2CDevice (namespace Microsoft.SPOT.Hardware, assembly Microsoft.SPOT.Hardware.dll), il cui costruttore prevede un parametro del tipo I2CDevice.Configuration per poter essere opportunamente configurata; tale configurazione permette di impostare :

  • Address : indirizzo dello slave con cui comunicare;
  • ClockRateKhz : frequenza del clock;

Tutti i parametri di configurazione suddetti sono sempre strettamente legati al device con il quale si intende comunicare e vanno ricercati all’interno del datasheet.

   1: I2CDevice.Configuration config = 
   2:                 new I2CDevice.Configuration(I2C_ADDRESS, I2C_CLOCK_RATE_KHZ);
   3:  
   4: I2CDevice i2c = new I2CDevice(config);

La classe I2CDevice mette a disposizione un unico metodo Execute() per poter effettuare una o più “transazioni” sul bus che rappresentano le operazioni di lettura e scrittura con lo slave. Tale metodo prevede in ingresso un array di oggetti I2CDevice.I2CTransaction ed un timeout. La classe I2CDevice.I2CTransaction è la classe base per la classe I2CDevice.I2CReadTransaction, nel caso di una transazione di lettura, e per la classe I2CDevice.I2CWriteTransaction, nel caso di una transazione di scrittura.

La creazione di un’istanza per ciascuna delle due classi suddette può essere effettuata attraverso i due seguenti metodi statici della classe I2CDevice :

  • CreateReadTransaction() : crea un’istanza della classe I2CDevice.I2CReadTransaction associando ad essa l’array di byte ricevuto in ingresso come buffer per la ricezione dati dallo slave (inizialmente vuoto);
  • CreateWriteTransaction() : crea un’istanza della classe I2CDevice.I2CWriteTransaction associando ad essa l’array di byte ricevuto in ingresso come buffer contenente i dati da trasmettere allo slave;

In definitiva, la procedura d’uso dell’I2C prevede di creare un array di “transazioni” di lettura e/o scrittura (ovviamente anche mixate) ed eseguire queste transazioni in un solo colpo, ritrovandosi i dati trasmessi allo slave ed i buffer di ricezione con i dati richiesti.

Immaginiamo di aver un componente I2C caratterizzato da una serie di registri interni e di voler leggere il contenuto di uno di essi. Questo tipo di comunicazione è caratterizzata da due “transazioni” I2C; la prima di scrittura per poter inviare allo slave l’indirizzo del registro da leggere (attenzione !! non parliamo dell’indirizzo dello slave stesso che viene inviato in precedenza) e la seconda di lettura per poterne leggere il contenuto.

   1: byte[] write = { REG_ADDRESS };
   2: byte[] read = new byte[1];
   3:  
   4: // create I2C write and read transaction
   5: I2CDevice.I2CTransaction[] i2cTx = new I2CDevice.I2CTransaction[2];
   6: i2cTx[0] = I2CDevice.CreateWriteTransaction(write);
   7: i2cTx[1] = I2CDevice.CreateReadTransaction(read);
   8:  
   9: // execution
  10: i2c.Execute(i2cTx, I2C_TIMEOUT);

Uno sguardo verso il basso : lo strato di HAL

Anche nel caso dell’I2C (come già visto per l’SPI), ciascun OEM deve implementare uno strato HAL (e PAL) che faccia da “ponte” tra la parte CLR (fino al codice managed ad alto livello) ed il particolare hardware sottostante.

Prendiamo come riferimento la board Netduino (generazione 1) che ha come microcontrollore un Atmel AT91. Scaricando i sorgenti del firmware (sono open source) dal sito ufficiale, possiamo individuare l’implementazione in codice managed C# della classe I2CDevice (Framework\Core\Native_Hardware\I2C.cs) all’interno della quale viene invocato il metodo GetI2CPins() sull’istanza corrente dell’HardwareProvider.

   1: public I2CDevice(Configuration config)
   2: {
   3:     this.Config = config;
   4:  
   5:     HardwareProvider hwProvider = HardwareProvider.HwProvider;
   6:  
   7:     if (hwProvider != null)
   8:     {
   9:         Cpu.Pin scl;
  10:         Cpu.Pin sda;
  11:  
  12:         hwProvider.GetI2CPins(out scl, out sda);
  13:  
  14:         if (scl != Cpu.Pin.GPIO_NONE)
  15:         {
  16:             Port.ReservePin(scl, true);
  17:         }
  18:  
  19:         if (sda != Cpu.Pin.GPIO_NONE)
  20:         {
  21:             Port.ReservePin(sda, true);
  22:         }
  23:     }
  24:  
  25:     Initialize();
  26:  
  27:     m_disposed = false;
  28: }

Dopo una serie di invocazioni a cascata attraverso il CLR fino all’implementazione dell’HAL, sarà invocato il metodo GetPins() sulla classe AT91_I2C_Driver(DeviceCode\Targets\Native\AT91\DeviceCode\AT91_I2C\AT91__I2C.cpp) che ritorna gli identificativi dei pin del processore associati alla porta I2C.

   1: void  AT91_I2C_Driver::GetPins(GPIO_PIN& scl, GPIO_PIN& sda)
   2: {
   3:     NATIVE_PROFILE_HAL_PROCESSOR_I2C();
   4:  
   5:     scl = AT91_TWI_SCL;
   6:     sda = AT91_TWI_SDA;
   7: }

Nel caso della board Netduino (generazione 2) che ha un processore STM32, la funzione di lettura dei pin I2C è I2C_Internal_GetPins() (DeviceCode\Targets\Native\STM32\DeviceCode\STM32_I2C\STM32_i2c_functions.cpp).

   1: void I2C_Internal_GetPins(GPIO_PIN& scl, GPIO_PIN& sda)
   2: {
   3:     scl = I2Cx_SCL_Pin;
   4:     sda = I2Cx_SDA_Pin;
   5: }

Conclusione

Il bus I2C a differenza dell’SPI non è ovviamente full duplex essendo caratterizzato da una sola linea dati ed è anche più lento in termini di velocità. Il vantaggio principale è quello di non avere la complessità di un segnale di selezione dello slave e di poter lavorare in modalità multi master.

Il .Net Micro Framework permette di utilizzare questo bus con estrema semplicità con una sola classe ed il concetto di “transazioni” lettura/scrittura I2C in modo da eseguire la comunicazione in un solo “colpo”.

Molto presto vedrete un esempio reale di applicazione di questo bus (come per il bus SPI) con un managed driver che ho sviluppato per un chip NFC della NXP !

Netduino e memoria seriale 24LC256 

Posted by Marco Lai Thursday, January 16, 2014 1:47:00 PM
Rate this Content 0 Votes

Piccolo tutorial sull'uso della memoria EEPROM seriale 24LC256 prodotta da Microchip; tutto i dettagli sl mio sito:

http://www.logicaprogrammabile.it/2014/netduino-impiegare-la-memoria-24lc256/

Page 6 of 38 << < 1 2 3 4 5 6 7 8 9 10 20 > >>