Recapitulando lo que hemos hecho hasta ahora solo nos queda libre el GPIO2 y todavía tenemos que poner:
- Un sensor de ultrasonidos HC-SR04P-> 2 pines
- Un led de estado-> 1 pin
- Un relé reed para que el usuario pueda interactuar->1 pin
- Un buffer para conseguir que los sensores no consuman cuando el micro está en Deep Sleep-> 1 pin
- Un termómetro para hacer la compensación de temperatura del sensor de ultrasonidos-> 1 pin.
En total tenemos que liberar 6 pines, lo cual parece una tarea imposible, pero estoy firmemente dispuesto a que este circuito sea lo más sencillo posible, por lo que vamos a darle una vuelta.
Aclaro algunas cosas en este punto: Me gustaría tener un mecanismo para poder configurar el dispositivo, cambiarle los periodos de sleep, las claves de Lora, y para poder almacenarlo en un modo con un consumo mínimo y que el cliente se lo active al recibirlo. Uno de los motivos por los que hemos utilizado el ESP8266 es para poder poner el dispositivo en un modo que nos permita acceder a través de su wifi y configurarlo. Para ponerlo en modo wifi hace falta algún elemento que haga de interfaz con el usuario. Como queremos que sea lo más impermeable posible pondremos un relé reed. Acercando un imán al dispositivo el relé se habilitará y la WiFi se pondrá en marcha en modo de configuración. También queremos dar al usuario un indicador de que estamos en modo de configuración, la idea es utilizar un led, posiblemente dentro de la carcasa aprovechando la trasparencia que tiene el material. Nos quedan dos temas por resolver: por un lado para calcular el nivel utilizamos un sensor de ultrasonidos y calculamos la distancia en función del tiempo que tarda el rebote y la velocidad del sonido. Como la velocidad del sonido varía en función de la temperatura no nos iría mal conocerla para compensar la diferencia. Finalmente, no quiero tener permanentemente alimentados los sensores ya que nos consumirían energía mientras el micro duerme. Por ese motivo mi intención es que la línea de alimentación de los sensores se active solo cuando necesitemos medir, con un pin. Mientras el micro duerme no estarán alimentados, en el momento en el que el micro tenga que leer los alimentará. El pin, directamente, no soporta la corriente necesaria por lo que vamos a hacer la prueba con un buffer, he encontrado uno que consume solo 0,9uA en reposo, que parece el adecuado.
Recuperando pines
Leyendo la documentación de la librería LMIC veo que el Pin DIO3 de la radio se utiliza para la modulación FSK, como solo vamos a usar Lora lo liberamos directamente. Ohhh, malas noticias, el pin que habíamos usado es el GPIO3 que corresponde al RX de la UART, podremos hacer algo, pero no es utilizable para cualquier cosa.
Buscando buscando llego a este artículo, al parecer alguien tiene un comit pendiente a la librería LMIC para poder prescindir de los DIOS de la radio y en lugar de leerlos por hardware leer un registro del RFM95 a través del SPI. Lo pruebo y funciona!!! con lo que liberaríamos dos pines, pero leo que no está del todo claro que no hayan problemas de timing con la recepción de Lora. Al final opto por una solución intermedia que sugieren, que es conectar los DIO1, DIO2 y DIO3 con unos diodos emulando una puerta OR y una resistencia de pulldown. He recuperado otro GPIO sin correr demasiados riesgos, y este es de los buenos.
Veo que la última versión de la librería del sensor de ultrasonidos permite utilizar el trigger y el echo en el mismo pin del procesador. Tiene todo el sentido del mundo, en lugar de usar dos pines la librería pone el trigger como output, dispara lo pone como input y espera el echo (me imagino), con esto no libero ningún pin, pero me ahorro uno.
Intento sensar el relé reed en el puerto analógico, pero veo que no puedo, el puerto analógico es utilizado por la función ESP.getVcc() para recoger la tensión de alimentación y este dato lo necesitamos para conocer el nivel de la batería. No me sirve la idea, mi plan B que era utilizar un sensor de temperatura analógico también se desmonta.
Aunque el GPIO0 se utiliza para poner en modo programación el ESP y alguna cosilla más, pienso que es un buen puerto para poner el LED. Este puerto tiene que estar a nivel alto para que el procesador arranque en el modo que deseamos, pero la comprobación se hace solo en el inicio, por lo que entiendo que después se puede utilizar sin problemas. Pruebo el LED y me doy cuenta de que ese puerto cambia de estado varias veces cuando arranca el micro. No nos sirve!!!! el cambio de estado implica que el LED se enciende y consume batería. Posteriormente pruebo el termómetro por este GPIO y veo que funciona sin problemas (o con problemas que no tienen que ver con esto que comentaremos más adelante), con lo que recupero un GPIO más porque el GPIO0 lo había descartado inicialmente.
He puesto el GPIO3 (RX) con input, lo cual me permite seguir depurando por el TX y utilizarlo para la entrada del relé reed. Como el relé reed está normalmente abierto me va a permitir subir los programas cuando lo necesite sin Interferir, así que al final podremos aprovechar el primer GPIO que liberamos.
Nos falta uno y habremos triunfado para el buffer que va a alimentar los sensores. El ESP 12e tiene accesibles unos pines en la parte de atrás, cuando intento configuar el modo me aparece basura por el puerto serie y el ESP se acaba reiniciado desde el wdg. Después de algunas búsquedas veo que se utilizan internamente para la comunicación con la memoria flash, lo cual hace inviable el utilizarlos. profundizando e investigando un poco más veo en este artículo que hay dos pines que se utilizan para la comunicación QIO y no se utilizan para la comunicación DIO con la flash. Uno no se puede utilizar porque está cableado internamente a la memoria, pero el GPIO10 se puede liberar si el modo de comunicación con la flash es DIO. Pruebo y, eureka!!!!! me funciona sin problemas para conectar el bufferque proporcionará la alimentación a los senores.
Tengo todos los GPIO que necesitaba que era una cosa que no tenía clara al principio. Con todo esto ya podemos dibujar el esquema del circuito.