Integrazione Nucleo↔Driver-Board

[giuseppe-caliaro]

In questa issue discuterò l'integrazione della Nucleo stm32 F767ZI con la driver-board del Pioneer 3DX, inizalmente dal punto di vista elettrico/alimentazione, e succcesivamente dal punto di vista della gestione dei segnali (PWM per controllo motori, lettura encoder, pulsanti ecc.)

• Alimentazione
  Da User manual STM32 Nucleo-144 boards Pag. 22:

Come descritto la Nucleo può essere alimentata in tre modi differenti, Vin, E5V e 3.3V, tutti con un loro range di tensioni tollerate e un limite di assorbimento di corrente.

Essendo la driver-board del Pioneer alimentata a 5V, utilizzati della circuiteria di controllo dei motori, encoder, sensore di temperatura e per l'interfacciamento con la MCU proprietaria, e 12V per alimentare i due motori DC, credo che sia corretto supporre che utilizzeremo la modalità E5V per alimentare la Nucleo.
Questo implica come specificato dal manuale nel settare corretamente il jumper di JP3 per selezionare l'alimentazione corretta, e rimuovere il jumer di JP1 per eliminare il limite di 100mA di assorbimento di corrente.

Come mostrato nella figura sottostante la driver-board fornisce i 5V per alimentare la MCU attraverso il connettore J13, mentre lato MCU proprietaria il connettore è collegato a J22

Il pinout del connettore J13 è il seguente:

Di questi pin solo i pin 1,2,3 raggiungono l'MCU proprietaria.
Oltre ai 5V, il connettore J13 fornisce 12V , i quali sono utilizzati dallo User Control Panel, attraverso il connettore J11 (come si vede sopra in figura), per l'array di Sonar e vari componenti ausiliari come Joystick e giroscopio.

Fammi sapere se l'analisi relativa all'alimentazione della Nucleo è secondo te corretta.

[giuseppe-caliaro]

Condivido inoltre una sequenza definita mandatory:

Spiega quali siano i passaggi per alimentare esternamente la Nucleo e avere comunque la possibilità di flashare o debuggare attraverso l'USB di debug, evitando di riscontrare i problemi descritti nell'immagine sopra.

[jack23247]

Mi sembra tutto OK. Nella pratica la cosa è ancora più semplice (lo configuri una volta e poi funziona)

[giuseppe-caliaro]

Intendi la questione jumper JP3? In tal caso sì ho fatto qualche esperimento alimentando la Nucleo esternamente ed è molto semplice

[giuseppe-caliaro]

- PWM e direzione motori
Al fine di controllare i motori del Pioneer, come abbiamo discusso nella issue dedicata all'IC TD340, la Nucleo deve generare 4 segnali:

1. PWM motore sinistro
2. PWM motore destro
3. Segnale HIGH/LOW per direzione motore sinistro
4. Segnale HIGH/LOW per direzione motore destro

La famiglia STM32F7, alla quale appartiene la nostra Nucleo, fornisce diversi timer per la gestione del segnale PWM, in particolare fornisce quattro timer General purpose: TIM3 e TIM4 a 16 bit, e TIM2 e TIM5 a 32 bit, come mostrato in figura;

Da datasheet dell'IC TD340, la frequenza massima con la quale è in grado di commutare il segnale è di 25KhZ.
Credo quindi che possiamo optare per l'utilizzo dei timer TIM3 e TIM4 a 16 bit e ottenere comunque una risoluzione più che sufficiente in termini di sottolivelli. (Esempio potrei impostare ad 1 il prescaler, quindi utilizzare senza divisori direttamente la frequenza massima del clock del sistema ottenendo addirittura 3839 sottolivelli, quindi penso che 16 bit siano più che sufficienti per un controllo preciso dei motori).

Posso quindi impostare il pin GPIO PA6 come TIM3_CH1 (PWM Generation Channel 1 attraverso il timer TIM3) e PD12 come TIM4_CH1 (PWM Generation Channel 1 attraverso il timer TIM4).
Questi due segnali permettono quindi di controllare la velocità del motore di destra e del motore di sinistra del Pioneer.

---

Per quanto riguarda la gestione della direzione dei motori, l'IC TD340 richiede come detto prima un segnale per motore.
Il valore di questo segnale deve essere HIGH o LOW e determina il senso di rotazione del motore.
A questo scopo penso che possiamo utilizzare due pin GPIO qualsiasi, magari tenendo conto semplicemente di non utilizzare dei pin GPIO che possono implementare Alternate Function particolari, così da evitare di utilizzare inutilmente un pin GPIO con funzionalità avanzate per un semplice toggle.

---

Fammi sapere se questa analisi ti sembra corretta così procedo oltre.

[giuseppe-caliaro]

Ho appena testato il timer TIM3 pilotando un led utilizzando la PWM e funziona tutto correttamente, sia alimentato da usb che alimentato esternamente.

Questione aperta:
La nucleo fornisce in uscita dai pin GPIO una tensione massima di 3.3V.
L'IC si aspetta dei segnali con valori compresi tra 0V e 5V, sia per quanto riguarda la velocità, quindi PWM, che la direzione (HIGH e LOW).
Dobbiamo gestire la differenza di livello logico tra la Nucleo (3.3V) e la driver-board (5V) tramite un circuito di adattamento, per assicurare la compatibilità dei segnali.

Ora procedo con l'interfacciamento degli encoder dei motori e la Nucleo.

[giuseppe-caliaro]

---

• Encoder

La driver-board del Pioneer P3DX offre due encoder ottici a quadratura (uno per motore), i quali generano sulle loro uscite due segnali A e B, cioè due onde quadre sfasate di 90°.
Questi segnali sono inviati al microcontrollore, il quale dopo averli processati, è in grado di stabilire velocità/rotazione/direzione/distanza percorsa ecc. .

La Nucleo offre una modalità specifica per gestire i segnali di encoding, l'Encoder Mode, la quale è implementata attraverso l'utilizzo di timer opportunamente configurati.

Supponendo di utilizzare come detto prima TIM3 (PA6) e TIM4 (PD12) per i segnali PWM, potremmo utilizzare TIM1 e TIM2, i quali sono rispettivamente Advanced Timer e General Purpose Timer a 16 bit, per gestire gli encoder.
Al fine di gestire i due canali forniti da ciascun encoder, una volta configurati i timer sopracitati in Encoder Mode, vengono riservati automaticamente due pin GPIO per timer.
Per TIM1 vengono riservati i pin GPIO PE9 e PE11, mentre per TIM2 vengono riservati i pin GPIO PA0 e PA1.

---

Come per la gestione della PWM, anche per gli encoders si solleva il problema della compatibilità elettrica tra la Nucleo e la driver-board. La driver-board fornisce segnali di encoding a 5V mentre la Nucleo lavora a 3.3V.
Potremmo quindi, come proposto per i segnali PWM in output, studiare una circuiteria che ci permetta di gestire questi segnali in input.
Tuttavia come spiegato nella documentazione che allego sotto, molte famiglie delle board STM sono 5V tolerant sui pin di I/O, la famiglia F7 alla quale appartiene la nostra Nucleo è 5V tolerant.

Chiedo quindi se sia necessario applicare una circuiteria al fine di abbassare il livello di tensione dei segnali di encoding, ad esempio con un level shifter, per poterli gestire in sicurezza, oppure dato che la Nucleo in questione è 5V tolerant, possiamo evitare di gestire questa cosa.

[giuseppe-caliaro]

Intanto confermo che da datasheet PE9 e PE11, e PA0 e PA1 sono 5V tolerant, nella colonna I/O Structure FT significa 5V tolerant:

PE9/PE11

PA1

PA0

[jack23247]

• Ottima analisi. Per i pin puoi guardare il firmware scritto da Federica per Otto che trovi sul GitHub di IRALab per vedere che pin ha usato lei all'epoca
• Per passare a 3v3 a segnali TTL possiamo usare un level-shifter che ci fa anche da buffer

[jack23247]

Per gli input non lo so. Usare un level-shifter è problematico perché potrebbe distorcere il segnale che arriva dagli encoder in maniera troppo significativa.

[giuseppe-caliaro]

Guardando il firmware di Federica noto che:

• Utilizza due canali dello stesso timer per generare il segnale PWM (TIM4, CH1 attraverso il pin PD12, CH2 attraverso il pin PD13).

• Per quanto riguarda gli encoder utilizza TIM2 e TIM5 in modalità Encoder, riservando automaticamente CH1 e CH2 attraverso i pin PA0 e PA1 per TIM5 e PA5 e PB3 per TIM2

• Per quanto riguarda la direzione utilizza PF12 e PF13 in modalità GPIO Output

[giuseppe-caliaro]

Per quanto riguarda l'incompatibilità dei segnali output di direzione e PWM con la driver-board del Pioneer potremmo utilizzare un Logic Level Shifter come quello mostrato in figura:

[giuseppe-caliaro]

Analizzando il percorso che i segnali seguono dal connettore Motors presente sulla MCU proprietaria noto che:

• I segnali di PWM e Direzione provenienti dal processore prima di arrivare al connettore ed essere trasmessi alla driver-board passano attraverso ad un HCT541.
  HCT541 è un buffer non invertente, il quale ha il compito di ripetere i segnali in uscita, amplificandone la corrente e isolando unidirezionalmente la MCU (quindi anche proteggendola) dalla driver board.
• I segnali di Encoding (lo stesso vale per i segnali provenienti dai sensori di prossimità) provengono invece dal connettore e prima di arrivare al processore passano attraverso un LVC541A.
  L' LCC541A, come l'HCT541 è un buffer, con la differenza che opera con tensioni di uscita minori. Questo perchè i progettisti della MCU-board del Pioneer hanno dovuto interfacciarsi con due tensioni differenti (come noi), quella dei segnali di encoding a 5V e quella dei pin del processore a 3.3V (difatti sono presenti due regolatori di tensione LT1086 sulla MCU-board, uno per alimentare il processore, l'altro per alimentare i due integrati LVC541A, uno per i segnali di encoding l'altro per i sensori di prossimità).

Penso quindi che i due integrati sopra descritti, l'HCT541 e il LVC541A possano essere una soluzione concreta anche per il nostro problema di interfacciamento.

Cosa ne pensi? I due integrati, alimentati rispettivamente a 5V l'integrato che gestisce direzione e PWM e 3v3 l'integrato che gestisce i segnali di encoding, sono quindi dei Level Shifter che possiamo utilizzare?

[giuseppe-caliaro]

Assumendo che il ragionamento relativo agli integrati che ho descritto precedentemente sia corretto, ho fatto una prima bozza di come collegherei la Nucleo e la driver-board attraverso la board di interfaccia:

Qualche considerazione:

• Devo assicurarmi di cortocircuitare a GND i segnali di Enable degli integrati HCT541 e LVC541A al fine di attivarne le uscite.

• LVC541A assorbe corrente nell'ordine delle decine di mA, quindi penso che la Nucleo riesca a gestirle. Possiamo comunque con un regolatore di tensione abbassare i 5V provenienti dalla driver-board a 3v3 e alimentare direttamente l'integrato, evitando così di sovraccaricare inutilmente la Nucleo. Lo schema in questione è infatti quello consigliato da datasheet:
  

• Da datasheet viene raccomandato di mettere a GND tutti i pin non utilizzati:
  

• Utilizzare un bypass capacitor per il pin di Vcc per evitare dei disturbi dell'alimentazione: Each VCC pin should have a good bypass capacitor to prevent power disturbance. For devices with a single supply, 0.1 μf is recommended;

[giuseppe-caliaro]

Per quanto riguarda la questione latenza introdotta dai buffer, da datasheet l'IC HCT541 introduce un ritardo tipico di 12 ns, mentre l'IC LVC541A introduce un ritardo massimo di 5.1 ns.

[jack23247]

Ok, come vedi l'integrato migliore è stato usato per gli encoder perché sono più sensibili alla latenza. Controlla anche la tensione max che possono fornire i due IC