Chip,
There's a small discussion about adding some preprocessor macros to the Spin language over here - https://forums.parallax.com/discussion/174674/mixing-pnut-and-flexspin-specific-code/p1 Flexspin has a distinct departure from PNut with the memory map and notably doesn't support REGLOAD nor interrupts. So it'd be nice have conditional compiling supported in the language itself.
@Ariba said:
Also FOR - NEXT in BASIC, and for(;;) in C have the index variable outside the range after the loop, that is just how this type of loop works. I don't see any advantage in the changed behaviour of Spin2.
Neither do I, really, but someone in the past had impressed upon me that we needed to change it, so I did.
Please change it back. I didn't realize that it had been modified, and I know that I have un-ported P1 code that tests the loop control value to verify that the loop went all the way through.
To use the debugger, just insert "DEBUG" into your Spin2 or PASM code. The debugger will open when DEBUG is encountered. DEBUG just compiles to a BRK #0 instruction. Normal DEBUG() messages use BRK #1..255.
Here is an included "debugger_demo.spin2" program that will launch another cog and cause two debuggers to open, one for the Spin2 cog and one for the PASM cog:
CON _clkfreq = 200_000_000
'debug_main 'uncomment to single-step through everything, even COGINITs
'debug_coginit 'uncomment to break on COGINITs
PUB go() | i
coginit(newcog, @pasm_program,0) 'start another cog with a PASM program (another debugger will open)
repeat 'keep looping while incrementing a variable
i++
debug 'break everytime through the loop if "DEBUG" is selected (default)
DAT org
pasm_program debug 'do a DEBUG at the start of the program to open debugger
.loop add pa,#1 'select "MAIN" in the debugger to single-step
sub pb,#2
jmp #.loop
long 0[12] 'fill with some NOP's to make it easy to see the code above
Please let me know if you find any bugs. I think it works fine, but this was really complicated to develop. It kind of grew organically, as I figured out what was possible to do. This took me several months, which was way longer than I anticipated. I like the way it turned out.
And, Chip, please put your above download link in the first post of this topic as well. It's gonna get lost in here quickly. I only just realised that v35t existed.
And, Chip, please put your above download link in the first post of this topic as well. It's gonna get lost in here quickly. I only just realised that v35t existed.
I totally meant to do that, but I was in a hurry. Thanks for reminding me.
Any word on how the debugger is working? Any questions?
As you navigate around with the mouse, a hint shows up on the bottom line of the debugger, explaining what you can do. It should be pretty self-explanatory.
Chip,
My guess is everyone that is waiting for this, exclusively uses PropTool.
On that note, I'd love it if Pnut's comport handling could be put into Proptool too. Possibly just the port opening code is all that's needed to fix the only apparent issue that PropTool has under Wine.
@evanh said:
Chip,
My guess is everyone that is waiting for this, exclusively uses PropTool.
On that note, I'd love it if Pnut's comport handling could be put into Proptool too. Possibly just the port opening code is all that's needed to fix the only apparent issue that PropTool has under Wine.
Chip,
for me it is not usefull, i get the following Error message.
or this after a few single steps:
I have a P2 EVAL Rev.B and the Pnut runs on an iMac i7 with Parallels und Win7.
I use this setup every day and I have no Problems with debug(...)
I try to set DEBUG_BAUD = 1_000_000, but the debug not starting any more.
And, Chip, please put your above download link in the first post of this topic as well. It's gonna get lost in here quickly. I only just realised that v35t existed.
PNut GitHub link added to the URL evanh mentioned.
Having fun figuring out how to use the new debugger.
I noticed if I click in the box with the PASM variables the values disappear and it has REG with a yellow triangle. Can't get the variables back unless I hit the GO button with DEBUG selected - even then not all the variables previously showing come back.
I figured out the single step is done by selecting MAIN and then pressing GO, that is a great feature! How is the bottom box refreshed based on the current code line in the debug window? I did something at one point where it shows what appears to be a hub memory location but I don't know what I did to get that.
Is there a way to make the debug window larger, I have a high resolution monitor and the text is hard to read, especially the green letters on the background?
@DiverBob said:
Having fun figuring out how to use the new debugger.
I noticed if I click in the box with the PASM variables the values disappear and it has REG with a yellow triangle. Can't get the variables back unless I hit the GO button with DEBUG selected - even then not all the variables previously showing come back.
I figured out the single step is done by selecting MAIN and then pressing GO, that is a great feature! How is the bottom box refreshed based on the current code line in the debug window? I did something at one point where it shows what appears to be a hub memory location but I don't know what I did to get that.
Is there a way to make the debug window larger, I have a high resolution monitor and the text is hard to read, especially the green letters on the background?
The whole debugger is the same font size as what you have in the editor. While in the editor, just do Ctrl-Up to increase the font size. Then, do Ctrl-F10 to download and run the debugger with the new font size.
When you click in the hub data area, you set the hub-view location and the disassembly pane to the same address. Left click on the disassembly pane and you will lock it back to the PC, while the hub data stays at the same location.
The Reg-Delta pane show registers that have changed, since the last GO button. You can right-click on GO to automate the updating, then you can observe the cog and LUT map highlighting, showing where you are executing from.
All these things are indicated in the hint line at the bottom of the window, as you move the mouse around.
With help from Jeff, I've got the PNut serial communication code now running in a separate thread from the GUI. It should be much more reliable and will hopefully work better on a Mac now (running a Windows emulator).
The new version is in the first post of this thread.
@cgracey said:
With help from Jeff, I've got the PNut serial communication code now running in a separate thread from the GUI. It should be much more reliable and will hopefully work better on a Mac now (running a Windows emulator).
The new version is in the first post of this thread.
I am here to remind you that the GitHub still hasn't been updated.
Also, you still haven't posted the live forum video from last week.
@cgracey said:
With help from Jeff, I've got the PNut serial communication code now running in a separate thread from the GUI. It should be much more reliable and will hopefully work better on a Mac now (running a Windows emulator).
The new version is in the first post of this thread.
I am here to remind you that the GitHub still hasn't been updated.
Also, you still haven't posted the live forum video from last week.
@wummi said:
Chip,
for me it is not usefull, i get the following Error message.
or this after a few single steps:
I have a P2 EVAL Rev.B and the Pnut runs on an iMac i7 with Parallels und Win7.
I use this setup every day and I have no Problems with debug(...)
I try to set DEBUG_BAUD = 1_000_000, but the debug not starting any more.
Wummi, the DOWNLOAD_BAUD can be set to 1_000_000 and DEBUG_BAUD will then inherit the same value.
I found that at _CLKFREQ = 10_000_000, things were sluggish, so I added a Application.ProcessMessages line into the breakpoint handler. It freed up the GUI quite a bit. So, I posted a new version with the same name as before. If you already downloaded the .zip file, just download it again and you will have the new one.
@evanh said:
DEBUG_BAUD is working again. Good on Wine too.
Thanks for trying it out. That's good news.
I don't do any baud-rate switching, anymore, between download and debug. I could probably add it back in, but what I have now just got working after discovery of deep buffers in the driver that needed purging via reading. What amounts to a serial port via USB running in Windows is an unknowable abyss of layered drivers and handlers beneath the Windows app. For now, just set DOWNLOAD_BAUD and it will use the same value for DEBUG_BAUD.
@cgracey said:
... For now, just set DOWNLOAD_BAUD and it will use the same value for DEBUG_BAUD.
Okay, I was always setting both the same anyway.
I do have a slight puzzle with the debug terminal. Can it be used with send() ? I'm trying but failing to print text to the comport using F10 compile + run and with the F12 debug terminal open.
Comments
Chip,
There's a small discussion about adding some preprocessor macros to the Spin language over here - https://forums.parallax.com/discussion/174674/mixing-pnut-and-flexspin-specific-code/p1 Flexspin has a distinct departure from PNut with the memory map and notably doesn't support REGLOAD nor interrupts. So it'd be nice have conditional compiling supported in the language itself.
With Electrodude's prompting, I've looked up the FreePascal reference and found its syntax. I figure that'd suit your taste - https://forums.parallax.com/discussion/comment/1540432/#Comment_1540432
Please change it back. I didn't realize that it had been modified, and I know that I have un-ported P1 code that tests the loop control value to verify that the loop went all the way through.
The earlier conversation - https://forums.parallax.com/discussion/comment/1532503/#Comment_1532503
And real case with Pnut pre-35q and PropTool post-35q - https://forums.parallax.com/discussion/174701/code-works-with-pnut-flexprop-but-not-prop-tool-how-possible/p1
Here is the latest PNut with the PASM-level debugger:
https://drive.google.com/file/d/1hNyuwfbMHU7zkmp_wAIEFnyAOB9Ykaij/view?usp=sharing
To use the debugger, just insert "DEBUG" into your Spin2 or PASM code. The debugger will open when DEBUG is encountered. DEBUG just compiles to a BRK #0 instruction. Normal DEBUG() messages use BRK #1..255.
Here is an included "debugger_demo.spin2" program that will launch another cog and cause two debuggers to open, one for the Spin2 cog and one for the PASM cog:
CON _clkfreq = 200_000_000 'debug_main 'uncomment to single-step through everything, even COGINITs 'debug_coginit 'uncomment to break on COGINITs PUB go() | i coginit(newcog, @pasm_program,0) 'start another cog with a PASM program (another debugger will open) repeat 'keep looping while incrementing a variable i++ debug 'break everytime through the loop if "DEBUG" is selected (default) DAT org pasm_program debug 'do a DEBUG at the start of the program to open debugger .loop add pa,#1 'select "MAIN" in the debugger to single-step sub pb,#2 jmp #.loop long 0[12] 'fill with some NOP's to make it easy to see the code abovePlease let me know if you find any bugs. I think it works fine, but this was really complicated to develop. It kind of grew organically, as I figured out what was possible to do. This took me several months, which was way longer than I anticipated. I like the way it turned out.
Slight nag: You haven't updated the PNut github in ages
I know. I would have done it today, but I didn't have much time. I will get it up in a few days.
I didn't know Pnut was hosted there. Maybe add it to the links - https://forums.parallax.com/discussion/173000/propeller-2-users-get-started-here/p1
And, Chip, please put your above download link in the first post of this topic as well. It's gonna get lost in here quickly. I only just realised that v35t existed.
I totally meant to do that, but I was in a hurry. Thanks for reminding me.
Any word on how the debugger is working? Any questions?
As you navigate around with the mouse, a hint shows up on the bottom line of the debugger, explaining what you can do. It should be pretty self-explanatory.
Chip,
My guess is everyone that is waiting for this, exclusively uses PropTool.
On that note, I'd love it if Pnut's comport handling could be put into Proptool too. Possibly just the port opening code is all that's needed to fix the only apparent issue that PropTool has under Wine.
Okay, Evan. Thanks. We will see what we can do.
Chip,
for me it is not usefull, i get the following Error message.
or this after a few single steps:
I have a P2 EVAL Rev.B and the Pnut runs on an iMac i7 with Parallels und Win7.
I use this setup every day and I have no Problems with debug(...)
I try to set
DEBUG_BAUD = 1_000_000, but the debug not starting any more.Agreed, defining the DEBUG_BAUD constant doesn't work.
EDIT: Just tested DEBUG_BAUD on Pnut v35s and it works there. So it's a regression in v35t.
Indeed. Struggling to find something that PNut doesn't choke on.
Speaking of, need to finalize the YM2608 object. It's been sitting semi-finished for a while.
PNut GitHub link added to the URL evanh mentioned.
Thanks
Thanks for the feedback, Everyone. I will look into these issues.
Having fun figuring out how to use the new debugger.
I noticed if I click in the box with the PASM variables the values disappear and it has REG with a yellow triangle. Can't get the variables back unless I hit the GO button with DEBUG selected - even then not all the variables previously showing come back.
I figured out the single step is done by selecting MAIN and then pressing GO, that is a great feature! How is the bottom box refreshed based on the current code line in the debug window? I did something at one point where it shows what appears to be a hub memory location but I don't know what I did to get that.
Is there a way to make the debug window larger, I have a high resolution monitor and the text is hard to read, especially the green letters on the background?
The whole debugger is the same font size as what you have in the editor. While in the editor, just do Ctrl-Up to increase the font size. Then, do Ctrl-F10 to download and run the debugger with the new font size.
When you click in the hub data area, you set the hub-view location and the disassembly pane to the same address. Left click on the disassembly pane and you will lock it back to the PC, while the hub data stays at the same location.
The Reg-Delta pane show registers that have changed, since the last GO button. You can right-click on GO to automate the updating, then you can observe the cog and LUT map highlighting, showing where you are executing from.
All these things are indicated in the hint line at the bottom of the window, as you move the mouse around.
With help from Jeff, I've got the PNut serial communication code now running in a separate thread from the GUI. It should be much more reliable and will hopefully work better on a Mac now (running a Windows emulator).
The new version is in the first post of this thread.
I am here to remind you that the GitHub still hasn't been updated.
Also, you still haven't posted the live forum video from last week.
I just updated the PNut_public files on GitHub.
I need to upload the video from last week, still.
DEBUG_BAUD is working again.
Good on Wine too.
Wummi, the DOWNLOAD_BAUD can be set to 1_000_000 and DEBUG_BAUD will then inherit the same value.
I just tried something on a lark and it actually works now:
CON download_baud = 3_000_000 'debug_baud will inherit the download_baud value
The new serial works at 3 Megabaud!
I found that at _CLKFREQ = 10_000_000, things were sluggish, so I added a Application.ProcessMessages line into the breakpoint handler. It freed up the GUI quite a bit. So, I posted a new version with the same name as before. If you already downloaded the .zip file, just download it again and you will have the new one.
Thanks for trying it out. That's good news.
I don't do any baud-rate switching, anymore, between download and debug. I could probably add it back in, but what I have now just got working after discovery of deep buffers in the driver that needed purging via reading. What amounts to a serial port via USB running in Windows is an unknowable abyss of layered drivers and handlers beneath the Windows app. For now, just set DOWNLOAD_BAUD and it will use the same value for DEBUG_BAUD.
Be sure to set the USB serial Latency Timer to 1ms.
Okay, I was always setting both the same anyway.
I do have a slight puzzle with the debug terminal. Can it be used with send() ? I'm trying but failing to print text to the comport using F10 compile + run and with the F12 debug terminal open.
Hi chip,
It works on my iMac with "download_baud = 1_000_000"
With 3Mbaud and 2Mbaud it is not working.
I think that is too much for the VM.