[Linux embedded] Come si passano eventi tra processi?

[GuidoB]

Buona sera a tutti.

Ho programmato per anni microprocessori e microcontrollori che dovevano gestire eventi in tempo reale (soft). A volte avevo sotto un sistema operativo, altre volte il "nudo hardware".

Per la prima volta mi trovo a dover inviare e ricevere eventi su Linux embedded. Per esempio devo informare di pressioni e rilasci di pulsanti, e ricevere ordini di accensioni e spegnimenti di led.

Mi consigliano (o meglio mi obbligano) ad utilizzare file:
A) Un file per ogni pulsante, contenente un solo carattere, in cui scrivo '1' o '0' a seconda che il pulsante sia premuto o meno. Devo lasciare immutato ciascun file per un minimo di tempo, altrimenti chi va a leggere questi file ogni 10 ms potrebbe perdere eventi (il polling, questo disgraziato);
B) ciascun led è gestito da vari file. Se ho ben capito, un file contiene un carattere che mi informa se un led dev'essere acceso, spento o fatto lampeggiare, e altri due file che in caso di lampeggio specificano il tempo di "on" e di "off" in millisecondi. A quanto pare in Linux esiste una classe standard che gestisce così i led. Dovrei leggere ogni 10 ms tutti i file dei led (aprire il file, leggere il carattere, chiudere il file), controllare se ci sono variazioni ed agire di conseguenza.

A me questo uso massivo del polling fa rizzare i capelli. E va bene che oggi abbiamo microcontrollori potenti, ma finora il metodo principale che ho utilizzato è stato quello di informare i "clienti" dei miei eventi, e ricevere messaggi (o chiamate) quando devo fare qualcosa. Non il viceversa (cioè dovendo chiedere continuamente se è successo qualcosa, caricando e rallentando il processore).

E poi usando dei file! Dei normali file, a quanto ho visto, da aprire con fopen e chiudere con fclose... ogni 10 ms . Niente code di eventi...

Mi sembra un metodo molto inefficiente, ma non sapendo praticamente nulla di Linux embedded, chiedo a voi se è normale.

Chiedo inoltre: come si avvisa "canonicamente" un processo Linux di un evento? Con un signal? E come si avvisa un thread?
Come si passano le informazioni relative a eventi tra processi e thread in tempo reale in modo efficiente? Con pipe? Con qualche tipo di coda di eventi in memoria RAM? Oppure con dei file come mi hanno detto di fare?

Potreste consigliarmi qualche buona lettura sull'argomento?

Grazie per la vostra attenzione.

[gvee]

Linux non supporta le interruzioni hardware real-time, quindi se questo é il tuo obbiettivo, non é la soluzione migliore come gia sai.

L'interfaccia userspace per i GPIO é il filesystem sys in /sys/class/gpio.

Linux embedded é solo un termine per dire che l'OS é installato su una scheda embedded.. Ma sempre Linux é.

Ad ogni modo prova a vedere IPC se hai bisogno di comunicazione tra i processi.

[GuidoB]

Linux non supporta le interruzioni hardware real-time, quindi se questo é il tuo obbiettivo, non é la soluzione migliore come gia sai.

No, gli eventi arrivano da un altro micro via porta seriale.

Ad ogni modo prova a vedere IPC se hai bisogno di comunicazione tra i processi.

Ti ringrazio Simo, vado a cercare "Inter Process Communication in Linux"

[gvee]

Se usi una porta seriale allora usa la select per il polling.
Cerca in rete il libro di Michael Kerrisk.

[Praticamente]

Erm ci sono i segnali, le pipe, i semafori, la memoria condivisa, i socket e poi i file

La possibilità di vedere come fosse un file qc che nonlo é

[harpefalcata]

Il metodo che ultimamente va per la maggiore è di usare dei sistemi di gestione distribuita degli eventi. In pratica esistono una moltitudine di "producer" che committano gli eventi ad un servizio centralizzato: un "broker". Poi esistono i "consumer" che, in base alle loro esigenze possono richiedere ai broker i vari topic ai quali sono interessati, in maniera tale che non ci sia ne polling ne una coda crescente.

Chi genera gli eventi non dovrà fare altro che pubblicarlo sul broker e sul topic che gli interessa.

Di tutto questo si occupa ad esempio Apache-Kafka.

E' un sistema che gir asulla memoria RAM e, in base all'estensione del sistema stesso puoi decidere quanto storico mantenere in memoria.

Chi genera i segnali esterni non dovrà fare altro che pubblicare sul broker il tipo di segnale e la sua marcatura temporale.

Saluti

[GuidoB]

Grazie a tutti.

Se usi una porta seriale allora usa la select per il polling.

Mi hanno fornito una classe da usare, che ricopre un socket. Da quel lato non dovrei avere grossi problemi, a parte il fatto che l'altro micro non è molto ubbidiente.

Oggi ho visto che per cambiare un led da spento a acceso e viceversa devo prima farlo lampeggiare per un centinaio di millisecondi, altrimenti non funziona .
L'altro micro scrive sul display alla linea che vuole lui, in caratteri giapponesi (credo), e non c'è verso di farglieli cambiare. L'encoder manda da 8 a 17 impulsi al giro, dipende da come gli gira

Per questo mi piace aver sotto il nudo hardware, ma stavolta non si può.

Cerca in rete il libro di Michael Kerrisk.

"The Linux programming interface" Ha ottimi giudizi, sembra un buon investimento. Ci faccio un pensiero .

La possibilità di vedere come fosse un file qc che nonlo é

Credo che nasca dal fatto che, come ha detto gvee,

L'interfaccia userspace per i GPIO é il filesystem sys in /sys/class/gpio.

In quella ditta sono abituati a vedere i GPIO come file e vogliono continuare così, anche se stavolta in mezzo c'è un socket e il giro che vogliono fare è di un'orribile inefficienza. Pazienza, sopravviverò anche a questa.

Il metodo che ultimamente va per la maggiore è di usare dei sistemi di gestione distribuita degli eventi...

Anche nel mio caso mi sono "abbonato" a un paio di tipi di eventi, ma non è un "broker" così sofisticato. Buono comunque a sapersi.