Thanks everyone. This problem is solved as of Reply # 5 (and improved by Reply # 7, thanks again dc42; I will aim for that).
I seem to have caused a bit of confusion with my sentence structure. It was always the arduino
which was either powered by USB or by a battery. I don't have a USB powered potato, unfortunately. I wish I had now though. I bet those things would sell like hot cakes. Maybe I should patent the idea ...
If you read it, and then read it again, and then read it again, it will always read, either HIGH or LOW. How would you expect anything else ?
That's kind of the point. The idea is to take a reading from an analog pin when a digital PWM pin is HIGH, and then again when it is LOW - without using digitalRead() to get the state of the PWM pin. Maybe 1000 readings was a bit of overkill though.
The analogReference() function has nothing to do with digitalRead() or analogWrite(), so you are barking up the wrong tree there.
The analogReference() is for fine tuning the analog pin which is doing the reading using analogRead() of a value which depends upon the output of a digital pin set to PWM with analogWrite(), at a time specified by the result of digitalRead() of that PWM pin. This is related to the problem which spawned this question, that I referenced in my first post. The code I posted above in my first post in this thread refers only to a separate simplified example using an LED to show the problem I am having with reading the state of a PWM pin. Sorry for the confusion!
Code inside an "if" will not be run if the condition is not met. Take that as a fact.
Exactly. I assumed that the command braces should not run if the conditional is not met, so either my code is incorrect, or there is some kind of problem with the electronics - hence my question here.
If you just want to poll the input state and wait for it to go high and low, why don't you just do that and get rid off all these flags and counters?
I used flags because I was originally printing the value of the flag over the serial to check the outcome, and they just remained as a replic when I switched to printing words instead.
Admittedly using != HIGH or != LOW is more elegant, thanks.
I used the counter to limit the run throughs of the first cycle, after I realised it was getting stuck in an infinite loop.
If you can define "run properly" as opposed to "run improperly" we might get somewhere.
When the first cycle is limited to only 10 run throughs, then the loop() function runs fine and the LED fades up and down. The LED can only
change brightness if the code in the command braces of the two conditionals (one in each cycle) is run - specifically if the analogWrite() code is run. I assume this is correct, since the only other place I use digitalWrite() is in the setup() function. However, when this occurs then the LED blinks, but no value is printed over the serial in the command braces which runs when the PWM pin is detected as HIGH. There is
a value printed when the PWM pin is detected as LOW. Therefore the analogWrite() command in each set of braces is being run correctly in both conditionals, but the Serial.println() command is not.
Either this is a problem with the Serial.println() or with the running of the command braces. It seems unlikely to be a problem with Serial.println(), because that exact command is working fine in the first cycle, and it is printing a pre-defined value, not the actual state of the PWM pin. Hence my suggestion that the problem is with the running of the command braces.
Furthermore, the analogWrite() command to brighten the LED can only occur if the conditional it is sitting in correctly uses digitalRead() and gets the state of the pin to be HIGH, and since the LED is blinking then that suggests the read is being performed properly. This changes when the limit of 10 passes is removed from the first while condition (by deleting the second condition in the brackets). When there is no limit, then the whole thing hangs seemingly in an infinite loop, and the LED does not change it state, and nothing is printed over the serial. This can only occur if the digitalRead() of the PWM is now never reading the state as HIGH - even though it was
apparently able to read it as HIGH when there was no limit on the number of times the cycle could run. This can only happen if digitalRead() is suddenly not able to read when the PWM is HIGH, or if the condition is being met but the commands associated with it are not being run.
As far as I can see, the results are not what would be expected. I was not able to find any other info on a problem like this. I wondered whether there was a known issue with the board in this type of instance, which would cause this apparently unusual behavior in the way the code is being run, or whether in fact the fault is with me and I have made a school boy error with my code.
But either way, whether my code is wrong or there is a problem with the board, I no longer require the answer to the original question because I have switched to using a loop that just runs analogRead() and skips the implementation of the digitalRead(). It was digitalRead() which was causing the problem.