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.
Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769
Posted: 09:17pm 11 Sep 2016
Copy link to clipboard
Print this post
Back a few months ago when I discovered Geoff's wonderful MMBasic interpreter I initially decided to try to use a MaxiMite CPU to control my geothermal heating system. I quickly discerned that I would probably need two CPUs. One CPU would continuously loop through the reading of the 14 temperature sensors, then the decision-making logic, and would finally control 12 relays. The second CPU would display the real-time operating parameters, accept control settings from the user, and periodically write data in a delimited form to a file on a camera card. I determined that the two CPUs would have to talk to each other, passing data back and forth, and that there would be approximately 375 individual numeric variables which would have to be passed back and forth. In order to simplify the coding of the communications routines I decided to hold all of the numeric variables in multidimensional arrays, which would enable me to transfer the array contents using loop structures.
The real reason for using two CPUs was to enable the first CPU to continuously loop through its data acquisition, decision-making, and control functions without interference caused by a slow speed human keying in control setting changes. The human would only interface directly with the second CPU which would not be in direct control of the machinery. I thought that the initial human interface would include a large monitor and a 10 key pad.
Then the interrupt driven GUI extensions to MMBasic, the E64, and now the E100 appeared. All of my initial decisions might now be invalid. I believe that either the E64 or the E100 interfacing to a touch sensitive display might be more than powerful enough to handle the entire job.
Before I make this change I need to know something more about how the interrupt driven GUI extensions operate, and I believe that Geoff will be the only person who can answer my question.
Assuming that the code is cycling continuously through the primary loop wherein it reads 14 DS18B20 sensors at maximum resolution, then makes about 75 comparisons of numeric values, then actuates the 12 relays, taking approximately 5 seconds to traverse each iteration of the primary loop, I need a quick estimate of how long it will take for it to complete the following interrupt driven tasks:
1. Display approximately 30 real-time values on a single screen.
2. In response to a touch on a pad display an alternate screen with approximately 20 numeric values.
3. In response to a touch on one of the displayed values display the GUI NUMBERBOX.
4. In response to a touch on one of the number pads in the GUI NUMBERBOX build a temporary variable.
5. In response to a touch on the enter pad in the GUI NUMBERBOX transfer the value entered into the underlying GUI variable.
In describing the GUI NUMBERBOX the documentation says that a pen down interrupt will be generated when the keypad is deployed and a key up interrupt will be generated when the Enter key is touched and the keypad is hidden. Also, when the Enter key is touched the entered number will be evaluated as a number and the NUMBERBOX control redrawn to display this number.
Does this mean that the entire GUI NUMBERBOX call generates one long interrupt to the main program loop which lasts until the GUI NUMBERBOX control is redrawn displaying the new number, or does it mean that each individual touch generates a relatively short interrupt to the main program loop.
If each touch is a separate event which only interrupts the main loop for a few milliseconds this will work. If, on the other hand, the GUI NUMBERBOX control interrupts the main loop for the entire time it takes the human to touch a displayed value to be modified, then touch the three digits and the decimal point needed, then touch the enter pad, the total length of the interrupt could easily reach 10 seconds which would not work at all.