Arduino Ehternet Shield

Dans mes tests touchant la communication Ethernet et Arduino, j'ai commencé par le plus facile, soit le shield ethernet standard. Non seulement la librairie est incluse dans le IDE mais comme c'est un shield, ça se branche facilement. J'ai donc avancer mon code de serveur web au point de pouvoir recevoir des requêtes et y répondre. 

Le code est assez simple merci. Je me suis basé sur les exemples afin de faire un serveur Ethernet dont l'IP est obtenu via le DHCP et qui écoute sur le port 80. Ensuite, suffit de boucler sur l'attente d'une requête, ce qui retourne un objet EthernetClient implémentant un Stream.  Suffit de lire et d'écrire comme n'importe quel autre Stream ( tel que Serial ). Je n'ai pas fais de test avec plusieurs requêtes concurrentes ni des volume de données important, mais pour le moment tout marche numéro 1.

Par contre. la librairie Ethernet et SPI viennent prendre quelque peu de RAM. Comme mon but est d'avoir un serveur web assez complet sur un UNO n'ayant que 2K de RAM, ça reste un assez bon défi.

Alors voici quelque truc utiliser pour sauvegarder de la RAM:

1. L'URL et les autre objet de type chaîne de caractère sont hashé sur 32 bits (FNV) et la comparaison se fait selon le hash. Plus rapide qu'une série de strcmp et prendre moins de RAM. 
2. Aucune allocation de mémoire n'est dynamique et tout se fait dans un buffer configurable pour le moment de 256 octets ( décodage des caractères URL, hashing, etc ).
3. Les valeur de hash sont gardé dans un tableau en PROGMEM et l'index 8bit du hash, si trouvé, est retourné.
4. Seulement si  le client support gzip, les page HTML en PROGMEM pré-compressées sont retournées.
5. Un objet HTTPResponse permet de spécifier le type et options de la réponse et la génération HTTP se fait via des string gardées en PROGMEM.
6. L'analyse de la requête se fait ligne par ligne et un objet HttpRequest contenant les attributs selon des define et les hash de l'URL, host et connection est retourné.

L'idée est d'utiliser le plus possible l'espace FLASH et non la RAM. Reste qu'il n'y a que 32K de Flash sur un UNO.

N'empêche, présentement le serveur répond avec une erreur 404 sir l'URL n'est pas trouvé, deux page ( /index.html et /data.html ) retourne des page HTML en PROGMEM et un réponse en JSON a partir d'un senseur de température LM35 branché su A1 répond tel un service REST via /api/temperature. 

Ce n'est pas optimisé ni testé et pas très fonctionnel encore mais lorsque ce sera plus ready, je mettrai le tout sur github.  Reste a solidifer la gestion des paramètres de l'URL ( via un callback ) et implémenter le même genre de callback pour analyser l'envoie de formulaire et ce devrait être assez fonctionnel pour être distribué. Va reste a implémenter le Websocket et devrait permettre d'implémenter à peu près n'importe quel projet ( avec tout de même plusieurs limitations ).

Prochaine étape est d'ajouter une classe encapsulant le EthernetClient afin d'en compiler selon un define des version utilisant UIPEthernet afin de ne pas lié le serveur à une librairie précise. Je pourrai tester mon autre petit board Ethernet qui celui nécessite un voltage divider puisqu'il fonctionne sur 3.3 volt.

Évidemment, le but est de faire une page dont le Facicon, css et images proviennent du Arduino et dont la mise à jours des données et le contrôle du module s'effectue en javascript via des webservices. Donc plus évolué que simplement retourné une réponse harcodé lorsque l'on reçoit un GET et attendre une double fin de ligne. Cependant, dans une optique M2M ( Machine 2 Machine ) quelque chose que MQTT est plus approprié. Ici, c'est d'en faire un senseur intéractif via tablette et PC en plus d'être M2M friendly.