I've added some cool stuff into the DEBUG displays:
1) New bitmap display, nine different 1..32-bit modes mimic the streamer modes
2) CLOSE command, so that displays can be dynamically stopped and started
3) Packed LONG/WORD/BYTE modes for efficiently conveying 1/2/4/8/16-bit values
4) String buffer increased to handle up to 1K of longs from an array.
5) For logic, scope, scope_xy, scope_rt, and bitmap displays, data can be streamed in from packed arrays.
The bitmap mode can place pixels in any direction as data is streamed in. You can choose between X and Y dominance, plus separate X and Y inc/dec-wrapping. Also, you can select a pixel size of 1..32 base pixels. In this MP4, I am only supplying the rightmost column of pixels, then using SCROLL to move the image left by one pixel. I am feeding the scope display with one command.
I need to get recharged and I will post this new version of PNut.
- Initially works great, output goes to new pin as desired...
-- When is redirected empty debug terminal still starts up - which isn't needed. (have to just drag it to mostly off screen to hide it. putting it behind doesn't work as next run it's moved forward again.)
- Problems moving between redirected and not...
-- Load file without redirection constants and run with debug. Debugger output does not resume.
-- Add redirection constant but set pin to default pin. Debugger output does not resume.
-- Power cycleing board and shutting down, restarting pnut finally took away the redirection. (not sure which cleared it as i had already done both by the time it cleared.)
Are my expectations correct in that the current code loaded should be driving all debug, right?
- load code with no redirection and run with debug: output should be to default pin?
- load code with redirection and run with debug: no debug windows should be shown?
- Initially works great, output goes to new pin as desired...
-- When is redirected empty debug terminal still starts up - which isn't needed. (have to just drag it to mostly off screen to hide it. putting it behind doesn't work as next run it's moved forward again.)
- Problems moving between redirected and not...
-- Load file without redirection constants and run with debug. Debugger output does not resume.
-- Add redirection constant but set pin to default pin. Debugger output does not resume.
-- Power cycleing board and shutting down, restarting pnut finally took away the redirection. (not sure which cleared it as i had already done both by the time it cleared.)
Are my expectations correct in that the current code loaded should be driving all debug, right?
- load code with no redirection and run with debug: output should be to default pin?
- load code with redirection and run with debug: no debug windows should be shown?
Stephen, I will work on this. I never really considered all these possible outcomes. There are probably a number of issues like these.
Stephen, if the flash is programmed and the chip is reset, it will output any debug stuff that was in that image.
Thanks, Chip. Sounds like what I'd expect and good to know. The current state is not really interfering with my characterization of the RPi stuff. I just wanted to keep you informed of what I'm seeing as I am playing between the two environments as that boundary will be very misleading to a new person if it doesn't behave well. I'm sure I'm preaching to the choir here... ;-)
I'm continually amazed and excited about what you are producing using your new P2. These debug displays are great visualizations!
Stephen, if the flash is programmed and the chip is reset, it will output any debug stuff that was in that image.
Thanks, Chip. Sounds like what I'd expect and good to know. The current state is not really interfering with my characterization of the RPi stuff. I just wanted to keep you informed of what I'm seeing as I am playing between the two environments as that boundary will be very misleading to a new person if it doesn't behave well. I'm sure I'm preaching to the choir here... ;-)
I'm continually amazed and excited about what you are producing using your new P2. These debug displays are great visualizations!
I appreciate you pointing out these things that need fixing. And I really like your enthusiasm.
I'm thinking that we need an FFT display next. Someone already mentioned this. It would be neat to just send it a set of samples and have it do the transform, with an option to show phase in color, with power being on the Y axis. Maybe a rolling spectrograph display, too, where pixel intensity represents energy at a frequency at a point in time and color represents phase. That would be four dimensions of data on a 2D display.
There is a lot of unexplored stuff possible with the Goertzel function in the streamer, where you can can output reference sine signals and measure returning signals which can be summed and differenced before going into the Goertzel. It will be useful for frequency sweeps to detect resonances, for example. A handy FFT display would let you do proof-of-concept work without having to code much on the P2.
I think, in order to do phase coloring in an FFT, there needs to be an option to maybe use some lower frequency phase as a reference for the rest. The problem is that in most cases, phase is uncorelated with the sample set. In the Goertzel, though, these things can be connected via feedback, for absolute phase relationships. That is quite unexplored, at this point.
Chip,
I don't know if the FFT and other goodies are limited to being available in debug mode only. I'm presuming these features could be coded in their own cog while still using debug. Just want to check if that's correct as I think an FFT demo program would be really neat and show off the P2's abilities admirably.
Chip,
I don't know if the FFT and other goodies are limited to being available in debug mode only. I'm presuming these features could be coded in their own cog while still using debug. Just want to check if that's correct as I think an FFT demo program would be really neat and show off the P2's abilities admirably.
That spectrum demo has an FFT in PASM. I thought it would just be handy to have one in the PC, also, so that it can convert a raw sample set into a spectrum. It would be useful if you got some sampling system working, but had not yet coded an FFT. You could get some early results on transducer performance.
All these DEBUG displays take in raw data and present them in some graphical way.
To take this to the next level, I need the debugger program that runs in the debug ISR to operate in a packet mode, which would no longer work on a normal serial terminal, but would allow whole arrays to be sent in pieces, as they get reconstructed inside the PC. This would cut down all cogs' debug latencies. It would also allow a framework of polling and response, so that a real breakpoint debugger could be implemented.
....It would also allow a framework of polling and response, so that a real breakpoint debugger could be implemented.
The graphical debug stuff looks really nice and is very useful for real time debugging. When the debuggee has to interact with external hardware in real time a single step debugger is not of much help. Graphical output is ideal for watching medium speed signals where the human eyes can follow the changes and idetify unusual behaviour (glitches, noise, peaks...). If the signals are too fast for the human eye triggering to special events helps.
But there are other debugging scenarios where you really want a single step debugger. When debugging complex algorithms and especially complex data structures you need to watch the states of all variables and the changes each statement makes. With printf-style debugging you have to know which variables you want to watch before compiling. But if you have to deal with dynamic data structures like linked lists or trees of pointers you can't print them all at once. You have to follow the pointers interactively while the program is halted.
Dynamic data structures where not very commonly used on the P1 but with the P2 this will change, I think. More memory allows more complex software which in turn asks for dynamic memory allocation and operating systems supporting it.
The VBA32 engine (the only one left detecting a problem) is a Belarusian company, that seems to be labeled "abandonware" by some on the 'net, after their main engineer went to Kaspersky. I've sent it to their false positive "team" anyway to see what happens.
Okay, that was a waste of time. Their only documentation saying how to send them false-positives lists an email address to send them too. I did that and eventually got this response from our mail server:
554 5.7.1 Service unavailable; Client host [209.85.218.65] blocked using dnsbl.sorbs.net; Currently Sending Spam See: http://www.sorbs.net/lookup.shtml?209.85.218.65
sorbs.net is the "Spam and Open Relay Blocking System"
I got an FFT debug display working today. It can display power in terms of input amplitude for each bin. If you input a sine wave of amplitude 10, you get a power level of 10. Very straightforward. The numerical explosion of FFT's always seemed unweildy.
Is there a way to set breakpoints?
I read the doc, but I can’t find the info how to set breakpoints and watch variables or dump some memory
Please help, my english is not the best
Is there a way to set breakpoints?
I read the doc, but I can’t find the info how to set breakpoints and watch variables or dump some memory
Please help, my english is not the best
A bug was introduced back in v34i, but only detected recently, where object array methods used as terms/parameters were causing the compiler to complain that a '.' was expected when an [index] was encountered. This was caused by the introduction of automatic constant-expression resolving in v34i. It is now fixed.
Two new DEBUG displays have been added: BITMAP and FFT. BITMAP is complete, but I'm still improving FFT.
The compile issue appears to be fixed, but I'm encountering a new issue (may have occurred on older versions as well).
When I try to load spin2 files downloaded from github it removes all line breaks and gives me "no PUB methods found" when trying to compile them. Stuff I wrote myself does not seem to have that issue.
The compile issue appears to be fixed, but I'm encountering a new issue (may have occurred on older versions as well).
When I try to load spin2 files downloaded from github it removes all line breaks and gives me "no PUB methods found" when trying to compile them. Stuff I wrote myself does not seem to have that issue.
Interesting. I’m getting the same error trying to test jm_serial. I’ve been trying to download jm_serial again (first time I opened each file as raw in GIT and did a cut and paste) but totally failed to get GIT to work and gave up.
I’ll look at the line end encoding when I get home soon as that may be the problem. And yes, it’s the same on much older versions.
Comments
They seem have more important problems over there right now, might take a good while for anyone to even read your mail.
1) New bitmap display, nine different 1..32-bit modes mimic the streamer modes
2) CLOSE command, so that displays can be dynamically stopped and started
3) Packed LONG/WORD/BYTE modes for efficiently conveying 1/2/4/8/16-bit values
4) String buffer increased to handle up to 1K of longs from an array.
5) For logic, scope, scope_xy, scope_rt, and bitmap displays, data can be streamed in from packed arrays.
The bitmap mode can place pixels in any direction as data is streamed in. You can choose between X and Y dominance, plus separate X and Y inc/dec-wrapping. Also, you can select a pixel size of 1..32 base pixels. In this MP4, I am only supplying the rightmost column of pixels, then using SCROLL to move the image left by one pixel. I am feeding the scope display with one command.
I need to get recharged and I will post this new version of PNut.
Usage issues with debug pin redirection:
- Initially works great, output goes to new pin as desired...
-- When is redirected empty debug terminal still starts up - which isn't needed. (have to just drag it to mostly off screen to hide it. putting it behind doesn't work as next run it's moved forward again.)
- Problems moving between redirected and not...
-- Load file without redirection constants and run with debug. Debugger output does not resume.
-- Add redirection constant but set pin to default pin. Debugger output does not resume.
-- Power cycleing board and shutting down, restarting pnut finally took away the redirection. (not sure which cleared it as i had already done both by the time it cleared.)
Are my expectations correct in that the current code loaded should be driving all debug, right?
- load code with no redirection and run with debug: output should be to default pin?
- load code with redirection and run with debug: no debug windows should be shown?
Stephen, I will work on this. I never really considered all these possible outcomes. There are probably a number of issues like these.
Thanks Chip. Excellent!!
FFT and debug will be fun to play with.
Thanks, Chip. Sounds like what I'd expect and good to know. The current state is not really interfering with my characterization of the RPi stuff. I just wanted to keep you informed of what I'm seeing as I am playing between the two environments as that boundary will be very misleading to a new person if it doesn't behave well. I'm sure I'm preaching to the choir here... ;-)
I'm continually amazed and excited about what you are producing using your new P2. These debug displays are great visualizations!
I appreciate you pointing out these things that need fixing. And I really like your enthusiasm.
I'm thinking that we need an FFT display next. Someone already mentioned this. It would be neat to just send it a set of samples and have it do the transform, with an option to show phase in color, with power being on the Y axis. Maybe a rolling spectrograph display, too, where pixel intensity represents energy at a frequency at a point in time and color represents phase. That would be four dimensions of data on a 2D display.
There is a lot of unexplored stuff possible with the Goertzel function in the streamer, where you can can output reference sine signals and measure returning signals which can be summed and differenced before going into the Goertzel. It will be useful for frequency sweeps to detect resonances, for example. A handy FFT display would let you do proof-of-concept work without having to code much on the P2.
I don't know if the FFT and other goodies are limited to being available in debug mode only. I'm presuming these features could be coded in their own cog while still using debug. Just want to check if that's correct as I think an FFT demo program would be really neat and show off the P2's abilities admirably.
That spectrum demo has an FFT in PASM. I thought it would just be handy to have one in the PC, also, so that it can convert a raw sample set into a spectrum. It would be useful if you got some sampling system working, but had not yet coded an FFT. You could get some early results on transducer performance.
All these DEBUG displays take in raw data and present them in some graphical way.
To take this to the next level, I need the debugger program that runs in the debug ISR to operate in a packet mode, which would no longer work on a normal serial terminal, but would allow whole arrays to be sent in pieces, as they get reconstructed inside the PC. This would cut down all cogs' debug latencies. It would also allow a framework of polling and response, so that a real breakpoint debugger could be implemented.
The graphical debug stuff looks really nice and is very useful for real time debugging. When the debuggee has to interact with external hardware in real time a single step debugger is not of much help. Graphical output is ideal for watching medium speed signals where the human eyes can follow the changes and idetify unusual behaviour (glitches, noise, peaks...). If the signals are too fast for the human eye triggering to special events helps.
But there are other debugging scenarios where you really want a single step debugger. When debugging complex algorithms and especially complex data structures you need to watch the states of all variables and the changes each statement makes. With printf-style debugging you have to know which variables you want to watch before compiling. But if you have to deal with dynamic data structures like linked lists or trees of pointers you can't print them all at once. You have to follow the pointers interactively while the program is halted.
Dynamic data structures where not very commonly used on the P1 but with the P2 this will change, I think. More memory allows more complex software which in turn asks for dynamic memory allocation and operating systems supporting it.
Okay, that was a waste of time. Their only documentation saying how to send them false-positives lists an email address to send them too. I did that and eventually got this response from our mail server:
sorbs.net is the "Spam and Open Relay Blocking System"
I won't pursue this one further.
I read the doc, but I can’t find the info how to set breakpoints and watch variables or dump some memory
Please help, my english is not the best
You can print variables, but no breakpoints, yet.
A bug was introduced back in v34i, but only detected recently, where object array methods used as terms/parameters were causing the compiler to complain that a '.' was expected when an [index] was encountered. This was caused by the introduction of automatic constant-expression resolving in v34i. It is now fixed.
Two new DEBUG displays have been added: BITMAP and FFT. BITMAP is complete, but I'm still improving FFT.
Yes, we will update PropellerTool soon with the new compiler guts.
Thanks for trying that, Cluso.
Everything is great here too
Thanks!! Chip
When I try to load spin2 files downloaded from github it removes all line breaks and gives me "no PUB methods found" when trying to compile them. Stuff I wrote myself does not seem to have that issue.
https://github.com/parallaxinc/propeller/blob/master/libraries/community/p2/All/jm_serial/jm_nstr.spin2 as an example.
I’ll look at the line end encoding when I get home soon as that may be the problem. And yes, it’s the same on much older versions.
It is not formatting properly. Everything is in a single line .
[img][/img]