Page 1 sur 1

[RESOLU] Inhiber l'IT via wiringPiISR()

Posté : jeu. 6 avr. 2017 11:01
par Thierry
Bonjour,

J'utilise la bibliothèque GPIO "wiringPi" de Gordon (https://projects.drogon.net/raspberry-p ... functions/)
Dans cette biblio il y a la fonction wiringPiISR(...) qui permet de lancer un vecteur d'interruption sur une entrée et un front défini dans cette fonction.
Jusque la tout va bien, l'IT fonctionne correctement. Cependant je souhaiterais l'interrompre quelques temps puis la relancer sur un autre front, voire les deux, mais je ne trouve pas le moyen d'interrompre l'IT :shock: :shock: :shock:
Si vous avez déjà utilisez cette biblio, merci de m'éclairer.
@+
Thierry

Re: Inhiber l'IT via wiringPiISR()

Posté : jeu. 6 avr. 2017 13:51
par Thierry
Je me répond ...
En fait Gordon explique ici https://www.raspberrypi.org/forums/view ... 6&p=338500
qu'il n'a pas de solution avec sa biblio mais qu'avec les instru Linux ca se passe bien ... ;)
Par contre ATTENTION aux numéros des pins qui sont différentes :?
Merci qui :?: Merci Gordon :lol:

Re: Inhiber l'IT via wiringPiISR()

Posté : jeu. 6 avr. 2017 18:40
par spourre
Thierry a écrit :Je me répond ...

Merci qui :?: Merci Gordon :lol:
Bonjour,

Merci à toi aussi pour ce retour.
La libwiringPi est pleine de ressources mais aussi de pièges, en particulier cette numérotation des pins GPIO.

SSylvain

Re: [RESOLU] Inhiber l'IT via wiringPiISR()

Posté : mar. 2 mai 2017 10:51
par Thierry
Attention,
j'ai l'impression, aprés avoir relu la fonction wiringPiISR, que nous n'avons pas réellement une interruption hardware, mais un thread qui fais du pooling sur une entrée :roll: :roll: :roll:
Finalement C pas Top pour du temps réel sur cette carte :?

Re: [RESOLU] Inhiber l'IT via wiringPiISR()

Posté : mar. 2 mai 2017 11:34
par spourre
Linux n'a jamais prétendu être un OS "temps réel".
Selon les exigences ont peut :

- Optimiser
- prendre un kernel low latency
- prendre les extensions RT
- faire du bare metal et se passer d'OS (mais il faut tout gérer, au plus bas de la machine).

Sylvain

Re: RE: Re: [RESOLU] Inhiber l'IT via wiringPiISR()

Posté : mar. 2 mai 2017 17:54
par destroyedlolo
Thierry a écrit :Attention,
j'ai l'impression, aprés avoir relu la fonction wiringPiISR, que nous n'avons pas réellement une interruption hardware, mais un thread qui fais du pooling sur une entrée :roll: :roll: :roll:
Finalement C pas Top pour du temps réel sur cette carte :?
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.
A+

Envoyé de mon E2303 en utilisant Tapatalk

Re: RE: Re: [RESOLU] Inhiber l'IT via wiringPiISR()

Posté : mar. 2 mai 2017 18:45
par spourre
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

Re: [RESOLU] Inhiber l'IT via wiringPiISR()

Posté : ven. 12 mai 2017 09:29
par Thierry
Merci à tous pour ces précisions. ;)
J'ai finalement opté pour une deuxième carte qui s'occupe de gérer mes inputs et envoie le résultat à la RasPi via uart, car celle-ci est déjà FULL avec ROS et ses multiples noeuds LASER/CARTO/... a gérer.