Programmation temps réel

Dev
1

Salut les geek, les, purs, les vrais, j’ai des questions pour vous

[3615 My job]
Suite à des incomprehensions, on a confirmé a un sous traitant un passage en temps réel d’un programme qui traite des données provenant de 2 ports série.
Actuellement il existe , mais pas en temps réel.
Si il a pas le temps de prendre une nouvelle valeur sur le port série, il conserve l’ancienne ( et ca, ca va pas)
[/3615 My job]

Du coup j’ai des questions :

  • ca peut exister un système temps réel sous windows, ou c’est boiteux ?
  • c’est très compliqué de passer de pas temps réel à temps réel ?

Je développe pas trop (manquerait plus que mon interlocuteur technique me réponde sur GZ :slight_smile: )

2

A priori, pour faire du vrai temps réel, il te faudrait un OS temps réel. Donc ca impose pas mal de choses, et a donc surement un os non windows. Et de ce que j’en ai vu (formation su VxWorks) c’etait loin d’etre simple.

Apres, ce que tu entends par temps réel ne l’est ptet pas forcement necessaire ici ( http://fr.wikipedia.org/wiki/Syst%C3%A8me_temps_r%C3%A9el ).

3

Systeme temps reel, ca veut dire OS temps reel. Chez microsoft, seul windows CE peut etre considere un OS temps reel. Donc a part si ton systeme utilise CE, oui ca risque d’etre boiteux…

4

Comme l’explique le lien fourni par Ana-l, “temps réel” ne veut rien dire en soit. Il faut définir ta fréquence de traitement maximum et la latence que tu es prêt à accepter. Selon les industries et les projets, temps réel ça peut vouloir dire une update par milliseconde comme une update par demi-journée.

Si ton unité de temps est de l’ordre de la quinzaine de millisecondes, tu peux faire du temps réel sous windows sans trop de problèmes (à condition de coder un soft qui va suffisamment vite bien sûr). Pas besoin d’OS ou de langage spécial.
En dessous c’est plus chaud.

5

Merci a tous pour vos réponses.

[quote=“Twin, post:4, topic: 49269”]Comme l’explique le lien fourni par Ana-l, “temps réel” ne veut rien dire en soit. Il faut définir ta fréquence de traitement maximum et la latence que tu es prêt à accepter. Selon les industries et les projets, temps réel ça peut vouloir dire une update par milliseconde comme une update par demi-journée.

Si ton unité de temps est de l’ordre de la quinzaine de millisecondes, tu peux faire du temps réel sous windows sans trop de problèmes (à condition de coder un soft qui va suffisamment vite bien sûr). Pas besoin d’OS ou de langage spécial.
En dessous c’est plus chaud.[/quote]

bon l’ordre de grandeur , c’est la centaine de millisecondes ( une nouvelle série de valeur a traiter a chaque fois qu’il y a cet interval de temps )

En fait ce qu’il faut , c’est qu’il fassent les taches liées a ces valeurs ( ce qui doit passer vu le proc) , et qu’apres seulement il traitent le reste ( ou pas, si il fait le reste un peu plus tard c’est pas génant)

donc pour que ca fonctionne comme ca , c’est pas trop lourd a modifier c’est ca ?
actuellement, le truc traite bien les valeurs assez vite, mais “oublie” d’aller cherché des nouvelles valeurs sur le port série dans 10 à 3 pourcent des cas.
0 ce serait le top , 1/mille acceptable

Apres, je demande pas que l’appli foncionne si un abruti lance un autre prog en parrallélele ( antivirus, defrag, excel …)

Le sentiment que j’ai , c’est que les priorités sont mal faites ( traiter les valeurs quitte a ne pas en avoir de nouvelles, ou bien il rattrape son retard en traitant plusieurs fois le même valeurs plutot que d’avoir mémoriser celle qu’il a loupés).

Ca vous semble cohérent ?
Ca se remet vite fait d’aplomb ? c’est super compliqué ?

6

Ca se remet vite d’aplomb, surtout que c’est un port serie, que ya deja du code existant, que la frequence est pas super elevée. Quand tu parlais de temps réel, je pensait que c’etait nettement plus short niveau timing. La ou j’etais, c’etait plus du 1/4 de ms. Et la, t’as pas le temps de faire ce que tu veux, et t’en est presque rendu a compter les cycles machine. La, il suffirait (apres, je connais pas le projet ni le contexte) de placer quelques threads bien comme il faut, deja, le programme serait nettement plus reactif. Surtout que vu les timings voulu, c’est largement faisable “facilement”, et sous windows.

7

Merci pour cette réponse.
On va éviter de partir sur une usine à gaz.
J’ai eu les infos que je cherchais ( mais si quelqu’un a quelque chose d’intéressant a ajouter qu’il n’hésite pas)

8

La définition de machine temps réel ca se rapproche de "machine capable de garantir l’execution d’un programme de facon périodique ou pseudo périodique en garantissant de traiter les données en temps t. ". C’est pas encore assez précis (je t’invite a chercher un article parlant d’ordonnancement). A partir de la, si tu peux te permettre d’avoir des fautes ( louper un cycle, dépasser le temps de traitement) de temps a autre, un OS ‘normal’ devrait suffire. S’il t’est interdit je te conseille de passer a des OS comme RTAI: la programmation d’un module temps réel est simple (fait en TP en 10 mins) par contre le debug est pas simlple: si ca foire, ca foire, et on ne m’a pas présenté de moyen de débugguer - le noyau plante et tu n’as plus qu’a reboot ta machine. Je n’ai jamais travaillé sur CE, donc je laisserai les pros t’en dire du bien ou du mal !

9

Pour de la centaine de milliseconde, Windows no soucy (perso on utilise même des temps des cycles bien inférieur genre 20ms sans soucis). La où ca devient touchy c’est quand des I/O complexes interviennent.

Je pense qu’à priori pour traiter ton problème il faut juste s’assurer de bien faire des appels cycliques… A mon avis c’est plus une erreur de conception qu’autre chose (l’erreur fréquente étant de faire les traitement dans le scheduler)

10

Ayant une petite expérience de l’utilisation des ports séries en .Net sous Windows (mon père est un bricoleur électronicien qui aime faire des montages type domotique), je rajouterai qu’il est très simple de gérer les ports sériels dans ce langage, même pour des configurations atypiques (la dernière expérience de pilotage par port sériel de mon père utilisait une puce qui n’utilisait pas les ports de communications du port sériel, mais un signal sur une broche que-j’ai-déjà-oublié-comment-elle-s’appelle).

Si c’est pour la même puce, je pourrais te filer l’API que j’ai développée (elle a l’air assez commune, mais je ne me rappelles plus du nom, l’électronique c’est pas trop mon truc) si vous faites çà en .Net.

11

[quote="[PERE]Cil, post:10, topic: 49269"]
Ayant une petite expérience de l’utilisation des ports séries en .Net sous Windows (mon père est un bricoleur électronicien qui aime faire des montages type domotique), je rajouterai qu’il est très simple de gérer les ports sériels dans ce langage, même pour des configurations atypiques (la dernière expérience de pilotage par port sériel de mon père utilisait une puce qui n’utilisait pas les ports de communications du port sériel, mais un signal sur une broche que-j’ai-déjà-oublié-comment-elle-s’appelle).

Si c’est pour la même puce, je pourrais te filer l’API que j’ai développée (elle a l’air assez commune, mais je ne me rappelles plus du nom, l’électronique c’est pas trop mon truc) si vous faites çà en .Net.[/quote]

Je rentre de congé aujourd’hui et effectivement le sujet est toujours d’actualité.
C’est effectivement en .net , mais comme on passe par un sous traitant je dois décliner ton offre
( je me vois mal dire au sous traitant que j’ai récupéré une API pour lui sur un forum de geek. En plus on risquerait de découvrir mon identité secréte)
je vais attendre les news de mon sous traitant.

En tout cas merci pour vos infos , qui m’ont permis de briller devant un ponte technique de ma société ( même si je n’ai pas caché que j’avais surtout récupéré des infos sur “un forum d’internet” .

12

[quote="[PERE]Cil, post:10, topic: 49269"]
[…][/quote]
Genre System.IO.SerialPort ?

13

Oui l’API pour la puce que j’ai faite est basée sur SerialPort. Non je n’ai pas reprogrammé SerialPort non plus :).

14

[quote="[PERE]Cil, post:10, topic: 49269"]
Si c’est pour la même puce, je pourrais te filer l’API que j’ai développée[/quote]

C’est pas le rôle du device driver d’offrir cette couche d’abstraction ?

15

La puce elle est de l’autre coté du câble RS232, pas dans le PC :). l’API fait de l’interprétation des données envoyées par la puce et traduit ça “en clair”. Donc je ne sais pas trop si on peut appeler ça un driver, mais techniquement ca a le même principe :crying: (d’ailleurs, l’API je l’ai appellée… xxxxxDriver ou xxxx est le nom de la puce que j’ai oublié)…

16

Bonjour !
as-tu essayé d’utiliser les interruptions materiel ?

$ 3F8-3FF pour com1 si je me souviens bien.
( et irq 4 )

17

[quote=“tart1ne, post:16, topic: 49269”]Bonjour !
as-tu essayé d’utiliser les interruptions materiel ?

$ 3F8-3FF pour com1 si je me souviens bien.
( et irq 4 )[/quote]

Je suis pas sûr que ce soit une bonne idée. Au mieux le driver Windows interceptera les demandes (qqun peut confirmer ?) et donc je suis pas sûr que ça changera vraiment grand chose vu que le problème ne semble pas être ici tant l’appel mais la façon dont le programme est fait. Au pire ça risque de foutre une zoppa pas possible (ou pas marcher du tout)