Suggerimento per interfaccia web <--> microcontroller

[boiler]

Ciao a tutti

Ho un mezzo progetto per la testa, e mi servirebbe qualcosa con una discreta capacità di calcolo e soprattutto con un'interfaccia grafica comoda.

Visto che ormai lo smartphone, tablet o PC ce l'abbiamo ovunque, avrei pensato di scaricare la complessità dell'interfaccia grafica su un'applicazione web.

Lo schema di principio potrebbe essere questo:

Sorgente FidoCadJ | Ingrandisci | Cos'è Fidocad

Sul Raspberry Pi dovrei avere un webserver che mette a disposizione una pagina sulla quale si trova l'interfaccia grafica. Qui l'utente può leggere valori, può settare parametri, può avviare funzioni premendo un pulsante.

Oltre al webserver servirà l'applicazione che gestisce questi dati e li sincronizza con il microcontroller (via USB).

Le due applicazioni possono essere in realtà un'applicazione sola, se questo ha senso.
Oppure possono comunicare in qualche modo (named pipe, database... sono aperto piú o meno a tutto).

Mi trovo a mio agio con C#, maneggio il C/C++ (ma piuttosto per roba embedded) e mio malgrado capisco qualcosa di Python. HTML, PHP, Javascript: il minimo sindacale.
Non conosco Java.

Tra tutto quello che c'è sul mercato, avete una piattaforma/soluzione/framework che vi sentite di raccomandarmi?

Stavo pensando a WASM che poi comunica via un socket con l'applicazione sul RPi, ma mi sembra macchinoso e poco efficiente. Sono sicuro che nel 2025 c'è qualcosa di meglio

Saluti Boiler

P.S.: sto pensando a qualcosa come Grafana, soprattutto per quel che riguarda la facilità di configurazione. Ma dovrebbe essere bidirezionale, deve anche poter scrivere, non solo di leggere.

[fairyvilje]

Come puoi ben immaginare, ci sono infiniti approcci possibili per quello che vuoi fare .
Ho giusto un paio di domande che vorrei fare per meglio informare la strategia:

• Hai intenzione di supportare multipli front-end, quindi potenzialmente più client, possibilmente includendo una UI locale su raspberry? Costa poco permetterlo dall'inizio, molto più difficile adattare software in seguito per soddisfare il requisito.
• Ti fidi del client, della connessione col raspberry, e della sua capacità di implementare parti della logica?

-

[fairyvilje]

Questo comunque è il mio modo standard per affrontare questa classe di problemi.

Il database è un servizio locale, eseguito sul raspberry, e viene esposto direttamente alla/e UI, ma con permessi e view che limitano lo scope delle mutazioni e la generale visibilità. Volendo esistono anche wrapper REST per database come postgres (postREST se non ricordo male) che risultano molto comodi se il consumatore è un'applicazione web.
Dovrebbero esserci soluzioni simili per sqlite che forse è più indicato in questo caso.

Il programma di controllo che si interfaccia col resto della parte embedded espone messaggi e riceve comandi su una unix domain socket.
Un thin-wrapper attorno alla UDS la inoltra come websocket.

Il client infine, è una SPA (Single Page Application) in Blazor/Svelte/whatever che si connette via websocket al servizio offerto dal raspberry (ed al database chiaramente con autenticazione e permissions) per presentare UI e funzionalità di front end.

UI locali sul raspberry possono direttamente fare uso dello UDS, mentre quelle remote passano dal layer websocket che realisticamente gestisce anche i processi autenticazione su un altro endpoint.

[boiler]

Come puoi ben immaginare, ci sono infiniti approcci possibili per quello che vuoi fare .

Certo, ed è questo il motivo per cui ho chiesto. Google qui non basta

Hai intenzione di supportare multipli front-end, quindi potenzialmente più client, possibilmente includendo una UI locale su raspberry? Costa poco permetterlo dall'inizio, molto più difficile adattare software in seguito per soddisfare il requisito.

Non è necessario. Serve un front-end solo (nel senso di utenti connessi contemporaneamente).
Se però mi dici che non costa molto, sarebbe probabilmente sciocco non prevedere questa opzione.

Ti fidi del client, della connessione col raspberry, e della sua capacità di implementare parti della logica?

Non ho ben capito cosa intendi.
Mi fido della connessione, nel senso che non serve autenticare il collegamento. Non servono certificati SSL e non serve login.

Se con fidarsi invece tu intendi l'affidabilità del collegamento, se si perde la connessione con il browser non succede nulla di grave. Lo stato del sistema pensavo comunque di gestirlo sul microcontroller.

La business-logic che serve sul raspberry è di questo tipo:
- leggi i dati dal microcontroller
- prendi delle decisioni in base ad un algoritmo definito via UI (probabilmente uno script in Lua)
- scrivi i dati modificati sul microcontroller
Dovrebbe essere sufficientemente leggera.

Boiler

[boiler]

Grazie mille per l'intervento. Mi studio i sistemi che hai citato nel secondo messaggio e vedo cosa riesco a combinare

Boiler

[fairyvilje]

Non è necessario. Serve un front-end solo (nel senso di utenti connessi contemporaneamente).

Non intendevo single-user/multi-user, quello è un problema correlato che sicuramente ha senso considerare, ma riguarda più che altro la gestione dei permessi e delle risorse non condivisibili.

Mi riferivo all'idea che tutto ciò che hai sul raspberry sia agnostico (o meno) nei confronti del client o dei client in uso. Ci sono architetture dove il server espone un'interfaccia pubblica molto pulita e poi sta ai client gestire tutto il resto. Altre dove c'è una concorrenza fra i due.

Il costo nell'implementare la prima soluzione è leggermente più alto in fase di progettazione, perché devi pensare a cosa vuoi dare ai client in anticipo, senza delegare al momento che implementi quella specifica feature. Parlo di che views rendere pubbliche, che formato regolare i messaggi su UDS debbano avere etc. Ma è estremamente più sostenibile sul lungo periodo.
Nel secondo scenario, non hai un'interfaccia chiara fra server e client (o meglio, è fluida in base a come ogni nuova funzionalità viene implementata). Qualcuno (me) direbbe "bad engineering" . Ma per mettere in piedi un rapido prototipo non è la fine del mondo, o questa è la scusa generalmente usata. Poi diventa permanente .
Il client in questo secondo caso è molto meno standalone o flessibile, visto che molto del processing e della generazione dell'XML/HTML/JSON per presentazione viene fatto sul raspberry.

Se con fidarsi invece tu intendi l'affidabilità del collegamento, se si perde la connessione con il browser non succede nulla di grave. Lo stato del sistema pensavo comunque di gestirlo sul microcontroller.

La domanda riguardava un po' tutto; al di là dei certificati che sono "banali" da integrare, mi riferivo a:

- Cosa accade se il raspberry resta senza testa perché la connessione salta.
- Cosa accade se il client è compromesso da un attore terzo e che rischi pone.

Ma da quello che dici entrambe le casistiche non sono un problema.
Ed il fatto che parli di script lua mi fa pensare che non stai esattamente realizzando un'applicazione con requisiti strict real-time su lato raspberry.

La mia lista è molto leggera in dettagli, non farti problemi a chiedere servissero chiarimenti .

[daniele1996]

Mi si è presentata anche a me questa tipologia di problematica, non volendo adattare o scrivere programmi su diversi linguaggi di programmazione e avendo esigenze particolari di calcolo, ho optato per scrivere da zero un webserver in C : N task in attesa di accettazione di connessione con ognuno la propria area di memoria, processi avviabili con ognuno la propria area di gestione, le pagine su librerie dinamiche (Li chiamo "plugin") e un area riservata alla gestione del server, ci ho fatto l'esame di sistemi operativi... implementare l'HTTP non è difficile, diventa più complicato se necessiti dell'HTTPS (cosa che probabilmente tra qualche anno dovrò fare). L'unica cosa un po più complicata è saper come realizzare le strutture dati: Quanta memoria dare per le stringhe dei cookie, dati passati tramite metodi GET/POST, quanta memoria allocare per la ricezione dell'intera richiesta: riceverla per intero o divisa in parti e comporre il blocco dati?, dove applicare le shared memory (che vanno anche loro identificate sul processo padre perché dipende com'è vanno chiuse)...Sicuramente lo step successivo sarà implementare il multiserver... Ho fatto la prova a farlo funzionare su un raspberry pi zero w, ma sicuramente è meglio farlo funzionare su degli xeon. Se non hai grandi necessità sulle funzionalità di gestione come già detto un piccolo webserver in C non è molto difficile, poi a questo ci agganci gli algoritmi che ti servono per far funzionare il programma del micro. Una cosa su cui stare attenti è che più diventano grandi le necessità del programma che necessita interfaccia grafica, più crescono le esigenze di gestione. Io l'ho trovato il metodo più semplice e veloce rispetto al dovermi trovare la soluzione "più comoda" tra le soluzioni disponibili su internet...

[fairyvilje]

Ma perché? Possi capire il valore educativo o ricreativo di scriversi un webserver in C da zero...
Ma credo che boiler sia interessato a mettere in piedi un'applicazione funzionante, non perdere i prossimi 20 anni a reimplementare parte del network stack .
Ci sono librerie già fatte, ed onestamente C non è il linguaggio più adeguato allo scopo.

Stiamo parlando un raspberry pi, dove hai tutto il potere computazione e tutto lo spazio in memoria per tenere i piedi una distribuzione moderna completa con sessione grafica. Anche implementando un server in typescript/javascript via node o bun, non si arriva nemmeno lontanamente vicini a saturare le risorse.
Sulla scrivania in questo momento ho un SBC con 64MB di memoria e due core riscv che un raspberry pi 5 a confronto è un supercomputer. Un semplice server HTTP/WS scritto in typescript ed eseguito con bun riesce a servire qualche migliaio di connessioni attive contemporaneamente, e solo perché ho fermato i test arrivato a quel punto.

[boiler]

Mi riferivo all'idea che tutto ciò che hai sul raspberry sia agnostico

Ah, direi proprio di sì!

La mia lista è molto leggera in dettagli, non farti problemi a chiedere servissero chiarimenti .

Come sempre gentilissimo!
Grazie, preferisco porre le domande man mano che saltano fuori, invece che abusare del tuo tempo parlando di cose che forse poi non verranno realizzate

Ieri sera ho giocato un po' con Blazor, che non conoscevo. Mi sembra piuttosto facile da usare e dovrebbe funzionare. Grazie per l'indicazione.

Una domanda concreta però ce l'avrei:

Un thin-wrapper attorno alla UDS la inoltra come websocket.

Usi qualcosa off-the-shelf o l'hai scritto tu? Nel primo caso, se mi puoi indicare qualcosa te ne sarei grato.


@ daniele1996: grazie, ma no grazie

Boiler

[EnricoMigliore]

Ciao,

Ciao a tutti
Sul Raspberry Pi dovrei avere un webserver....

Io userei Apache.

Oltre al webserver servirà l'applicazione che gestisce questi dati e li sincronizza con il microcontroller (via USB).

Le due applicazioni possono essere in realtà un'applicazione sola, se questo ha senso.
Oppure possono comunicare in qualche modo (named pipe, database... sono aperto piú o meno a tutto).

Mi trovo a mio agio con C#, maneggio il C/C++ (ma piuttosto per roba embedded) e mio malgrado capisco qualcosa di Python. HTML, PHP, Javascript: il minimo sindacale.
Non conosco Java.

Tra tutto quello che c'è sul mercato, avete una piattaforma/soluzione/framework che vi sentite di raccomandarmi?

Stavo pensando a WASM che poi comunica via un socket con l'applicazione sul RPi, ma mi sembra macchinoso e poco efficiente. Sono sicuro che nel 2025 c'è qualcosa di meglio

Saluti Boiler

P.S.: sto pensando a qualcosa come Grafana, soprattutto per quel che riguarda la facilità di configurazione. Ma dovrebbe essere bidirezionale, deve anche poter scrivere, non solo di leggere.

Per quanto riguarda la web application lato client io userei uno di questi 3 stack:

HTML/CSS/Javascript

HTML/CSS/WASM/C

HTML/CSS/WASM/C#

Per quanto riguarda la web application lato server puoi scegliere tra i diversi moduli di Apache.

----

Se lato server hai un DB allora puoi anche NON usare i moduli Apache e accedere al DB direttamente da Javascript/C/C#

I tempi di sviluppo sono legati al debugging.

Ti consiglio di fare un reposistorio pubblico su GitHub e farti aiutare da ChatGPT Pro sia per la generazione del codice dell'applicazione che del codice delle funzioni di test.

ChatGPT ha accesso anche ai repositori GitHub locali o remoti.