MISE EN PLACE D'UNE CONNECTIVITE IP 802.3 10BaseT A UN EQUIPEMENT ELECTRONIQUE

Patrice KADIONIK kadionik@enseirb.fr

http://www.enseirb.fr/~kadionik

MAJ du : 07-Fév-2003

17/09/01 version 3.0 : Description de la solution eZ80

10/09/01 version 2.0 : Description de la solution IPC@CHIP de Beck.

15/06/01 version 1.0 : Version initiale

TABLE DES MATIERES

1. INTRODUCTION *

2. RAPPELS TECHNIQUES *

3. SOLUTIONS MATERIELLES *

4. SOLUTIONS LOGICIELLES *

5. SOLUTIONS MIXTES *

6. CONCLUSIONS *

1. INTRODUCTION

Cette étude se propose de présenter des solutions matérielles et logicielles pour réaliser cette connection à un réseau de type Ethernet :

• liaison Ethernet 10 Mb/s 10BaseT
• connexion de type RJ 45

• couches de protocoles IP, TCP, UDP : il convient de voir si l'on peut trouver ces briques logicielles s'interfaçant aux matériels à mettre en oeuvre précédemment. Il convient aussi de voir si des solutions freeware ou du type GPL (Gnu Public Licence) existent.
• services de l'Internet : HTTP (serveur web), mail : il convient de voir si l'on peut trouver ces briques logicielles s'interfaçant aux couches logicielles précédentes. Il convient aussi de voir si des solutions freeware ou du type GPL (Gnu Public Licence) existent.

La présentation des solutions retenues pour cette étude se fera de façon down/top en partant du matériel au logiciel. Les solutions complètes intégrant les 2 aspects seront présentées en dernier lieu.

2. RAPPELS TECHNIQUES

Cette partie se propose de faire le point sur les protocoles de l'Internet en décrivant leur mise en oeuvre sur Ethernet suivant la méthode d'accès IEEE 802.3. Les explications données ici seront ensuite exploitées dans les parties suivantes.

L’IAB (Internet Architecture Board) coordonne la recherche et le développement autour d'Internet. Toutes les informations sur les protocoles de la famille Internet sont centralisées et distribuées par le NIC (Network Information Center). Ces rapports numérotés chronologiquement sont connus sous le nom de RFC (Request For Comments).

Internet désigne en fait une famille d’une vingtaine de protocoles dont font partie les protocoles TCP, UDP et IP. En réseau local, moins d’une dizaine d’entre eux sont utilisés. Internet se positionne d’emblée comme un protocole d’interconnexion de réseaux hétérogènes. A ce titre, il est totalement indépendant des couches basses et du support de transmission (Ethernet, Token Ring, X.25). Il recouvre les couches 3 à 7 du modèle OSI (Open System Interconnexion) sans qu’il puisse y avoir de corrélation précise entre les couches de l'Internet et celles du modèle OSI. En effet, Internet est bien antérieur au modèle OSI (1983).

Une des raisons de la popularité d'Internet provient de l’adaptabilité de ses protocoles à la plupart des réseaux et média. Par l’expression "interface matérielle", il faut comprendre le support de transmission associé et sa méthode d'accès MAC (Medium Access Control) correspondant globalement aux niveaux 1 et 2 du modèle OSI.

La sous-couche MAC se charge des méthodes d’accès utilisées pour contrôler l’accès au support physique du réseau. Dans le cas d'un réseau de type Ethernet, c’est le protocole d'accès CSMA/CD (Carrier Sense Multiple Access / Collision Detection) géré par la couche MAC qui assure ce service.

La sous-couche LLC peut s’interfacer avec n’importe quel réseau LAN (Local Area Network) de type 802.x (Ethernet, Token Bus, Token Ring,...). Il a pour objectif de masquer à la couche 3 (IP ici) les différences inhérentes aux réseaux LAN 802.x sous-jacents.

Ce protocole est défini par la RFC 791. La couche IP a pour but d’acheminer un paquet de données entre une station source et une station destinataire qui peut être située sur le même segment de réseau ou sur des réseaux différents reliés par un ou plusieurs routeurs. Chaque paquet est une entité qui est absolument indépendante de toutes les autres. IP n’offre qu’un service de type remise de datagrammes, c’est-à-dire d’unités de données en mode non connecté donc un service non fiable. Il ne s’occupe pas du contrôle de flux de données et ne propose aucun mécanisme de contrôle de séquencement des datagrammes ou de contrôle d’erreur.

Le protocole IP, mode non connecté, ne définit de qualité de service (QoS), on parlera plutôt de best effort. On transmet des datagrammes IP de taille variable et au plus de 65536 octets (en pratique il est assez rare que la taille du datagramme soit supérieure à 1500 octets).

Un datagramme IP est constitué de deux champs :

• un champ entête (20 octets + une partie optionnelle variable).
• un champ de données qui constitue la charge utile.

bit F : Fragmentation autorisée ou non

bit M : More pour indiquer la suite ou non

• Position fragment (13 bits) : précise la localisation ou le déplacement du fragment dans le datagramme courant.
• Temps de vie (8 bits) : compteur utilisé pour limiter la durée de vie des datagrammes. Il décompte le temps de séjour en sauts du datagramme dans le réseau avec une limite maximale de 255 sauts. Chaque noeud traversé décrémente le compteur et lorsque celui-ci arrive à 0, il y a destruction du datagramme.
• Protocole (8 bits) : lorsque la couche réseau du destinataire a assemblé un datagramme complet, l'application supérieure a besoin de savoir quoi en faire et comme l'interpréter. Ce champ lui indique par un numéro à quel protocole de transport le confier (01 pour ICMP, 06 pour TCP, 17 pour UDP, 29 pour TP4-ISO).
• Somme de contrôle (16 bits) : vérifie exclusivement la validité de l'entête.
• Adresse source/destination (32 bits x2) : adresse IP appelant/appelé.
• Options : ce champ facultatif de longueur variable fut conçu pour offrir une extension aux évolutions du protocole et permet d’effectuer des tests et des mises au point sur le réseau (sécurité, horodatage).
• Bourrage (Padding) : bits de bourrage pour que l’entête ait une longueur multiple de 32 bits.

Chaque ordinateur et chaque routeur du réseau Internet possède une adresse IP unique au monde. Toutes les adresses sont exprimées sur 32 bits (pour IPv4) et sont utilisées dans les champs adresse source et adresse destination des datagrammes IP. Les ordinateurs connectés simultanément sur plusieurs réseaux ont des adresses différentes. Cette attribution d'adresse IP est gérée par un organisme, le NIC (Network Information Center), organisme officiel dépendant de l'ISOC (Internet SOCiety).

Le protocole IP dispose donc de son propre adressage. Ainsi, en ce qui concerne la compatibilité avec les couches inférieures, le protocole IP peut s’appuyer sur différentes interfaces réseau. Parmi celles-ci, les plus utilisées concernent le standard Ethernet IEEE 802.3 présenté après, Token-Ring (IEEE 802.5), X.25, FDDI ou des interfaces asynchrones type SLIP (Serial Line Internet Protocol) ou PPP (Point to Point Protocol).

TCP est un protocole de transport de bout en bout en mode connecté, chargé d’assurer un transport fiable de données. L’unité d’échange de ce protocole est le segment. Ils sont aussi bien utilisés pour l’établissement de la connexion que pour les acquittements, les transferts de données…

TCP ne définit qu'un seul format de segment. Son entête est donc prévu à la fois pour le transport des données, les acquittements et les commandes. Il comporte des informations d’identification et de contrôle.

Les numéros de port source/destination indiquent les numéros de port TCP qui identifient les applications source et destination aux extrémités de la connexion.

Le numéro de séquence donne la position du segment dans le flux de l’émetteur.

Le numéro de séquence acquitté (ou d’accusé de réception) indique le numéro du prochain octet attendu par le récepteur.

La longueur de l'entête (LGR) donne, en multiple de 4 octets, la longueur de l'entête du segment TCP.

Les segments peuvent transporter des acquittements ou des données. Pour les différencier, on utilise des bits de code qui déterminent ainsi le rôle et le contenu d’un segment :

URG valide le champ pointeur sur les données urgentes.

ACK valide le champ numéro de séquence.

PSH demande de délivrer immédiatement les données en attente.

RST demande la réinitialisation de la connexion (suite à la détection d'une anomalie grave).

SYN pour l'échange et l'acquittement des numéros de séquence (synchronisation).

FIN demande de déconnexion.

Le champ fenêtre indique la taille de la fenêtre en réception.

Le total de contrôle est calculé sur l'ensemble du segment TCP.

Le pointeur sur données urgentes pointe sur le dernier octet urgent du champ de données.

Le champ des données d’un segment TCP est constitué des éléments suivants :

Options qui sont facultatives. On y trouve des renseignements concernant par exemple la taille maximale d’un segment. En effet tous les segments n’ont pas la même taille, mais les deux systèmes d’extrémité doivent être en mesure de les accepter. Pour cela ils définissent une Taille Maximale de Segment (MTU, Maximum Transport Unit).

Les bits de bourrage pour s’assurer que la taille du segment est un multiple de 32 bits.

Les données.

La relation avec les couches supérieures s’effectue par l’intermédiaire des ports logiques (sockets) qui désignent les entités TCP à chaque extrémité. C’est la recommandation RFC 960 qui fixe les numéros de ports utilisés par les applications distantes. Le numéro de port correspond en fait au point d'accès au service OSI (Service Access Point).

C’est un protocole de transport (recommandation RFC 768) orienté datagramme destiné au transport rapide de messages au travers d’un réseau. Il est utilisé par de nombreux applicatifs importants dont DNS (serveur de nom de domaine), NFS (système de fichiers réparti) et SNMP (gestion de réseau). Contrairement à TCP, UDP est non fiable et travaille en mode non connecté.

L’identification d’un service UDP par un client s’effectue comme sur TCP par une adresse formée par la concaténation de l’adresse IP et d’un numéro logique de port.

L’entête UDP a une structure simple :

Outre les fonctions d’adressage des applications clientes, UDP autorise en option un contrôle portant sur l’intégrité des données. UDP assure donc la détection d’erreur, mais pas la reprise sur erreur. Il n’utilise pas les accusés de réception pour garantir que les données ont été correctement réceptionnées, ne reséquence pas les messages reçus et n’assure pas de mécanisme de contrôle de flux pour permettre au récepteur de maîtriser le flot des données. Les datagrammes UDP peuvent donc être perdus, dupliqués ou déséquencés.

Néanmoins, la grande qualité d’UDP est sa simplicité. L’absence de mécanisme de connexion et de contrôle de flux (par opposition à TCP) accélère l’échange des données. UDP fonctionne de manière satisfaisante et performante en réseau local, ces derniers étant très fiables et minimisant les risques d’erreurs de transmission

2.8. AUTRES PROTOCOLES INTERNET

ICMP (Internet Control Message Protocol) : Ce mécanisme (recommandation RFC 792) inclus dans le protocole IP est un message destiné au logiciel de la machine destinataire. Il permet la communication entre différentes stations ou routeurs qui peuvent ainsi échanger des messages d’erreurs ou de contrôle. Les messages de contrôle fournis par ce protocole permettent de rendre compte des erreurs rencontrées durant la transmission de datagrammes IP et peuvent pallier ainsi la lacune ou l’absence d’un système de gestion de réseau. Le champ protocole de l’entête IP permet d’identifier ICMP avec la valeur $0001. Les données ICMP sont mises dans le champ données de IP.

ARP (Address Resolution Protocol) : Ce protocole, défini par la recommandation RFC 826, permet la résolution d’une adresse IP en une adresse physique du réseau physique sous-jacent (adresse MAC). Chaque système hôte sur lequel est implémenté le protocole ARP dispose d’une table de translation des adresses Internet @INT en adresses physiques @PHY. Ainsi, lorsqu’un système émet un datagramme IP, 2 cas peuvent se produire :

Comme pour IP, le champ longueur de données des trames IEEE 802.3 est utilisé pour identifier le code $0806 désignant le protocole ARP.

BOOTP (BOOTstrap Protocol) : Protocole qui permet à un client d'interroger un serveur pour savoir quelle est son adresse IP en fonction de son adresse physique sur le réseau. Il est souvent utilisé pour permettre à des stations sans disque de booter et d'être automatiquement configurées (acquisition de leur adresse IP).

SNMP (Simple Network Management Protocol) : Protocole de gestion et de réseau. SNMP utilise UDP comme protocole de communication, ce qui n’offre aucune garantie quant à la sécurisation du transport.

DNS (Domain Name System) : Comme SNMP, ce service se suffit d’un service de transport tel que UDP. Il permet la traduction d’une adresse symbolique toto.titi.fr plus facile à mémoriser et à utiliser en une adresse IP.

XDR (eXternal Data Representation) : C’est un protocole du niveau de la couche de représentation du modèle OSI. Il permet d’encoder des données de manière standard pour lever tous les problèmes d’hétérogénéité entre les plateformes.

RPC (Remote Procedure Call) : Ce protocole offre aux développeurs d’applications un mécanisme permettant de réaliser des appels à des procédures distantes.

Ces deux derniers protocoles ont été créés par Sun Microsystem en 1986, en vue du développement de NFS (Network File System) et du NIS (Network Integration Service).

Ethernet est une architecture de réseau local conçue par Xerox dès 1972 normalisée par l'IEEE (IEEE 802.3) (norme ISO 8802.3).

Ethernet est construit autour d’une topologie de type bus ou étoile, où tous les hôtes partagent de façon équitable le support de transmission. Ainsi, il n’existe qu’un seul chemin entre chaque paire de noeuds du réseau.

Le format d'un trame Ethernet 802.3 est donnée ci-après :

Préambule : 64 bits de synchronisation formés par une alternance de 1 et 0 avec les deux derniers bits à 1.

Adresse destination : adresse physique (adresse Ethernet) de la station devant recevoir la trame. Les 3 premiers octets de cette adresse sont imposés par l’IEEE aux fabricants de contrôleurs, ce qui garantit son unicité. Il y a diffusion si tous les bits sont à 1.

Adresse source : adresse Ethernet de la station ayant émis la trame.

Type : identifie le protocole de niveau supérieur (niveau 3) associé au paquet. Pour le protocole IP, la valeur de ce champ en hexadécimal est $0800.

Données : les informations à transporter.

CRC (Cyclic Redundancy Check, Code de Redondance Cyclique) : c’est un code de bloc cyclique portant sur tout les bits qui précèdent sauf ceux du préambule. Le destinataire recalcule ce code et peut déterminer par comparaison avec le CRC véhiculé si la trame est intègre.

En ce qui concerne son fonctionnement interne, Ethernet utilise la méthode d’accès CSMA/CD (Carrier Sense Multiple Access / Collision Detection). Ce protocole est mis en oeuvre au niveau de la couche liaison par la sous-couche MAC (Medium Access Control). Lorsqu’une station désire émettre sur le réseau, elle commence par examiner si la voie est libre, c’est-à-dire si le support de transmission est occupé ou non. Si une transmission est en cours, la station attend jusqu'à ce que la voie se libère, puis elle effectue sa transmission. Il peut évidemment se produire des collisions en raison du nombre d’équipements qui se partagent le support de communication. Lorsqu’une collision se produit, la station émettrice interrompt sa transmission et transmet des bits de bourrage pour avertir les autres stations du réseau de la collision. La station reprendra sa transmission ultérieurement en fonction d’un algorithme défini. La détection des collisions se fait par comparaison entre le signal émis par la station et le signal circulant sur le support de communication.

Sur Ethernet, les mécanismes assurant la correspondance entre l’adresse IP et l’adresse Ethernet sont basés sur le protocole ARP (Address Resolution Protocole) ou RARP (Reverse Adresse Resolution Protocole) pour la résolution d'adresse inverse.

Dans ce processus de résolution d’adresse, la relation entre ARP, IP et Ethernet au niveau de la couche de protocole et de la couche d’implémentation est résumée sur la figure ci-après.

Le paquet ARP est encapsulé dans la trame de couche de liaison de données du réseau IEEE 802.2 :

La communication entre 2 systèmes est réalisée par l’empilement de protocoles et s’effectue en encapsulant les données des couches supérieures d’une suite d’informations qui seront traitées à l’arrivée par la couche de niveau équivalent.

En ce qui concerne l’interface IP/Ethernet pour un datagramme IP dans une trame IEEE 802.3, celle-ci est definie par la recommandation RFC 1042. Les formats des champs LLC (Logical Link Control) et SNAP (Sub-Network Access Protocol) doivent être les suivants :

• LLC (3 octets) = DSAP + SSAP + Control avec DSAP=170, SSAP=170 et Control=3
• SNAP (5 octets) : Protocol ID = 0 sur 3 octets Ethernet Type = $0800 en hexadécimal

Les services de base d’Internet sont essentiellement les suivants :

3. SOLUTIONS MATERIELLES

3.1. INTRODUCTION

Il convient de revenir à la figure 1. Avec une intégration sur silicium de plus en plus importante, les solutions logicielles d'hier deviennent des solutions matérielles d'aujourd'hui avec le gain en rapidité d'exécution et de décharge pour le microprocesseur qui en découle.

Figure 10 : Evolution entre solutions matérielles et logicielles

Il semble que l'évolution des solutions matérielles se fasse au détriment des solutions logicielles pour le grand bien du concepteur !

Au minimum, la solution matérielle doit implémenter l'interface MAC, l'interfaçage physique au médium se faisant par l'ajout d'un transformateur de ligne externe.

On trouve aujourd'hui des solutions matérielles intégrant en plus le niveau IP, TCP et UDP mais avec des restrictions sur la nature du médium à mettre en œuvre.

Une solution idéale serait du dernier type avec un accès physique 10BaseT.

3.2. SOLUTION MATERIELLE 1 : CRYSTAL CS8900A

CIRRUS LOGIC propose depuis 2 ans un circuit d'interface 802.3 très intéressant : le CS8900A (voir annexe). Son architecture est résumée sur la figure 11.

Figure 11 : Architecture du circuit CS8900A

Ce circuit est un contrôleur Ethernet 802.3 full duplex qui implémente le niveau MAC au niveau hardware. Il implémente une interface ISA et fonctionne sous 5 V et 3,3 V. Son interface réseau préférentielle est 10BaseT (RJ45) mais il possède une interface AUI pour les modes 10Base2, 10Base5 et 10BaseF. Les filtres d'émission et de réception sont incorporés. Il se présente comme un boitier TQFP 100 broches. Son réel intérêt réside dans son interfaçage au logiciel. Il est accessible en mode I/O (16 octets d'espace d'adressage) mais aussi en mode MEMoire (2 Ko d'espace d'adressage) pour des raisons de performance. Les transferts DMA sont aussi autorisés.

L'intérêt du mode I/O est évident : le CS8900A peut s'interfacer facilement avec des microcontrôleurs/microprocesseurs 8 bits tels que les PIC, 68HC11 (voir annexe, AN181).

Son prix est abordable : 61,10 F HT par 10 chez Newtek !

Crystal fournit gratuitement les drivers pour les environnements linux, Microsoft Windows, pSOS, VxWorks, SCO...

En fait, ces drivers permettent l'interfaçage entre le niveau MAC du CS8900A et les protocoles Internet de niveau supérieur (IP, TCP, UDP) que doit implémenter le système d'exploitation pour la connectivité Internet.

Dans le cas où l'on n'utilise pas de systèmes d'exploitation classiques, il convient d'implémenter ces piles de protocoles ou de les acheter. On notera que la pile de protocoles Internet Treck présentée après supporte le circuit CS8900A.

Le tableau de la figure suivante résume les points importants de cette solution matérielle.

Adresse web	www.cirrus.com
Solution	Matérielle Circuit CS8900A TQFP 100 broches
Interfaces Ethernet	802.3 10BaseT, 10Base2, 10Base5 full duplex
Implémentation niveau MAC	Oui
Implémentation niveau IP	Non
Implémentation niveaux TCP, UDP	Non
Fonctionnalités	Interface ISA Modes I/O et MEM DMA
Schémas de principe d'utilisation	Oui
Qualité de la documentation	Excellente
Facilité de programmation	Oui
Drivers fournis	Oui Microsoft Windows Linux PSOS, VxWorks SCO
Prix des drivers	Gratuit
Prix du composant	61,10 F HT (par 10) revendeur : Newtek
Support après vente	Oui Hotline, SOS par mail Cirrus propose gratuitement de qualifier tout design à base du circuit CS8900A

Figure 12 : Résumé de la solution matérielle 1 : CRYSTAL CS8900A

Cette solution matérielle convient idéalement aux besoins. Concernant les protocoles Internet, un couplage avec les produits Treck est possible ou mieux avec des solutions GPL de type linux embarqué (projet Open Hardware, produit EZ328SIMM).

3.3. SOLUTION MATERIELLE 2 : REALTEK RTL8019AS

REALTEK propose un circuit d'interface 802.3 très intéressant : le RTL8019AS (voir annexe). Son architecture est résumée sur la figure 13.

Figure 13 : Architecture du circuit RTL8019AS

Ce circuit est un contrôleur Ethernet 802.3 full duplex qui implémente le niveau MAC au niveau hardware. Il implémente une interface ISA et fonctionne sous 5 V. Son interface réseau préférentielle est 10BaseT (RJ45) mais il possède une interface AUI pour les modes 10Base2, 10Base5. Il se présente comme un boitier PQFP 100 broches. Il est accessible en mode I/O.

L'intérêt du mode I/O est évident : le RTL8019AS peut s'interfacer facilement avec des microcontrôleurs/microprocesseurs 8 bits tels que les PIC, 68HC11.

REALTEK fournit gratuitement les drivers pour les environnements linux, Microsoft Windows, SCO...

En fait, ces drivers permettent l'interfaçage entre le niveau MAC du RTL8019AS et les protocoles Internet de niveau supérieur (IP, TCP, UDP) que doit implémenter le système d'exploitation pour la connectivité Internet.

Dans le cas où l'on n'utilise pas de systèmes d'exploitation classiques, il convient d'implémenter ces piles de protocoles ou de les acheter.

Le tableau de la figure suivante résume les points importants de cette solution matérielle.

Adresse web	www.realtek.com.tw
Solution	Matérielle Circuit RTL8019AS PQFP 100 broches
Interfaces Ethernet	802.3 10BaseT, 10Base2, 10Base5 full duplex
Implémentation niveau MAC	Oui
Implémentation niveau IP	Non
Implémentation niveaux TCP, UDP	Non
Fonctionnalités	Interface ISA Modes I/O
Schémas de principe d'utilisation	Oui
Qualité de la documentation	Bonne
Facilité de programmation	Oui
Drivers fournis	Oui Microsoft Windows Linux SCO
Prix des drivers	Gratuit
Prix du composant	? revendeur : inconnu
Support après vente	Non

Figure 14 : Résumé de la solution matérielle 2 : REALTEK 8019AS

Cette solution matérielle convient aux besoins. Le circuit n'est pas supporté pour l'instant par les produits Treck. On pourra remarquer la très grande similitude avec le circuit CRYTAL CS8900A même au niveau du brochage !

3.4. SOLUTION MATERIELLE 3 : AMD 79C9xx

AMD, leader dans les circuits d'interface réseau propose lui aussi des circuits d'interface 802.3 basé sur son célèbre circuit LANCE 7990 : les circuits de la série 79C9xx (voir annexe). Le circuit intéressant dans cette série est le 79C940 ou circuit MACE (Media Access Controller for Ethernet). Son architecture est résumée sur la figure 15. Il a été spécialement conçu pour les applications embarquées 16 bits.

Ce circuit est un contrôleur Ethernet 802.3 full duplex qui implémente le niveau MAC au niveau hardware. Son interface réseau préférentielle est 10BaseT (RJ45) mais il possède une interface AUI pour les modes 10Base2, 10Base5 et 10BaseF. Il se présente comme un boitier TQFP 80 broches ou PLCC 84 broches. Il est accessible en mode I/0. Les transferts DMA sont aussi autorisés avec 2 FIFOs d'émission et de réception.

AMD fournit gratuitement les drivers pour les environnements linux, Microsoft Windows, VxWorks, SCO...

Comme pour la solution matérielle 1, ces drivers permettent l'interfaçage entre le niveau MAC du CS8900A et les protocoles Internet de niveau supérieur (IP, TCP, UDP) que doit implémenter le système d'exploitation.

Dans le cas où l'on n'utilise pas de systèmes d'exploitation classiques, il convient d'implémenter ces piles de protocoles ou de les acheter. On notera que la pile de protocoles Internet Treck présentée après supporte le circuit 79C940.

AMD propose dans cette série d'autres circuits avec le même cœur mais possédant en plus une interface bus :

• Circuit 79C961A : circuit Pcnet ISA avec interface ISA.
• Circuit 79C965 : circuit Pcnet-32 avec interface VESA, bus local 486.
• Circuit 79C970A : circuit Pcnet PCI avec interface PCI.

Ces circuits sont à utiliser avec des processeurs Intel x86.

Le tableau de la figure suivante résume les points importants de cette solution matérielle.

Cette solution matérielle convient aussi aux besoins. Concernant les protocoles Internet, un couplage avec les produits Treck est possible ou mieux avec des solutions GPL de type linux embarqué (projet Open Hardware, produit EZ328SIMM).

3.5. SOLUTION MATERIELLE 4 : NATIONAL DP83905

National Semiconductor a aussi un circuit d'interface 802.3 : le circuit DP83905 (voir annexe). Son architecture est résumée sur la figure 17.

Figure 17 : Mise en oeuvre du circuit DP83905

Ce circuit est aussi un contrôleur Ethernet 802.3 full duplex qui implémente le niveau MAC au niveau hardware. Son interface réseau est 10BaseT (RJ45) mais possède aussi une interface AUI. Il implémente une interface ISA. Il se présente comme un boitier TQFP 160 broches. Il a par contre besoin de RAM externe, ce qui peut être vu comme un désavantage par rapport aux solutions précédentes.

National ne fournit pas de drivers pour les environnements classiques mais assure que son circuit est compatible avec les drivers Novell NE2000.

On notera que la pile de protocoles Internet Treck présentée après supporte le circuit DP83905.

Le tableau de la figure suivante résume les points importants de cette solution matérielle.

Adresse web	www.national.com
Solution	Matérielle Circuit DP83905 TQFP 160 broches
Interfaces Ethernet	802.3 10BaseT, 10Base2, 10Base5 full duplex
Implémentation niveau MAC	Oui
Implémentation niveau IP	Non
Implémentation niveaux TCP, UDP	Non
Fonctionnalités	Modes I/O RAM en plus en externe
Schémas de principe d'utilisation	Non
Qualité de la documentation	Moyenne
Facilité de programmation	Moyenne
Drivers fournis	Non Compatible NE2000
Prix des drivers	-
Prix du composant	9,5 $ (par 1000) revendeurs : Arrow, Avnet
Support après vente	Non

Figure 18 : Résumé de la solution matérielle 4 : NS DP83905

Cette solution matérielle peut convenir aussi aux besoins mais n'est pas aussi intéressante que les 2 précédentes. Concernant les protocoles Internet, un couplage avec les produits Treck est possible.

3.6. AUTRES SOLUTIONS MATERIELLES

D'autres solutions matérielles existent mais ne répondent pas complètement aux exigences. C'est généralement l'accès physique qui n'est pas conforme au cahier des charges (accès par RTC et connectivité à Internet par le protocole PPP). Ces solutions sont présentées succintement ici car elles sont aussi dignes d'intérêt. Elles permettent toutes une connectivité immédiate à Internet via le RTC en utilisant un fournisseur d'accès. En revanche, ces solutions intègrent sur le silicium les protocoles TCP et UDP. Il semblerait d'ailleurs que la complexité d'intégration d'IP, TCP et UDP sur le silicium soit équivalente à celle de MAC 802.3.

La société CONNECT ONE propose pour assurer une connectivité Internet des produits basés sur un circuit spécifique qu'ils ont créés et commercialisent : circuit iChip.

Ce circuit assure une connectivité Internet par l'intermédiaire d'un modem connecté à RTC via le protocole PPP.

L'interface hôte est du type UART en utilisant des commandes ASCII conformes à la norme HAYES.

Leur produit permet en fait de recevoir, émettre des mails et des pages HTML.

Le circuit iChip implémente ainsi les protocole PPP, IP, UDP, TCP et SMTP.

Le seul inconvénient est l'interface physique qui ne correspond pas au cahier des charges…

Le tableau de la figure suivante résume les points importants de ce produit.

La société SEIKO propose un circuit pour assurer une connectivité Internet : circuit S-7600A appelé aussi iChip.

Ce circuit assure une connectivité Internet par l'intermédiaire d'un modem connecté à RTC via le protocole PPP.

L'interface hôte est compatible avec la famille 68K de Motorola et x86 d'Intel. Un kit de développement est proposé pour développer des applications ainsi qu'une carte d'évaluation.

Le seul inconvénient est l'interface physique qui ne correspond pas au cahier des charges.

Le tableau de la figure suivante résume les points importants de ce produit.

La société SCENIX propose des microcontrôleurs RISC de la famille SX permettant une connectivité Internet en utilisant des broches d'E/S.

Ils ont introduit le concept de périphériques vituels (Virtual Peripheral) qui se présentent sous forme de bibliothèques logicielles utilisant une ou plusieurs broches d'E/S du microcontrôleur pour réaliser une fonctionnalité hardware.

Comme précédemment, on assure une connectivité Internet par l'intermédiaire d'un modem connecté à RTC via le protocole PPP.

Le tableau de la figure suivante résume les points importants de ce produit.

4. SOLUTIONS LOGICIELLES

4.1. INTRODUCTION

Contrairement à ce que l'on pouvait croire, il existe peu de briques logicielles implémentant les protocoles et services Internet (IP, UDP, TCP…) disponibles au niveau source et gratuits ou sous licence GPL.

En fait, l'implémentation de ces protocoles est toujours liée à un système d'exploitation lourd qui est à priori non embarquable. On trouve ainsi au niveau source (en langage C) les protocoles que l'on nommera TCP/IP globalement pour les OS (Operating System) UNIX BSD, FreeBSD, NetBSD et linux sous licence GPL. Leur exploitation semble à priori exclue mais une solution existe avec l'apparition de projets "linux embarqué" pour des petits systèmes matériels permettant ainsi d'avoir linux sur une plateforme restreinte et une connectivité "naturelle" à Internet.

Il ne semble pas envisageable de modifier les sources TCP/IP pour s'affranchir de l'OS sous-jacent car les 2 sont intiment liés (on y fait appel à des appels systèmes propres à l'OS). Il faut dans cette optique prendre TCP/IP et son OS.

Il existe donc peu d'implémentations de TCP/IP non liées à un OS généralement de type UNIX like.

On peut citer 2 piles TCP/IP sortant de ce cadre mais possédant beaucoup trop de restrictions d'usage et sortant du cahier des charges :

Projet WATTCP (www.wattcp.com) : pile TCP/IP écrite en langage C disponible gratuitement au niveau source tournant sous DOS avec le driver PKTDRVR pour un accès Internet par PPP.

KA9QNOS (http://people.qualcomm.com/karn/code/ka9qnos/ ) (d'un radioamateur à la base du packet radio) : pile TCP/IP écrite en langage C disponible gratuitement au niveau source tournant sous DOS pour un accès Internet par PPP. Le contrôleur de liaison série doit être de la famille Zilog Z8530.

Il reste alors à regarder les briques logicielles Internet commerciales pouvant être mises en oeuvre avec les solutions matérielles décrites dans la partie 3. On verra dans la partie 5 comment utiliser la connectivité Internet des solutions mixtes (matériel et logiciel).

4.2. SOLUTION LOGICIELLE 1 : PILE TCP/IP DE TRECK

La société TRECK propose une pile TCP/IP et ses sources (voir annexe). Ses produits sont optimisés et produisent des codes rapides, petits, réentrants et ROMables. A travers ses produits, on a accès à TCP/IP, UDP, PPP, ARP, ICMP, DHCP, SMTP et les services ftp, telnet tftp et serveur Web.

Les codes ont été testés avec les processeurs PowerPC, 68K, ARM, 320C32 et x86.

Il n'y a pas obligation d'utiliser un noyau temps réel ( Real Time Operating System RTOS) mais l'intégration des produits Treck avec un RTOS est toujours possible (par exemple uC/OS II). Les drivers pour piloter les contrôleurs Ethernet sont aussi disponibles et notamment pour les 3 solutions matérielles retenues suivantes : CS8900, Am79C940 et DP83905. Treck peut aussi développer le driver pour d'autres contrôleurs Ethernet.

Les produits Treck intéressants suivant le cahier des charges sont :

• Treck Real-Time TCP/IP.
• Treck RomPager Embedded Web Server (de la société Allegro).
• Treck RomPager Light Embedded Web Server.

Les 2 figures suivantes résument les principales caractéristiques des 2 premiers produits.

Cette solution logicielle convient idéalement aux besoins pour son adaptabilité et son indépendance à un OS ou RTOS. Les produits supportent en plus les principaux contrôleurs Ethernet 802.3.

4.3. SOLUTION LOGICIELLE 2 : PILE TCP/IP DE EBSnet

La société EBSnet propose des produits logiciels assurant une connectivité Internet et notamment une pile TCP/IP et ses sources (voir annexe) : produit RTIP. A travers RTIP, on a accès à TCP/IP, UDP, PPP, ARP, ICMP, RARP, BOOTP. Un serveur Web embarqué est aussi proposé.

Les codes ont été testés avec les processeurs PowerPC, 68K, ARM, x86…

Il y a obligation d'utiliser un système d'exploitation ou un RTOS proposant la gestion de tâches, sémaphores et signaux. Le RTOS uC/OS II est supporté. Les drivers pour piloter les contrôleurs Ethernet sont aussi disponibles et notamment pour les 2 solutions matérielles suivantes : CS8900, Am79C96x.

La figure suivante résume les principales caractéristiques du produit RTIP.

Adresse web	www.etcbin.com
Solution	Logicielle
Interfaces Ethernet	Oui par driver d'interface aux principaux contrôleurs (ex : CS8900, Am79C96x)
Besoin d'un RTOS	Oui mise en œuvre d'un RTOS possible uC/OS II supporté
Implémentation niveau IP	Oui
Implémentation niveaux TCP, UDP	Oui
Autres protocoles	ARP, ICMP…
Interface de programmation	Oui Sockets BSD
Processeurs testés	PowerPC, 68K, ARM, x86
Qualité de la documentation	Très bonne
Facilité de programmation	Très bonne, programmation sockets
Drivers fournis	Oui
Prix	8250 $ pour RTIP 2200 $ pour le serveur web pas de royalty

Figure 24 : Résumé du produit EBSnet RTIP

Cette solution logicielle convient aussi idéalement aux besoins.

On a par contre besoin par rapport à la première solution d'un OS ou RTOS. Le prix peut aussi sembler prohibitif. On n'a pas à ce jour de comparaison de prix possible avec la première solution…

4.4. SOLUTION LOGICIELLE 3 : PILE TCP/IP DE INTERNICHE TECHNOLOGIES

La société INTERNICHE TECHNOLOGIES propose une pile TCP/IP et ses sources (voir annexe). A travers ses produits, on a accès à TCP/IP, UDP, PPP, ARP, ICMP, DHCP, SMTP et serveur Web.

Les codes ont été testés avec les processeurs ARM.

Il n'y a pas obligation d'utiliser un noyau temps réel mais l'intégration des produits INTERNICHE avec un RTOS est toujours possible (par exemple uC/OS II). Le driver pour piloter le contrôleur Ethernet AMD LANCE est aussi disponible ce qui est un peu pauvre par rapport aux solutions précédentes.

Les produits INTERNICHE intéressants suivant le cahier des charges sont :

• Portable TCP/IP.
• WebPort.

Les figures suivantes résument les principales caractéristiques des 2 produits.

Cette solution logicielle convient idéalement aux besoins pour son adaptabilité et son indépendance à un OS ou RTOS. On n'a pas d'informations sur les contrôleurs Ethernet 802.3 supportés (AMD LANCE supporté).

4.5. SOLUTION LOGICIELLE 4 : SERVEUR WEB EMBARQUE ROMPAGER DE ALLEGRO

La société ALLEGRO SOFTWARE propose un serveur web embarqué pour les applications du même nom : produit RomPager. C’est en fait le même produit qui est revendu par la société TRECK. ALLEGRO propose aussi le produit RomPOP qui est un agent SMTP embarqué.

Les caractéristiques du produit RomPager sont en fait déjà résumées figure 23. Pour plus d'informations, se reporter à l'annexe.

RomPager convient aux exigences concernant la possibilité d’utiliser un serveur web embarqué.

4.6. SOLUTION LOGICIELLE 5 : SERVEUR WEB EMBARQUE PICOWEB DE LIGHTNER ENGINEERING

La société LIGHTNER ENGINEERING propose une solution mixte alliant matériel et logiciel afin de mettre en place un serveur web embarqué. Cette solution mixte sera présentée dans la partie suivante…

5. SOLUTIONS MIXTES

5.1. INTRODUCTION

Cette partie présente les solutions mixtes alliant à la fois matériel et logiciel qui peuvent être mises en oeuvre.

On trouvera en fait deux sortes de produits :

Serveur web embarqué permettant de contrôler des E/S. La connectivité Internet assure un contrôle à distance de ces E/S via un navigateur client.

Système d’exploitation classique " allégé " de la famille UNIX like embarqué sur une plateforme matérielle utilisant généralement un microcontrôleur. La connectivité Internet est assurée pleinement par UNIX où les piles de protocoles Internet sont intiment liées au noyau. On trouve ici surtout les systèmes du type linux embarqué. Il est clair que cet OS, fiable, disponible au niveau source sous licence GPL se prête plus qu’aucun autres à des portages sur des plateformes autres que des PC. Cette solution est une voie d’avenir dans tout ce qui est système embarqué avec en plus la maturité complète de RTlinux pour une version temps réel. L'adresse web collectant les projets linux embarquée est www.linuxembedded.com .

5.2. SOLUTION MIXTE 1 : SERVEUR WEB EMBARQUE PICOWEB DE LIGHTNER ENGINEERING

La société LIGHTNER ENGINEERING propose un serveur web embarqué appelé PICOWEB sur une carte possèdant un accès 802.3 10BaseT. C’est un système autonome autorisant une connectivité Internet via TCP/IP et bien sûr HTTP. Il faut noter que l’implémentation TCP/IP est assez sommaire compte tenu du processeur mis en jeu et réduite à sa plus simple expression pour supporter HTTP. La partie matérielle est construite autour d’un microcontrôleur ATMEL AT90S8515 possédant 8 Ko de mémoire flash, 512 octets d’EEPROM et 512 octets de RAM aussi que 32 E/S. Sur la carte est intégré un contrôleur Ethernet REALTEK ainsi qu’un circuit UART. Le dialogue entre un système hôte et PICOWEB se fait d’ailleurs par la liaison série de l’UART, ce qui permet ainsi un dialogue entre un navigateur web et l’hôte. On peut aussi contrôler à distance les E/S restantes du microcontrôleur non utilisées par PICOWEB.

Figure 27 : Schéma de principe du produit PICOWEB de LIGHTNER ENGINEERING

LIGHTNER ENGINEERING propose les schémas de son produit PICOWEB (sous licence) ainsi qu’une version allégée avec le logiciel au niveau objet (version breadboard) gratuite pour des utilisations non commerciales. Cette dernière s’interface en fait directement sur le connecteur ISA d’une carte Ethernet NE2000.

Un kit de développement complet comprend une carte PICOWEB et est disponible pour 149 $. Un bémol quand même avec un système de licence à acquérir (9 $ à l’unité) pour chaque produit basé sur PICOWEB vendu. Une licence grand volume est à négocier.

Le tableau de la figure suivante résume les caractéristiques de PICOWEB.

Adresse web	www.picoweb.net
Solution	Mixte
Description du matériel	Atmel AT90S8515, 8 Ko flash, 512 o EEPROM 512 o RAM, 32 E/S, contrôleur Ethernet Realtek, UART
Interfaces Ethernet	10BaseT
Implémentation niveau MAC	Oui
Implémentation niveau IP	Oui
Implémentation niveaux TCP, UDP	Oui HTTP
Schémas de principe d'utilisation	Oui
Qualité de la documentation	Très bonne
Facilité de programmation	Très bonne
Besoin d'un RTOS	Non
Interface de programmation	Non, dialogue par la liaison série
Support	Web support@lightner.net
Prix	145 $ pour le kit de développement royalty pour le firmware : 9 $ par PICOWEB

Figure 28 : Résumé du produit PICOWEB de LIGHTNER ENGINEERING

Cette solution mixte convient aux besoins sur les plans matériels et logiciels. Elle n'impose qu'une liaison série RS.232 comme interface entre l'hôte et PICOWEB. PICOWEB apparaît une boîte noire assurant la connectivité Internet. Il vaut néanmoins mieux avec PICOWEB travailler au niveau HTTP. En effet, l'implémentation de TCP/IP a été réduite au strict minimum pour interfacer HTTP. Ceci est dû à l'utilisation du microcontrôleur 8 bits assurant la passerelle entre l'hôte et le réseau.

5.3. SOLUTION MIXTE 2 : LINUX EMBARQUE, PROJET UCLINUX

Le projet uClinux fait partie des solutions mixtes où l'on retrouve linux embarqué. La plateforme matérielle est une carte SIMM 30 broches mettant en oeuvre un microcontrôleur MOTOROLA de la famille 68K, le 68EZ328. La carte SIMM possède 8 Mo de DRAM, 2 Mo de flash ROM, un port série RS.232 et une interface Ethernet 802.3 10BaseT via le circuit CRYSTAL CS8900A que l'on a déjà vu.

La remarque à faire sur la plateforme est le standard adopté, la carte SIMM qui n'est pas des plus communs. Un point fort est dans l'utilisation du contrôleur Ethernet CS8900A qui est un des plus intéressants (voir partie 3).

Concernant le logiciel, le noyau linux 2.0.38 a été porté sur cette plateforme, ce qui permet de bénéficier naturellement de la connectivité Internet et de tous ses protocoles !

La figure suivante résume les caractéristiques de cette solution mixte.

Adresse web	www.uclinux.org
Solution	Mixte
Description du matériel	MOTOROLA 68EZ328 16 MHz, 2 Mo flash, 8 Mo RAM, contrôleur Ethernet CRYSTAL CS8900A, UART
Interfaces Ethernet	10BaseT
Implémentation niveau MAC	Oui
Implémentation niveau IP	Oui
Implémentation niveaux TCP, UDP	Oui HTTP et autres
Schémas de principe d'utilisation	Non
Qualité de la documentation	Très bonne
Facilité de programmation	Très bonne
Interface de programmation	Oui Sockets BSD
Support	Web uclinux@uclinux.org
Prix	270 $ pour le kit de développement complet

Figure 29 : Résumé du produit uClinux

Cette solution mixte convient véritablement aux besoins sur les plans matériels et logiciels. Le seul bémol concerne le standard SIMM qui a été adopté. Une reprise de CAO concernant le routage serait à envisager…

5.4. SOLUTION MIXTE 3 : LINUX EMBARQUE, PROJET OPENHARDWARE

Le projet openhardware fait partie des solutions mixtes où l'on retrouve linux embarqué et est du même acabit que le précédent. La plateforme matérielle est là aussi une carte SIMM 30 broches mettant en œuvre un microcontrôleur MOTOROLA de la famille 68K, le 68EZ328. La carte SIMM possède 8 Mo de DRAM, 2 Mo de flash ROM, 3 ports série RS.232. 9 E/S sont disponibles. C'est en fait la reprise de la carte SIMM du projet uClinux. Une interface Ethernet 802.3 10BaseT via la circuit SMCS 91C96 sous la forme d'une carte SIMM est disponible que l'on a à enficher là aussi sur une carte mère.

La remarque à faire sur la plateforme est le standard adopté, la carte SIMM qui n'est pas des plus communs.

Concernant le logiciel, le noyau linux 2.0.38 a été porté sur cette plateforme, ce qui permet de bénéficier naturellement de la connectivité Internet et de tous ses protocoles !

La figure suivante résume les caractéristiques de cette solution mixte.

Cette solution mixte convient aussi aux besoins sur les plans matériels et logiciels. Le seul bémol concerne le standard SIMM qui a été adopté. Une reprise de CAO concernant le routage serait à envisager et l'on bénéficie en plus des schémas contrairement à la précédente solution.

5.5. SOLUTION MIXTE 4 : IPC@CHIP de BECK

Le produit IPC@CHIP (versions SC01, SC02, SC11, SC12) est une solution mixte se présentant sous forme d'un boîtier DIL 32 broches incorporant hardware et software, ce qui en fait une solution très intéressante pour un intégrateur ou une PME pour assurer une connectivité IP. Ce boîtier englobe en fait un microcontrôleur Intel 80186-80188 selon la version avec au plus 512Ko de RAM et 512 Ko de Flash ainsi qu'un interface Ethernet IEEE 802.3 10BaseT. La fréquence de travail est de 20 MHz. On a aussi accès selon la configuration de l'IPC@CHIP choisie à 14 I/O programmables, 7 sorties Chip Select, des entrées d'interruption INT, un démodulateur PWM, un entrée Timer, une sortie Timer, 2 ports série asynchrones, un bus I2C, 2 canaux DMA, un bus d'adresses/données de 8 bits, un watchdog ainsi que l'interface 10BaseT. Il est à noter que ces fonctionnalités peuvent s'exclure mutuellement suivant la configuratrion choisie.

Un kit d'évaluation est disponible (kit DK40) permettant de tester rapidement l'IPC@CHIP que j'ai pu tester grâce au don de ce kit par la société Beck IPC :-)

Du point de vue logicielle, l'offre est des plus complètes :

• noyau Temps Réel embarqué autorisant l'exécution des application DOS : on développe donc son application sous DOS à partir de son PC que l'on télécharge ensuite dans le composant. Cet environnement est bien ciblé car c'est généralement celui des PME !
• un interpréteur de commandes DOS like.
• un pile TCP/IP complète implémentant l'interface sockets TCP et UDP.
• un client DHCP.
• un serveur Web capable d'exécuter des scripts CGI.

La documentation est abondante et régulièrement mise à jour ainsi que le firmware. Des exemples d'applications sont aussi disponibles.

Des schémas électronique d'applications sont aussi donnés.

La figure suivante résume les caractéristiques de cette solution mixte.

Figure 31 : Résumé du produit IPC@CHIP

Cette solution mixte prête à l'emploi convient parfaitement aux besoins sur les plans matériels et logiciels. La licence de Run Time est peut être un frein pour une petite PME.

5.6. SOLUTION MIXTE 5 : eZ80 de ZILOG

Le produit eZ80 de Zilog est une évolution du célèbre Z80 auquel on a rajouté une connectivité IP. Le CPU n'implémente pas d'interface Ethernet IEEE 802.3. Elle est réalisée par l'ajout d'un circuit externe. La carte d'évaluation eZ80 utilise le cicuit CS8900A présenté précédemment. L'intérêt réside dans les protocoles Internet fournis pour le eZ80 :

• IPv4, TCP, UDP, ARP, RARP, ICMP, PPP, HTTP 1.1, DHCP/BOOTP, IGMP, SLIP, SMTP, SNMP, Telnet, TFTP
• utilitaire de configuration
• convertisseur HTML to C
• drivers Ethernet (CS8900A)
• compilateur C

Figure 32: Protocoles Internet supportés par le processeur eZ80

Le processeur eZ80 possède les caractéristiques suivantes (version eZ80190) :

• 50 MHz processor
• multiply and accumulate engine
• 16 MByte linear addressing
• 3.3V operation
• 2 DMA channels
• Universal ZiLOG Interface (selectable UART, IIC, SPI)
• 6 PRTs with prescalers 8kB SRAM
• 32-bit GPIO with interrupt support
• on-chip oscillator
• optimized pipeline architecture
• ZiLOG Debug Interface (ZDI)

Figure 33: Schéma de principe du processeur eZ80

La documentation est abondante et régulièrement mise à jour ainsi que le firmware.

Des schémas électronique d'applications sont aussi donnés (voir manuel de la carte d'évaluation) .

La figure suivante résume les caractéristiques de cette solution mixte.

Figure 34 : Résumé du produit eZ80

Cette solution mixte convient parfaitement aux besoins sur les plans matériels et logiciels et rappellera sûrement de bons souvenirs à certains.

Au vu de cette étude, on peut se rendre compte qu’il ne manque pas de solutions matérielles fiables et bon marché pour implémenter un accès Ethernet 802.3 10BaseT. Des circuits récents et faciles d'emploi sont disponibles depuis quelques années sur le marché. En fait, il est clair que les fondeurs suivent l’engouement général pour Internet et pour ce qui nous concerne l’Internet embarqué qui est en passe de remplacer la vieille liaison série RS.232 que possède tout bon système embarqué.

Le choix d’un circuit se fera surtout par rapport aux logiciels assurant la connectivité Internet et supportant le circuit choisi sous forme d’un driver. Sinon, il faudra bien sûr développer ledit driver pour interfacer le circuit aux logiciels.

Concernant les logiciels assurant la connectivité Internet, les choses sont plus floues et l’on se retrouve plutôt au début du développement de masse de ces derniers. Il existe ainsi peu de solutions gratuites répondant au cahier des charges. Seuls quelques rares produits commerciaux comme TRECK peuvent être mis en oeuvre en regardant aussi la compatibilité avec les circuits contrôleurs Ethernet pouvant être utilisés.

La solution passe sûrement par une solution mixte alliant matériels et logiciels comme PICOWEB ou comme les projets linux embarqué. Les projets linux embarqué sont très intéressants car la plateforme matérielle est assez standard et utilise notamment les circuits contrôleurs Ethernet choisis comme solution matérielle et l’on bénéficie aussi du noyau linux gratuitement sous licence GPL avec la connectivité complète à Internet car Internet fait partie intégrante du noyau linux.

L’engouement pour l’Internet embarqué est réel et les choses risquent d’évoluer maintenant très rapidement avec des solutions professionnelles complètes " en kit " qui vont bientôt apparaître. C’est en fait une évolution naturelle de l’informatique industrielle embarquée. A quand les microcontrôleurs intégrant une interface Ethernet complète avec les couches de protocoles Internet sur silicium telle une liaison série RS.232 ?

Au vu de ces remarques, on peut dégager les solutions suivantes complètes répondant au cahier des charges, c’est à dire ici :

liaison Ethernet 10 Mb/s 10BaseT

connexion de type RJ 45

couches de protocoles IP, TCP, UDP : il convient de voir si l'on peut trouver ces briques logicielles s'interfaçant aux matériels à mettre en oeuvre précédemment. Il convient aussi de voir si des solutions freeware ou du type GPL (Gnu Public Licence) existent.

services de l'Internet : HTTP (serveur web), mail... : il convient de voir si l'on peut trouver ces briques logicielles s'interfaçant aux couches logicielles précédentes. Il convient aussi de voir si des solutions freeware ou du type GPL (Gnu Public Licence) existent.

1. circuit CRYSTAL CS8900A. Une application est la carte 68HC11ETHER de l'ENSEIRB.
2. circuit REALTEK 8019AS ou AMD Am79C940.

1. pile TCP/IP DE TRECK ou linux embarqué (avec contraintes matérielles).
2. pile TCP/IP DE EBSnet.

1. IPC@CHIP.
2. Openhardware qui englobe uClinux (avec modifications du routage et utilisation du contrôleur Ethernet CS8900A). Il est possible d'utiliser les cartes d'évaluation Motorola ColdFire pour utiliser de suite uClinux.
3. eZ80.
4. PICOWEB.