Expériences avec (gratuit) incorporé des piles TCP / IP?

Quelqu'un a surtout de bonnes (ou mauvaises) expériences avec un des éléments suivants incorporés des piles TCP /IP?

Mes besoins pour un solide, facile à port de la pile. La taille du Code n'est pas très important, la performance est relativement important, mais la facilité d'utilisation & le portage est très important.

Le système sera probablement utiliser un système d'exploitation temps réel, qui n'a pas été décidé, mais dans mon expérience, la plupart des piles peut être utilisé avec ou sans système d'exploitation temps réel. Le plus probable de la plate-forme sera un BRAS de variante (ARM7 ou CM3 selon toute vraisemblance).

Pas trop inquiet au sujet de la montaison de la pile pour le pilote Ethernet, de sorte que n'est pas une grande priorité dans la sélection.

Je ne suis pas vraiment intéressée à l'extraction d'une pile d'un OS comme Linux, RTEMS, etc.

Je ne suis pas intéressé par les offres commerciales telles que Interniche, Micrium, etc...

La pile n'a pas besoin de toutes sortes de cloches et de sifflets, n'a pas besoin d'IPv6, et je n'ai pas besoin de trucs sur le dessus de celui-ci (serveurs web, serveurs FTP, etc..) En fait, il est possible que je vais seulement utiliser UDP, même si je peux imaginer quelques scénarios où TCP serait préférable.

Expériences avec d'autres piles que j'ai manqué sont bien sûr également beaucoup d'intérêt.

Merci pour votre temps & entrée.

InformationsquelleAutor Dan | 2009-07-21
  1. 17

    J'ai utilisé à la fois l'uIP et lwIP largement.

    uIP

    • Génial si vous êtes à seulement veulent quelque chose de simple comme un chargeur de démarrage
    • Petite empreinte de pas.
    • Utilise l'interrogation de sorte que nous n'avons jamais eu plus de 3kbit avec elle 🙁
    • Pas de DHCP "out of the box'
    • Pauvres UDP prise en charge

    lwIP

    • Entièrement interruption de manière beaucoup plus rapide (~ x10)
    • Comprend DHCP avec basculement AutoIP
    • UDP avec la multidiffusion
    • Plus

    EDIT:

    Et nous n'avons jamais utilisé soit avec un RTOS qu'il n'y a jamais été nécessaire.

    • Vous pouvez obtenir de l'uIP de faire plus que 3kbit/s. Je l'ai eu d'aller à > 100kByte/s, mais il nécessite beaucoup de peaufinage. l'uIP est bon si vous êtes le code limité, mais il est extrêmement os à nu.
    • Mon application est actuellement en cours d'exécution à près de 245kbits/sec, et c'est le w/o absolument pas de réglages à la couche sous-jacente. Tout ce que je assuré était que le sortant des cadres étaient tous comme près de 1500 octets que possible, et envoyer des appels ont été blocage.
    InformationsquelleAutor Tim
  2. 11

    +1 pour lwIP.

    Nous avons utilisé avec succès sur un projet de quelques années en arrière et l'a trouvé pour être généralement très fiables. Nous avons trouvé et fixé quelques questions (généralement en cas de coin dans le TCP code), nous avons présenté revenir au projet, et même si le projet a évolué un peu depuis lors, nous n'avons généralement pas de trouver qu'il manque à toutes les fonctionnalités.

    Que vous croyez qu'il va travailler avec ou sans système d'exploitation temps réel. Il a fallu environ une semaine pour le faire fonctionner sur notre système avec un RTOS, qui comprenait des changements, nous avons dû procéder à l'appui d'une inhabituelle DSP compilateur. Comme vous êtes probablement en utilisant GCC sur les BRAS, vous pouvez éviter de tout cet effort.

    Il contient beaucoup plus de fonctionnalités que vous avez besoin, mais si vos besoins changent dans quelques années la ligne, alors vous allez être mieux d'avoir commencé avec un plus substantiel de la pile.

    • Aussi, avec LwIP vous pouvez très probablement la destruction des fonctionnalités que vous n'allez pas l'utiliser pour enregistrer sur le code de l'empreinte.
    InformationsquelleAutor ukembedded
  3. 8

    lwIP

    J'ai travaillé sur un projet avec un modem 3G où nous avions besoin d'un UDP/IP de la pile (pas de TCP) sur le dessus de PPP. Nous avons rétréci vers le bas à l'uIP et lwIP. Nous avons choisi lwIP à la fin, parce qu'il avait PPP déjà (uIP ne fait pas), et nous avons eu assez de RAM libre.

    Notre projet particulier de ne pas utiliser un système d'exploitation temps réel, et lwIP était beau de les utiliser sans un RTOS.

    Je n'étais pas directement impliqué dans le transfert du lwIP code, bien que j'ai travaillé sur le pilote de modem pour l'interface avec elle. Mon impression était que le portage a fallu quelques semaines pour que tout ce passe pour le mieux, pour notre ingénieur qui avait précédente TCP/IP de l'expérience. Le lwIP code a été piraté par de nombreuses personnes, et par conséquent a certains angles (par exemple, quelqu'un a jeté dans un seul malloc() quelque part), mais il a travaillé pour nous après un peu de peaufinage. Nous l'avons testé avec une validation indépendante de la suite.

    En résumé, il a été "dûment fonctionnelle" pour notre UDP/IP, PPP besoins (mais je ne peux pas commenter sur sa TCP capacités).

    • Génial, merci pour vos commentaires...
    InformationsquelleAutor Craig McQueen
  4. 3

    +1 pour lwIP.

    Il est inclus dans le Luminaire Micros (maintenant TI) Serial to Ethernet design de référence, avec quelques fonctionnalités supplémentaires (une sorte de "server side scripting" et cgi) travail sur le métal nu (sans RTOS).

    Il est solide et très performant avec seulement 32 ko de RAM.

    Ce qui concerne

    PFM

    InformationsquelleAutor pfmaggi
  5. 3

    Je suis heureux avec lwip sur le Stellaris Cortex-M3.

    StellarisWare pour la LM3S6965 eval conseil d'administration comprend le enet_lwip démo. C'est un petit serveur web qui tourne sur lwip qui est en cours d'exécution sur métal nu-pas de FreeRTOS dans ce cas. Le système est piloté par la minuterie et Ethernet interruptions. C'était assez facile à arracher le serveur web et de les déposer dans mon application. Je n'ai pas à devenir un lwip expert pour obtenir cette running la première fois.

    Plus tard, j'ai réalisé que mon application est intrinsèquement jusqu'appel entraînée. Au premier abord, il avait une sockets-à-upcall joint. J'ai remplacé cette couche avec une autre beaucoup plus simple que traduit lwip natif upcalls à l'application upcalls, et une option hors lwip de l'API socket. Cette sauvé plus de flash et RAM de l'espace, et fait le tout plus rapide et plus simple. Avec un peu de peaufinage je l'ai eu en cours d'exécution sur le S2E conseil d'administration à l'aide de 52K flash et 30K de RAM.

    InformationsquelleAutor Jonathan Engdahl
  6. 0

    J'ai utilisé la Puce pile TCP/IP. J'ai été très heureux avec elle. Il a été très facile à mettre en œuvre, beaucoup de code de démonstration/tutoriels disponibles, et a un support pour un grand nombre de protocoles HTTP, tFTP, SMTP, SNTP, etc. Un point qui ne correspond pas à vos exigences, cependant, est qu'il n'est pas facilement le portable à une autre architecture. En fait, je pense que la licence de la pile interdit explicitement de ce parce que la Puce veut que vous exécutez la pile uniquement à l'aide de leur matériel, les PIC18, PIC24 et PIC32. Cependant, il existe une externe Ethernet controller vendre, ils vous permettent d'utiliser certaines parties de cette pile avec leur ENC28J60.

    InformationsquelleAutor mjh2007
  7. 0

    J'ai utilisé interniche sur les OTR.
    C'est un à part entière de la pile et prend en charge quelques fonctionnalités.
    Depuis que vous êtes à la recherche d'un non-version commerciale, mon vote est sur lwIP.

    InformationsquelleAutor yaGsd
  8. 0

    Vous pouvez essayer de l'open-source FNET pile TCP/IP.

    • Ce n'est pas vraiment une réponse à sa question. Mention d'une pile supplémentaire aurait été mieux de faire un commentaire.
    InformationsquelleAutor butok