destroyedlolo a écrit :
...
Ben, je n'utilise pas wiringPI, mais le Soc du rRI est capable de générer des interruptions pour chacun de ses GPIOs (cf son datasheet)... Donc ça serait vraiment étonnant que cette librairie se cantonne au busy-wait.
Après, il est vrai que le même datasheet indique que le dit soc fait un échantillonage basé sur son horloge... Mais c'est géré par l'électronique et n'influe donc pas sur les perfs du système. Il y a peut-être une confusion à ce niveau.
...
Je partage assez ce point de vue tout en apportant une précision supplémentaire:
la wiringPi s'appuie elle-même sur la bcm. Tout cela se déroule en "user land" donc est soumis aux aléa de la charge du CPU et des décisions du scheduler.
Une autre approche serait de développer un module pour le kernel (je ne sais pas faire).
Sinon, l'approche "bare metal" est certainement la voie royale pour faire du vrai temps réel et exploiter au mieux les ressources du SOC.
Il y a pleins d'applications qui ne nécessitent ni OS lourd, ni serveur X et interface graphique.
Dans le dernier LMF, page 48, il y a une introduction à la programmation "bare-metal". Les exemples fonctionnent (j'ai testé) et le programme de raytracing est livré avec un support du framebuffer qui exploite la sortie hdmi du raspberry. Cela devrait suffire pour des automates.
C'est un environnement de cross-compilation qui peut tourner dans un docker. Il y a un shell pour préparer la carte SD pour être bootable et démarrer soit sur un programme, soit sur un serveur gdb.
Il n'y a qu'une seule limitation, le debug bare-metal livré (à base de gdb), ne permet pas le debugg en multi-threads (étonnant quand on connaît la position de Denis sur ce point).
Je pense que vous devriez y trouver votre miel.
Sylvain
Merci Gordon 
