Simple, but full featured Debugger

Hanno

SEE VIDEO LINK at end...

I think I'm 99% there. I already can:

• start/stop a cog remotely from the PC
• inspect and change variables from the PC
• pause cog execution until PC sends a command
• compile and load spin files to the Propeller

What functionality do people require/wish for?

• Set a breakpoint in their code
• View a variable's value when the code hits the breakpoint (and even at any time in between, and even change them)
• Resume from the breakpoint by pressing a button on the PC- continue running at full speed
• Step one instruction at a time (involves pausing the cog after a determined time)
• Work for spin, assembly, c in any/all cogs
• you tell me!

This would all be based on my work with ViewPort- currently a "visual debugger"- get started with Andy's PE Lab to become familiar with it.
Hanno

Post Edited (Hanno) : 1/13/2009 11:01:30 AM GMT

StefanL38

Hello Hanno,

wow ! - this would be great !

what I would like to have MOST is:

1.) set breakpoint,
2.) view variables
3.) work for spin and assembly
4.) for one cog as a beginning



5.) change variables
6.) singlestep-mode
7.) work for all cogs
would be great and there will be situations where this is useful or nescessary
for fast hitting the bug, but for me 5-7 are second priority

best regards

Stefan

Hotdrop

If you could do that that would be amazing

Ariba

For me, a "full debugger" must be able to:

- show the actual position in the source code for Breakpoints and Single Steps
- set and clear breakpoints while debugging
- single stepping whole Spin source lines
- support step-in and step-over for methodes
- look at the memory and all variables while debugging

This all should be possible with BradC's or mpark's Spin compiler, because they produce detailed listings.

Andy

hippy

I'm with Ariba : The Holy Grail of Propeller debugging for me would be near identical to VB6 debugging, I particularly like the ability to pause and continue a program at will, hold the cursor over a variable and see its contents, view call stacks, plus the ability to edit code while debugging. To me it's not so much what it can do but how it does it. VB6 debugging wasn't perfect but it was a very simple intuitive mechanism.

Praxis

Interesting... I have used NoICE for many years and if you support the same type of features (which is pretty much everyones wish list) then great.

Some more tech info on the how would be usefull at this time i.e. what is the memory inpact on the prop and what type of user interface also
would the pricing structure follow ViewPort or be something else.

Cheers.

CannibalRobotics

- Pointer values and variable locations would be pretty cool.
- Conditional breakpoints.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Signature space for rent, only $1.
Send cash and signature to CannibalRobotics.

Hanno

One thing that out of my current scope of knowledge is editing the spin program while it's running- like in vb6. Call stacks are also iffy.

Hanno

It's been a busy week but I made some progress. See first screenshot! This is not a mock-up and it's not the Propeller Tool. It's a ViewPort plugin showing:
- a breakpoint
- value of a variable
- actions available for variable
- familiar syntax highlighting
I'll need beta testers in about a week... More to come soon!
Hanno

BradC

Sweet! really sweet!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!

Sapieha

Hi Hanno.

I can beta test it but only in 3 weeks.
I not have license on ViewPort

Ps. Even on non standart frequencies

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


Sapieha

Mike Huselton

Hanno, as an early cheerleader of your wonderful toolsystem, I would like to offer my services as a beta tester. I think that, once developers fully understand what you have accomplished, the floodgates will open for the deluge of applications that take advantage of your framework. The tipping point has been reached; accelerando is not far behind...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH - Electronics: Engineer - Programming: Professional

TJHJ

ME ME ME ME. Awesome work. I cant wait to try it out.

TJ

Hanno

Ok,
TJHJ, Quantum, Sapieha, Ingolf and Andy are in for beta-testing the Debugger- starting in about a week. I'm still taking feature requests- ideally screenshots of your favorite debugging tool.
Hanno

Joerg

I would like it somewhat like this:




Freescale_CodeWarrior with Debugger/Programing Interface for HC(S)08 MCU's


Saluti J

agodwin

I would like some features of the Lautenbach debuggers. Windowing features are somewhat like the Codewarrior layouts (source, asm, memory dump windows wherever you want) but it has some less obvious features under the hood :

There is an underlying scripting interface which you can use to get your target to a specific state. Anything possible from the interactive displays can be done with scripting and more besides - looping, conditionals etc. The command line has recall and autocompletion features to make it easier to remember the options, and I think the menu-driven operations put the command-line equivalent into the recall buffer (not sure about that one).

The interface to the target is very flexible, though it uses hugely expensive hardware pods. However, they can be connected through ISA, USB or ethernet for remote debugging. It is also sometimes possible to control multiple pods so that breakpoints on one processor will stop another.

I have some propeller boards with lantronix ethernet-to-serial interfaces on them and others where a serial interface is connected to a remote CPU, typically running Linux. I'd like to be able to run the debugger over that link : it doesn't need to actually run on the remote CPU, but it would be nice if I could proxy the connection so that the propeller sees a serial connection and the debugger sees a TCP port, with the links in between open enough for me to get them running on my own hardware.

Capt. Quirk

Will ViewPort and the Debugger spread to multiple monitors?

Hanno

Joerg,
I hope I can do better than your screenshot- that's ugly! So much wasted space- most panes only show 3 lines of data. I'm looking at 2 versions:
simple-
integrated source code with breakpoint and variable inspection/edit. See my screenshot. Buttons to allow loading, single step, run.
full-
source code pane as above, plus:
buttons to step into/over functions
call-stack
i/o pin display
watch list
command interpreter- let's you print/set variables, run, step, run to
memory map
you'll be able to resize individual panes, but not arrange them however you want
you won't be able to edit code while debugging
since this is a viewport plugin, i'm using the serial interface everyone already has- no need to buy a $5k pod

Anyone know if ViewPort spreads to multiple monitors?
Comments?
Hanno

Hanno

Here's a screenshot of the Debugger plugin- some items aren't live yet...
Shows:
- call stack
- variable watch list
- i/o pin status
- memory dump
- command interpreter
- syntax highlighting with breakpoint and "variable" value tooltip
- object structure
- file listing with browse button and list of recent directories

All panels are proportional- if you make the tool half as wide, all elements will shrink to half width.
Panels are layed out with a simple xml file, so you can create basically any layout you want- resize using mouse.
Hanno

Capt. Quirk

"Anyone know if ViewPort spreads to multiple monitors?"

Your connection speed tool bar will go outside VP and into a 2nd monitor but it won't stay or anchor there.

I asked the question, because I frequently use programs that·allow me to organize my screen space·and increase my productivity (like Eclipse, all my web and photography programs, MPLab, etc). It would be fantastic if ViewPort would split each of it functions into seperate window or panes. The DSO tab for example, could have just the Oscilloscope on 1 screen and the controls resized to fit on the other screen.

Bill

Post Edited (Capt. Quirk) : 11/5/2008 9:58:12 PM GMT

Mike Huselton

I would say call a code freeze and let people get familiar with the current iteration. I can't test a moving target - one could write up a test scenario that could be obsoleted with the next incarnation. At least show in big letters which version is being tested. All subsequent testing will have the same version on the same screen real estate. This avoids confusion in testing.

I for one vote to go for it, warts and all. Then have a bi-weekly release until the user misunderstandings are ironed out.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH - Electronics: Engineer - Programming: Professional

Post Edited (Quantum) : 11/5/2008 10:41:47 PM GMT

Hanno

Ok, almost there! Here are some actual lines from the interactive command interpreter (I typed the '>' lines, the debugger then carried out the instruction to the Propeller and returned with a result):

>r
Ok, run
>p
Ok, pause
>print a
Ok, a=191
>set a=200
Ok, sent 200 to a
>print a
Ok, a=200
>s20
Ok, take 20 steps
>print a
Ok, a=210
>w a<300
Ok, run while a<300
>print a
Ok, a=300
>help
Valid commands are:set VAR=VALUE,print VAR,R'un,S'tep,S'tepNUMBER,P'ause,W'hile VAR=<>VALUE,'U'ntil VAR=<>VALUE

Hanno

Everything's working! Check out my new spin development environment:

Has:
- Breakpoint, step into, step over, step out, pause spin code
- Watch Variables, display in binary, hex, decimal and string
- State of IO Pins
- Call stack (lists stack of functions called until current point)
- Profiler (graphs time spent in each function)
- Memory Dump (complete 32kb download when breakpoint hit/stepped)
- Command Interpreter (run, step N, run while Variable <>= Value)
- Familiar File/Object/Code view as in Propeller Tool with mouseover variables to inspect/change value

Will go to beta testers soon, then sold as a plugin for ViewPort....
Hanno

Post Edited (Hanno) : 11/20/2008 2:03:36 AM GMT

Timothy D. Swieter

OK - I have been around the Propeller since the inception, but I haven't been looking at the tools the community has created. I am looking over this thread and the Viewport looks amazing. Where have I been?

So, with the additions you are making to Viewport Hanno, will all code editing occurs in Viewport or will it require the Prop Tool still?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com

Post Edited (Timothy D. Swieter) : 11/20/2008 2:15:25 AM GMT

Hanno

Hi Timothy,
Thanks for the kudos. ViewPort's been around for a while... Some good links:
- Parallax's PE Lab
- ViewPort home page
- 60 page manual
- Short videos demonstrating ViewPort functionality
- Article in the Parallaxian
Hanno

Mike Huselton

I am deeply proud of Hanno; he has been working his Smile off for over a year.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH - Electronics: Engineer - Programming: Professional

Hanno

Anyone interested in an integrated PASM debugger? I think with the large memory model I could put together a complete debugger (same features as the spin one- see above) with little performance impact. Should I first finish the spin debugger?

Harley

Hanno,

Here's one vote for finishing the Spin debugger.

And YES, also an integrated PASM debugger. I suppose that would allow debugging any of the remaining 7 cogs, if assembly coded..

Sounds like another useful set of tools besides what ViewPort now offers.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

Timothy D. Swieter

So is the debugger also a programmer? I mean, can I write all my code in it and edit and change or do I write my code in the Propeller Tool and then load it in the Debugger for debugging?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com

Jim Patek

Hanno,

I'd vote for the SPIN debugger as well. The PASM debugger may be useful for me someday when I decide to give in and use assembly.

Hanno

Hi Timothy,
It's an Integrated Debugger- just like Visual Studio. Take a look at the screenshot- a big part of the screen shows the syntax highlighted code- just like the Propeller Tool. This is where I write my spin program. When I'm ready to debug, I hit the "Play" button at the top of the screen which compiles and loads the code I was working on to the Propeller. At that point, I can hit the "Pause" button to pause the cog that's currently executing the code in the active tab. I could also click to the left of the code to set a breakpoint, when the cog is about to execute the instructions in that line, the cog is paused. Once paused, I can step across single lines of spin code, step over functions, or step out of the current function. All the panes are updated- this lets me see the values and addresses of the watched variables, the complete 32kb of memory, a profiler, a call stack and the state of IO pins. I can also mouse over variables in the code which brings up a tooltip that shows the value of the variable and let's me change it. At any time I can "unpause" and resume the cog exactly where it stopped.