PWM odd variable reading

[Ed Straker]

I knew it wouldn't take me long to run into trouble.
I know the code is probably not optimal....learning.

I was experimenting with an LED fade circuit (previously provided) using a toggle switch for program control, Circuit flow as follows:

Power On -> Off State -> Toggle(on) -> Fade In -> Hold On -> Toggle(off) -> Fade Out -> stay Off (rinse and repeat)

Circuit seems to simulate as expected except there is an oddity showing up in VarA in the debug panel. When the program hits a
certain point (indicated in Red) the VarA values jumps to and absurdly high value and stays there even when it returns
to the Main Loop until toggle is again turned back to the on state and the program continues again normally.
In the attached diagram I have indicated in Black the blocks I have inserted in the different locations to try to troubleshoot
the problem, no joy except for the set VarA insertion but you still get a momentary flash of the 65535.



My question is, is this just a Editor/Simulator bug/glitch and means nothing or is this a point of functional concern and how can I remedy this?

I have not Breadboarded this circuit yet for actual test.

 

[Buzby]

It will take me too long to faff with Blocky in order to replicate your screen.

Could you please press the 'Picaxe BASIC' tab, then copy&paste into the forum ?. ( Or attach the Blockly .xml file. )

It looks like the "Count down from [varA] to [0] by [1]" line is counting down to -1, which is 65535 in a 16bit word.

Without seeing what the code is I can't tell why.

Cheers,

Buzby

 

[Buzby]

Well, I just replicated the single line, and the code is just a simple for/next loop.

A for/next loop with a negative step finishes when the index is less than the 'end' value.

Your 'end' value is zero, so the index needs to go below zero for the loop to exit.

Your VarA variable is not used anywhere other than in the loop, so it doesn't matter what value it is left at when the loop finishes.

( If you try a normal for/next, eg. 0 to 4, you will see the index is '5' when the loop is finished, ie, one greater than the 'end' value )

 

[Ed Straker]

I don't follow, my code looks a bit different so I attached the xml as requested.

 

[Buzby]

The code I posted was taken from the "Count down from [varA] to [0] by [1]" line, but shown as BASIC. I didn't replicate all the rest of your code. Making a simple piece of code that demonstrates the issue is a well known method of diagnosing a problem.

Basically, when a for/next loop loop finishes, the 'index' variable is left at a value 1 higher ( or 1 lower ) than the target 'end' value.
This is normal, as the 'index' variable is usually not needed outside of the loop, so it doesn't matter what value it is.

I've now modified your Blockly code to display the progress of the VarA variable, so you can see exactly how for/next loops work.

EDIT: I found out how to make the Blockly version of 'sertxd' print some text and a variable. This is not very user-friendly !

 

[hippy]

It looks like the "Count down from [varA] to [0] by [1]" line is counting down to -1, which is 65535 in a 16bit word.

That would be my analysis. The FOR loop continues while varA is between 10 and 0, and after being 0 it decrements, to -1 or 65535, that's not between 10 and 0 so the FOR loop ends.

That's as expected so seeing varA as 65535 is nothing to worry about.

 

[hippy]

Power On -> Off State -> Toggle(on) -> Fade In -> Hold On -> Toggle(off) -> Fade Out -> stay Off (rinse and repeat)

Your code seems rather complicated for what it is doing. You can fade up then wait in the main loop for the switch to be toggled, and once you have faded down you know the LED will be off so there's no need to explicitly set the LED off. This is how I would do it -

 

[Ed Straker]

Basically, when a for/next loop loop finishes, the 'index' variable is left at a value 1 higher ( or 1 lower ) than the target 'end' value.

That would be my analysis. The FOR loop continues while varA is between 10 and 0, and after being 0 it decrements, to -1 or 65535, that's not between 10 and 0 so the FOR loop ends.

I totally expected to find that my code would be a mess but out of curiosity I altered the final count Var from 0 to 1 (just to see) and don't you know when it went back to main loop I got 65535 anyway.

That's as expected so seeing varA as 65535 is nothing to worry about.

Well this is what I was concerned about, will it really adversely effect it's function if I left it alone.

Your code seems rather complicated for what it is doing.

I knew it would be.

Chalk up another learning experience, how frustrating. Thanks again for helping out.

 

[Buzby]

... out of curiosity I altered the final count Var from 0 to 1 (just to see) and don't you know when it went back to main loop I got 65535 anyway.

I'm not sure what you did there, because when I change the 'end' value to '1', it exits the loop with '0' in VarA, which is exactly as expected.

 

[Ed Straker]

@hippy:
I gave your Block Code a go (way more efficent indeed) and I did notice that on the up count VarA goes to 11 (overcount?) and on the down count VarA goes to 65535 (undercount).

I'm using 0-10 for simplicity in testing as I don't feel like waiting for the Sim to sloowly count all the way to 1023.

I also noticed that Pin C.2 also remains in an active state when the Down Count returns to the main loop.

Based on this I altered the code as follows:



By shorting the count by 1 in the up and down count, the up count ends exactly on 10 (or 1023 in actual use) and the down count ends exactly on 0.
I also added the pwmout 0.0 again as in my original to take C.2 out of an active state. That came from Manual2 regarding "turning off PWM"

Perhaps I'm overthinking the whole thing or being overly critical about it.
Working with discreet components all these years taught me to never assume tiny inconsistencies doesn't really matter or applying the "close enough" adage usual results in trouble.

 

[Ed Straker]

I'm not sure what you did there, because when I change the 'end' value to '1', it exits the loop with '0' in VarA, which is exactly as expected.

That's what left me scratching my head, when I did it, when it went back to main loop it seemed to give an extra count that resulted in the 65535.
?????

 

[hippy]

I also noticed that Pin C.2 also remains in an active state when the Down Count returns to the main loop.

Yes, but that's fine. It's still controlling the LED with a PWM duty of zero, off.

While not actually so problematic you can think of it as pulling a boat from one place to another and back gain. You don't want to let the rope go just because you are back at the starting position, you want to hold it where it is.

Once you have started PWM you don't usually need or want to turn it off, just set the duty to zero to keep the output off. The simulator will show the pin as active because PWM is still running on that pin even though the output is zero.

It doesn't cause any harm turning PWM off by setting period and duty to zero in this case, it's just an extra unnecessary instruction. And if it's helping show when the LED is off there's nothing wrong per se in doing that.

 

[Buzby]

Are you sure you edited the right field ?

I repeated my test, this time with hippy's code, and the result is still as expected.

 

[kfjl]

I can't see the sense in Blockly. There's as much code written in Buzby's picture as there is in the code below, which does more or less the same thing.

init:
pwmout C.2,150,0
main:
if pinC.3 = 1 then goto fadeIn
if pinC.3 = 0 then goto fadeOut
goto main

fadeIn:
if b0 < 150 then
pwmduty C.2,b0
pause 50
b0 = b0 + 5
endif
goto main

fadeOut:
if b0 > 0 then
pwmduty C.2,b0
pause 50
b0 = b0 - 5
endif
goto main

Programming on multi-coloured paper is no easier than programming on white paper.
And it hurts your eyes.

 

[kfjl]

My indentation got lost in the post so I attached the file as well.

 

[Ed Straker]

It doesn't cause any harm turning PWM off by setting period and duty to zero in this case, it's just an extra unnecessary instruction. And if it's helping show when the LED is off there's nothing wrong per se in doing that.

Ok, I didn't know, So either one doesn't hurt. Thanks again.

I repeated my test, this time with hippy's code, and the result is still as expected.

Actually if you look at your screen capture the Count with 0 - 10 by 1 in the receive buffer readout it is showing you that count after loop is 11(not 10) which is what I got also. In the Count Down with 10 - 1 by 1 the count after loop is 0. If you leave it at 10 - 0 by 1 it should result in that under count which is what I was originally questioning.

Programming on multi-coloured paper is no easier than programming on white paper.
And it hurts your eyes.

Since I'm in the learning stage, and quite the beginner, I find it easier for me to pick it up this way. I wish there a way to darken the background, it does indeed hurt your eyes. It is what it is.

 

[Buzby]

I can't see the sense in Blockly. ... Programming on multi-coloured paper is no easier than programming on white paper. And it hurts your eyes.

I don't like Blockly either. The code above was done because the OP doesn't like Basic !.

Blockly is seriously wasteful of screen area, cumbersome to edit, and a pain to simulate.

( Regarding simulation, if the 'PICAXE BASIC' tab is selected and simulation started, the BASIC is not animated, only the Blockly. This seems like an oversight. However, as this is a Blockly issue it's more likely to get fixed than any of the other issues which the simulator has. )

Another issue is that I can't see how to set or clear a breakpoint when simulation is paused, only an option to stop simulation.

Unless I've missed some fundamental points, I can't see how to divide the code over more than one screen, or how to have a floating comment.

The Watch/Break-on-Value feature does not seem to be in Blockly. It's very useful, why is it not there ?

Regarding the background colour, the option settings for colours only seem to work on real Basic files, not Blockly.

I agree that Blockly might be suitable for a 7 year old writing a simple prog with a few I/O, but I can't see how it is of benefit to real coding.

 

[Ed Straker]

The code above was done because the OP doesn't like Basic !.

First of all, don't put words in my mouth. Not all of us can gain PhD level knowledge in 3-4 weeks like you do.

I guess you became a Master Carpenter after your first couple of weeks in High School Shop Class. Some of us are not as fortunate as you are.
Apparently you are unacquainted with the terms "beginner" and "learning"

Second of all, I didn't know my question would degenerate into a conduit for personal opinions and rants on what software or
methods are "sanctioned" for use, or for that matter a critique of peoples intelligence for choosing one way over another is insulting and uncalled-for.

So much for trying being polite and professional.

My apologies to everyone else for the rant.

 

[Jeff Haas]

It has been common for quite awhile to think of visual scripting tools (such as Blockly) as just for beginners, and that after learning how to structure code, you should move on to "real" coding. But this type of scripting tool has moved beyond the educational area and is now used in a lot of professional development environments, so programming is more accessible to non-programmers.

Here are some examples:

Autodesk Maya - 3D modeling and animation software
Unity Visual Scripting - game development engine
Webflow - no-code website builder
Airtable - no-code database platform
Visiopharm - Pathology image analysis, used for automation of whole slide analysis in areas such as medical research

All of these use an environment that looks similar to Blockly. "Code-free" tools are useful and should not be looked down on. And their use is spreading!

 

[Buzby]

.... programming is more accessible to non-programmers.

Exactly right.

Access to a tool, whether it be Blockly, BASIC, Python, or any other environment does not teach programming.
BASIC itself was developed for learning, ( Beginners' All-purpose Symbolic Instruction Code ).

Tools like Blockly as a means of learning to program are a flashy distraction from the real objective.

The results from letting a non-programmer write trial-and-error with a 'code-free' tool are applications that are bloated and inefficient, but these deficiencies are usually hidden by a big fast computer, or the cloud !.

The task of any programming job is to define the logic for the solution, then write the code the in whatever is the most suitable language for the task. It could even be that different parts of the same application are written in different languages using different tools..

"Code-free" tools are useful and should not be looked down on.

Agreed, but if the only tool you have is a hammer, then every problem gets treated like a nail.

(I do use a graphical tool for some of my programming, and this is perfect for the specific applications where I use it, but it's not a general purpose tool like BASIC is supposed to be.

Anyway, I think we have reached an impasse.

So I'm out !.

Cheers,

Buzby

 

[kfjl]

So this is code-free programming? You just write what you want to happen? No language to learn?
I live in France.
I'll refer to post #13 because I don't know how to reproduce it here:

start (so I can write "début")
sertxd (google translate says that means "sertxd". It's not in the french dictionnary...)
set pwmout period 255 duty 0 on C.2 (this is SO much easier to understand than pwmout C.2,255,0)

etc...

A programming language has a syntaxe; so does Blockly.

Code-free programming? Tell that to a rain-forest pygmy or an eskimo or anyone else who doesn't speak english.

Vive Buzby!

I'm out too.