timer / compteur interne

[niconol]

Bonjour,
A-t-on accès sur RPI3 a des registres interne type TIMER, COMPTEUR, et des interruption associées?
En fait je ne sais même pas si il inclut de tels registres, si ils sont accessibles, si ils sont documentés (je ne trouve pas la datasheet du microc)
Je viens de l'électronique, pas de l'informatique, alors plutôt habitué à confier le déclenchement d'une routine à un moment prècis à un timer et son interruption.
Ou suis-je obligé de travailler avec un linux Temps réeel (déjà que je me met tout juste à linux ...)

Merci

[destroyedlolo]

Salut,

Oui, tous les microP ont ce genre de compteurs ... mais ils ne sont accessibles qu'au kernel sous Linux.

T'as donc 3 solutions, de la plus compliquée à la plus "simple" :

1. tu peux faire du Bare Metal c'est à dire développer sans OS comme tu as l'habitude de le faire ... mais bon, du coup tu perds l'avantage d'avoir un système complet et tu dois tout connaitre des entrailles de la bête (et il me semble qu'il y a des trucs non publique sur les raspberry).
2. tu peux créer un module kernel ... mais ça t'oblige à connaître les techno/API correspondantes (ça n'a rien de vraiment compliqués) mais surtout ... va falloir que tu trouve des ressources dispos pour ce que tu veux faire.
3. tu peux créer des timers en utilisant les API unix. Pour des délais synchrone, tu peux voir du coté de sleep() ou usleep(), pour de l'asynchrone, regarde du côté de itimer ou plus puissant, timerfd.

A+

[niconol]

Salut,

J'avais pas vu ta réponse si rapide, merci pour les différentes solutions,

Je veux conserver un OS, plus simple pour gérer l'écran, la clé USB, et la webcam USB ...
Pour ce qui est des timers, je veux un fonctionnement nickel et hyper réactif. Sleep() et usleep() sont des pauses, je ne suis pas sûr que l'on puisse faire autre chose pendant ce temps, et les temps de reprise risquent de présenter des latences. (tout est relatif, je ne suis pas, sur ce projet, a qq dizaine de µsecondes prêt, mais je veux prendre de bonne habitudes tout de suite).
J'avais donc opté pour du itimer. ça fonctionne bien visiblement, peut être un peu de latence qq part dans mon soft. Sur des interval de 5ms (pas trop rapide),j'ai du gîte de maxi 10µs. Il faudrait que j'essaye sur des fréquences d'interruption plus élevées.

Et donc je lis aujourd'hui ta réponse.
J'ai beau lire timerfd_create(2) , je ne comprends pas l'avantage à settimer .. tu sais me l'expliquer? Ca m'intéresse.

Merci
à+

[destroyedlolo]

Salut,

ouai, malheureusement, le manque de neige fait que j'ai plus de temps pour bricoler

J'ai beau lire timerfd_create(2) , je ne comprends pas l'avantage à settimer .. tu sais me l'expliquer? Ca m'intéresse.

Avec settimer(), tu n'utilises qu'un seul timer et tu génères des signaux qui sont comme des interruptions ... donc vont donc poser les mêmes problèmes pour synchroniser d'éventuels autres threads (dont la boucle principale de ton programme).
Avec les timerfd, tu passes par une abstraction supplémentaire que sont les descripteurs de fichier. Ces descripteurs sont la méthodes la plus standard et la plus versatile pour gérer des événements sous Unix.
Tu peux donc attendre plusieurs timers, l'arriver de caractères sur un fichier, ou des événements extérieure (par eventfd).

Un exemple étant plus parlant qu'un long discours, sur le tableau de bord de ma domotique, j'attends :

• un timer pour passer d'une page a l'autre : toutes les 5 secondes, je bascule entre la météo, les temperatures des differents étages de ma maison, des infos plus générales
• un second timer qui gère les animations graphiques (clignotement des alarmes, ...)
• l'arrivée d'information de ma domotique par MQTT (températures, ouverture de portes, défaillances de trucs et bidulles, ...)
• l'arrivée de commandes de contrôle

Tout est banalisé sous la forme de descripteur de fichier : donc que ce soit les timer, les events, les messages, ou du contenu par fichier, tout passe par la même boucle d'attente en utilisant les même API (fonction poll()).

Bref, ils seront donc légèrement moins précis (enfin, ça dépend surtout de la manière dont tu programmes), mais sont beaucoup plus flexibles et intégré au reste.