-
Notifications
You must be signed in to change notification settings - Fork 0
/
doc
38 lines (31 loc) · 3.72 KB
/
doc
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
*** INTRODUZIONE ***
L'applicazione in questione permette l'esecuzione di alcune delle funzionalità proposte dall'ambiente STMCubeID ad utenti che non posseggono alcuna board di casa STM.
E' stato quindi implementato (tramite un pattern architetturale di tipo Client-Server) un meccanismo di comunicazione tra entità che richiedono un servizio ( server ) ed altre che
soddisfano il servizio richiesto ( client ).
*** DESCRIZIONE DEI RUOLI ***
Server : Applicativo che gira sulla macchina di un generico utente che non disponde di una board e che permette l'adempimento di alcune funzionalità altresì impossibili
Le funzionalità proposte sono :
- Ottenere la lista dei client connessi;
- Inviare un messaggio ad uno dei client connessi;
- Effettuare il flash di un programma su una board messa a disposizione da un determinato client remoto;
- Effettura il degub del programma steso sfruttando una board messa a disposizione da un determinato client remoto;
Client : Applicativo che gira su una macchina alla quale è collegata una board specifica e che è capace di soddisfare le richieste da parte di un server
*** FUNZIONAMENTO ***
Per il corretto funzionamento , l'applicativo server viene startato su un determinato porto e rimane in attesa di connessioni da parte di uno o più client identificati da un ID univoco.
Una volta che uno o più applicativi client sono messi in esecuzione ,selezionano la STMicroelectronics STLink Virtual COM Port tra quelle disponibili ,inseriscono un nome ed il tipo di board che mettono a disposizione.
Successivamente avviene la connessione al server che può quindi usufruire delle board da remoto.
Vi sono più scenari che vengono gestiti come di seguito:
SCENARIO_0 : generico utente (lato server) vuole conoscere la lista dei client connessi
- Viene restituita la lista di tutti i client connessi in modo che il server ha la possibilità di scegliere colui che sarà in grado di soddisfare la richiesta
SCENARIO_1 : generico utente (lato server) vuole inviare un messaggio al client per fornire un'informazione di qualsiasi tipo.
- Il server inserisce prima l'ID del client con la quale vuole comunicare e successivamente il messaggio in questione
- Il client riceve il messaggio inviato e reagisce di conseguenza
SCENARIO_2: generico utente (lato server) scrive un programma tramite per una determinata board ma non ha la possibilità di flasharlo non avendo la scheda in questione.
- Il server una volta scritto e buildato il programma , otterà come output dall'IDE un file con estenzione '.elf' che sarà poi utilizzato da quest'ultimo per operazioni di flash.
A tal punto il server inserisce ed invia la path di tale file che servirà al client per effettuare l'operazione richiesta.
- Il client , una volta ricevuto correttamente il file .elf lo salverà in una cartella denominata "received" (precondizione per il funzionamento è che la cartella sia già creata).
Successivamente tramite l'utility tool software STM32CubeProgrammer il client aprirà un cmd lanciando l'eseguibile STM32_Programmer_CLI.exe che preso in input il .elf ricevuto permetterà
l'adempimento dell'operazione di flash richiesta dal server.
SCENARIO_3: generico utente (lato server) scrive un programma per una determinata board ma non ha la possibilità di effettuare un debug non avendo la scheda in questione.
- Il server una volta scritto il programma che ha intenzione di debbugare da remoto, inserirà l'ID del client da invocare e successivamente il porto per connettersi al GDB Server remoto.
Dall'IDE locale nella sezione "debug configuration" selezionerà quindi l'indirizzo IP del client ed il rispettivo port number.