Wiznet W5100 contre Microchip ENCx24J600

Quels sont les avantages et les inconvénients de Wiznet W5100 ou Microchip EncX24J600?

C'est un peu compliqué à expliquer.

Ma question concerne les performances de la pile Microchip TCP par rapport au noyau Wiznet TCP / IP sur la puce. Aussi sur les coûts ($$).

Par exemple: Avec Wiznet, le microcontrôleur aura moins de traitement, libérant ainsi le microcontrôleur pour effectuer d'autres tâches. Mais je pense que cela dépendra de la couche sur laquelle vous travaillez.

Avec la pile Microchip TCP, j'ai peut-être des limitations sur les périphériques que je peux contrôler. Je vais peut-être devoir utiliser un deuxième microcontrôleur.

Donc, j'espère que je vous ai expliqué mieux maintenant pour que vous m'aidiez dans le meilleur choix.

Le W5100 possède un cœur TCP / IP sur la puce. Avec les appareils Microchip ENC, l'utilisateur doit implémenter lui-même une pile TCP / IP sur le MCU qui lui est interfacé. C'est assez facile avec un PIC approprié, car des piles TCP / IP gratuites sont disponibles auprès de Microchip.

Le W5100 a l'avantage de pouvoir être utilisé avec pratiquement n'importe quel MCU, mais un appareil assez puissant est nécessaire pour exécuter une pile TCP / IP si une puce ENC est utilisée.

Bien sûr, une autre option consiste à utiliser un MCU avec un MAC et un PHY intégrés. Microchip en fait de jolis, et il y a aussi des variantes ARM avec eux.

La société pour laquelle je travaille utilise le PIC18F97J60. Il s'agit d'un microprocesseur 8 bits avec un MAC et un PHY intégrés très similaires à l'ENC24J60. Si vous prévoyez d'utiliser un microprocesseur PIC, vous pouvez utiliser la pile Microchip TCP / IP. Cette pile fournit tout jusqu'à la couche application. Si vous utilisez un processeur non Microchip, je pense que vous ne pouvez utiliser que les pilotes ENC24J60. Cela dit, il semble que le Wiznet intègre les couches de transport dans le matériel, pas seulement le MAC et le PHY. Cependant, ils laissent au développeur le soin d'implémenter les couches d'application comme Telnet, FTP et HTTP.

Vous pouvez également envisager d'autres puces.

Qu'est-ce qu'un bon microcontrôleur pour les applications Ethernet?

Je sais que c'est vieux, mais il se trouve que j'ai fait cela avec un épice l'année dernière, donc je vais résumer pour le bien des autres.

Tout d'abord, je n'utiliserais pas le W5100, mais son frère W5500 , qui est essentiellement une révision, et utilise le SPI beaucoup mieux. J'envisagerais également de passer à une partie qui a du DMA, surtout si vous voulez le faire uniquement en UDP.

Dans les deux cas, vous utiliserez probablement la pile Microchip MLA TCP / IP, Wiznet fournit des correctifs pour cela.

Malheureusement, toutes les variantes de pile Microchip TCP / IP semblent bloquer la communication via SPI (pas de DMA, pas de mode de tampon amélioré) . J'ai essayé de le réduire à UDP uniquement et j'ai coupé toute la partie de la puce (en utilisant directement le pilote sous-jacent wiznet et en le réécrivant dans le processus).

Je suis également d'accord avec MJH que le PIC18F97J60 activé par DMA est un meilleur choix qu'un PIC moins cher avec ENC (à moins que vos chiffres ne soient vraiment élevés), mais j'ai été quelque peu déçu que le TCP / IP n'utilise pas vraiment les avantages du J60, en collant au plus petit dénominateur commun.

Les avantages de l'utilisation d'une partie IP au lieu d'une partie Ethernet est que vous pouvez limiter un socket à un certain port, et vous n'aurez pas à transférer de trafic non lié sur votre lien SPI. Le W5500 a 4 Ko par socket, et j'utilise des sockets séparés pour la réception et l'envoi afin de maximiser l'utilisation du tampon.

Ma pile UDP actuelle ne réagit que sur l'interruption wiznet et ne télécharge pas les données utiles dont elle n'a pas besoin. Je l'utilise UDP, basé sur des paquets (pas de flux) et j'utilise des diffusions sur les ports pour l'envoi (pour éviter d'avoir à mettre en cache les données MAC à des fins ARP, bien que rétrospectivement ce ne soit peut-être pas la meilleure optimisation).

Sur le dspice 60MIPS, un aller-retour (recevoir un petit paquet, répondre avec un petit paquet) prend environ 100-120us, dont environ 10-12us est le temps CPU en trois morceaux différents (pré-réception (3-5us), post-réception et envoi (5-7 nous selon) et après l'envoi (2us). Une fois tous les 2 Ko, je dois faire une maintenance qui représente environ 40us de temps de mur et 5us de temps CPU.

Les commandes courtes sont effectuées à l'aide d'un tampon amélioré. Plus long se fait en utilisant DMA en utilisant (sur dspice, DMA a besoin de 2 bits de temps entre les octets (ou mots en mode 16 bits), pas le tampon amélioré).

La suite n'est pas (encore) ouverte, mais si sb a besoin de pointeurs, merci de répondre dans les commentaires. Je prévois de porter la pile sur pic32 (mk) dans l'année à venir.