[RESOLU] Inhiber l'IT via wiringPiISR()
Modérateur : Francois
[RESOLU] Inhiber l'IT via wiringPiISR()
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
Si vous avez déjà utilisez cette biblio, merci de m'éclairer.
@+
Thierry
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
Si vous avez déjà utilisez cette biblio, merci de m'éclairer.
@+
Thierry
Modifié en dernier par Thierry le jeu. 6 avr. 2017 16:47, modifié 1 fois.
Re: Inhiber l'IT via wiringPiISR()
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
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
-
- Raspinaute
- Messages : 735
- Enregistré le : lun. 22 déc. 2014 16:50
- Localisation : 67380 LINGOLSHEIM
Re: Inhiber l'IT via wiringPiISR()
Bonjour,Thierry a écrit :Je me répond ...
Merci qui Merci Gordon
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()
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
Finalement C pas Top pour du temps réel sur cette carte
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
Finalement C pas Top pour du temps réel sur cette carte
-
- Raspinaute
- Messages : 735
- Enregistré le : lun. 22 déc. 2014 16:50
- Localisation : 67380 LINGOLSHEIM
Re: [RESOLU] Inhiber l'IT via wiringPiISR()
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
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
-
- Raspinaute
- Messages : 1587
- Enregistré le : dim. 10 mai 2015 18:44
- Localisation : Dans la campagne à côté d'Annecy
- Contact :
Re: RE: Re: [RESOLU] Inhiber l'IT via wiringPiISR()
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.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
Finalement C pas Top pour du temps réel sur cette carte
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
- BananaPI : Gentoo, disque SATA de 2 To
- Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
- Multimedia par DNLA
- Et pleins d'idées ... et bien sûr, pas assez de temps.
-
- Raspinaute
- Messages : 735
- Enregistré le : lun. 22 déc. 2014 16:50
- Localisation : 67380 LINGOLSHEIM
Re: RE: Re: [RESOLU] Inhiber l'IT via wiringPiISR()
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()
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.
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.