Module Ethernet

[xiantia]

Re a tous:

Je viens à vous car dans le cadre d'un projet perso, j'ai commandé des modules ENC-28j60 (interface ethernet vers un µP).
D'après le datasheet la puce est alimenté en 3.3V et c'est bien ce type de module que j'ai. Par contre la barrette de connexion du module a deux PIN en plus
marquées 5V / GND.

Je me demande si je peut alimenté ce module en 5V. Vous allez me dire en principe oui mais bon vue que ça vient de chine je voudrais pas les cramer.

Donc si des fois vous avez ce type de module (perso, école, ...)

On vois a gauche les PIN GND/3.3V et a droite 5V/GND (oui pas très visible)

IMAG0071.jpg

[miikkkllll]

Ah tien, j'avais commandé un module de ce type,


Résultat , pas de colis après 2 mois d'attente

Donc je ne peux pas t'aider

[xiantia]

Merde pas de chance

Moi j'en ais pris deux chez le chinois pour 6€ le tout et 18 jours pour la livraison, 6€ c'est même pas le pris de la fiche ethernet !

Bye Yannick

[xiantia]

re ::

Une petite confirmation , quelqu'un serait ce qu'est un "Dummy Byte" ? un octet qui sert a rien ou octet de bourra ?

Bye Yannick

[shrad]

tu as vu juste, c'est la traduction

[julienlev]

quelque chose me dit qu ece post est un indice pour le type d'interface utilisé par ton logiciel!!!

[xiantia]

Tout as fait

De plus je vous donnes quelques nouvelles. le module Ethernet est actuellement connecté a mon µP
J'ai bien galéré avec mon port série qui ne voulais pas fonctionné. Oui j'ai bien dit port série, il me permet d'envoyé des commandes au µP,
qui lui les re balance en mode SPI vers le module et inversement, afin de tester et se familiarisé avec le module.

Les premiers tests sont encouragent car la lecture/écriture des registres internes du module fonctionne. Reste a le configuré maintenant pour qu'il puisse traiter les trames réseaux ....

Bye Yannick

[xiantia]

re :

Initialisation du module fonctionnel
(petite précision, il est initialisé a partir du PC et non à partir du programme interne du µP à cet instant ) 63 octets a mettre en mémoire.

Il est donc prêt pour recevoir et envoyé des trames réseaux ....

Bye Yannick

[julienlev]

c'est cool ca avance bien ce petit projet...

[xiantia]

oui sauf que je reçoit bien des trames dans le module, mais rien en sortie pour le moment (

[miikkkllll]

Je suis ton petit projet avec attention,

Pour ce qui est de l'émission, comment cela fonctionne-t-il exactement?
Les trames sont directement envoyées du module Ethernet sur ton PIC (et vice-versa), ou alors le module "décortique" une partie des informations et ajoute ensuite tout ce qui est nécessaire pour que l'info transite sur le réseau?

[xiantia]

Voila après quelques erreurs d'initialisation de pointeurs du buffer d’envois, le module émet bien les trames

miikkkllll :
Je ne connais pas ton niveau dans le domaine des trames Ethernet, alors avant de pas assé ou trop en dire, donne mois plus d'info.

En ce qui concerne le module, il n'a pas trop d’intelligence, c'est un module générique, il peut donc faire pas mal de chose.
Il contient juste un filtre permettant d'avoir que les trames qui lui sont destiné. Et oui il faut ce taper les trames a la mimine

Par exemple (ce que j'ai tester) lorsque vous faites un ping depuis un ordi, celui-ci envoi une commande sur le réseau de type ARP.
Cette requete va permet au pc de "jumeler" les adresse physique avec les adresses logiciel.

commande "ping 192.168.1.32" -> requête ARP -> le destinataire ayant cette ip répond par un ARP reply indiquant sont adresse MAC (physique).
Maintenant le pc qui ping peut construire la trame de ping avec l'adresse logiciel (IP) et sont adresse matériel (MAC).

Voila a quoi ressemble une trame requête ARP:

Code: Select all

ff ff ff ff ff ff	// pour touts les destinataire (broadcasting)
54 55 58 10 00 24	// de ma part (addr MAC)
08 06				// type Ethernet ARP
00 01			// type de donné = Ethernet type
08 00			// ARP
06				// taille des champs MAC (6 octets)
04				// taille des champs IP (4 octets)
00 01			// request ARP
54 55 58 10 00 24	// mon adr MAC (sender)
c0 a8 01 21		// mon Ip  (sender)
00 00 00 00 00 00	// adr MAC (inconnue car je la demande) du pc qui
c0 a8 01 25		// a cette adresse Ip (receiver)

Maintenant le pc qui a cette adresse Ip va répondre par la même structure mais en remplaçant le ARP request par le ARP reply (0x02) et remplir le champs
inconnue par sont adresse MAC.

encArpRequest.png

On vois bien les trois trames que le module a émis "Broadcast ARP" qui a comme adresse MAC 54:55:58:10:00:24 / IP 192.168.1.33 et qui
demande qui a l'ip 192.168.1.37

Bye

[xiantia]

miikkkllll :

Pour répondre a ta question de qui envois les trames et qui les reçois, je doit expliquer comment sont relier les différents interfaces.

- un pc portable
- un convertisseur USB -> serie
- une carte µP a base de 68HC11 (oui il est vieux)
- un module Ethernet type ENC28j60
- un réseau Ethernet local.

Connexion :

PC <-> convertisseur USB/ serie <-> serie <-> carte µP <-> module Ethernet <-> réseau.

IMAG0072.jpg

Sachant que le PC est aussi relier au réseau, j'ai donc une boucle

Le programme interne du µP est une sorte de passerelle (firmware) serie/SPI, c'est a dire que j'ai implémenté les fonctions de base comme:
- fonction 0 = "ReadRegister"
- fonction 1 = "WriteRegister"
- ...

Après depuis mon portable j’envoie 0x00 sur le port série (fonction ReadRegister) , le µP attend maintenant le numéro de registre a lire, 0x09 par exemple,
le µP envois la commande au module qui répond par la valeur du registre et pour finir le µP envois cette valeur sur le port série.

Cela me permet de lire/écrire les registres du module. Le µP + PC peut être vu comme un programme de gestion/débugger du module Ethernet.

La phase d'initialisation du module est faite par le PC qui initialise 10/15 registres environ automatiquement. ( cette phase va être codé dans le µP par la suite).

Pour les lire/écrire des trames réseaux, d'autre fonction sont implémenté dans le firmware :
- fonction 3 = WriteBufferMemory
- fonction 4 = ReadBufferMemory

Ces deux fonctions permettent d’écrire et de lire les trames réseaux. Ces trames réseaux sont celle que l'on peut voir avec WireShark.
Le module comporte juste :
- un filtre MAC ( reception QUE des trames qui lui sont destiné, sort de mode "promiscuous" on/off)
- un system de pending de trame ( ajout de 000000000... dans la trame si celle-ci fait moins de 60octets)
- un system de calcul auto de CRC (code de contrôle)

Pour le reste ben tu te démerde a décoder la trame ( ARP, ICMP, IP, ....)

Voila je sais pas si ça répond aux questions.

By Yannick

[miikkkllll]

Génial l'explication !


Alors j'ai déja utilisé le 68HC11 à l'école. Au niveau des trames réseau, nous avions parcouru cela "vite fait". C'est à dire la structuration, comment la communication se fait, mais hélas aucune application pratique .


Par contre nous avions analysé et décortiqué plus en détail les trames d'un réseau embarqué CAN, standard dans le domaine automobile actuel. Il y a le message en lui même, complèté d'un identifiant. L'identifiant permet de définir qui a la priorité si deux émetteurs se retrouvent à utiliser la voix de communication. Exemple : ABS a un niveau 4, le GPS a un niveau 50 (le plus prioritaire : 0 , le moins prioritaire : 255). Prioritaire -> ABS. Et c'est logique !


Donc ma question était de savoir si le ENC28j60 s'occupait de "nettoyer" l'information pour ne donner que ce qui est utile au µP.

Merci pour tes explications. Il est vrai que le sujet est tout de même un peu complexe .

[miikkkllll]

Génial l'explication !


Alors j'ai déja utilisé le 68HC11 à l'école. Au niveau des trames réseau, nous avions parcouru cela "vite fait". C'est à dire la structuration, comment la communication se fait, mais hélas aucune application pratique .


Par contre nous avions analysé et décortiqué plus en détail les trames d'un réseau embarqué CAN, standard dans le domaine automobile actuel. Il y a le message en lui même, complèté d'un identifiant. L'identifiant permet de définir qui a la priorité si deux émetteurs se retrouvent à utiliser la voix de communication. Exemple : ABS a un niveau 4, le GPS a un niveau 50 (le plus prioritaire : 0 , le moins prioritaire : 255). Prioritaire -> ABS. Et c'est logique !


Donc ma question était de savoir si le ENC28j60 s'occupait de "nettoyer" l'information pour ne donner que ce qui est utile au µP.

Merci pour tes explications. Il est vrai que le sujet est tout de même un peu complexe .

[xiantia]

re :

Oui c'est bien le module qui gère le réseaux (collision , link fail, ...) tu as donc la trame utile accessible dans le buffer du ENC28j60,
après c'est au µP de décortiquer (analyser) la trame.
"C'est bien pour moi? (filtrage MAC destination), "Qui a envoyé le message (adresse MAC source)", "Type de message( ARP, IP, ICPM,..)", "Donnée du message (Ip source, ip destination, port source, port destination, ...)".
"Réponse a l'envoyeur" si nécessaire.

De même pour envoyer une trame, "De ma part MAC", "Pour toi (MAC) ,"Type de message", "Donnée du message (Ip source, ip destination, port source, port destination, ...)"

En ce qui concerne les priorités cela dépend du type de message, par exemple un flux vidéo doit avoir une priorité haute et en temps réel (protocole RTI). Mais pour nous pas besoin (enfin je pense), le module ce charge de l’émission en mode standard. Pour le DAC ça sera de l'internet protocole + message UDP.

Ps: il reste le "chat" si tu veut plus d'info. voir topic 'Carte des membres" pour la connexion depuis votre navigateur.
Bye

[tek-man]

J'utilise aussi le vieux µc 68HC11
Je trouve ton projet vraiment bien, bon courage pour la suite

[xiantia]

Re:

Petit état d'avancement :

Phase d'initialisation du module maintenant implémenté dans le µP, Ok

Récupération des trames reçues par un dump mémoire du module par le pc, Ok.
Envois d'une trame faite par le PC puis envoyé au module, Ok.(vue avec wireshare)

Par contre le peut de EEPROM dans le HC11 va m’obliger à utiliser une petite EEPROM i²c 24LC16 bien connue afin de continuer les tests.
Passage par la suite dans un petit PIC (le 16F84 devrait convenir) et il est connue aussi

Ça avance pas mal car le plus dur est fait !

Bye

[shrad]

un conseil....

utilises un autre PIC comme le 18F2550 ou 18F4550

support USB en natif, mutiplication 8bit en une instruction, pas de switch de banques... programmable en C, et toutes les librairies dispos gratuitement chez microchip... y compris celle de ta pile TCP

[xiantia]

un conseil....

utilises un autre PIC comme le 18F2550 ou 18F4550

support USB en natif, mutiplication 8bit en une instruction, pas de switch de banques... programmable en C, et toutes les librairies dispos gratuitement chez microchip... y compris celle de ta pile TCP

Salut Shrad :

Le but est de faire un DAC lowcost Ethernet. 3€ de module chez le chinois, un pic a 2/3€ , une eeprom a 2/3€ soit 10€ environ juste pour la communication et la gestion du DAC en lui même.

Pour le PIC16F84, si j'en parle, c'est parce que j'en ais plein les poches, ça aide pour les tests et facile à prendre en main.

USB , , je suis allergique à ce truc (au niveau programmation) toujours un driver qui merde ou autre, de plus je tourne sous Linux alors les logiciels avec driver usb c'est pas a 100% fonctionnel. Même si il existe MPlab pour Linux de mémoire.

Je programme tous les jours en C/C++ donc le code, pas de pb pour moi, par contre je trouve que la compilation C -> asm -> hex n'est pas optimisé, pis j'aime bien savoir ce que fait le truc. Je fait donc le code en ASM moi même. Pour info l'initialisation du ENC28j60 tien en moins de 420 octets contre plus de 1Ko avec le lib pour Arduino. (ok il y a aussi des fonctions en plus).

Pour la pile TCP , j'en ais pas besoin, les trames réseaux que j'utilise et celle auxquelles je doit répondre sont simples. Et de toute façon, que ça soit fait maison ou à partir d'une lib .... ça rentre dans le µP.

Peut être par la suite si le DAC fonctionne correctement, pourquoi pas un autre PIC, oui .... pour afficheur / lecture de carte / ..... déporté.

Bye Yannick

[shrad]

salut

pour l'USB pas de soucis il y a une lib C et une lib ASM normalement, et le peripherique par defaut correspond a un port serie virtuel allant jusqu'a 115Mbps, donc aussi facile que n'importe quelle com serielle (deux buffers a gerer et c'est tout)

ca reste aussi un micro pas cher et on l'a en echantillon gratuit facilement

apres c'est comme tu veux, mais les performances du 16F85 sont franchement limitees par rapport aux 40Mips du 18F2550/4550 et il y a meme un bootloader USB compatible pickit2 qui va avec...

[xiantia]

re :

Héhé oui le 16F84 est pas très rapide comparé aux nouvelles versions de PIC, mais il est sûrement plus rapide que mon HC11
Déjà je vais voir la vitesse (en Kpps théorique) avec HC11 (faut pas compter avoir 200Kpps avec !!) et comme je le maîtrise pas trop mal je vais pourvoir avoir des valeurs de teste cohérentes. Avec quelques calcul on doit pouvoir tout de même approcher les 100Kpps avec le module Ethernet (vitesse µP mis a part).

donc je garde la ref du PIC en mémoire au cas ou ...

Bye Yannick

Note : Actuellement, extraction de la trame réseaux reçue Ok, reste a l’interpréter et répondre.
Je vais donc implémenter la réponse à la requête ARP et au ping (qui est la base)

[julienlev]

a savoir que déjà si tu arrive a faire du 40kpps ça sera très bien, par exemple quickshow ne dépasse pas les 30kpps!

[xiantia]

Merci de l'info Julien.

A ce sujet j'aimerais, si une personne est disponible, vérifier mes calculs ( sans donner comment j'ai fait pour ne pas être faussé ).

Alors sachant que le réseaux est a 10Mbit/s et que je diffuse des paquets de 100 pts (X,Y, R,G,B le tout sur 2 octets) , cela fait une trame de 100 * 10 = 1000 octets. A ajouter 60 octets de trame de transport, soit un total 1060 octets pour 100 pts.

Alors à combien au maximum on peut monter en kpps si on admet que le réseau ne fera pas autre chose et que le µP suis ?

Bye Yannick

[julienlev]

d'après mes calculs rapides ça fait 102294000 points par seconde! ... je pense que les scanners ne suivront pas!!

[djbastien]

julien c'est pas possible d'être à 102Mpps avec un débit à 10Mbit/s

@xiantia:
1060 octets = 8480 bits
soit 1236 paquets par seconde et 12360 pps si ton bus est utilisé à 100% ce qui est impossible donc c'est un peu juste.

[shrad]

il te faut imperativement 100Mbps

et le pic16f84 ne suivra certainement pas, je doute meme que le 18f2550 suive aussi

je pense plus a un MSP430 ou pic32 avec au moins 100 MIPS et de quoi suivre la com

[xiantia]

j'ai pas dit que j'envoyé les paquets toutes les secondes ?

par contre oui c'est bien 8xxx bit/s, faut donc connaître maintenant le temps de transfert de cette trame qui contient 100pts.
Puis calculer le temps entre chaque point pour du 20kpps par exemple et calculer le temps de lecture pour les 100pts a 20Kpps.

Et finalement en déduire la vitesse max en kpps.


Bye yannick

[julienlev]

j'ai du me planter quelque part...
1kbit =1024 bit
1Mbit=1024 Kbit
10Mbit/s = 10485760 bit par secondes...
ce qui nous donne en octet: 1310720 oct/s
vu qu'une trame prend 1060 octets ça nous fait 1236,5283018867924528301886792453 trames par secondes
et vu que dans une trame on a 100 points ça nous fait 123652,83018867924528301886792453 points par seconde
Soit en arrondissant 120Kpps, mais je dois avoir faux quelque part!

[xiantia]

ha, 117Kpps pour moi, donc ça doit bien être ça. Si une autre personne peut nous le confirmer ?

Bye Yannick

[djbastien]

ah oui j'ai oublié un x10 quelque part ^^

En tous cas c'est sûr que le pic ne suivra pas!
le 18f25k22 peut monter à 64MHz mais seulement 16MIPS je crois.
après tout dépend de ce que tu veux lui faire faire. Si il est occupé à 100% avec l'ethernet pourquoi pas sinon va falloir passer sur du PIC32.

[julienlev]

youhou je me suis pas planté!

[xiantia]

re:

Le ARP request fonctionne c'est a dire que lorsque je veut faire un ping sur le module, une requête ARP est générée (recherche de l'host qui as l'ip 192.168.1.33 pour connaître sont adresse physique xx:xx:xx:xx:xx:xx).

Un fois l'adresse physique connue (celle du module puisqu'il a repondu) le ping commence en tant que tel. Et la ça fait 2 heures que je cherche pourquoi le module n'avait pas le ping request !!!! Ce con de module marche en Little india pour l'address physique (MAC).
Maintenant j'ai bien la demande ping. Reste a répondre

Ça commence prendre tournure !

ArpRequest and ping request.png

Bye Yannick

[xiantia]

Yes !!

Ping fonctionnel ! le tout dans un pauvre 68Hc11 en "Program : 640 bytes, Reserved : 139 bytes [789 bytes], Ram : 6 bytes".
Bon j'approche les 1Ko de mémoire max du µP

On vois déjà que le µP va pas très vite comparé à ceux de nos PC. mais pas si mal que cela.

Le ping de mon serveur :
"64 bytes from 192.168.1.20: icmp_req=17 ttl=64 time=1.44 ms"

Ping module/HC11:
"64 bytes from 192.168.1.33: icmp_req=7 ttl=64 time=27.1 ms"

1.44 ms contre 27.1 ms en provenance du module.

Mais bon je m'en fou ! le test est bon. Youpi.

By Yannick

[djbastien]

super!
ça avance bien!
effectivement on voit bien que le HC11 est lent...
Va falloir mettre un PIC qui pédale!