[RESOLU] Inhiber l'IT via wiringPiISR()

Comment utiliser Win32DiskImager, putty, winscp ? c'est par ici que ça se passe

Modérateur : Francois

Répondre
Avatar du membre
Thierry
Messages : 21
Enregistré le : lun. 13 févr. 2017 08:52

[RESOLU] Inhiber l'IT via wiringPiISR()

Message par Thierry » jeu. 6 avr. 2017 11:01

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
Modifié en dernier par Thierry le jeu. 6 avr. 2017 16:47, modifié 1 fois.

Avatar du membre
Thierry
Messages : 21
Enregistré le : lun. 13 févr. 2017 08:52

Re: Inhiber l'IT via wiringPiISR()

Message par Thierry » jeu. 6 avr. 2017 13:51

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:

spourre
Raspinaute
Messages : 735
Enregistré le : lun. 22 déc. 2014 16:50
Localisation : 67380 LINGOLSHEIM

Re: Inhiber l'IT via wiringPiISR()

Message par spourre » jeu. 6 avr. 2017 18:40

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

Avatar du membre
Thierry
Messages : 21
Enregistré le : lun. 13 févr. 2017 08:52

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

Message par Thierry » mar. 2 mai 2017 10:51

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 :?

spourre
Raspinaute
Messages : 735
Enregistré le : lun. 22 déc. 2014 16:50
Localisation : 67380 LINGOLSHEIM

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

Message par spourre » mar. 2 mai 2017 11:34

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

destroyedlolo
Raspinaute
Messages : 1585
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()

Message par destroyedlolo » mar. 2 mai 2017 17:54

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
  • 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.
Un descriptif de ma domotique 100% fait maison.

spourre
Raspinaute
Messages : 735
Enregistré le : lun. 22 déc. 2014 16:50
Localisation : 67380 LINGOLSHEIM

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

Message par spourre » mar. 2 mai 2017 18:45

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

Avatar du membre
Thierry
Messages : 21
Enregistré le : lun. 13 févr. 2017 08:52

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

Message par Thierry » ven. 12 mai 2017 09:29

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.

Répondre

Retourner vers « Les utilitaires et le Raspberry Pi »