Questo tutorial che ho tenuto durante la conferenza Linux incorporato cerca di rispondere alle domande, fornendo collegamenti a una descrizione più dettagliata degli argomenti affrontati e usando l'esempio pratico di guida di un drone 4WD, in cui un Arduino Mini Pro agisce come slave e controlla le 4 ruote indipendenti . Il documento originale è disponibile qui .
Nota: questa risposta è attualmente in corso di elaborazione, poiché adatterò i punti salienti del collegamento.
Applicazioni tipiche del bus I2C
- Interfacciamento con periferiche relativamente lente. Es: sensori, attuatori meccanici.
Controllo di periferiche "veloci", che utilizzano altri canali per lo scambio di dati. Es: codec.
In un PC, il sistema operativo di solito interagisce su I2C con:
- misuratori di temperatura e voltaggio della batteria;
- regolatori di velocità della ventola;
- codec audio.
Nel caso in cui siano disponibili più controller di bus, le periferiche sono raggruppate per velocità, in modo che quelle più veloci non vengano penalizzate da quelle più lente.
Una rapida introduzione al bus I2C - caratteristiche chiave
- Bus seriale.
- Solo 2 righe: Serial CLock e Serial DAta (più terra).
- 4 velocità: 100kHz, 400kHz, 1MHz, 3.2MHz.
- In genere, 1 dispositivo master e 1 o più slave.
- Le comunicazioni vengono sempre avviate da un dispositivo master.
- Più master possono coesistere sullo stesso bus (multi-master).
- Open-Drain: sia SDA che SCL hanno bisogno di resistori pull-up.
- "Clock Stretching"
- Il master controlla SCL, ma uno slave può tenerlo premuto (perché open drain), se è necessario regolare la velocità.
- Il master deve verificare questo scenario.
- Uno slave può rimanere bloccato e bloccare il bus: necessità di ripristinare le linee dal master allo slave.
- In genere indirizzamento a 7 bit, ma anche 10 bit è supportato.
- Protocollo logico: i livelli di tensione effettivi non sono specificati e dipendono dalle singole implementazioni. Es: 1,8 V / 3,3 V / 5,0 V.
URL di riferimento:
Esempio di configurazione del bus
Caratteristiche del protocollo (semplificato)
- 2 tipi di messaggi: lettura e scrittura
- Bit di avvio / arresto: rappresentato come “[“ e “]” nel resto della risposta
- Indirizzo: 7 o 10 bit
- R / W bit: R = 1 / W = 0 Utilizzato per discriminare il tipo di messaggio inviato.
- Dati sul bus: (Indirizzo << 1 | R / W)
- Registra come gestori delle informazioni, all'interno del dispositivo selezionato.
Esempio di traffico bus
Schiavi personalizzati
Perché creare uno slave I2C personalizzato?
- Sensore / attuatore desiderati non disponibili con interfaccia I2C.
- Indirizzi meno unici disponibili degli schiavi necessari.
- Funzionalità personalizzata desiderata sullo slave:
- Reazioni semi-autonome agli stimoli.
- Filtraggio / preelaborazione dei dati di input.
- Ottimizzazione dell'alimentazione: l'hub sensore personalizzato esegue le pulizie mentre il processore principale è inattivo.
- Risposta in tempo reale agli input.
- [la tua immaginazione qui]
Come progettare uno slave I2C personalizzato?
- Definire i requisiti (vedere la diapositiva precedente).
- Scegli microcontrollore o microprocessore.
- Scegli Scheduler o Sistema operativo (se presente).
- Definire il sub-protocollo di comunicazione:
- Definire parametri e comandi da scambiare.
- Organizzali in "registri" e scegli un indirizzo gratuito.
Progettazione del Master I2C
Criteri di progettazione chiave:
- Peso / Dimensioni.
- Potenza computazionale richiesta e latenza media.
- Dispositivo simile a un PC
- Dispositivo incorporato, in genere senza testa.
- Linguaggio di programmazione preferito: interpretato vs compilato.
- Disponibilità di autobus / gpios per la guida degli schiavi:
- Solo GPIO: bitbang il protocollo
- I2C: applicazione spazio utente vs driver kernel.
- Nessuna interfaccia GPIO / I2C disponibile: adattatore da USB a I2C.
Debugging: Divide and Conquer
Assumi il controllo diretto del bus con un dispositivo ad hoc. Esempi:
BUS Pirate
- Principalmente per scopi di sviluppo.
- Entrambi possono fiutare l'autobus e guidarlo.
- Interfaccia console tramite porta seriale (ttyACM), incluse macro o accesso programmatico per diversi linguaggi di programmazione.
- Resistenze pullup integrate e sorgenti di tensione (5 V / 3,3 V)
- Supporta molti altri protocolli.
- Riferimenti: Wikipedia , pagina principale
Adattatore da USB a I2C
- Piccola impronta.
- Adatto per installazioni permanenti.
- Non sono necessarie connessioni speciali sull'host: può essere utilizzato per interfacciarsi con un PC tipico.
- Variante disponibile che supporta anche SPI.
- Nessuna interfaccia console, solo protocollo binario seriale.
- Richiede il wrapper di protocollo .
- Riferimento: protocollo
sigrok e pulseview
logo sigrok (componente bakend)
esempio pulseview (visualizzatore)
Esempio di analizzatore logico di fascia bassa
- Standard di fatto per le misurazioni basate su PC su Linux (ma disponibile anche su altri sistemi operativi).
- Supporto per una vasta gamma di analizzatori logici, ambiti e misuratori.
- Vari decodificatori di protocollo, incluso I2C.
- Utile per visualizzare i segnali logici e gli errori del protocollo di debug.
- Anche HW di fascia bassa ed economica può fornire una dimensione completamente nuova al debug.
- Riferimenti: sigrok , pulseview , hardware supportato
Esempio: guida di un drone 4WD
Prototipo realizzato con 2 Arduino Mini Pro.
Cosa fa lo schiavo nell'esempio?
Lo slave I2C:
- Controlla la quantità di coppia applicata a ciascuna ruota.
- Controlla la direzione di rotazione di ciascuna ruota.
- Misura la velocità di rotazione di ciascuna ruota attraverso un encoder ottico (odometro).
- Espone i parametri sopra al Master I2C.
Schema a blocchi di alto livello dello slave I2C.
- Perni / funzioni sufficienti da fornire per ogni ruota:
- 1 uscita PWM con configurazione indipendente del duty-cycle.
- 1 GPIO per la registrazione dell'ingresso del contachilometri come IRQ.
- 2 GPIO per la selezione:
- Inoltrare
- Inverso
- Inattivo
- Serratura
- Blocco I2C HW per scambi i2c comandati da interrupt.
- Pin dedicati per la programmazione basata su SPI.
- Piccola impronta.
- A basso costo.
- Il layout della scheda del clone rappresentato nell'immagine è ottimizzato per il montaggio su una presa DIL.
ICD specifico per slave: AVR Dragon
Selezione del sistema operativo: ChibiOS
- RTOS: preemption, compiti, semafori, tic di sistema dinamico, ecc.
- Ingombro ridotto: collega solo codice / dati utilizzati.
- Distinzione tra RTOS e BSP tramite HAL.
- GPLv3 per uso non commerciale.
- Sviluppato attivamente, ma già maturo.
- Supporta 8 bit AVR.
Tuttavia aveva un supporto BSP limitato per AVR, mancanza di: - interrompe il driver per i GPIO AVR (aggiunto). - Supporto I2C per la modalità slave AVR (personalizzato). Che doveva essere sviluppato separatamente come parte del Drone SW per l'AVR .
Definizione dei parametri di comunicazione
Per ogni ruota:
Ciclo di funzionamento del segnale PWM utilizzato per guidarlo - 1 byte. 0xFF = coppia massima / 0x00 = nessuna coppia.
Direzione di rotazione - 1 byte.
- 0x00 = inattivo
- 0x01 = indietro
- 0x02 = avanti
- 0x03 = bloccato
Periodo medio tra gli slot dell'encoder ottico - 2 byte.
- La scrittura di qualcosa ripristina la misurazione.
Indice parametri - 1 nibble:
- 0 = Ciclo di lavoro
- 1 = Direzione
- 2 = Periodo medio
Indici delle ruote - 1 bocconcino:
- 0 = Posteriore sinistro
- 1 = Posteriore destro
- 2 = anteriore destro
- 3 = anteriore sinistro
- 4 = Tutti
Sottoprotocollo: definizione dei registri
Formato registro: 0xαβ
- α = Indice parametri - β = Indice ruota
Indirizzo (scelto arbitrariamente): 0x10
Formato bus pirata:
- [= bit iniziale -] = bit finale - r = byte di lettura - tempi indirizzo 2 (spostamento a sinistra 1), per bit R / W
Esempio: in formato Bus Pirate
[i2c_addr reg_addr = (parm, wheel) reg_value]
[0x20 0x20 0x02] Left Rear Forward
[0x20 0x21 0x01] Right Rear Backward
[0x20 0x22 0x01] Right Front Backward
[0x20 0x23 0x02] Left Front Forward
[0x20 0x14 0xFF] Wheels set to max torque
L'auto gira in senso orario.