Forum Programmation.python Protocole de communication maison via port ethernet

Posté par  (site web personnel) .
Étiquettes : aucune
5
26
avr.
2010
Bonjour à tous,
Je vais peut être dire des énormités mais je souhaite en avoir le coeur ethernet.

La problématique:
Je travaille dans une équipe de microélectronique qui développe des asics pour le spatial. Dans ces asics, deux parties, une partie analogique et une partie numérique. Pour communiquer avec la partie numérique nous utilisons un protocole maison. Pour fonctionner ce protocole utilise une horloge (strobe), une entrée (din) , un trigger et une sortie (dout). Le signal d'horloge est cadencé à 20MHz, les autres signaux étant évidemment directement dépendant de cette horloge.

La solution existante:
Aujourd'hui pour faire fonctionner ces asics nous utilisons le programme Labview (que je n'aime pas du tout) le port parallèle (trop lent). Sur ce port nous avons une petite carte qui nous permet de faire la conversion 5V vers 3.3V qui convient à notre circuit.

Mon idée:
Je voudrais nous débarrassez de Labview pour une solution simple, libre et efficace. Une solution qui permette aussi d'être facilement modifier par des électroniciens qui ne sont pas forcement féru de programmation.
Pour ce faire j'avais commencé à me renseigner du coté de python et des librairies pyserial et pyParallel qui permettent de faire, si j'ai bien compris, du bit à bit (envoie 1 sur telle pin, lis cette pin, remets la pin à 0...) . Mais ces ports ne sont pas assez rapides. Je pense donc au port ethernet. Je ne trouve aucune information permettant de dire si je peux faire du "custom protocol" au travers d'un port ethernet. Si c'était possible je ne rendrais pas service qu'a mon labo...
Le choix du python se justifie principalement par le fait que c'est un langage que je suis en train d'apprendre, que j'aime bien, sans compilation, multi-plateforme...

Si ca vous pique les yeux je suis désolé.

D'avance je vous remercie pour votre aide.

Olivier
  • # A priori...

    Posté par  . Évalué à 2.

    Un câble ethernet n'est rien qu'un ensemble de paires de fils, parfois blindé. A priori, tu devrais donc pouvoir faire transiter les informations que tu souhaites, comme tu le souhaites.
    Dans la pratique, à moins de concevoir/fabriquer ta propre carte de communication, je doute que tu puisses y arriver sans passer par les couches réseau usuelles. AMHA je pense qu'aucune carte réseau ne te laissera prendre la main sur le contrôle des envois/réceptions sur la prise RJ45.
  • # Bonjour, je suis electronicien donc je peut te dire ce que j'en pense

    Posté par  . Évalué à 6.

    Non l'étage physique ethernet est connecté directement aux controleur donc tu ne peut pas t'en servir comme d'une entre/sortie pilotable à volonté.
    La facon la plus efficace de géré ton pb est de prendre une carte avec un PIC (exemple) intégrant un port USB (device), dans le PIC tu crée des macros fonctions (SendXbytes, ReceiveXbyte) et avec libusb ou les drivers windows fournit par microchip n'importe quel programme en C (en mode console) peut se servir de ce port.

    Sinon pour une communication synchrone voici des points d'entrés

    http://www.cypress.com/?id=1133
    http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_P(...)
    • [^] # Re: Bonjour, je suis electronicien donc je peut te dire ce que j'en pens

      Posté par  . Évalué à 4.

      Entièrement d'accord, usb puis microcontroleur (atmel ?? Plus facile et outils gcc que PIC !)

      Attention, en général les microcontrolleurs sont pas non plus des foudres de guerre, regarde un peu ce que tu peut avoir comme débit.

      Il y a une autre solution : le sheevaplug (ou une de ses variantes) : un arm 1.2GHz, qui possède dans sa version de base de sorties et entrées numériques ! Il existe une variante spéciale dédiée à ce genre de problématique (ici relevé de données météo, mais c'est pareil globalement).

      Tout ce qu'il te faut, c'est du 20MHz :-)
    • [^] # Re: Bonjour, je suis electronicien donc je peut te dire ce que j'en pens

      Posté par  . Évalué à 7.

      La même chose avec un AVR :
      http://www.tty1.net/userial/

      Le gros plus, c'est que du coté PC, c'est vu comme un port série et le protocole est en ASCII, donc facile à débogguer (un simple printf suffit) - Tu peux même utiliser directement minicom

      Ca marche direct avec l' AT90USBKey d'Atmel (32$)
  • # Deux choses en même temps ?

    Posté par  . Évalué à 3.

    Je comprends que tu as deux "problèmes" que tu essayes de résoudre : remplacer LabView par quelque chose de libre, et remplacer ton port parallèle lent par quelque chose de plus rapide. Mais je vois que tu essayes de résoudre les deux en même temps, et j'ai l'impression que c'est ça qui te bloque. Selon moi, il vaudrait mieux que tu t'attaques à chaque problème séparément.
    • [^] # Re: Deux choses en même temps ?

      Posté par  (site web personnel) . Évalué à 3.

      Tu as raison.
      Concernant Labview, la motivation est effectivement de trouver une alternative libre. Je ne supporte pas que mon labo paye cette cochonnerie si chère alors que nous pourrions tout a fait utiliser des outils libres et/ou gratuit au moins, si ce n'est bien plus, performant.
      Concernant le port, il me semble trop lent. Nous tournons actuellement sur ce port à des fréquence proche de 20MHz. Au cours de mes recherches j'ai lu a plusieurs reprises que ceci est bien au delà des capacités usuelles du port. Mais si ça tourne, moi le port je m'en fout.
      l'USB me fait peur, mais c'est en affrontant ses craintes qu'on évolue, pas en les fuyant.


      PS: J'ai peut être oublier de le dire mais je tourne sous Linux...

      Les logiciels de traitement de texte sont à la rédaction ce que la 2CV est à l'automobile, une vieille voiture dont on se souvient avec nostalgie mais technologiquement dépassée

      • [^] # Re: Deux choses en même temps ?

        Posté par  . Évalué à 3.

        Je comprends tout à fait ta motivation de passer à quelque chose de libre :-)

        Par contre, en ce qui concerne le port, je pense que tu as dû mal capter quelque chose : si vous utilisez un protocole physique spécifique, ce n'est pas en te tournant vers de l'USB ou de l'ethernet que tu trouveras une solution : ils ont des protocoles physiques bien définis, incompatibles avec votre matos. Le port parallèle c'est bien pratique parce que c'est un port qu'on peu utiliser de manière "générique", à bas niveau, mais ce n'est pas le cas pour tous les protocoles modernes.

        J'ai l'impression également (par la manière dont tu t'exprimes) que tu es plutôt débutant dans le domaine (je ne suis pas du tout un expert non plus). Je pense que pour l'interco avec tes ASICS, ce serait bien d'aller voir les mecs qui les développent pour voir comment eux voient l'interconnexion de leur machin avec des machines "standards" qui n'ont que des interfaces "standards".

        Car oui, tu peux t'amuser à gérer en soft le protocole physique avec des GPIO (ce que fait en gros ton port parallèle, mais qui correspond aussi aux solutions proposées par les gens au dessus qui te parlent de micro-contrôleur) mais c'est pas gagné que tu puisses monter très haut en fréquence (d'ailleurs, je n'ai toujours pas compris pourquoi tu dis que le port parallèle est "trop lent" : ça marche actuellement ou pas à cette fréquence ?).

        Bref, j'espère ne pas avoir l'air condescendant, mais va lire en:Bus (computing)
        • [^] # Re: Deux choses en même temps ?

          Posté par  (site web personnel) . Évalué à 3.

          Justement, je fais parti de l'équipe de développement de l'asic en question. Sur ce projet TOUT est fait maison: asic, protocole, carte, banc de test...Moi je suis arrivé bien tard sur le projet et ce genre de choses s'est décidé sans moi. Je ne cherche pas a recréer la roue. Je veux juste montrer a mon équipe des solutions alternatives, parce qu'elles existent, qu'elles peuvent être plus performantes et/ou plus simples. L'interco est très simple:

          une carte directement connecté sur le port parallèle via un port mâle qui va bien.
          Sur cette carte (PCB) un buffer pour convertir le 5V en 3.3V
          un connecteur
          une nappe (30cm)
          connecteur
          l'asic bondé sur un PCB


          Actuellement, sous Labview, les trames sont ''fabriquées'' sur le PC et envoyées bit à bit vers l'asic. C'est d'ailleurs pour cette raison que nous utilisons le port parallèle. Au risque de me répéter, le protocole est absolument custom et ne ressemble en rien a quelque chose d'existant. Je ne peux pas en dire beaucoup plus a ce sujet et pas par manque de connaissance...

          Mon idée de départ c'est de faire la même chose en python et QT (ils veulent une interface graphique).

          Oui ça marche actuellement, sur le port parallèle mais quand je regarde mes signaux a l'oscillo on est plus proche de la forme en triangle que d'une forme carré. Maintenant notre circuit fonctionne à 20MHz mais les dev futurs prévoient des cadences supérieures et je voulais anticiper un peu.

          J'espère avoir éclaircie quelques points.

          Les logiciels de traitement de texte sont à la rédaction ce que la 2CV est à l'automobile, une vieille voiture dont on se souvient avec nostalgie mais technologiquement dépassée

          • [^] # Re: Deux choses en même temps ?

            Posté par  . Évalué à 2.

            Regarde du côté des puces ftdi. http://www.ftdichip.com/FTProducts.htm
            Elles permettent d'utiliser des interfaces séries ou parallèle avec le port USB.
            L'aspect gestion de l'usb est totalement transparent: on programme comme si l'on "voyait" directement l'interface série ou parallèle. en:Bit-banging
            C'est compatible windows et linux. Le module est déjà présent dans le kernel, il n'est pas nécessaire de l'installer.
            Il existe des kits intégrant clés en main pour le prix de quelques dizaines d'euro.
            Ca se programme aussi bien en C qu'en python.
          • [^] # Re: Deux choses en même temps ?

            Posté par  . Évalué à 3.

            De mon point de vue, si tu veux leur montrer des solutions alternatives, c'est aussi en concertation avec. Ce sera plus facile de comprendre les raisons de leur choix, et de voir ce qui sera le mieux adapté à vous tous. Bon, d'un côté, si c'est dans l'aérospatiale, "rationnel" n'est peut-être pas le maître mot ...

            Déjà, je te conseillerais de de concentrer sur le problème soft avant d'aller voir les histoires d'interco. Si ton bouzin marche déjà bien comme ça, garde le port parallèle, et essaye de faire un soft en python.

            Si tu veux changer l'interco et passer à autre chose que le port parallèle, il te faudra de bonnes connaissances en électronique, ce dont je ne suis pas sûr que tu aies. La plupart des micro-contrôleurs dont on parle au dessus tournent eux-mêmes à une fréquence inférieure à 20MHz, et mes petites recherches sur l'Arduino (un micro-contrôleur bien connu des bidouilleurs) montrent qu'il ne peut pas vraiment dépasser les 10MHz pour les signaux en sortie. Même un port parallèle à 20MHz, c'est hallucinant (c'est pas pour rien que tes signaux sont pas très carrés). Bref, si tu veux encore plus que ça, va falloir aller voir des gens qui s'y connaissent. Ou passer à un bus standard, genre PCI, mais là va falloir changer l'interface de l'ASIC.

            En plus, bit-banger à 20MHz ça me paraît déjà énorme. L'USRP en:USRP fait du 128MS/s (en analogique 14 bit, c'est vrai) et c'est du matos super haut de gamme. C'est pas pour rien que la boîte s'est fait racheter par National Instruments, d'ailleurs (qui produit ... LabView !). Bref, monter au dessus de 20MHz, pour quelqu'un qui n'a pas de connaissances en électronique, c'est quasi-impossible.

            Voilà, c'est pas pour te démotivé (t'as l'air de bien aimer ça !) mais je te conseille d'aller en parler à des gens qui "savent mieux" (et je te le redis, j'en connais pas non plus des tonnes) avant de te lancer dans le truc.
            • [^] # Re: Deux choses en même temps ?

              Posté par  (site web personnel) . Évalué à 3.

              Je précise que ce n'est pas moi qui ait mis au point cette solution sur port parallèle et que c'est justement parce qu'elle me semble un peu bancale que je souhaite apporter ma petite contribution.

              Je reconnais aussi avoir peu de connaissances dans le domaine de l'électronique que je qualifierai de ''télécom'' mais ca n'est pas vraiment mon domaine...

              Pour l'instant je ne me lance dans rien. Je fais des recherches de faisabilités et aussi pour ma culture personnelle. Mais c'est vrai que si mes recherches convergent vers une solution efficace et libre, je soumettrais l'idée à mes collègues.

              Je vais effectivement aller voir les personnes de la deuxième équipe de test. Il me semble qu'ils bossent avec une solution autour d'un fpga...

              Les logiciels de traitement de texte sont à la rédaction ce que la 2CV est à l'automobile, une vieille voiture dont on se souvient avec nostalgie mais technologiquement dépassée

              • [^] # Re: Deux choses en même temps ?

                Posté par  . Évalué à 3.

                Bon, désolé si j'ai l'air d'avoir un ton un peu péremptoire, je suis un peu comme ça quand je donne mon avis. Je comprends tout à fait que tu envisages plein de trucs différents, et que tu ne sais pas si ça va marcher.

                Pour la solution "port parallèle", je ne critique pas du tout : c'est très bien si ça marche ! C'est changer vers une autre solution sans avoir toutes les connaissances "appropriées" qui me semble risqué.

                Et effectivement, le FPGA peut être une bonne méthode. Mais j'y connais encore moins, alors je te laisse continuer à chercher. Bon courage !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.