Prove su e-Bike

Dopo aver effettuato le prove appena descritte si `e optato per connettere il modulo Wi-Fi con la scheda Renesas presente sull’e-Bike.

6.2.1 Cambio dei pin dei PWM per conflitto con pin di Rx e Tx del Wi-fi

Fin da subito, `e sorto un problema riguardante i pin scelti sul microcontroller per la comunicazione Wi-Fi, ovvero i pin 22 e 23 del JN2, in quanto erano gi`a stati adoperati per connettere i PWM. Quest’ultimi, sono dei segnali ad onda quadra con duty cycle variabile in funzione dell’ampiezza del segnale modulante, necessari per alimentare i motori presenti nel circuito dell’e-Bike. Andando ad analizzare l’implementazione di quest’ultimi, si `e per`o notato che vi erano quat-tro canali disponibili nel quale inizializzare i due segnali; perci`o si `e proceduto a controllare nello Schematics della scheda Renesas che i canali restanti corrispon-dessero a delle porte fisiche dove poter connettere i PWM. I canali rimanenti erano l’1, al quale era associata la porta logica P17 e il 2, con porta logica PJ3; a tali canali corrispondevano rispettivamente il pin 1 del connettore JP17 e il pin 15 del connettore J8. Avendo, perci`o, avuto un riscontro positivo con entrambi i canali, si `e proceduto a connettere i PWM alle porte fisiche appena citate per poter collegare il modulo Wi-Fi e testarne il funzionamento. Dopodich`e, `e stato necessario andare a modificare i canali dove avveniva l’inizializzazione dei PWM nel codice di e2studio. In particolar modo, `e stato assegnato il canale 1 al motore di trazione e il 2 al motore di sterzo. Infine, si `e deciso di segnalare nella funzione PWM Init(unsigned char channel number) nel file PWM.c l’utilizzo delle porte associate ai canali 3 e 4 per la comunicazione Wi-Fi.

6.2.2 Risoluzione del problema pin JN2 della Renesas non funzionanti correttamente

Dopo aver risolto la corrispondenza tra i pin dedicati ai PWM e al modulo Wi-Fi, si `e proceduto con il collegamento di quest’ultimo alla scheda Renen-sas. Tuttavia, si `e riscontrato ancora una volta un mal funzionamento nella comunicazione Wi-Fi; infatti, mentre in ricezione al microcontroller giungeva il comando correttamente e veniva stampata a schermo la stringa corrispon-dente, in trasmissione i dati inviati all’ESP-WROOM-32 o non erano esatti o

non veniva ricevuto alcunch´e. Si `e cos`ı deciso di verificare se ci fosse un qualche conflitto tra la periferica UART e i componenti non ancora analizzati del circuito dell’e-Bike. Dopo aver esaminato quest’ultimi singolarmente, per`o, si `e concluso che non vi erano contrasti come si era ritenuto probabile. Cos`ı, dopo un’attenta riflessione, si `e optato per connettere singolarmente i pin di ricezione e trasmis-sione del JN2 della scheda Renesas ad un oscilloscopio, per analizzarne l’uscita.

Per fare ci`o `e stato necessario inizializzare nuovamente i PWM nei canali usati precedentemente, ovvero il 3 e 4, corrispondenti ai pin interessati del micro-controller Renesas. Da questa analisi, si `e riscontrato che dal pin 22, ovvero il canale di ricezione, si aveva in uscita un segnale ad onda quadra, ovvero il PWM, come richiesto, mentre dal canale di trasmissione non si riscontrava alcunch´e.

Si `e quindi concluso che tale pin non fosse funzionante, perci`o `e stato necessario trovare un’alternativa alla SCI12, ovvero la serial communication interface 12.

La soluzione a tale problema verr`a affrontata nella sezione successiva.

6.2.3 Cambio dell’interfaccia seriale di comunicazione con la SCI6: problema di corto-circuito dei pin risolto poi incidendo nella parte posteriore la scheda Rene-sas

Per trovare un’alternativa alla SCI12, inizialmente, si `e consultato il Man-uale Hardware della scheda Renesas e lo Schematics, per verificare se ci fosse un’ulteriore interfaccia seriale con delle porte fisiche utilizzabili. Si `e trovato che la SCI6 era la periferica pi`u adatta all’esigenze dell’e-Bike, alla quale erano associate le porte logiche P31 e P32. Queste, rispettivamente, corrispondevano alle porte fisiche 24 di ricezione e 21 di trasmissione del connettore J8. Perci`o, si `e deciso di procedere andando a modificare l’implementazione delle funzioni presenti nel file bike uart.c su e2studio, nelle quali veniva utilizzata la SCI12 per sostituirla con la SCI6. Dopodich´e, si sono connessi i pin di Tx e Rx dell’ESP-WROOM-32 secondo la seguente tabella ed sono state eseguite delle prove per verificare il funzionamento di questa seriale.

ESP-WROOM-32 Connettore J8 Scheda Renesas

Pin Rx2 Pin 21

Pin Tx2 Pin 24

Tuttavia, si `e riscontrato anche in questo caso un malfunzionamento. Cos`ı,

`e stato necessario connettere anche tali pin all’oscilloscopio per verificare che fossero effettivamente funzionanti. Da tale analisi si `e riscontrata la presenza di un corto-circuito tra le due porte fisiche utilizzate. Andando ad esaminare i connettori coinvolti con le porte fisiche RXD6 e TXD6, si `e scoperto che nel connettore JP16, nella parte posteriore della scheda Renesas, era presente un corto circuito. Per poterlo rimuovere `e stato necessario incidere la scheda dove indicato dallo Schematics come riportato di seguito.

Dopo aver rimosso il corto circuito, sono stati effettuati ulteriori test per verifi-care se il problema fosse stato risolto, cosa che effettivamente `e avvenuta.

Si `e deciso, inoltre, di lasciare nei commenti l’implementazione del codice su e2studio con la SCI12 perch`e, se in futuro sar`a necessario sostituire la scheda Renensas presente nel circuito dell’e-Bike, sar`a possibile ripristinare il codice con la seriale precedentemente utilizzata.

Chapter 7

Schema a blocchi e funzionale del codice WiFi

In questo capitolo verr`a mostrato lo schema a blocchi e il funzionale del codice Wi-Fi implementato su e2studio, dopo aver eseguito la funzione uart init().

SCI6 RXI6 int split matlab parseCommand

send data bSE

main

T x F LAG CST ART = 1

send data

SCI6 T XI6 int

T X F LAG CST ART = 0

bN D

Dopo aver ricevuto un comando attraverso la comunicazione Wi-Fi, interviene l’interrupt di ricezione, che colloca i dati ricevuti nel buffer di ricezione. Se quest’ultimo `e pieno o si riceve la stringa ”\n” avviene la chiamata alla fun-zione split matlab(), che salva il comando ricevuto nella variabile apposita della struttura Packet. Dopo aver effettuato tale chiamata, si ripulisce il comando ricevuto e la coda di ricezione per la prossima comunicazione, poi si disabilita l’interrupt. Infine, si inizializza nuovamente l’interrupt di ricezione per essere

pronti per la comunicazione successiva.

All’interno di split matlab(), viene chiamata la funzione parse command(), da cui si possono avere due possibili scenari. Se il comando ricevuto `e ”bSE”, ovvero si vuole iniziare la trasmissione dati, inizialmente viene inviata una stringa attraverso la funzione send data() per indicare quali dati si stanno in-oltrando, poi si pone la flag Tx FLAG CSTART a uno. Tale variabile viene richiamata all’interno della CMT nel main, ove nei 100ms, se posta a uno, avviene la trasmissione dei dati attraverso la medesima funzione utilizzata in precedenza. Nel momento in cui avviene la chiamata alla funzione send data, al suo interno viene inizializzato l’interrupt di trasmissione attraverso la inter-rupt tx init(), che viene subito dopo avviato. All’interno di tale interinter-rupt, se la coda non `e vuota, i dati da trasmettere vengono messi nel buffer di trasmissione e sono inoltrati. Dopo aver inviato tutti i dati, si disabilita l’interrupt e viene pulita la coda di trasmissione. Se, invece, il comando ricevuto `e ”bND”, quindi si vuole interrompere la trasmissione dei dati, viene posta la flag Tx FLAG CSTART a zero, cosicch´e nei successivi 100ms della CMT, non venga pi`u trasmessi al-cunch´e.