Bonjour,
tu as bien compris mon casse tête en effet.
Il s'agit bien, globalement d'écrire 10000 trames de 20 octets chaque seconde.
Effectivement, cela représente une quantité astronomique si l'application tournait en permanence.
Dans notre cas, il s'agit de réaliser un enregistreur de bord automobile, qui se déclenche que sur certains évenement (apparition d'un trame dont le champ N prend une valeur M par ex, etc...) ce qui signifie que la carte va stocker temporairement les trames recues, les traiter (étudier si elle correspondent à un evenement declenchant l'enregistrement ou non).
Dans le cas où elles ne correspondent pas, etant donné qu'on ne peut acquérir en permanence faute de mémoire infinie, effectivement nous devons utiliser un méthode basée sur les buffers tournants. Ici la fifo joue ce double role, a la fois de passerelle entre les différents espaces (kernel / user) et de tampon.
Donc pour ce qui est de l'aspet mémoire, on peut l'omettre quelque peu, puisque si l'enregistreur de bord stock pendant 1 heure après l'evenement declencheur, on pourra considérer qu'il y a assez d'information pour effectuer les diagnostic necessaires, et deceler d'eventuels erreurs.
La où se situe le problème est bel et bien le temps de traitement.
D'apres toi, la solution la plus simple est d'acquérir une quantité de trames, puis d'effectuer l'ecriture dans un fichier distant seulement une fois l'acquisition terminée. Jsuis parfaitement daccord avec toi, ce principe etait utilisé sur le precedent enregistreur: un buffer circulaire acquérissait les trames, le CPU les traitait, et sur detection d'un evenement declencheur, enregistrait sur la carte une certaine quantité de trames dans la limite de la mémoire disponible. Puis, une fois l'enregistrement terminé, on ecrivait les trames acquises dans un fichier sur un PC distant, destinées a etre traiter posterieurement.
Aujourdhui on beneficie d'une nouvelle plateforme, beaucoup plus performante que la précedente, car elle nous permet d'acquérir sans perte, des trames toutes les 90us. On souhaite realiser un proto capable de realiser cette acquisition. Mes supérieurs, trop ambiteux au début, pensaient même pouvoir realiser un traitement sur ces trames (traitement assez complexe realisé par le PC distant dans la version precedente)
Apres m'etre apercue des problèmes auxquels nous sommes confrontés, nous avons revu les objectifs à la baisse. C'est pourquoi, on souhaite, une simple acquisition à la volée des trames et leur enregistrement sur PC distant (le PC proposant un espace de stockage bien plus important, et effectuerait les différents traitements postérieurs)
Voila pourquoi je "chasse" la microseconde à tout va.
J'ai par ailleurs essayer d'utiliser les sockets en TCP pour maitriser l'acces en ecriture par Ethernet sur le PC distant. J'ai gagner encore quelques us mais encore pas assez.
Il semblerait qu'en UDP je puisse en gagner encore plus, mais utiliser l'UDP serait un non sense, car il ne garantit pas la non perte des trames, et leur ordre de reception.
J'essaie donc de chercher où se situe le goulot d'etrenglement en quelques sortes.
Tu me confortes egalement dans mon idée d'utiliser la mémoire partagée. Le seul point noir est qu'on tire profit de la mémoire partagée lorsqu'elle est effectivement partagée par deux plateformes ou CPU différents.
Ainsi, grossièrement, comme tu l'as expliqué, quand le premier fait l'acquisition, le second accede a un espace different, et ecrit une trame precedement acquise et rebelotte. On aurait donc un reel parallelisme, et moyennant une synchronisation des deux CPU, on gagnerait reellement en temps. Comme tu l'as dis, il est difficile de faire faire la même chose au même micro, etant donné les contraintes de temps.
Dans mon cas, le buffer mémoire etant en embarqué sur la carte, c'est le même CPU qui realise l'acquisition et l'ecriture. Certes, il semblerait que l'acces en ecriture/lecture à la mémoire partagée sous Linux RTAI est plus performant que l'acces au FIFO ou mailboxes (ca reste a vérifier) mais ce qui est sur, c'est qu'on perd l'interet de la mémoire partagée, puisqu'on est en pseudo parallèlisme.
La mémoire partagée semble être la solution, mais je ne sais pas comment la partager vers le PC distant.
De plus, la où l'on soulage le CPU embarqué, car il n'effectue qu'une seul opération grossièrement, on risque peut etre de perdre, ou du moins de ne pas gagner autant que ce qu'on pensait, puisque tout le mecanisme de synchronisation, c'est à dire qui appel le PC distant pour lui dire qu'il a accède a telle partie de la mémoire, et cela a travers une communication Ethernet, peut prendre un certains temps. A prendre en compte...
Si quelqu'un connait les mecanismes pour partager une mémoire circulaire embarquée sur une carte entre le CPU de la carte (OS Linux RTAI) et un PC distant (Linux NON RTAI) ?
il semble que je ne pourrai pas utiliser les "rtai_scb" (Shared (memory) Circular buffer) car le PC distant n'est pas temps réel. Néanmoins une mémoire partagée même non temps réelle devrait permettre un gain de temps important.
Si quelq'un a un avis / conseil / critique sur le sujet, j'apprécierai votre participation.
Merci d'avance
Poste le Wednesday 16 August 2006 12:02:02