Discussion :

[petitcoucou31]

Bonjour a tous,

Je ne sais pas si je me trouve dans la bonne rubrique pour ce post.

Je suis à la recherche d'information, de tutoriel, aide, voir d'exemple pour apprendre a utiliser le port Ethernet (écriture et lecture d'information).

L'objectif: établir un dialogue bidirectionnel entre un PC et une machine distante de quelque dizaine de mètres au moyen d'un câble (voir Wifi dans l'avenir). Il ni a pas de notion de réseau car juste deux systèmes seront connectés sur le même câble.

Etat actuel:
A ce jour ce dialogue est exécuté depuis le port parallèle sur lequel se trouve un "sérialisateur" basé sur un FPGA avec un protocole maison. Vous imaginez bien les difficultés rencontrées pour trouver aujourd'hui (même si on y arrive encore à des prix ... ) des pc portables équipés de port parallèle, quand aux convertisseurs port Pcmcia/parallelle, eux ne sont pas adaptés au terrain.

D'ou le choix de remplacer ce mode de communication par un nouveau.
Pourquoi "Ethernet", car c'est un port qui existe en natif sur tout les pc de bureau, portable voir mini! qui devrait rester pérenne quelle années encore et pour la distance couverte.

Contrainte
Pour assurer une compatibilité avec le matériel existant , nous devrons nous adapter au protocole existant, donc pas de TCP.IP qui avec tout ces contrôles ( normaux pour des réseaux) pourrait ralentir le dialogue. Nous devons envoyer des trames relativement courte "10ene d'octet".

Voila si quelqu'un a des idées, déjà simplement pour envoyer et recevoir un simple octet sur le port Eternet, et que je pourrais visualiser qu'une maniere quelconque sur ce port.

Si quelqu'un y voit une impossibilité technique qu'il me le dise aussi (vue que je ne connais pas intimement son fonctionnement)

Merci a tous d'avance.

[Mac LAK]

Le souci, c'est que tu ne pourras pas éviter les 18 octets de la capsule Ethernet (6 octets adresse destination, 6 octets adresse source, 2 octets protocole/longueur, ta trame, et enfin 4 octets de CRC32).

Si c'est rédhibitoire pour toi, aucune solution via Ethernet. Sinon, ta solution s'appelle "raw sockets" et te permet d'émettre directement au niveau du protocole Ethernet, sans passer par IP et protocoles au dessus (UDP, TCP).

Reste ensuite le souci de l'encodage : tu ne pourras pas connecter directement ton RJ-45 à ton appareil, car cela ne permettrait pas la communication. Un contrôleur Ethernet est requis de chaque côté de la connexion.

[Franck SORIANO]

Contrainte
Pour assurer une compatibilité avec le matériel existant , nous devrons nous adapter au protocole existant, donc pas de TCP.IP qui avec tout ces contrôles ( normaux pour des réseaux) pourrait ralentir le dialogue. Nous devons envoyer des trames relativement courte "10ene d'octet".

Oui enfin qu'en même, tu vas passer d'une liaison parallèle à une liaison Ethernet en point à point.
Qui plus est, j'imagine que la liaison parallèle doit être programmée en PIO.

Avec l'Ethernet tu auras une bande passante nettement supérieur à ta liaison actuelle, qui plus est, la carte réseau va prendre en charge l'envoi de la trame réseau sur le médium.
Donc même si la liaison réseau génère un peu plus de traffic qu'avec ta solution actuelle, il n'est pas impossible qu'un envoi en UDP soit plus performant que ce que tu as actuellement.
D'autant plus que l'émission de la trame et sa réception étant assurée par la carte réseau, la machine sera sûrement plus disponible pour traiter les trames.

Donc a ta place, je commencerais par faire le test en UDP, en faisant passer ton protocole actuel à l'intérieur de trames UDP (voir même TCP/IP).

[petitcoucou31]

salut et merci a vous pour vos réponses ,

J'avais bien cru comprendre en lisant à droite à gauche, que je devrai obligatoirement passer par la trame Ethernet (6 octets adresse destination, 6 octets adresse source, 2 octets protocole/longueur, ta trame, et enfin 4 octets de CRC32).

Quand je parle de vitesse c'est pas tant la bande passante qui pourrait me gêner mais la taille des paquets, qui pourrait retarder les échanges bidirectionnels.

Je m'explique:
Dans le dialogue présent un convertisseur converti les données parallèles reçus en une trame (la taille réelle est à contrôler) de 8 Octets dans les deux sens (écriture et lecture).

Ce dialogue permet de piloter une machine (en fait de la régulation de processus, donc chaque action est fonction du résultat reçus) d'où un échange bidirectionnel intensif entre les deux systèmes mais de petite trame.

Supposons que pour envoyer ma trame de 8 octet je mette 500 µS (valeur à titre d'exemple et non réelle), et que pour faire mon processus j'ai besoin d'envoyer/recevoir 40 trames. Le temps pour effectuer le processus prendra 20 ms.

Supposons que pour envoyer ma trame de 8 octet + les 18 octets de la trame internet je mette 800µS (globalement plus rapide de le dialogue ci-dessus). mais pour mon processus de 40 trames il faudra 32ms donc presque le double de temps qu'auparavant.

Ceci dit aujourd'hui je ne connais pas les temps réels ni d'un système ni de l'autre, peut être que l'UDM ne posera pas de problème.

J'ai aussi cru lire quelque part que la trame ne pouvait pas être inférieure a environ 1500 octet suivant la version , ce qui prendra encore plus de temps que pour envoyer une trame de 18+8 octet.

VU que je ne connais rien à ce genre de dialogue (UDM) je suis preneur de toutes infos

Merci de vos réponses et autres infos.

[Paul TOTH]

la taille de trame est de 1500 octets en [ame="http://fr.wikipedia.org/wiki/Ethernet"]Ethernet II[/ame] en effet

[Mac LAK]

Houlà, du calme !! 1500 octets, c'est la taille MAXIMALE d'une trame Ethernet, et non pas sa taille "obligatoire" ! Cette valeur s'appelle le MTU, pour info.

La taille minimale UTILE d'une trame Ethernet, sinon, c'est un octet. Reste à prendre en compte les limitations inhérentes au protocole (notamment le CSMA/CD, qui peut différer l'émission réelle de la trame), et le délai de traversée du contrôleur Ethernet et de la couche basse de la stack (y compris en raw sockets).
En UDP, par contre, tu as une taille minimale de 64 octets "tout compris (trame utile + entêtes)" par trame.

Si tu as de telles contraintes temporelles, pourquoi n'envisages-tu pas éventuellement un bête RS-232 ? Les contrôleurs récents peuvent monter quasiment au mégabit par seconde en vitesse, et via les adaptateurs USB/RS-232, tu te garantis d'avoir toujours un bus à disposition...

Ou, si tu as le choix de la technologie, un bus USB "réel", malgré la limite de 5 mètres par segment qui t'obligerait à installer un câble actif et/ou un hub ?

[Paul TOTH]

la taille minimale des données est de 46 octets (RFC 894 - Frame Format). (toujkours sur WP)

[Mac LAK]

la taille minimale des données est de 46 octets (RFC 894 - Frame Format). (toujkours sur WP)

Tu as loupé la ligne suivante : si nécessaire, pour atteindre les 46 octets de données, un bourrage est effectué, et celui-ci est transparent au niveau utilisateur...
Donc, on a bien une charge utile variant de 1 à (MTU-18), même si effectivement il n'y a aucun changement de vitesse / débit entre 1 et 46 octets utiles transférés à cause du padding.