 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : SetPin GPnn, DOUT [DIN] setup time query
| Author | Message | ||||
| carlschneider Senior Member  Joined: 04/08/2023 Location: South AfricaPosts: 158 |
Hopefully somebody can help me on the right path :) please. I'm trying to use the web server functionality of the Webmite but finding it quite unstable, i.e. the Pico is locking up. The HW Watchdog is too fast for some of the web server responses, as Peter has pointed out, and the software watchdog comes with its own challenges. I believe the culprit to be the web server, as evidenced by an error message relating to a connection, when there shouldn't be, unless the web server is being overloaded by page requests. To overcome this apparent unanswered web request I have introduced a WEB TCP CLOSE a% in a For Loop with an ON ERROR SKIP at the exit of the web server interrupt sub routine, in the hopes of closing any lingering TCP Clients. This has not improved the web server stability. To overcome this I have assembled a 555 astable multivibrator with a negative pulse when it times out. Time out is adjustable between ±0.5s and 80s. The low pulse is ±15ms. At the console the commands below work as expected. The 555 reset output pulse is inhibited with the 555 being reset by the DOUT and when DIN the Hi-Z of the pin floats the reset input of the 555 and the timer counts. > setpin gp14, din > setpin gp14,dout > However I don't seem to be able to replicate this in the program itself. I have tried various combinations but either get errors relating to the pin's IO declaration or in the example below, no 555 reset and thus it times out and fires the low output pulse. The only way I can get any stability is to introduce a Pause 30 as indicated in the code below. Sub PatDog 'SetPin GP14, DIN SetPin GP14, DOUT 'Set pin to DOUT, should be low 'Pause 1000 'Port(GP14,1)=&H1 Pause 30 'Port(GP14,1)=&H0 SetPin GP14, DIN 'Set pin back to Hi-Z End Sub As an alternative I tried putting the SetPin GP14, DOUT in a for loop with 75 iterations, which appears to have a similar result. This begs the question, how long does it take the Pico (MMBasic) to change the Pin's state from DIN to DOUT and for it to settle to a defined state? Or what am I missing that works at the console but not in the code? If HW Watchdog is too short at 8331ms and Watchdog is not entirely reliable then what else is there to do? Cheers Carl Retirement is tough on Hobbies without a day job |
||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 6100 |
' PIN(GP13) = 0 DO SETPIN GP13,DOUT SETPIN GP13,DIN PAUSE 1 LOOP This code gives a 20-30uS low pulse every 1mS on a pico running at 250MHz It needs an external pullup. I haven't had any reboots on my server since Peter made changes which included the HW watchdog. Before that I would monitor the RTC and if it had stopped, do a reboot. This worked because the timer that had a habit of stopping drove the RTC as well as SETTICK and the watchdog. Jim VK7JH MMedit MMBasic Help |
||||
| carlschneider Senior Member Joined: 04/08/2023 Location: South AfricaPosts: 158 |
Jim would you care to comment on the attached? After all my proof reading and editing I got the date wrong  Zen & the Art of Watchdogs.pdf Edited 2023-09-08 13:25 by carlschneider Cheers Carl Retirement is tough on Hobbies without a day job |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6100 |
I am the last person to comment on programming styles but I am sure you should be able to detect most if not all system failures without the need for external hardware. If you do use a 555, make sure it is a variant that runs on 3.3V such as the 7555 My choice of circuit would be  Your circuit should work. In either case, a longer pulse is desirable. Jim VK7JH MMedit MMBasic Help |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4246 |
EDIT: ignore the text below, you need a 74LVC123 (retrigerable monostable) to do this, 555 won't work since it cannot re-trigger). But the technique is usable if you choose for a 74xx123 chip.  Set GPIO pin 14 to output, and toggle it every X seconds (X<timeout). something like: SETPIN GP14,DOUT PIN(GP14)=1 'MAIN DO 'whatever needs to be done PULSE GP14,10 'generate a low 10ms pulse LOOP Pin GP14 connects to ICM7555 pin 2 directly. The output (ICM7555 pin 3) connects directly to the reset pin (RUN pin). At startup the capacitor is empty, causing the reset pin to be high -> the picomite starts up. It may be desirable to add a diode from the capacitor to 3.3V to make sure the capacitor also discharges fast at a power cycle. The monostable has a timeout of 1.1 x R x C. Volhout Edited 2023-09-08 19:40 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6100 |
If it was my system, I would use the ATTiny85 for minimum parts count and fully programmable. But that wasn't the question. Jim VK7JH MMedit MMBasic Help |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4246 |
Yeah.. But be ensured that mission critical applications are not allowed to use software (ATTINY) to perform a watchdog function. The blunt statement is still "software protection is no protection". But the world is changing ... PicomiteVGA PETSCII ROBOTS |
||||
| carlschneider Senior Member Joined: 04/08/2023 Location: South AfricaPosts: 158 |
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 Cheers Carl Retirement is tough on Hobbies without a day job |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
In that sort of situation it is *essential* that local control to handle the high temperature situation is done. If it could result in a dangerous situation then it must also be done in hardware, not software. It's fair enough to monitor the system and allow control (within limits set locally) using software. You should be unable to send a command that could cause a problem or force something out of limits no matter what happens to the software. Once again, it *must* be impossible for the system to get into a dangerous condition no matter what the software does at either end. You must assume that any software will always fail at some point and into the most dangerous mode. Hardware must take control away from the software and force the system into a safe mode that requires local resetting. This could be as simple as an automatic pressure-operated release valve (venting to a safe place) if there is a danger of fluid boiling in the system. All this is basic control systems stuff. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1109 |
Just my opinion, but I think you are putting too much into one Picomite, especially if there are such mission critical aspects that can result in dangerous failures. Instead, use one (non-wifi) Picomite that reliably handles just the important control aspect, and outputs a simple serial logging stream. A second one can swallow that serial stream and present it via wifi as desired. If it falls over, the important parts will continue to run safely on the first one. Visit Vegipete's *Mite Library for cool programs. |
||||
| carlschneider Senior Member Joined: 04/08/2023 Location: South AfricaPosts: 158 |
Thanks for the input. @MixTel90 - there are mechanical safeguards in place. @vegipete - I'll give the approach some thought. Cheers Carl Retirement is tough on Hobbies without a day job |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
I agree with Pete on this. Leave the control loop functional at all times. It removes a big headache. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
 Print this page |
