if serial available OR analog read is 2V..... first read the char that MAY NOT BE THERE?
That's what your code does.
That's just one line begging to be a bug that I am not tracing down to fix. One of many puzzles that include mixing millis timing with blocking commands and loops.
All at once? Don't you need to get text BEFORE voltage?
I apologize for replying a little late. Currently, four conditions are required
if (enableDataLogging == 0 && (receivedChar.indexOf("2") > -1 || voltage > 2 ) )
I increased this even more There are 4 conditions.
if (( voltage > 2 || (receivedChar.indexOf("2") > -1 ))&& enableDataLogging == 0 && receivedChar.indexOf("3") > -1 )
in this case i want it to work here. 1-) enableDataLogging == 0 AND receiveChar.indexOf("3") > -1
2-) received Char.indexOf("2") > -1 OR voltage>2 will return true if all conditions are true.
but here, these two conditions should always be checked first, and if these two conditions are not true, the other conditions should not be checked.
enableDataLogging == 0 AND receiveChar.indexOf("3") > -1
Thank you for your help
I have not followed all details of this thread.
As a general hint: as a first step:
You should describe the desired functionality in normal words with avoiding any programming-terms.
As a not so experienced programmer you might have misconceptions of how the code works. Using normal words ensures to keep out misunderstandings.
The description should have typical example-data as written characters or digits
So a rough sketch of such a description applied to your case would look like that
over serial interface a sended "A" is received.
voltage is measured 1,87V
No the code shall check if
- first condition .... written in normal and precise words
- second condition ....written in normal and precise words
if these two conditions are true and only if these two conditions are true
the following conditions shall be checked:same kind of description as above.
precise words mean avoid generalising words like "the value" "that" etc.
always repeat the descriptive word
not "the value"
but "the voltage of temperatur-sensor top-temperature"
not "the adc-reading"
but
"the ADC-value of temperatur-sensor bottom-temperature"
etc.
This gives a clear picture about the desired functionality.
Using state-machines can reduce the number of if-conditions a lot, because the mutual exclusiveness of code-execution inside a state-machine reduces what code gets executed.
So my question is: did you understand the fundamental principle of state-machines?
best regards Stefan
The text that is sent, you only look for the presence of '2' or '3'.
What text do you expect to receive? A '2' or '3' or line end?
Reason is simple.. you can read text a single char at a time to check for '2' or '3' without putting any of it into a C string or C++ String. Just watch the text stream for what you want, there is no reason to save any of it.
Yes you can get help with the code, the hard part may be believing that something so simple can work. It does and it works faster than making the computer do more -- no surprise there hey? We want simple, it takes fewer lines which means fewer lines to debug.
When I debounce a button, the possible states that I might care about are:
button staying down
button staying up
button transition up to down
button transition up to down
button is bouncing
If I only care to catch button just pressed then I need 1 bit to represent T/F.
If I want to catch button release as well then I need 2 bits for 4 binary states:
state 00: equal to if (( just pressed == false ) && ( released == false ))
state 01: equal to if (( just pressed == true ) && ( released == false ))
state 10: equal to if (( just pressed == false ) && ( released == true ))
state 11: equal to if (( just pressed == true ) && ( released == true ))
Where state 11 (decimal 3) should never happen except by bug or chip malfunction which tight, complete code error checks for, but that is professional software.
I think that you only need to detect button presses, only need 1 bit True if just pressed.
Then Voltage state bit, True if > 2V
Then 1 bit for True if measuring time interval?
And then 2 bits for 3 possible Serial states, in binary
00 is neither '2' nor '3' is read, most of the time Serial.available() Will be 0, no char.
01 is that a '2' has been received.
10 is that a '3' has been received.
11 is literally impossible except by bug or chip malf, an extreme error state!
So looked at like this I get 5 bits to cover every possible combination of Inputs.
I would collect each Input and build that 5 (or however many) bit Total State one tiny step at a time, the code will be simple and fast.
When I have that, how about the single if(), right?
We can use a switch-case statement to cover every possible outcome, make a case for the "legal" combinations and catch the rest as the default case which catches errors.
Spend time defining what to do in every case, it will be simple. Each case is an if ( with 5 different compares ) that the switch value matches... the state bits evaluate themselves by matching a case or becoming the default that matched no other case.
The wonderfully simplifying switch-case statement!
As always, practice will strengthen then complete your understanding.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.