next topic »

[Reply #15 on:]

Alors c'est que je bouffe du flash sans m'en rendre compte ! Ca serait pas simplement les librairies qui prendraient des tonnes de place ? Effectivement en trifouillant davantage, je me rends compte qu'écrire de gros morceaux consomme peu de place en définitive.

En tout cas merci pour le nom, je retiens, on ne sait jamais !

Les requêtes POST en webclient me rendront fou.

[Reply #16 on:]

Si tu n'utilises pas l'IDE Arduino attention aux options de compilation :
utiliser des bibliothèques statiques avec les options pour le linker qui vont bien -> voir tous les sujet sur l'utilisation d'Eclipse ou Code::block c'est détaillé.

[Reply #17 on:]

28Ko de flash ça se remplit vite quand on manipule l'Ethernet shield en weblient /webserver et qu'en plus on joue avec un LCD, et puis on ne sait jamais, dans des projets futurs.

oulala... ben non. je monte mon serveur http et cela consomme rien... et j'ai de l'embarqué : jquery, jcarrousel, jquery mobile, etc etc ... donc je te garantie que le probleme est ton code et pas la mémoire flash ... mon serveur va fournir tout le backoffice de gestion dynamique de mes peripheriques et le controle/config de chaque sensor etc ... il y a du lourd et la mémoire n'est pas du tout un problème.

perso je pense que ton code n'est pas adapté a la "machine". on est pas sur un pc, il faut adapter le code a l'arduino.  moi je m'éclate... bon je prog depuis vingts ans faut dire ...

[Reply #18 on:]

Je ne code pas depuis 20 ans mais je ne pense pas que ça soit mon code le problème  Je n'ai pas non plus dit que j'avais rempli les 28Ko, j'ai encore du chemin.

Ceci dit le serveur http prend sans doute moins de subtilités que le client avec l'arduino, qui est vraiment pas simple à manipuler et qui doit s'adapter à chaque site visité (sauf si on se base sur du commun genre json ou rss); pas que le serveur soit "simple" à faire, mais le client demande beaucoup de blabla pour peu de matière en sortie, et ce pour chaque nouveau serveur visité.

[Reply #19 on:]

mouaaiisss.

bon fun


ce n'était une réponse constructive désolé ...

que tu sois client ou serveur sur ton arduino tu vas manipuler de gros data et en arduino au vu des capacités "technologique" proposés tu ne peux pas faire comme sur un ordinateur de "bureau" : charger un fichier en mémoire, pour le parser a ta guise (même si tu consommes un webservice qui te retourne de l'xml ou json, rss... tu pourrais a la limite parser d'un coup mais je te le déconseille, mais tout dépend de ton api et de tout ce quelle dois traiter également).
Tu dois donc utiliser des buffers, et cela que tu sois le client (en réception) ou en émission en tant que serveur ou en réponse client et ces ces buffers que tu vas manipuler.
Sans buffer tu n'arriveras a rien sur l'arduino ou alors ton api sera super longue en temps de traitement de l'information (réception ou émission : client ou serveur) et ton api instable (si tu as une fuite de mémoire ton arduino va rebooter...), après tout dépend effectivement des performances recherchés de ton application et des taches // qu'elle doit traiter, car si en natif l'arduino ne fais pas le muli thread et est donc bloquant, il est cependant très simple de le mettre en place et de créer des traitements non bloquant pour chaque traitement effectué. (imagine que pendant l'envoi ou la reception de ta page ton api soit bloqué pendant tout le traitement de l'information emisse ou receptionnée... c'est relativement bloquant ! c'est le cas de le dire ! ton api est paralisée pendant tout le temps que tu vas traiter ta page, et utiliser les interruptions proposés par arduino ne résoud rien du tout).

donc dans l'un ou l'autre cas il n'y a aucune difficultée. Construire une requête POST n'est pas plus compliqué que de parser une réponse et ce, quelque en soit la taille de la réponse et de la réception ou le protocole utilisé. faut juste s'adapter a l'arduino et faire pas plus que ce qu'il t'accorde.