Comunicación PIC a PIC usando WiFi

Dr. Zoidberg

Well-known-Papá Pitufo
El delay está demas. Hay que dar un client.flush() en lugar del delay y despues el stop() o nó, depende si queres seguir hablando con el cliente y si este soporta http 1.1 o superior.
 

Dr. Zoidberg

Well-known-Papá Pitufo
El delay está demas. Hay que dar un client.flush() en lugar del delay y despues el stop() o nó, depende si queres seguir hablando con el cliente y si este soporta http 1.1 o superior.
El comportamiento de client.flush() está medio inentendible por que en readthedocs dice:
https://arduino-esp8266.readthedocs.io/en/latest/esp8266wifi/client-class.html dijo:
flush and stop
flush(timeoutMs) and stop(timeoutMs) both have now an optional argument: timeout in millisecond, and both return a boolean.
Default input value 0 means that effective value is left at the discretion of the implementer.
flush() returning true indicates that output data have effectively been sent, and false that a timeout has occurred.
stop() returns false in case of an issue when closing the client (for instance a timed-out flush). Depending on implementation, its parameter can be passed to flush().
Mientras que en la API de Arduino, con la que este debería ser compatible, dice:
https://www.arduino.cc/en/Reference/WiFiClientFlush dijo:
flush()
Discard any bytes that have been written to the client but not yet read.
:oops: :oops:
Que es totalmente lo opuesto a lo anterior y también opuesto al 100% de los lenguajes del planeta.

Mejor probalo y fijate como vá...
 
Estoy de acuerdo que depende del proyecto y que sin dudas, mientras menos "agregados" tengas, menor la posibilidad de fallas.

Pero agregar un uC aparte te puede dar la flexibilidad que tiene ese uC y tal vez no el ESP, por ej. control PWM, múltiples SPI, DAC, incluso más puertos.

Se me ocurre un ej. donde tener otro uC puede ser útil:

Supongamos que la conexión WiFi deja de responder (no necesariamente por el ESP, sino por el Router o cosas mágicas del WiFi), el ESP te ofrece un puerto para resetear el dispositivo y reestablecer conexión cuando los comandos/funciones internas dejan de ser útiles (y pasa muy seguido). Si usás el watchdog del ESP podrías conseguir eso, sin embargo si estás en medio de un proceso de control, no es buena idea hacer eso. Con un uC externo, reseteas el ESP y seguís controlando como si nada pasara.

También está el asunto que menciona Scooter, para manejar bien el ESP, es necesario meterte con las API que ofrece el fabricante (hablo en C puro, no Arduino) y sus métodos de programación. Lo cual no está mal, es como cualquier otro uC que hay que familiarizarse, pero tal vez el tiempo que lleva y los beneficios en costo por la cantidad a fabricar, no valen la pena esa inversión de tiempo. Como todo, siempre es mejor aumentar el conocimiento, pero el tiempo puede ser también determinante.
 

Dr. Zoidberg

Well-known-Papá Pitufo
También está el asunto que menciona Scooter, para manejar bien el ESP, es necesario meterte con las API que ofrece el fabricante (hablo en C puro, no Arduino) y sus métodos de programación. Lo cual no está mal, es como cualquier otro uC que hay que familiarizarse, pero tal vez el tiempo que lleva y los beneficios en costo por la cantidad a fabricar, no valen la pena esa inversión de tiempo. Como todo, siempre es mejor aumentar el conocimiento, pero el tiempo puede ser también determinante.
Es que con la pseudo-API Arduino-Like podés hacer muchas cosas, y en particular gestionar la comunicación en red bajo TCP/IP...aunque supongo que la API del fabricante también lo tendrá. Digo, a menos que quieras explotar el chip para algo muy sofisticado (y que sabés que esta disponible), usando el IDE de Arduino podés programar lo que quieras, aún no usando la API Arduino-Like que está implementada para que la transición de Arduino al ESP sea no-traumática (otro tema es si esto es una buena o mala elección), pero si detrás tenes el compilador para el C de ESP y el IDE de Arduino no es más que un editor (que no es mas que eso), yo no veo para que tener que liarme con un entorno de programación del fabricante que tal vez sea diferente a lo conocido si lo puedo hacer con el entorno "fácil" del Arduino (yo uso el Code::Blocks para programa en C y C++, para compilar con el GCC, el Open Watcom y no me acuerdo cual versión del compilador del Visual Studio de Mocosoft...y anda para todos igual)

Todo el mundo se persigue con el IDE del Arduino, pero no es más que un editor fácil de usar, en el que si querés usás la API y si nó querés (por que sabés mas) programás como se te cante, que mientras sea código compatible con el AVR-GCC, no vas a tener ningún problema.

Pues acá es lo mismo...

PD: Péguenle una revisada al código de las bibliotecas externas al Arduino (como las que puse acá) y van a ver que todos los "dolores" son totalmente infundados ==> podés programar lo que se te cante como se te cante.
 
Arriba