Steve,
Thanksfor quick reply. I am still struggling with how to interface my project to BMA. Here is a basic outline of my project:
[code]
{{File name Stepservo_v2.spin is a program to demonstrate the Jimsstepper_asm1.spin
}}
_clkmode = xtal1 + pll16x ' System clock → 80 MHz
_xinfreq = 5_000_000
con
'' Parallax Serial Terminal
'' Control Character Constants
''─────────────────────────────────────
CS = 16 ''CS: Clear Screen
CE = 11 ''CE: Clear to End of line
CB = 12 ''CB: Clear lines Below
HM = 1 ''HM: HoMe cursor
PC = 2 ''PC: Position Cursor in x,y
PX = 14 ''PX: Position cursor in X
PY = 15 ''PY: Position cursor in Y
NL = 13 ''NL: New Line
LF = 10 ''LF: Line Feed
ML = 3 ''ML: Move cursor Left
MR = 4 ''MR: Move cursor Right
MU = 5 ''MU: Move cursor Up
MD = 6 ''MD: Move cursor Down
TB = 9 ''TB: TaB
BS = 8 ''BS: BackSpace
BP = 7 ''BP: BeeP speaker
con
mP1= 4 'base pin for Motor 1 uses 4 contiguous pins
mP2 =16 'base pin for Motor 2 uses 4 contiguous pins
cmd = 0
stps1 = 1
stps2 =2
VAR
long stepParms[6]
long debug1[8]
long debug2[8]
Long Value
Byte inputstr[8]
Long stack [ 65]
' Long tGrowth
OBJ
term : "Parallax Serial Terminal" ' Variable & I/O display tool
rc : "RC_Time_ASM" ' RC Time is also an option
stepserv : "Jimsstepper_asm1" 'using ASM version of stepper program
nums : "Numbers" 'lib program to assist with number manipulation
PUB Main | idx ,tGrowth , adjust, x , y
' Set up Parallax Serial Termial display
term.start(115_200) ' start serial
stepserv.start(@stepParms,mP1,mP2)
rc.start(1, 0, clkfreq/1_0000, clkfreq/2000, clkfreq/1000,@tGrowth)
nums.init
term.str(string("Step Servo Test V1 "))
term.str(String(" Time Measurements units = 12.5 ns"))
term.NewLine
term.str(string("
"))
term.NewLine
term.str(String(" Intitial Servo Position is "))
term.DEC(tGrowth)
[code\]
my obj "stepserv" is where the assembly software resides. My problem seems to be in passing the Parms from "demo" to "stepserve". I was going to attach the archive to this post but I need to further study the process as it was not working for me this AM.
Thanks
Jim
@Tubular,
Yes, uterm is a very simple program. It's written in C# and should work with .net 2.0+.
Heater added support for running on Linux with mono.net where I use it all the time.
Press ESC to exit for now.
Steve,
Thanksfor quick reply. I am still struggling with how to interface my project to BMA.
@RS_Jim,
One thing that stands out is that term is using the serial port. BMA needs to have access to that port. Here is a todo list. Hope it helps.
1. You'll have to replace this:
OBJ
term : "Parallax Serial Terminal" ' Variable & I/O display tool
with this
OBJ
term : "FullDuplexSingleton" ' Variable & I/O display tool
2. Then you need to add a PUB start before Main, and comment out this in Main.
' term.start(115_200) ' start serial
' stepserv.start(@stepParms,mP1,mP2)
success!
really quite convient to use BST and his terminal program. Just wish his program would recognize my flashdrive. Now if I just comment out the debug start I can leave the hook in the ASM file without a problem can't I? It looks to me like it will just be 8 NOP before the program starts.
Jim
Now if I just comment out the debug start I can leave the hook in the ASM file without a problem can't I? It looks to me like it will just be 8 NOP before the program starts.
Jim
Steve,
I am continuing to develop and refine my piece of software under BMA. However, I am getting the following results out of 1 step that I am unsure about:
T0.PC 011 Ok>
T0.PC 011 . : test 623d2694 Z N D:093 0001000b S:094 00000008 D=093 0001000b C
T0.PC 012 Ok>
T0.PC 012 NZ : jmp 5c540073 N D:000 083c01f3 S#073 D=000 083c01f3 C
T0.PC 073 Ok>
T0.PC 073 . : cmp 873d01fc ZCN D:080 00013880 S:PHSA d9e4054e D=080 00013880 C
T0.PC 074 Ok>
T0.PC 074 NC_|_NZ: jmp 5c5c0011 N D:000 083c01f3 S#011 D=000 083c01f3 C
T0.PC 011 Ok>
T0.PC 011 . : test 623d2694 Z N D:093 0001000b S:094 00000008 D=093 0001000b C
T0.PC 012 Ok>
T0.PC 012 NZ : jmp 5c540073 N D:000 083c01f3 S#073 D=000 083c01f3 C
T0.PC 073 Ok>
T0.PC 073 . : cmp 873d01fc ZCN D:080 00013880 S:PHSA 6807f03e D=080 00013880 C
T0.PC 074 Ok>
T0.PC 074 NC_|_NZ: jmp 5c5c0011 N D:000 083c01f3 S#011 D=000 083c01f3 C
Now clearly the contents of PHSA are greater than $13880 and the carry flag is showing as set but my expectation is that it would fall through to the next step but it is jumping to PC 011 not falling through to step 75. Any ideas?
Jim
Now clearly the contents of PHSA are greater than $13880 and the carry flag is showing as set but my expectation is that it would fall through to the next step but it is jumping to PC 011 not falling through to step 75. Any ideas?
When I first saw your post this evening, I thought maybe you had found a bug in the debugger. Kuroneko does note correctly though that the Z flag is not set in your instruction trace, and the jmp from PC 074 to PC 011 seems valid.
My IF_NC_|_NZ notation for if_nc_or_nz may be a little confusing, and if so sorry about that. I had to use that and others like IF_NC_&_NZ to keep the step display consistent on a fixed width font terminal.
Steve,
I am continuing to develop and refine my piece of software under BMA. However, I am getting the following results out of 1 step that I am unsure about:
Now clearly the contents of PHSA are greater than $13880 and the carry flag is showing as set but my expectation is that it would fall through to the next step but it is jumping to PC 011 not falling through to step 75. Any ideas?
Jim
When I first saw your post this evening, I thought maybe you had found a bug in the debugger. Kuroneko does note correctly though that the Z flag is not set in your instruction trace, and the jmp from PC 074 to PC 011 seems valid.
On a lighter note, using if_nc_or_nz after a cmp wc,wz seems rather odd
OK,
My concept was that if the counter had reached its destination, I was done, if it had overshot the destination, I was also done. The step will still do what I want it to do if I change to WC, and if_nc it will just happen 1 pass latter if it happens to be arriving at the exact point where PHSA = $13880. If I change the instruction to IF_NC_and_NZ will that do what I want?
Steve, yes I have found it very useful especially when it demonstrates unexpected behaviors like this one.
Jim
Kuroneko,
You are right. I was thnking about it while doing the breakfast dishes and realized I needed to change the or to and. Thanks again for catching my error.
Jim
Steve,
I have hit another quagmire! The attached code when run under BMA, Takes over 1 minute to exicute the first step and more than a minute per step under the "ax" command. When I strike the a key the debugger responds with a space and then locks up not accepting the milliseconds of timing. I started the annimation today and went to take a shower and shave, when I got back it had exicuted 8 steps! What have I done to your poor baby?
Jim Stepservo_v3debug-bst-archive-110926-221012.zip
Just an observation, when you wait for more than half a second after pressing a the time variable (in animate) remains uninitialised and may well be 0 which would explain the ~1min intervals. Probably best to initialise time to 1 AND guard the waitcnt (in case your clock frequency is low).
Steve,
I have hit another quagmire! The attached code when run under BMA, Takes over 1 minute to ....
Your Main code needs a little fix.
PUB Main | idx ,tGrowth , adjust, x , y
'term.str(string("starting test"))
'term.tx(NL)
longfill(stepParms,0,8) ' <--- small problem
' ...
longfill(stepParms,0,8) ... this sets hub address 0 = 0. not good for serial communications
longfill(@stepParms,0,8) ... this is probably what you want.
I see you've mentioned waitcnt .... that's my first search keyword in this case, but that's not the problem here. Still, you can not "animate" code contaiing waitcnt. set breakpoints and "go" with the g command instead (real-time).
Just an observation, when you wait for more than half a second after pressing a the time variable (in animate) remains uninitialised and may well be 0 which would explain the ~1min intervals. Probably best to initialise time to 1 AND guard the waitcnt (in case your clock frequency is low).
Steve?
The intention of the "a" command was to wait for a moment to see if you want a different step-wait value from the default. Looking at the code the default appears to be 0 or whatever is left on the stack. It works for me, although I'm not sure how exactly. For the time being just enter "a9" or something. The time variable should be initialized to 50 or some reasonable default.
Steve,
When I key "a" I then get a lock up of the input. I always try to enter a 1 as the animation delay as my main goal is to save the debug file for later review not watch in "real" time. I think I am also getting a long delay with the go command moving to a break point 50 or so steps away. Setting the break at PC009 when 008 calls a subroutine. I can single step through it faster!
I will fix the missing @. The mention of waitcnt was in mention of the fact that I was NOT using waitcnt because it would keep one process from running while the other was waiting for a delay. Instead I am using the two counters to provide my delay and measuring PHSA/PHDB against my wait variable. If PHSA has not counted upto or over MS001, then I jmpret over to the other process to check its progress.I just realized I am not starting the second process correctly as it is waiting for a return from the first. Unfortunately, in single step or animate, PHSA goes beyond 1 ms to quickly to trap the next step correctly. I may resort to a substitute step(s) to allow me to see if the jmps are occuring correctly. Thanks for all the assistance and for the debugger. Also pointing out BST's listing files was a huge benifit to the debugging process. Now if I could just figure out how to dump a couple of var's as binary....
Jim
Jim, you need to fix the missing @ for anything to work.
As far as "a" goes ...
I use "a9" ... "a1" is a little fast for me. Don't add a space between "a" and the number.
I recommend adding time := 20 to PUB animate in BMAUtility.spin.
I'll post an update with this change later.
pri animate | time
time := 20
waitcnt(clkfreq/2+cnt) ' give a moment for next argument
Yes, I noticed there wasn't a waitcnt in the PASM. Using PHSx like this is a nice alternative - just remember to follow the PHSx write rules. PHSx can go very fast - it is a powerful feature. Unfortunately "a" or any step command like "enter" takes many instructions.
If you use the "g" command your breakpoint must be on a PC location that gets hit during execution. There are some instructions that do not behave very well for breakpoints though such as any "ret" ... there is not much I can do about that problem except recommend that "ret" instructions not be used as breakpoints.
Regarding variable dumps, the "h" command dumps hex values and it calls dumpHubAddrs ... you could change that to dump bits. An alternative is to add an "H" command that calls a new dump this would be fairly easy to do, but will consume memory. I could add this to a special version.
No time to play right now, need to be off to work. Will correct the @ problem ASAP. I will look at dumpHubAddrs to see about the bit dump. Not sure it is worth it, May just have to figure out what the bin is from hex dump. really only need to look at 4 Vars. I don't break on a ret or waitcnt and I understand step or a use much time. I could look at what kind of results I am getting out of PHSA and make the comparison number higher than that to get it to exicute the steps I want to see. Ok to use break on the step RET jumps to after a call? If not I could have it return to a NOP and then break on the next step. I also am having a problem with skipping over an andn step that I use to clear the drive lines prior to or outa, guess I will break between steps and dump OUTA.
Thanks for all the help,
Jim
Ok to use break on the step RET jumps to after a call? If not I could have it return to a NOP and then break on the next step.
Seems like I've had to pick a different instruction or add a NOP like that too. Not sure why that would be. It was annoying, but I decided to live with the work-around mostly when doing heavy debugging.
Steve,
missing @ on the longfil at the begining of main was the source of much of my agony! I am now back to debugging and that is going well. used some temp vars to get around the delay problem so that I could check how the jmpret routines were working.
Thanks again for the wonderful tool.
Jim
steve,
Crash and burn time! attached are two files. One is the compiled listing I was trying to debug, the second is the list output of the debugger.
Jim log928_1710.txtlist938_1710.txt
your movi start_stp2,#0 doesn't create a nop but a wrbyte (see listing). As the zero flag isn't set it even gets executed and most likely corrupts memory. The instruction at start_stp2 doesn't modify the flags so it would be better to use something like cmp (%100001_000) which doesn't do any harm.
You should also check your jumps with cmdloop? targets. Currently they are indirect jumps.
Kuroneko,
While I was a way from the code, I got to thinking about that movi instruction. I wished there was an easy way to steal the instruction part of an instruction and write it to another instruction. As to the indirect jmp's I wonder how many times I will be condemmed to do that before I always get it right? I am glad I switched to BST for the terminal program and the Listings. With Steve's program, following the listing and the disassemembled output does make a difference in the ability to diagnose the problems.I had just changed the cmdloop instructions away from calls as I realized that the call instructions would block the 2nd motor from starting. Can you suggest a better way to start the second motor without either motor blocking the other from running correctly?
Thanks for all your help.
Jim
Comments
cheers
tubular
Thanksfor quick reply. I am still struggling with how to interface my project to BMA. Here is a basic outline of my project:
[code]
{{File name Stepservo_v2.spin is a program to demonstrate the Jimsstepper_asm1.spin
}}
_clkmode = xtal1 + pll16x ' System clock → 80 MHz
_xinfreq = 5_000_000
con
'' Parallax Serial Terminal
'' Control Character Constants
''─────────────────────────────────────
CS = 16 ''CS: Clear Screen
CE = 11 ''CE: Clear to End of line
CB = 12 ''CB: Clear lines Below
HM = 1 ''HM: HoMe cursor
PC = 2 ''PC: Position Cursor in x,y
PX = 14 ''PX: Position cursor in X
PY = 15 ''PY: Position cursor in Y
NL = 13 ''NL: New Line
LF = 10 ''LF: Line Feed
ML = 3 ''ML: Move cursor Left
MR = 4 ''MR: Move cursor Right
MU = 5 ''MU: Move cursor Up
MD = 6 ''MD: Move cursor Down
TB = 9 ''TB: TaB
BS = 8 ''BS: BackSpace
BP = 7 ''BP: BeeP speaker
con
mP1= 4 'base pin for Motor 1 uses 4 contiguous pins
mP2 =16 'base pin for Motor 2 uses 4 contiguous pins
cmd = 0
stps1 = 1
stps2 =2
VAR
long stepParms[6]
long debug1[8]
long debug2[8]
Long Value
Byte inputstr[8]
Long stack [ 65]
' Long tGrowth
OBJ
term : "Parallax Serial Terminal" ' Variable & I/O display tool
rc : "RC_Time_ASM" ' RC Time is also an option
stepserv : "Jimsstepper_asm1" 'using ASM version of stepper program
nums : "Numbers" 'lib program to assist with number manipulation
PUB Main | idx ,tGrowth , adjust, x , y
' Set up Parallax Serial Termial display
term.start(115_200) ' start serial
stepserv.start(@stepParms,mP1,mP2)
rc.start(1, 0, clkfreq/1_0000, clkfreq/2000, clkfreq/1000,@tGrowth)
nums.init
term.str(string("Step Servo Test V1 "))
term.str(String(" Time Measurements units = 12.5 ns"))
term.NewLine
term.str(string("
"))
term.NewLine
term.str(String(" Intitial Servo Position is "))
term.DEC(tGrowth)
[code\]
my obj "stepserv" is where the assembly software resides. My problem seems to be in passing the Parms from "demo" to "stepserve". I was going to attach the archive to this post but I need to further study the process as it was not working for me this AM.
Thanks
Jim
I did briefly run your demo program last night and it seemed to work fine through PST turning echo off.
Jim
Yes, uterm is a very simple program. It's written in C# and should work with .net 2.0+.
Heater added support for running on Linux with mono.net where I use it all the time.
Press ESC to exit for now.
@RS_Jim,
One thing that stands out is that term is using the serial port. BMA needs to have access to that port. Here is a todo list. Hope it helps.
1. You'll have to replace this:
OBJ
term : "Parallax Serial Terminal" ' Variable & I/O display tool
with this
OBJ
term : "FullDuplexSingleton" ' Variable & I/O display tool
2. Then you need to add a PUB start before Main, and comment out this in Main.
' term.start(115_200) ' start serial
' stepserv.start(@stepParms,mP1,mP2)
3. The start should look like this:
PUB start
term.start(31,30,0,115200)
waitcnt(clkfreq+cnt)
cognew(Main, @stack)
stepserv.start(@stepParms,mP1,mP2) ' add debug code inside stepserv.start
repeat ' do nothing
4. add stack for cognew your Main
VAR long stack[128]
5. In stepserv start, you need to add debug code
OBJ
deb : "BMAUtility"
pub start(stepParms,mP1,mP2) ' add debug code inside stepserv.start
deb.debug(@pasm, parms) ' this is just a guess, but it replaces cognew(@pasm, parms)
The very first line in your pasm code should be long 0 [8] ... that's space for the debugger stub.
Hope this helps.
--Steve
Jim
Got all of the edits done, will wait until in the morning to try it.
Jim
really quite convient to use BST and his terminal program. Just wish his program would recognize my flashdrive. Now if I just comment out the debug start I can leave the hook in the ASM file without a problem can't I? It looks to me like it will just be 8 NOP before the program starts.
Jim
Exactly Right!
I am continuing to develop and refine my piece of software under BMA. However, I am getting the following results out of 1 step that I am unsure about: Now clearly the contents of PHSA are greater than $13880 and the carry flag is showing as set but my expectation is that it would fall through to the next step but it is jumping to PC 011 not falling through to step 75. Any ideas?
Jim
cmp label, phsa wc,[COLOR="orange"]wz[/COLOR] if_nc_[COLOR="orange"]or_nz[/COLOR] jmp #$11 org $80 label long 80_000You're right in that carry is set but the zero flag is not which is enough to take the jump.When I first saw your post this evening, I thought maybe you had found a bug in the debugger. Kuroneko does note correctly though that the Z flag is not set in your instruction trace, and the jmp from PC 074 to PC 011 seems valid.
My IF_NC_|_NZ notation for if_nc_or_nz may be a little confusing, and if so sorry about that. I had to use that and others like IF_NC_&_NZ to keep the step display consistent on a fixed width font terminal.
I hope you have found BMA useful to date.
Thanks,
--Steve
My concept was that if the counter had reached its destination, I was done, if it had overshot the destination, I was also done. The step will still do what I want it to do if I change to WC, and if_nc it will just happen 1 pass latter if it happens to be arriving at the exact point where PHSA = $13880. If I change the instruction to IF_NC_and_NZ will that do what I want?
Steve, yes I have found it very useful especially when it demonstrates unexpected behaviors like this one.
Jim
You are right. I was thnking about it while doing the breakfast dishes and realized I needed to change the or to and. Thanks again for catching my error.
Jim
I have hit another quagmire! The attached code when run under BMA, Takes over 1 minute to exicute the first step and more than a minute per step under the "ax" command. When I strike the a key the debugger responds with a space and then locks up not accepting the milliseconds of timing. I started the annimation today and went to take a shower and shave, when I got back it had exicuted 8 steps! What have I done to your poor baby?
Jim
Stepservo_v3debug-bst-archive-110926-221012.zip
Steve?
Your Main code needs a little fix.
PUB Main | idx ,tGrowth , adjust, x , y 'term.str(string("starting test")) 'term.tx(NL) longfill(stepParms,0,8) ' <--- small problem ' ...longfill(stepParms,0,8) ... this sets hub address 0 = 0. not good for serial communicationslongfill(@stepParms,0,8) ... this is probably what you want.
I see you've mentioned waitcnt .... that's my first search keyword in this case, but that's not the problem here. Still, you can not "animate" code contaiing waitcnt. set breakpoints and "go" with the g command instead (real-time).
The intention of the "a" command was to wait for a moment to see if you want a different step-wait value from the default. Looking at the code the default appears to be 0 or whatever is left on the stack. It works for me, although I'm not sure how exactly. For the time being just enter "a9" or something. The time variable should be initialized to 50 or some reasonable default.
When I key "a" I then get a lock up of the input. I always try to enter a 1 as the animation delay as my main goal is to save the debug file for later review not watch in "real" time. I think I am also getting a long delay with the go command moving to a break point 50 or so steps away. Setting the break at PC009 when 008 calls a subroutine. I can single step through it faster!
I will fix the missing @. The mention of waitcnt was in mention of the fact that I was NOT using waitcnt because it would keep one process from running while the other was waiting for a delay. Instead I am using the two counters to provide my delay and measuring PHSA/PHDB against my wait variable. If PHSA has not counted upto or over MS001, then I jmpret over to the other process to check its progress.I just realized I am not starting the second process correctly as it is waiting for a return from the first. Unfortunately, in single step or animate, PHSA goes beyond 1 ms to quickly to trap the next step correctly. I may resort to a substitute step(s) to allow me to see if the jmps are occuring correctly. Thanks for all the assistance and for the debugger. Also pointing out BST's listing files was a huge benifit to the debugging process. Now if I could just figure out how to dump a couple of var's as binary....
Jim
As far as "a" goes ...
I use "a9" ... "a1" is a little fast for me. Don't add a space between "a" and the number.
I recommend adding time := 20 to PUB animate in BMAUtility.spin.
I'll post an update with this change later.
Yes, I noticed there wasn't a waitcnt in the PASM. Using PHSx like this is a nice alternative - just remember to follow the PHSx write rules. PHSx can go very fast - it is a powerful feature. Unfortunately "a" or any step command like "enter" takes many instructions.
If you use the "g" command your breakpoint must be on a PC location that gets hit during execution. There are some instructions that do not behave very well for breakpoints though such as any "ret" ... there is not much I can do about that problem except recommend that "ret" instructions not be used as breakpoints.
Regarding variable dumps, the "h" command dumps hex values and it calls dumpHubAddrs ... you could change that to dump bits. An alternative is to add an "H" command that calls a new dump this would be fairly easy to do, but will consume memory. I could add this to a special version.
Thanks for all the help,
Jim
missing @ on the longfil at the begining of main was the source of much of my agony! I am now back to debugging and that is going well. used some temp vars to get around the delay problem so that I could check how the jmpret routines were working.
Thanks again for the wonderful tool.
Jim
Crash and burn time! attached are two files. One is the compiled listing I was trying to debug, the second is the list output of the debugger.
Jim
log928_1710.txt list938_1710.txt
Please attach your source. I see the listing. It's easier to figure out with a source .zip though.
My best guess is that you have tried to print something from Main. ... well maybe not.
your movi start_stp2,#0 doesn't create a nop but a wrbyte (see listing). As the zero flag isn't set it even gets executed and most likely corrupts memory. The instruction at start_stp2 doesn't modify the flags so it would be better to use something like cmp (%100001_000) which doesn't do any harm.
You should also check your jumps with cmdloop? targets. Currently they are indirect jumps.
While I was a way from the code, I got to thinking about that movi instruction. I wished there was an easy way to steal the instruction part of an instruction and write it to another instruction. As to the indirect jmp's I wonder how many times I will be condemmed to do that before I always get it right? I am glad I switched to BST for the terminal program and the Listings. With Steve's program, following the listing and the disassemembled output does make a difference in the ability to diagnose the problems.I had just changed the cmdloop instructions away from calls as I realized that the call instructions would block the 2nd motor from starting. Can you suggest a better way to start the second motor without either motor blocking the other from running correctly?
Thanks for all your help.
Jim