È disponibile su GitHub SLX Serial Check, il nuovo progetto Silicon LogiX per eseguire collaudi seriali ripetibili su schede elettroniche e dispositivi embedded. L’applicazione desktop invia sequenze di comandi, verifica le risposte rispetto a criteri definiti e conserva risultati, tempi e traffico di comunicazione in un archivio locale.
Il software è sviluppato con React, TypeScript, Rust e Tauri 2 ed è distribuito in pacchetti per Windows e Linux. Il progetto mostra come integriamo interfacce realizzate con tecnologie web, servizi nativi e comunicazione con l’hardware: dalla configurazione della prova alla gestione degli errori, fino all’esportazione delle evidenze.
Dal controllo manuale a una procedura di collaudo ripetibile
Durante lo sviluppo di un prodotto elettronico, molte verifiche passano da una porta seriale: controllare la versione del firmware, inviare un comando, leggere un valore o verificare una risposta diagnostica. Ripetere queste operazioni a mano richiede di mantenere allineati comandi, soglie, tempi di attesa e annotazioni per ogni scheda.
SLX Serial Check permette di descrivere questa procedura in una sequenza di test riutilizzabile. L’operatore seleziona la porta, identifica scheda e postazione, carica la sequenza e avvia l’esecuzione. Ogni comando ha il proprio criterio di accettazione e produce un risultato consultabile. Questo flusso è utile per verifiche di laboratorio, confronto tra revisioni firmware e preparazione di procedure di collaudo specifiche per un prodotto.
Sequenze configurabili: testo, HEX e limiti numerici
L’editor organizza i comandi nell’ordine di esecuzione e consente di impostare risposta attesa, timeout, pausa prima dell’invio e numero di ripetizioni. Un comando può essere disabilitato mantenendone la configurazione, oppure provato singolarmente prima di avviare l’intera sequenza.
Sono supportati comandi testuali e pacchetti binari in formato HEX. Le risposte testuali possono essere verificate con un confronto esatto, la presenza di una stringa, un’espressione regolare o un intervallo numerico. Per i pacchetti binari si possono confrontare i byte attesi e definire una lunghezza precisa della risposta.
Gli esempi inclusi nella repository rendono concreto il funzionamento: inviare PING e attendere PONG, verificare il formato della versione firmware o estrarre dalla risposta a VOUT? un valore compreso tra 4,9 e 5,1 V. In quest’ultimo caso il software valuta il valore comunicato dal dispositivo. L’esempio HEX invia AA 01 55 e verifica una risposta di quattro byte.
Biblioteca delle sequenze e gestione delle revisioni
Le procedure vengono salvate con nome e revisione in una biblioteca locale. Il formato JSON consente di importarle, esportarle e consultarle anche al di fuori dell’applicazione. Una copia salvata conserva la configurazione della sequenza; le modifiche successive diventano parte della voce di biblioteca quando l’operatore le salva esplicitamente.
Cambiando nome o revisione si crea una nuova voce, conservando la precedente. Il software segnala le modifiche non salvate e chiede conferma prima di sostituire il lavoro corrente. Per chi prepara procedure destinate a più prodotti, queste funzioni aiutano a organizzare le varianti e a riconoscere quale configurazione si sta utilizzando.
Esecuzione, tempi di risposta e gestione degli errori
La sequenza completa viene validata prima di inviare dati alla scheda. Il motore mantiene una sola connessione seriale per l’intera esecuzione e gestisce sia la ripetizione del singolo comando sia più cicli della procedura. Baud rate, bit dati, parità, bit di stop e modalità di delimitazione delle risposte fanno parte della configurazione.
Durante il test, l’interfaccia mostra avanzamento, ciclo corrente, traffico trasmesso e ricevuto ed esiti delle verifiche. Una risposta fuori criterio può interrompere il flusso secondo l’opzione scelta dall’operatore. Timeout, errori di comunicazione, dati non validi e annullamento arrestano la sequenza, distinguendo i controlli falliti da quelli non eseguiti.
L’arresto richiesto dall’operatore conserva le evidenze disponibili e impedisce l’avvio dei cicli successivi. Anche la chiusura dell’applicazione durante una prova gestisce annullamento e salvataggio prima di terminare. I tempi misurati descrivono l’esecuzione sul sistema desktop e servono a confrontare il comportamento osservato nelle prove.
React e TypeScript per l’interfaccia operatore
L’interfaccia è realizzata con React e suddivisa in tre aree operative: Test Bench per connessione ed esecuzione, Sequences per preparare le procedure e Results per consultare lo storico. Componenti dedicati gestiscono editor dei comandi, stato della connessione, avanzamento, finestre di conferma e dettagli dei risultati.
La logica dell’interfaccia è organizzata in hook React separati per esecuzione, biblioteca e archivio. Il gestore della prova in corso segue gli stati di avvio, esecuzione, attesa e arresto, mantiene la configurazione usata dalla prova e scarta eventi tardivi appartenenti a una precedente esecuzione. Sono scelte che rendono esplicito il ciclo di vita delle operazioni asincrone.
TypeScript definisce le strutture di sequenze, richieste, eventi e report, aiutando a mantenere coerente il codice che li utilizza. La verifica statica dei tipi si affianca alla validazione dei dati nel motore nativo. Vite gestisce sviluppo e build del frontend: lo stesso codice dell’interfaccia può essere esplorato in un’anteprima browser, mentre l’esecuzione sulla porta seriale avviene nell’applicazione desktop.
Rust per comunicazione seriale e logica di collaudo
Il cuore del software è un motore Rust indipendente dall’interfaccia, organizzato nella libreria serialcheck-core. Moduli distinti gestiscono modello dei profili, accesso seriale, esecuzione, codifica dei comandi, valutazione delle risposte ed esportazione dei risultati. La separazione consente di verificare il comportamento delle sequenze senza avviare la GUI.
Il motore affronta aspetti concreti della comunicazione: letture parziali, risposte ricevute in più frammenti, terminatori di messaggio, lunghezza dei pacchetti e scadenze di ricezione. I servizi desktop eseguono la prova in un’attività separata dall’interfaccia e controllano che ci sia una sola esecuzione attiva. Una richiesta di annullamento viene controllata durante gli scambi e le pause.
Questa architettura documentata nella repository rende visibili le competenze di sviluppo in Rust applicate a I/O, gestione dello stato, concorrenza e trattamento degli errori. Il codice della procedura resta distinto dai servizi che mostrano gli eventi e conservano i dati.
Tauri 2: tecnologie web e servizi nativi nello stesso desktop
Tauri 2 collega il frontend React ai servizi Rust attraverso comandi nativi e canali di eventi. L’interfaccia richiede l’elenco delle porte, avvia o interrompe una prova e consulta lo storico; il backend accede alla seriale e al filesystem e comunica l’avanzamento. Le responsabilità dei due livelli sono esplicite anche nel modulo di comunicazione frontend-backend.
Il risultato è un’applicazione desktop che usa tecnologie web per la presentazione e servizi nativi per le operazioni sul dispositivo. Sequenze, storico e guida rapida restano disponibili localmente, e l’avvio non richiede una connessione Internet. È un’impostazione adatta a strumenti tecnici che devono lavorare sulla postazione dell’operatore e comunicare direttamente con l’hardware.
Risultati tracciabili e collegamento a SLX Test Report
Ogni esecuzione conserva numero di serie della scheda, operatore, postazione, identificativo della prova, configurazione effettiva, risposte ed esiti. L’impronta SHA-256 del profilo effettivo identifica la configurazione utilizzata. Il registro TX/RX conserva i dati trasmessi e ricevuti, con rappresentazioni testuali ed esadecimali e riferimenti temporali.
Lo storico può essere cercato e filtrato per data ed esito, con dettagli per ciclo e singolo controllo. L’esportazione comprende CSV, JSON e JSONL: il CSV raccoglie i risultati, il JSON contiene il report completo e il JSONL conserva il flusso degli eventi. Gli stati distinguono prove superate, fallite, errori, annullamenti e controlli saltati.
Il salvataggio è parte del flusso di esecuzione: gli eventi vengono registrati prima di essere comunicati all’interfaccia, e un errore nella scrittura del log interrompe la prova. I file finali vengono completati tramite scritture temporanee. Questo comportamento aiuta a mantenere collegati risultato mostrato ed evidenze conservate.
Il CSV è compatibile con SLX Test Report, il nostro software per report PDF di collaudo. I due progetti coprono quindi passaggi consecutivi: Serial Check esegue i controlli e raccoglie i risultati; Test Report importa il CSV, analizza le misure e genera il documento PDF. Il formato delle evidenze è descritto nella documentazione.
Test automatici e pacchetti per Windows e Linux
La repository comprende test TypeScript con Vitest e test Rust per validazione dei profili, revisioni salvate, risposte frammentate, pacchetti binari, timeout, annullamento ed esportazione CSV. Su Linux un test di integrazione usa uno pseudoterminale del sistema operativo per esercitare il driver seriale con uno scambio controllato.
Il workflow GitHub Actions configura controlli su Windows e Linux: analisi del codice, verifica dei tipi, formattazione, test, compilazione e verifica dei pacchetti. Include inoltre controlli di avvio degli archivi Linux in ambienti Ubuntu 22.04 e Debian 12 senza WebKitGTK preinstallato.
La distribuzione cura anche le dipendenze necessarie all’utente: Windows include il proprio runtime WebView2 e Linux le librerie applicative previste dal pacchetto. Sulla postazione di utilizzo non occorre installare Node.js o Rust. La documentazione di build e packaging descrive preparazione degli archivi, controlli delle dipendenze e verifiche di avvio.
Come scaricare e provare SLX Serial Check
La release v0.3.1 mette a disposizione pacchetti x64 per Windows 10/11 e Linux con ambiente grafico, Ubuntu 22.04+ o Debian 12+, insieme alle impronte SHA-256 degli archivi. Dopo aver estratto l’intera cartella, si avvia l’eseguibile Windows o il launcher Linux.
Per una prima prova si può caricare una sequenza di esempio, adattarla ai comandi della scheda, scegliere la porta seriale e impostare i dati dell’esecuzione. La guida operatore accompagna preparazione, avvio e consultazione dei risultati. La comunicazione implementata è quella seriale; TCP/IP, strumenti SCPI e test multi-scheda sono indicati nell’interfaccia come integrazioni sviluppabili su richiesta.
Sorgenti, screenshot ed esempi sono disponibili nella repository GitHub di SLX Serial Check. Il progetto è distribuito con la Silicon LogiX Evaluation License per studio e valutazione; l’uso in produzione o commerciale richiede un’autorizzazione scritta.
Software su misura per interfacce, dispositivi e collaudo
SLX Serial Check mostra un percorso completo di sviluppo software su misura: progettazione dell’interfaccia React, modelli TypeScript, motore Rust, integrazione desktop con Tauri, gestione dei dati, test e distribuzione. Queste competenze permettono di costruire strumenti tecnici con funzioni definite sul processo dell’azienda, dai pannelli di controllo alle applicazioni che dialogano con dispositivi e sistemi esistenti.
Silicon LogiX sviluppa applicazioni desktop e web per aziende e segue lo sviluppo firmware per dispositivi embedded. Un progetto può quindi comprendere sia il software della postazione sia il protocollo e la diagnostica del prodotto, mantenendo coerenti comandi, criteri di verifica e dati esportati.
Parliamo del tuo progetto software: descrivi il dispositivo o il processo, i sistemi operativi previsti, i dati da conservare e le operazioni da automatizzare. Valutiamo insieme requisiti e primo passo di sviluppo.
