Ejemplos de programación en B4X

[D@rkbytes]

Ejemplo de actualización OTA (Over The Air) para ESP8266
O sea, actualizar nuestro dispositivo vía inalámbrica, esto se puede hacer localmente con un servidor casero o con un servidor en la red del tipo HTTP.

Esta forma de actualización tiene sus ventajas y desventajas.
La principal ventaja es que no necesitamos conectar nuestro dispositivo a la PC para actualizarlo.
Podemos tener varios dispositivos instalados y se podrán actualizar ellos mismos tras un tiempo programado o de forma manual.
Los clientes podrán recibir actualizaciones y no tenemos que ir nosotros.
Al crear nuestros proyectos con la tarjeta base (la del SoC) podremos actualizarlos sin cables, estén donde estén.

Las desventajas son en mi caso, solo una.
Si tienes varios clientes y cada dispositivo tiene protección de identificación, se tendrán que subir al servidor varios archivos.
Y por supuesto, con cada actualización hay que programar bastante, por lo menos en lo que respecta a las claves.

Cabe mencionar que cada programa debe contar con el sistema OTA más el código de usuario.

El ejemplo que subo es muy sencillo, carece de verificación de versiones y muestra poca información como log.
Aunque mostrar información sobre el proceso es importante, no se debe mostrar todo, al menos no en lo que respecta a direcciones de archivos.
Obviamente un log lo podemos ver por RS-232, pero al usuario solo se le muestra información concisa en pantalla.

El ejemplo que adjunto es funcional desde el primer uso, ya que lo dejé con un enlace válido de descarga de un servidor gratuito.
Tras compilar y grabar el programa, este descargará el archivo, lo guardará en la memoria, dará formato a las particiones y grabará el archivo descargado.
En este caso, el ESP8266 empezará a destellar el LED del módulo o SoC (GPIO 2) cada segundo. (El clásico blink)
Como el archivo en el servidor no tiene el sistema OTA, solo quedará destellando el LED.
Ya ustedes pueden crear sus programas y añadir la actualización OTA a sus proyectos.

Próximamente subiré el ejemplo para los ESP32 que, al ser más elaborado, proporciona bastante información sobre el proceso.

 

[D@rkbytes]

Ejemplo de actualización OTA (Over The Air) para ESP32

Este ejemplo es más completo que el anterior para los ESP8266, este sí cuenta con verificación de versiones.
Esta verificación se realiza sin descargar ningún archivo, se lee directamente del servidor usando HttpJob.

El programa puede comparar la versión en el dispositivo y la versión en el servidor.
Comprueba si es mayor, menor o igual.
Obviamente la actualización solo debe realizarse cuando la versión en el servidor sea mayor a la del dispositivo.
Sin embargo, pueden optar por realizar un down-grade.

De igual forma que el anterior, es completamente funcional desde el primer uso, ya que usará archivos de un servidor activo.
La versión base es la 1.0 que hace destellar un LED cada segundo, mientras que la del servidor es la 1.1 y destellará un LED cada 250 mS.
El archivo en el servidor no tiene el sistema OTA, no tiene caso que se lo ponga porque no se conectaría al estar programado para mi red.

Requisito importante:
Al reprogramar un ESP no se borra el contenido de la zona reservada para "EEPROM" en la Memoria Flash.
Por eso es necesario que sea borrada, ya que si existe contenido, este puede afectar en la comprobación de versiones.
En este ejemplo usé 7 bytes, ya que la versión se compondrá por: MajorVersion y MinorVersion.
Al ir separadas por un punto, tenemos la posibilidad de hacer verificaciones cómo 1.1, 1.2, 1.3, etc.
Así que la comprobación será del tipo "Double" hasta 254.254 (El 255 es considerado como locación sin datos)

El borrado de la Memoria Flash lo pueden realizar de forma sencilla con ESP Restorer

Notas:
El procedimiento de comprobación de versiones lo pueden usar para los ESP8266

 

[D@rkbytes]

Actualización para el ejemplo ESP32 OTA Updater

En el ejemplo anterior se utilizaban 7 bytes para almacenar la versión en la EEPROM, en esta actualización solo se usarán 2 bytes.
Sucede que estaba guardando el valor como una cadena al escribirla como texto.
Ahora estoy guardando la cadena como debe ser, en ASCII y sin usar el punto.
Así solo se leerán los correspondientes bytes para MajorVersion y MinorVersion, los cuales sumo para su posterior comparación.
Así que ya no usé variables del tipo double y las cambié por Int.
Entonces para el máximo valor de la versión que sería 254.254, se obtiene un total de 508
La visualización correcta de versiones al estilo "v4.7X" se realiza por software de forma sencilla añadiendo el punto.

También moví la locación de almacenamiento de la versión hasta las últimas locaciones de la EEPROM (0x1FE y 0x1FF)
Dejando así libres las primeras locaciones que por comodidad suelen ser las más usadas.

Como escribir en ASCII no es para nada sencillo, realicé una aplicación que genera el archivo de la versión.
Este archivo será el que se debe subir ahora al servidor.

Edit:
Me quedé pensando que al sumar las versiones puede haber un error.
Esto es porque sumar, por ejemplo: v1.25 resultaría: 1 + 25 = 26, pero si la versión es v2.3, resultaría: 2 + 3 = 5
Así que la comparación sería incorrecta aunque la versión sea superior.
Debido a esto, opté por comparar cada byte por separado y así ya no hay error, aparte de que retiré las variables Int.
Subo la corrección aquí mismo, dejando el archivo anterior solo para la posteridad.

 

[D@rkbytes]

Actualización para el ejemplo ESP8266 OTA Updater

Se agregó la comprobación de versiones.

Nota.
Esta actualización hace destellar el LED (On-Board) cada segundo, tras la actualización destellará cada 250 ms.
Hasta ahí se quedará porque debido a lo mencionado anteriormente, el archivo en el servidor no tiene el sistema OTA.

 

[D@rkbytes]

Ejemplo de Servidor TCP con ESP/12/8266/32 y Cliente con VS .NET C#

Continuando con los ejemplos de programación en B4R, esta vez les comparto algo que para mí fue un reto.
Y menciono que fue un reto porque esto lo traté de hacer desde el 2021 y lo logré pero parcialmente.
El problema radicaba en la aplicación cliente que la inicié en VB6 y solo podía recibir mensajes, pero el servidor ESP32 no los recibía.
Comunicando con otras aplicaciones servidor, sí los recibían pero el ESP32 no lo hacía, solo los podía recibir de aplicaciones Android.
Así que tras la derrota, me olvidé del asunto, pero me quedé con la duda del por qué el ESP32 no recibía los mensajes.
Pasó un tiempo y volví a la carga pero ahora usando VB .NET, pero la cosa seguía igual, no lograba hacer que el ESP32 recibiera los mensajes.
Poniendo un poco de atención, noté que cuando enviaba un mensaje el ESP32 se detenía, lo que me hizo pensar que al menos estaba recibiendo datos pero que seguramente no los podía interpretar.
Traté de implementar un Socket con API pero el resultado era el mismo, así que lo volví a dejar en el olvido.
Cierto día y ya transcurridos dos años, me encontré la carpeta del proyecto, y me dije... esta vez lo tienes que lograr.
Entonces me olvidé del VB .NET y empecé a escribir una aplicación en VS .NET C#
La inicié desde cero usando la clase Sockets (System.Net.Sockets), sin embargo, el resultado seguía siendo el mismo.
El ESP32 se rehusaba a recibir los mensajes, y cabe mencionar que recibirlos en el cliente también tiene su ciencia.
Pues resulta que el ESP32 me enviaba como cabecera lo siguiente: "\r\0\0\0"
Estos datos hacían que no se pudieran mostrar en el TextBox y aparte se omitía el resto del mensaje enviado por el ESP32.
Haciendo un poco de depuración fue como dí con esto, de otra forma, ni recibir ni enviar hubiera podido.
Así que en VB6 y VB .NET hice uso de la función Mid para omitir los primeros 4 bytes, ya el resto sería el mensaje.
No sé si esto también suceda al escribir un programa servidor en Arduino, pero en B4R esto sucede.
Solventado este inconveniente, solo me hacía falta que el ESP32 interpretara los mensajes que le enviaba.
Apliqué lo mismo; enviar la misma cabecera que recibía y posteriormente el mensaje, pero nada.
Inicié esto enviando cadenas de texto, como el clásico: "Hola, mundo.", pero el ESP32 tan solo se inmutaba, más no mostraba nada.
Me puse a buscar ejemplos y el resultado era el mismo, así que aquí había algo que yo no sabía y tenía que averiguarlo.
Estudiando un poco el protocolo TCP, vi que se tenía que enviar un encabezado que debe contener la longitud del mensaje, y debe especificarse si el encabezado tiene o no tiene un plan de texto sin formato.
Así que se concatena todo y se envía como un paquete de bytes.
Tras esto, implementé una clase que llamé TCPClass y en ella está todo lo necesario para enviar el paquete (PacketHeader).

Viendo la luz.
Obviamente, al ir implementando esta clase tuve varios problemas pero fueron solventados con depuración.
Como me encontré con un repositorio NuGet llamado SuperSimpleTcp, lo instalé y lo empecé a usar en mi aplicación.
¿Por qué? Pues porque me resultó muy cómodo su uso, así que tuve que hacer que mi clase TCPClass pudiera ser compatible con este NuGet.
No tuve inconvenientes en lograrlo y ahora ya todo funcionaba, el ESP32 podía interpretar los mensajes y mi aplicación cliente podía recibirlos.
Bien, ya lograba recibir y enviar cadenas de texto, así que ahora quise enviar bytes.
Y este es el ejemplo que les comparto, ya que enviar cadenas de texto es como para un chat.
Sin embargo, esta aplicación en C# .NET también puede enviar cadenas de texto y el ESP32 las recibirá, pero no hará nada, solo las mostrará por Log.
La finalidad de este proyecto es poder tratar con sensores y recibir sus datos, así como controlar periféricos y saber su estado.

Cabe mencionar que usé .NET 5.0, en Windows 10, por lo que deben usar versiones recientes de Visual Studio.
Yo usé Visual Studio 2019 que es la máxima versión soportada por este sistema, ya que las versiones más recientes como VS 2022, aunque se puedan instalar en Windows 10, al final nos dice que posiblemente algunas cosas lleguen a presentar incompatibilidad.
Si tienen instalado Windows 11 también se podrá y hasta usar un .NET más reciente, como el 6, 7 u 8.0
Pero la migración a veces tiene consecuencias que suelen ser un dolor de cabeza resolver.

Notas finales:
El cliente no cuenta con detección de cierre del servidor, quedó pendiente.
No será necesario instalar el repositorio NuGet SuperSimpleTcp porque incluí en el programa las clases necesarias como cliente.
Podrán implementar el código de B4R en ESP12, ESP8266 y ESP32, como en este caso. (Solo deben especificar la plataforma)
En un diseño final es conveniente integrar una pantalla LCD I2C al ESPX para mostrar el IP del servidor, porque puede cambiar.
Se puede obligar al ESPX a usar un IP siempre fijo, y sobre esto me pueden consultar.
En los programas se van a encontrar con instrucciones comentadas (No usadas) y son las que posteriormente dejé de usar cuando estaba realizando pruebas con cadenas de texto.
El valor del sensor 2 es fijo, quedó sin implementar, no contiene código, eso es para que lo usen como quieran.
Quedando como muestra de que se debe usar un Encoding adecuado para poder recibir y enviar bytes con valores superiores a 127
En este caso usé la codificación ISO-8859-1
Lo que el servidor envía es simplemente un conteo UInt cada 100 ms, el estado de un GPIO controlado y otro GPIO como entrada digital.

​

Ejemplos como este, y sobre todo, programando en B4R conjuntamente con C#, no los van a encontrar.
Así que por ese lado me siento orgulloso de compartir una novedad.
Como siempre, espero que estos ejemplos sean de utilidad.

 

[Dr. Zoidberg]

El cliente no cuenta con detección de cierre del servidor, quedó pendiente.

Suporongo que en C# se dispara una excepción en el cliente al cerrar el socket servidor, si es que la lectura es bloqueante. Si es así, es sencillo detectar el cierre del socket servidor...

 

[D@rkbytes]

Suporongo que en C# se dispara una excepción en el cliente al cerrar el socket servidor, si es que la lectura es bloqueante. Si es así, es sencillo detectar el cierre del socket servidor

Sí, por supuesto, pero como me interesaba más poder hacer que el ESP pudiera interpretar lo que enviaba, que eso lo dejé para luego.
Si lo quieren implementar, ahí está el código.

Añado también lo siguiente como una mejora al código en C#:

                        // Separar cada byte de la cadena.
                        for (byte x = 0; x < MAX_BUFFER; x ++)
                            dato[x] = strData.Substring(x, 1);
                        /* Lo anterior reemplaza a esto:
                        dato[0] = strData.Substring(0, 1);
                        dato[1] = strData.Substring(1, 1);
                        dato[2] = strData.Substring(2, 1);
                        dato[3] = strData.Substring(3, 1);
                        dato[4] = strData.Substring(4, 1);
                        dato[5] = strData.Substring(5, 1);
                        dato[6] = strData.Substring(6, 1);
                        */

Vista real en VS:


Algo que también podrán notar en el código de VS C# es el modo de control sobre el estado del GPIO en el ESPX, que en este caso es un LED (OnBoard)
El texto del botón se establece conforme al estado recibido, no conforme a lo pulsado o expresamente decidido.
Este método ofrece una seguridad completa sobre el estado del GPIO desde que la aplicación se conecta al servidor.

 

[Dr. Zoidberg]

Hay una forma más rápida de hacer la conversión a bytes, el problema es que esto siempre depende de la codificación que use el string;

How to Convert String To Byte Array in C#

The Encoding.GetBytes() method converts a string into a byte array in C#. This article includes a code example of how to convert a C# string into a byte array.

www.c-sharpcorner.com

 

[D@rkbytes]

Hay una forma más rápida de hacer la conversión a bytes, el problema es que esto siempre depende de la codificación que use el string;

How to Convert String To Byte Array in C#

The Encoding.GetBytes() method converts a string into a byte array in C#. This article includes a code example of how to convert a C# string into a byte array.

www.c-sharpcorner.com

Lo apliqué y funcionó correctamente.

El código ahora quedó así:

// Separar cada byte de la cadena.
byte[] dato = Encoding.GetEncoding("ISO-8859-1").GetBytes(strData);

byte ident1 = dato[0];
byte ident2 = dato[1];

if (ident1 == 36 && ident2 == 64)   // Identificadores válidos.
{
    byte msbCount = dato[2];  // Obtener el MSB
    byte lsbCount = dato[3];  // Obtener el LSB

    int Count = (lsbCount + (msbCount << 8));   // Obtener el entero.

    byte led_state = dato[4];
    byte sensor1_state = dato[5];
    byte sensor_value = dato[6];
    ...

Gracias.

 

[Dr. Zoidberg]

Gracias.

De nada!!
En Java existe un metodo de la clase String que te lo convierte a bytes...creo que se llamaba getBytes() o toByteArray() y supuse que C# debía tener uno parecido. Me puse a buscar y encontré ese.

 

[D@rkbytes]

Downgrade

Aplicación Cliente para el ESP32 pero ahora programado con VS C# 10 (Express y .NET 4.0)

Me quité la comodidad de usar librerías de terceros y aparte opté por escribir el programa con lo básico del entorno.
Estudié que como aplicación cliente no se puede obtener muy fácilmente un controlador de Servidor cerrado.
Y esto es porque se carece de ese evento, lo que se tiene es el evento "Connected", pero este evento es más propio del cliente, más no del servidor.
Así que, empleando ciertas estrategias de programación, se puede por lo menos determinar por error el estado de conexión.
Y es que, aparte de no existir un evento nativo, "ServerDisconnected", capturar el error de servidor desconectado puede tardar.
Esto conlleva a que se pueda enviar un dato con el servidor desconectado y posteriormente generar un error.
La única forma de solventar este problema es haciendo uso del "catch" y proceder de manera adecuada ante el error.

Anteriormente comenté que el reto era al usar el servidor programado con B4R
Ya que este entorno es muy diferente a Arduino, y naturalmente tiene mucho más ventajas.
He explicado que programar en este entorno es muy similar a programar en VB.NET y que para lograrlo se hace uso de RTOS.
Bastante genial el asunto, pero obviamente se consume más memoria, cosa que en un ESP32 no es preocupante, pues dispone de sobra y se puede aumentar hasta más de sus 4 MB.

Comento lo anterior porque al programar un servidor en Arduino no hay problema con el protocolo TCP.
Es tan simple que, un Socket en VB6 puede lograr conexión bilateral sin problemas.
O sea que, recibirá los datos sin problemas, al igual que cualquier programa cliente TCP programado en cualquier lenguaje y plataforma.
Caso que no sucede al programar un servidor con B4R, aquí las cosas cambian, por eso se implementó la clase TCPClass.
Y esta clase es exclusiva únicamente para el envío de datos, ya que la recepción se da sin problemas, pero haciendo un recorte de la cabecera, que ya fue explicado anteriormente.

¿Por qué quise hacer el Downgrade?
Como programador tienes que estar al tanto de las novedades y actualizaciones del entorno que usas.
Y así como avanzan los sistemas operativos, también lo hacen sus entornos de programación.
Esto es de considerarse normal, pero infortunadamente, no todos pueden tener acceso a un nuevo PC que soporte el sistema operativo más reciente.
Es por ello que escribí este nuevo programa completamente funcional y que es apto con un .NET por defecto en Windows 10

Adjunto el nuevo proyecto completo, con ejecutable compilado y todas sus carpetas.
Nota: Se creó en modo Release para Windows 10 x64, si lo quieren usar en x86 u otro CPU, tendrán que cambiar las opciones de compilación.