Go Down

Topic: Problème Ethernet Shield HTTP (Read 4 times) previous topic - next topic

Jean-François


Bonjour, Jean-Francois je me permet d'ajouter mon grain de sel ^^"


Sans soucis ... même pas mal   XD
MacBook intel core 2 duo  os X snow Leopard 10.6
 eMac PPc G4  os X Leopard 10.5
powerbook G4 os X Leopard 10.5
imac PPC G3 os X Pa

pl88

Bonmatin à vous,

j'ai essayé votre code, pas de problème, je l'ai modifié pour récupérer la page en boucle, pas de problème non plus. j'ai donc repris mon code après l'avoir vidé (j'avais 20ko d'autres choses) pour ne laisser que ma fonction de récupération HTTP avec un appel dans loop(), ça fonctionne...

Pourtant dans le reste du code je ne touche pas au réseau, étrange.
Peut-être est-ce le LCD qui est en route ? Mais il ne prend pas de ports utilisées par le shield normalement, il est connecté sur les pins 2, 3, 4, 5, 8 et 9.

Petite précision : si je remet le code qui plante dans l'arduino, que j'attends le premier plantage après 4 ou 5 connexions, et qu'après avoir planté je reprogramme l'arduino avec votre code, cela plante toujours, même avec un reset, il faut que je débranche et rebranche l'usb pour que ça reprenne correctement.

Gromain59

Quote
Peut-être est-ce le LCD qui est en route ?

C'est la première fois que tu mentionnes l'utilisation d'un LCD non ? C'est le genre de détails qui peuvent expliquer ton problème pourtant...

Quote
cela plante toujours, même avec un reset, il faut que je débranche et rebranche l'usb pour que ça reprenne correctement.

Si tu es obligé de couper c'est qu'il y a certainement corruption de données. Probablement coté wiznet. J'ai le cas lorsque son buffer (circulaire) de réception est saturé. Donc soit tu ne vides pas assez vite/souvent son buffer, soit tu reçoit de trop gros paquets d'un coup. Le buffer de réception est configuré à 2ko par défaut (8 ko partagés entre les 4 sockets disponibles du wiznet).
Vois pour charger des pages plus light, décharger le buffer au plus vite (pas de delay() qui neutralise l'arduino trop longtemps !) ou, en dernier recours, augmenter la taille du buffer au détriment des autres sockets.

Gromain
"pour résoudre un gros problème, il est souvent plus facile de le diviser en petits problèmes élémentaires..."

projet domotique xPLDuino
IRC: freenode #xplduino

pl88

Bon, même avec le code simplifié je fini par planter (cette fois après quelques minutes de réussite pour une page par seconde tout de même).
Je dois pouvoir laisser l'arduino fonctionner sans avoir à le redémarrer manuellement, si encore je pouvais réinitialiser totalement le W5100 quand ça plante pour que ça reprenne correctement, ça me conviendrait, mais je ne vois pas.

Je viens de regarder du côté de wireshark,  les requêtes GET sont toujours erronées lorsque ça plante, mais cela signifie que le buffer d'émission dépasse et pas celui de reception ?

Est-il possible que le buffer de réception déborde sur celui d'émission ? je croyais qu'il s'agissait de buffers circulaires.

Le premier plantage cette fois commence toujours par une déconnexion pendant l'attente de réponse.

Gromain59

Quote
les requêtes GET sont toujours erronées lorsque ça plante, mais cela signifie que le buffer d'émission dépasse et pas celui de reception ?

en émission, il peut probable que tu satures le buffer sur un simple GET

Quote
Est-il possible que le buffer de réception déborde sur celui d'émission ?

Je dirais que non.

Quote
Le premier plantage cette fois commence toujours par une déconnexion pendant l'attente de réponse.

selon moi, et surtout selon TCP/IP, il faut systématiquement faire une connexion avant l'envoi de la requête, puis fermer celle-ci à la fin de la réponse. Si j'ai bien compris, tu ouvres la connexion au niveau du setup, puis tu fais tes requêtes. Ça pourrait expliquer pourquoi ça merdouille quand tu subis une déconnexion ?

Le serveur est chez toi ?

Gromain
"pour résoudre un gros problème, il est souvent plus facile de le diviser en petits problèmes élémentaires..."

projet domotique xPLDuino
IRC: freenode #xplduino

Go Up