Properly using the Code Simulator in the Editor

Gramps

Senior Member
Are there some instructions somewhere (perhaps in the manual) that show what the simulator does, and how to interpret the results?

Gramps
 
Last edited:

Gramps

Senior Member
Example code ( from erco's hand)
When we change the value of C.1, in the simulator, C.4 switches from high to low.
Debug shows the changes too..
Can we see the value of B1 in the serial terminal?
What other uses does Simulate have?
Code:
#picaxe 08M2
#no_data

init: pwmout C.2,100,150 ; start pwm
main:
readadc C.1, B1 ' read pot, store ADC value 0-255 in B1
if b1<128 then reeverse
foreward: high c.4: b2=b1-128: goto speed
reeverse: low c.4: b2=128-b1
speed: w2=8*b2
pwmduty C.2,w2 ; set pwm duty

goto main
 

lbenson

Senior Member
In the simulator, if you click the "Memory" (sideways) tab on the far right, you can see the RAM memory, EEPROM, or TABLE (and scratchpad on X2s).

The ram memory include the named variables, b0-b27 (which are also WORD variables, and include the 32 bit variables in the first 4 bytes of RAM (b0-b3).

In general, you should avoid DEBUG, which slows critical code. Alan said a few days ago that he had NEVER used DEBUG, and the same is true for me--I've never used DEBUG. You do much better with a targeted SERTXD, where you can include text to show where you are in the program and what values you are displaying.

You can also "single-step" through your code in the simulator--walk through your program line by line, setting inputs and providing values for variables to show how the program actually operates--the flow of control. You can also set breakpoints that your program can run to without single-stepping, so you can just quickly execute code which you believe is operating properly.
 

Gramps

Senior Member
You do much better with a targeted SERTXD, where you can include text to show where you are in the program and what values you are displaying.
Yes, SERTXD is a cool tool. We see it used in code all the time.
Where are the secret instructions hidden in the manual to use "targeted SERTXD"?
 

lbenson

Senior Member
Where are the secret instructions hidden in the manual to use "targeted SERTXD"?
You the coder are the targeter, I'm afraid. You determine what you need to know, and write the SERTXD to display it.

Debug launches in the simulator even when that command is not in the code!
I don't know what that means, but never having used DEBUG in my code, perhaps I don't know what I should be looking for.
 

lbenson

Senior Member
I'd recommend that you try it in the simulator, with, for instance:
Code:
#picaxe 28x2
symbol DESIRED_POT=12 ' some ADC channel number
do
  sertxd("On channel ",#DESIRED_POT, ", ADC value read = ",#b1,cr,lf)
  b1 = b1 + 10 ' just to provide a changing value for b1
  pause 3000 ' time to look at the output
loop
 

AllyCat

Senior Member
Hi,
Debug launches in the simulator even when that command is not in the code!
That's rather the wrong way around. The Simulator IS a "Debug Window". The Simulator is basically just an "Array of Numbers" that are updated by reading a sequence of instructions (i.e. the program) in the Editor. IF it didn't show the "numbers" to a User, then there wouldn't be much point in using it! :) In practice, there are additional Wizards and device Emulations included in the Editor/Simulator, but that's just Rev. Ed. being helpful to Students (or their teachers).

The DEBUG command is intended to give a similar "User Experience" when using a "Real" PICaxe chip and to be honest it does that quite well. Potentially very useful for commands that the Simulator doesn't support (e.g. PEEK/POKESFR), or incorrectly (there are just a few "bugs", particularly with PE5), or where the Simulator is too slow. But the latter is the reason that I don't use it (i.e. never include it in any of my programs or snippets that I post to the forum). To be fair, the Command Syntax is completely honest in saying:

"Note that the debug command uploads a large amount of data and so significantly slows down any program loop. To display user defined debugging messages use the sertxd command instead."

The problem is that some Users may never read that, or not appreciate that their program is "Time Critical", or "forget" that they ever read it! Therefore, the "safe" recommendation is to NOT use it.

As an aside, one of the reasons that some programmers dislike the GOTO command and prefer "Structured Programming" is that if you wrote a program: DO : READADC c.1 , b0 : DEBUG : LOOP then the Editor could issue a "WARNING - Debug will slow down the program", but if the program has a GOTO main buried somewhere in it, the Editor has no way of knowing if there is a practical issue or not. However, people generally dislike "warnings", and in that particular example the DEBUG actually might be an advantage, because it will slow the screen updates down to about 6 per second. Replace that DEBUG with a SERTXD (#b0 , " ") and the Terminal screen will fill up so fast that you won't be able to see what's happening. However, it will give an idea how fast even a PICaxe can work. ;)

Cheers, Alan.
 

Gramps

Senior Member
I'd recommend that you try it in the simulator, with, for instance:
sertxd("On channel ",#DESIRED_POT, ", ADC value read = ",#b1,cr,lf)
It looks like:
"On channel ", is the first statement.
#DESIRED_POT, is 12 which is the second statement.
ADC value read = " is the variable.
,#b1 is the address of the data.
but what is ,cr,lf) ??
Is it a location position in the Serial Terminal?

In the example code it's 13,10
Code:
main:    for b1 = 0 to 63                ; start a loop
      sertxd("The value of b1 is ",#b1,13,10)
      pause 1000
    next b1
 
Last edited:

lbenson

Senior Member
sertxd("On channel ",#DESIRED_POT, ", ADC value read = ",#b1,cr,lf)
It looks like:
"On channel ", is the first statement.
#DESIRED_POT, is 12 which is the second statement.
ADC value read = " is the variable.
,#b1 is the address of the data.
but what is ,cr,lf) ??
Is it a location position in the Serial Terminal?
First, CR and LF are predefined constants in PICAXE BASIC which stand for Carriage Return and Line Feed. The constants have the values of 13 and 10, You can see these ASCII characters defined in the ASCII table here: https://www.asciitable.com/
Depending on the output device, these characters cause the cursor (position of next character to be printed/displayed) to be moved to the first position (CR) on the next line (LF). On a manual typewriter they correspond to hitting the return lever. They are separate characters because on at least some devices, you want to be able to return the carriage without moving to a new line. In the early days of computer art, with no graphical output device, some people liked to make black and white "art" by repeatedly overstriking single lines to produce different shades of gray. The Mona Lisa was a favorite example.

Regarding the SERTXD statement, I wouldn't call the portions separated by commas "statements". I don't know what they should be called; the manual calls them "data"--but they include constants, variables, string constants, etc. In the given statement, DESIRED_POT is a named constant (named in a SYMBOL statement) which has a value of 12. If you look in the ascii table, you will see that 12 is the ascii character for Form Feed (or New Page). If you wrote a binary 12 to a line printer the current page would be ejected and the next character would be printed at the top of the following page. That's not what you want--you want to print the two decimal characters which will give you "12" on the printed output. The "#" character causes this to happen in the SERTXD statement. It means that the following binary value, a numeric constant or bit, byte, or word, is to be displayed in human-readable form. That means that a binary 12 (%00001100) will be printed as the numeral 1 followed by the numeral 2.

b1 is the name of the variable which contains the result of the statement READADC DESIRED_POT,b1. The "#" which precedes the variable name causes the output to be numerals.
 

lbenson

Senior Member
There are times when you don't want a new line for each time you want to see a value. If you're reading something every few seconds and outputting a value, you can terminate each SERTXD with " ", and so get a long string of values separated by spaces.
 
Top