Pinhapple a écrit :
Bonjour !
...
J'ai regardé cette page chaque jour depuis mon dernier message, et ce n'est qu'aujourd'hui que Firefox se décide à actualiser la page...
(Véridique ! Je crois qu'il n'actualise pas mes onglets automatiquement quand je les reprends d'une session à l'autre, je dois faire ça manuellement...)
....
bonjour,
J'ai le même problème avec Seamonkey (issu de Mozilla). Il y a des périodes où je ne vois aucun message nouveau.
C'est au point que je passe systématiquement en revue mes messages pour voir s'il y a une réponse.
Pinhapple a écrit :
...
Du coup oui, ça a bien avancé côté électronique ! Mon montage avec le DS26LS32CN fonctionne correctement, de même que le pont diviseur de tension qui fait le lien entre lui et le RPi. Ma crainte était que le pont diviseur n'écrase trop le signal et que la détection des fronts soit impactée, mais finalement ça va.
Voila donc une très bonne nouvelle et de quoi alimenter ton mémoire.
Pinhapple a écrit :
...
Côté RPi, celui-ci a un peu de mal à calculer les durées souhaitées : durées de chaque impulsion (du front montant au front descendant) et durée entre deux impulsions (de front montant à front montant). Les mesures se font, mais je doute de la précision des valeurs ; par exemple, en test local avec mon Arduino qui me génère le signal, j'obtiens entre 137 et 146 µs de largeur d'impulsion pour le signal des tops nords, là où je m'attends à avoir du 125 µs. Je dois maintenant faire des tests sur le radar afin d'établir si les écarts mesurés sont dus au RPi ou à de la gigue.
Le fait que Raspbian ne soit pas un OS temps réel me fait craindre que le problème vienne du RPi, mais après ce sera à voir avec mon maître de stage pour les écarts tolérés, même si j'aimerais obtenir une précision à la microseconde près.
Deux cas de figure : 1) le RPi mesure tout correctement, les écarts sont dus à de la gigue -> validation de l'outil et autre mission confiée, ou 2) le RPi n'arrive pas à suivre -> j'aurais prouvé que ce n'est pas possible avec ces outils, et autre mission confiée. Dans chaque cas, j'aurais appris pas mal de choses en électronique, et j'aurais surtout gagné en confiance au niveau des manipulations !
J'irai sur le radar cet après-midi pour faire un test en conditions réelles, je vous tiendrai au courant de ce que ça donne !
Bon ça, on s'en doutait (Bud et moi) dès le début d'où notre conseil de passer au compilé.
Je ne sais pas quelle définition tu as du temps réel (
http://connect.ed-diamond.com/GNU-Linux ... temps-reel ) mais effectivement Linux n'a jamais été conçu pour l'être. En général, on utilise une machine surdimensionnée en espérant que cela permettra de répondre à l'attente et souvent, cela fonctionne.
Le problème du Raspberry est qu'il est trop rachitique pour cette approche. La wiringPi s'appuie elle-même sur la bcm. et tout cela se déroule en "user land" et est donc soumis aux aléa de la charge du CPU et des décisions du scheduler.
Selon les exigences et les contraintes temporelles,, il y a plusieurs approches possibles:
-) Développer un module pour le kernel (je ne sais pas faire). Suite à ma remarque sur un autre fil, un posteur a lancé une demande d'aide mais n'a pas encore reçu de réponse.
-) Passer aux extensions RT
-) Se passer de Linux et développer directement une appli qui tourne sur le matériel (Baree metal)
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).
Si ton CDI est abonné, ça vaut le coup de lire cet article, voire d'acheter le magazine.
En fonction de la décision de ton maître de stage, ceci pourrait constituer la conclusion de ton travail et fournir des pistes aux prochains stagiaires.
Nota: Nous n'avons évoqué que les pistes logicielles mais tu devrais aussi regarder du côté de la stabilité de l'oscillateur du Raspberry.
Sylvain