Hello all,
I made a scetch for an UNO which controls both our heat pump and our central-heating boiler, depending on around 6 temperatures measured at different places within the heating system, and also a few digital inputs.
There are many IFs and dependences. MANY.
Well, it seems to work, but quite difficult to test.
No chance to test with the true heating system, its by far too slow. And in summer not possible.
So the idea, replace the temp sensor inputs by variables and change them during runtime.
But how?
Serial.read() can read one variable (or string) only at a time, no random entry possible.
My best idea up to now, input strings like "T1: 45" , and have a parser which understands that T1 is my variable I want to change, and then allocates 45 to it.
Not so fancy, but might work.
Any better idea?
If not, I need to write a parser also... but I'm not so good when it comes to string manipulations.
I'm pretty sure that somebody else had the same situation already... I just could not find a solution in the forum.
Thanks for any help!
How about using the analogue input port and using pots to simulate the signals from your sensors. If there are not enough ports you can always multiplex them.
I like Mike's idea... At some point you'll need to functionally test the real controller with real inputs and for that, you'l' need to sumulate the hardware inputs.
But, I'd start by hard-coding some variable values and/or maybe changing/incrementing some values under software control. This will require re-compiling every time you want to change a variable and it may not allow you to test every combination, but it give you a rough idea if things are working.
The parser idea is nifty! It would be handy for troubleshooting once you have a working design... It would be super-handy if you were going "into production" building many of these things. But, I think it's a lot of work to write and debug the parser and integrate it with your main code. If something doesn't work you won't know if it's the main program, the parser, or the communication between the two...
Hi all, thanks for your replies!
Attaching pots to the analog inputs: well, there are no free inputs as I have an UNO, and attached an SD card (4 pins), a Nokia 5110 (5 pins + background LED), 1-wire, i2C for the RTC, and the rest is fully eaten up by the digital controls. And also, welcome to 21th century.. why build a breadboard full of pots, if there is a computer available?
The last suggestion: "use constant values within the software for testing", thats what I have now. It does not help at all, as there are timers running also... cannot re-compile and upload as the timers are reset to zero then.
Squirt in via I2C? How? Don't say: attach pots to an i2c ADC please!
Seems I have to write the parser if no other idea comes up, but I'm sure I'm "inventing the wheel again" as we say here.
If it's not connected to the real heating system all the pins that would be connected to the heater should available for connecting other test things to? Perhaps switches that simulate the outputs from the heater or pots to represent temp sensors.
I would treat the verification of the program logic separately from verifying the working of the sensors and "pretend" sensors will do for verifying program logic.
I think that most of your inputs should be provided by fake sensors (or perhaps even real sensors under your control) rather than fudging the results by a debugger. The missing element is time. I guess you have an RTC and if so I assume you have the means to configure it and set the time. In that case you could provide a command that sets the RTC to a specified time. I don't see the need for more complex/general command handling, but if you do decide to take that approach then you could look at adding a Bitlash interpreter to your sketch.
But, I think it's a lot of work to write and debug the parser and integrate it with your main code.
Not really. For design considerations, write the parser to operate on constant-width string verbs, then the variables can be random numerical ASCII digits.
One could also use EEPROM if it is not being used for other program use to contain test data... during the test, EEPROM data would be processed to create the test-case output for validation.
Or, one could keep the test data in flash static structures specified by PROGMEM and swap variable pointer at test time in the code.
swap(&a, &b)
Implementation would depend upon the design of the main program to a large degree.
thanks for your replies again! @awol, yes you mentioned. Unfortunately I have no idea how to modify parameters during runtime thru I2C. @Robin2: yes I could use those pins. Its 1 pin for the 1-wire sensors, 2 more digital INs and 2 digital out. And now? Yes I COULD attach pots. But really, I dont want to change all my pin layout and make a breadboard with pots (and there are not enough free pins anyway). I was looking for a more smart solution, thats why I posted. @PerterH: exactly. My fake sensors should be parameters which are changeable during runtime.... Time is not missing. There is a debug-mode in which all the long delays are set to a few seconds.
Mrburnette: good idea, but EEPROM data might not work. Need mostly 'analog' values slowly changing, and have to watch the behavoir of the scetch (there is plenty of debug output thru serial.write()). And, if something is wrong with your eeprom data, you would have to recompile and reload (and stop the scetch). The current status was lost then.
Gentlemen, its not my first project. I earned my living with custom-designed controllers years ago. I still remember how to effectively debug complex control structures...
Its my first project with Arduino however, and this is why I posted.
Please let us go back to my initial question: how to change say 10 different variables in a running scetch, by software ?
Up to now I have no better solution than the one mentioned in my initial post: thru Serial.read, with a small parser who 'decodes' what has been typed.
Any better idea, I'm glad to learn about!
Meanwhile I'll look into Mrburnette's link to a parser!
