Senior Member
Joined: 04/08/2023
Location: South AfricaPosts: 158
| Posted: 06:45pm 08 Sep 2023 |
Thanks to all for your input.
Perhaps a little background might be in order. I currently have a working application using an ESP32 which functions as an excess PV diversion to hot water storage, Solar Water Heater controller and an air tempering controller. The ESP32 provides logging information, including Modbus TCP register reads from a SMA Sunny Island and Sunny Boy through a JSON string to a fetch script running on a Pi4; which data is stored in FluxDB and displayed through Grafana running on the Pi4. The code, compile, run, fix, repeat development cycle from over 3 years ago is now all but a distant memory and I have avoided bug fixes for fear of breaking the code. The code, run, fix, repeat development cycle is very attractive. However all the data is moved across the ESP 2.4GHz WiFi.
So I'm looking to replicate this using MMBasic on the Pico W from what I perceive to be a better development cycle/environment. Therefore the Web Server is an essential component in the development of the Pico W MMBasic replacement. As Peter has indicated the Web Server is processor heavy and the HW Watchdog is potentially too short at 8331ms and the MMBasic provided firmware watchdog has its own issues.
The problem is that if the Web Server looses track of a TCP connection or the TCP connection is not closed or the TCP Client decides to retry a closed connection then the WiFi module causes a console generated error message and an abort to console prompt. Autorun does not restart the program from the console prompt. The program crashes I can tolerate but failure to autorun could have Solar Collector Header high temperature consequences.
In light of the foregoing, for my intended application, it is important that unattended operation is truly unattended. To this end the external watchdog rabbit hole.
@TassyJim - yes I'm using the TLC555CP which is good for 2V-15V. Thanks for the circuit, unfortunately I won't be able to test that because I have extremely limited component selection currently, which doesn't stretch to PNP transistors.
@Volhout - with the 555 configured as an astable it is 'retriggerable'. I don't currently have access to a 74LVC123, so can't try this approach currently. Your comment regarding PULSE made me go back to the manual and reread it. One of my concerns with the Pause approach was that the execution stops at the Pause, noting that interrupts still work. For PULSE durations 3ms and above the PULSE is backgrounded so does not affect the program flow in the way PAUSE does. SO yes PULSE could well be used less often for a longer duration.
One of my concerns was the state of the GPIO when the Pico is reset/power cycled/locked up in terms of resetting the astable. From practical experience so far the GPIO revert to Hi-Z status when things go awry, so even if there is an abort to console prompt the external watchdog is still alive. One must just remember to disable the external watchdog when one is busy at the console or you'll get some unintended resets :)
To divert excess PV energy into the geyser I'm using a purpose wound transformer with secondary taps, which are switched in with a tap changer comprising a bank of relays. The transformer losses are quite high, 70W, so I switch the transformer primary through a power MOSFET. Unfortunately being a 2kW inductive load the inrush current can be very high. On the ESP 32 conditioned mains is fed into an optoisolator with a Schmidt trigger output which drives the interrupt on a pin. I use this period to determine the mains frequency of the off-grid island. I attempted to use the voltage zero crossing plus half a cycle to switch the transformer on at a voltage peak and thus ensure the inrush current was limited to full load and not multiples thereof. Unfortunately this did not work. However, given the PIO state machines, your PIO frequency counter and your PIO course I'm hoping to implement the transformer MOSFET trigger using the PIO to drive the output pin precisely half a cycle after the program decides to turn on the transformer.
@phil99 - Unfortunately the ATiny85 is not a device I've had the pleasure of playing with. Volhout's comment regarding the failsafe nature of the external watchdog is valid. I guess it's that perennial question of who is watching the watcher :)
Thanks again for your comments and assistance.
Edited 2023-09-09 04:49 by carlschneider