@rogloh said:
JMPREL is good but it is slower for HUBEXEC and will also interfere with a REP loop.
REP blocks INT1/2/3. If it also blocks debug INT0 there's no point having BRK inside a REP loop.
I doubt the DEBUG int should ever be blocked (if so a single step debugger couldn't ever work inside a rep loop but perhaps it does...?) I've not tried it.
Doesn't Chip's fancy debugger do single step? I've not used it (Mac mini system here) so don't know.
Gonna try a debug statement inside a rep loop now to see if it works. Will report back momentarily...update: yes it does work (tested in flexspin not Pnut however).
results in a bunch of these being spewed out
Cog5 rep loop
Cog5 rep loop
Cog5 rep loop
Cog5 rep loop
Cog5 rep loop
Cog5 rep loop
Cog5 rep loop
Cog5 rep loop
...
Maybe it breaks out of the REP though....need to check that too.
Re: the IF_C DEBUG type stuff. It feels to me like it may be better to leave this up to the programmer. Silently inserting code (whether it's SKIP or JMPREL or whatever) behind the programmer's back seems a bit dubious to me. If they want to have a conditional debug, let them add whatever instructions are appropriate for their own program, rather than making a one size fits all hack in the assembler.
@ersmith said:
Re: the IF_C DEBUG type stuff. It feels to me like it may be better to leave this up to the programmer. Silently inserting code (whether it's SKIP or JMPREL or whatever) behind the programmer's back seems a bit dubious to me. If they want to have a conditional debug, let them add whatever instructions are appropriate for their own program, rather than making a one size fits all hack in the assembler.
@Wuerfel_21 said:
+1 on that, seems kinda iffy in general.
Well, it can be very convenient, too, because it all goes away when DEBUG is not in use.
About messing up SKIP patterns, you would probably not put a DEBUG in the middle of a skip pattern because the skip pattern would have to be altered to accommodate it when DEBUG-compile is active. The most-likely scenario is that you single-step through a skip pattern to verify it, instead of interrupting it midstream.
@wummi said:
Hi Chip, i found a problem with pointer to methods in structures.
{Spin2_v50}
CON STRUCT sABC(Method, Time)
VAR sABC ABC
PUB start() | m,t
ABC := @Prog1, 0
repeat 10
ABC := ABC.Method(ABC.Time): 2 'Error: "Method pointers must be long....", but ABC.Method is a long
'm,t := ABC 'this workaround compiles
'ABC := m(t): 2
PRI Prog1 ( time ): Method, nextTime
debug(sdec(Time))
return @Prog1, time + 1_000
This took me all day to sort out, but I think I've got it now. There is a new PNut_v50p1 on the OBEX (top of this thread has a link).
Thank you very much for reporting this problem, Uwe. You are using Spin2 in ways that make sense, but I didn't anticipate.
I added the possibility of using a CON STRUCT name after the colon on a method pointer call, instead of just a constant. Now, you can code it like this:
In my project I use one cog for all the communications tasks.
The uart communication is interrupted driven. (up to 100_000 Interrupts/s)
The protocol handling is written in Spin2 and use the same cog.
When I use debug(......) in the Spin2 program interrupts are missed.
I habe no problems wenn debug is disabled for this cog
debug("Debug loop nr: ",sdec(i))
this line needs 150us to execute at _clkfreq = 240_000_000
are all interrupts disabled during this 150us? And can you change this behavior?
Debug+fast running realtime cog=problem. You have to have time for not only debug code itself, but also the serial transmission from debug to complete.
When I had to debug my audio driver using BRK debug , I had to set the sample rate to single Hz to make debug messages to appear on the terminal slow enough to not hog the cog and the terminal.
I have thought that for some real-time processes, the only way to use DEBUG for them is to have another cog issuing the DEBUG commands, based on status data updated by the real-time cog(s).
Chip, as I've suggested before, you could at least halve the amount of data sent over serial by debug commands by adding a binary mode where it just sends the message index and its arguments in raw unformatted binary, and expects the other end do the formatting on its own time. You could support both modes: always start out in text mode, and have a way to switch to binary mode - either some magic debug command, or a message sent by the debug window to request the switch to binary mode. When switching to binary mode, the P2 would send its message formatting table to let the host know how to interpret the binary data. The host might need to be able to request a switch back to text mode or to re-request the message table in case it gets disconnected and then reconnected.
I exclusively use DEBUG as a terminal print tool to a generic terminal. I've never used any of the graphics features. Partly because Pnut's built-in terminal sucks as an actual terminal.
@evanh said:
I exclusively use DEBUG as a terminal print tool to a generic terminal. I've never used any of the graphics features. Partly because Pnut's built-in terminal sucks as an actual terminal.
Would you like that TERM display to be interactive? Right now, it's just an output terminal.
@evanh said:
I exclusively use DEBUG as a terminal print tool to a generic terminal. I've never used any of the graphics features. Partly because Pnut's built-in terminal sucks as an actual terminal.
Yes, I've thought about that. I would need to think more about how to recode the data. I have been thinking lately that a Base64 mode would be helpful. It would be less of a deep change to the system.
@Electrodude said:
Chip, as I've suggested before, you could at least halve the amount of data sent over serial by debug commands by adding a binary mode where it just sends the message index and its arguments in raw unformatted binary, and expects the other end do the formatting on its own time. You could support both modes: always start out in text mode, and have a way to switch to binary mode - either some magic debug command, or a message sent by the debug window to request the switch to binary mode. When switching to binary mode, the P2 would send its message formatting table to let the host know how to interpret the binary data. The host might need to be able to request a switch back to text mode or to re-request the message table in case it gets disconnected and then reconnected.
Yes, I've thought about that. I would need to think more about how to recode the data. I have been thinking lately that a Base64 data mode would be helpful. It would be less of a deep change to the system.
@cgracey said:
Would you like that TERM display to be interactive? Right now, it's just an output terminal.
Don't worry, no, I rarely interact. I've come to prefer command line compiling and the resulting history. And terminal running in the console flows naturally into that. Which does exclude graphics but I only want it for diagnostics so text only is fine there.
One thing that bugs me is sharing the console IO with DEBUG as they tend to interfere with each other especially in flexspin which I mainly use. I guess you need to keep them on different pins or something. The problem is then you'd need additional HW to attach and P62/P63 is already a natural console and/or DEBUG port that's already attached to a PC via USB on P2-EVAL or a PropPlug on many other boards.
As soon as I add any debug I typically need to remove the console code and that can be a PITA if it's for the user interface. If a DEBUG console allowed reverse comms back into the P2 it might be possible to use that instead.
@Electrodude said:
Chip, as I've suggested before, you could at least halve the amount of data sent over serial by debug commands by adding a binary mode where it just sends the message index and its arguments in raw unformatted binary, and expects the other end do the formatting on its own time. You could support both modes: always start out in text mode, and have a way to switch to binary mode - either some magic debug command, or a message sent by the debug window to request the switch to binary mode. When switching to binary mode, the P2 would send its message formatting table to let the host know how to interpret the binary data. The host might need to be able to request a switch back to text mode or to re-request the message table in case it gets disconnected and then reconnected.
Yes, I've thought about that. I would need to think more about how to recode the data. I have been thinking lately that a Base64 data mode would be helpful. It would be less of a deep change to the system.
Just some thoughts about this.
Since the debug data table is generated by the compiler, it may not be necessary to send it to the debug terminal each time if integrated in the compiler, just export the data from the compiler to the debug terminal window internally.
For external programs, just in case, the compiler could save the debug table to a file that external programs read before starting.
The above could be controlled with a dedicated DEBUG_??? constant (like the other DEBUG constants) or command-line parameter.
Sending binary debug codes may conflict with the PASM debugger which already sends binary data, the "standard" debug codes should at least be preceded with a byte >= 8 (that is a long, but still greater than 7 to not trigger the PASM debugger).
@wummi said:
are all interrupts disabled during this 150us? And can you change this behavior?
Debugger essentially runs as INT0 and therefore takes priority over other interrupts, so "Yes" and "No"
I now this, but when the debugger ist startet and the Interrupt routines not use COG-RAM $00-$0f, the interrupts maybe can be reenabled for the serial output the debug data.
@cgracey said:
I just posted a new v48 which includes a preprocessor and flash-image saving. P2_PNut_Public is updated, as well.
Hi Chip,
one question for the new flash-image saving.
Is there any CRC or Checksum over the File.flash to check the integrity of the File before flash it to $000000?
Comments
REP blocks INT0. So if a BRK happens in a loop, the debugger is invoked once after the loop. Usually not what you want.
I doubt the DEBUG int should ever be blocked (if so a single step debugger couldn't ever work inside a rep loop but perhaps it does...?) I've not tried it.
It won't single step. Exactly how interrupt management should work. The code has control. NMIs are evil.
Doesn't Chip's fancy debugger do single step? I've not used it (Mac mini system here) so don't know.
Gonna try a debug statement inside a rep loop now to see if it works. Will report back momentarily...update: yes it does work (tested in flexspin not Pnut however).
z80debugger rep #3, #10 DEBUG("rep loop") nop nop nopresults in a bunch of these being spewed out
Cog5 rep loop
Cog5 rep loop
Cog5 rep loop
Cog5 rep loop
Cog5 rep loop
Cog5 rep loop
Cog5 rep loop
Cog5 rep loop
...
Maybe it breaks out of the REP though....need to check that too.
Hi Chip, i found a problem with pointer to methods in structures.
{Spin2_v50} CON STRUCT sABC(Method, Time) VAR sABC ABC PUB start() | m,t ABC := @Prog1, 0 repeat 10 ABC := ABC.Method(ABC.Time): 2 'Error: "Method pointers must be long....", but ABC.Method is a long 'm,t := ABC 'this workaround compiles 'ABC := m(t): 2 PRI Prog1 ( time ): Method, nextTime debug(sdec(Time)) return @Prog1, time + 1_000Re: the
IF_C DEBUGtype stuff. It feels to me like it may be better to leave this up to the programmer. Silently inserting code (whether it's SKIP or JMPREL or whatever) behind the programmer's back seems a bit dubious to me. If they want to have a conditional debug, let them add whatever instructions are appropriate for their own program, rather than making a one size fits all hack in the assembler.+1 on that, seems kinda iffy in general.
Well, it can be very convenient, too, because it all goes away when DEBUG is not in use.
About messing up SKIP patterns, you would probably not put a DEBUG in the middle of a skip pattern because the skip pattern would have to be altered to accommodate it when DEBUG-compile is active. The most-likely scenario is that you single-step through a skip pattern to verify it, instead of interrupting it midstream.
This took me all day to sort out, but I think I've got it now. There is a new PNut_v50p1 on the OBEX (top of this thread has a link).
Thank you very much for reporting this problem, Uwe. You are using Spin2 in ways that make sense, but I didn't anticipate.
I added the possibility of using a CON STRUCT name after the colon on a method pointer call, instead of just a constant. Now, you can code it like this:
Thank you Chip, now it is very easy to implement state machines.
But the best is:
Super! Thanks, Uwe.
What else is needed?
any chance to get pointer to objects?
In my project I use one cog for all the communications tasks.
The uart communication is interrupted driven. (up to 100_000 Interrupts/s)
The protocol handling is written in Spin2 and use the same cog.
When I use debug(......) in the Spin2 program interrupts are missed.
I habe no problems wenn debug is disabled for this cog
debug("Debug loop nr: ",sdec(i))this line needs 150us to execute at _clkfreq = 240_000_000
are all interrupts disabled during this 150us? And can you change this behavior?
Debug+fast running realtime cog=problem. You have to have time for not only debug code itself, but also the serial transmission from debug to complete.
When I had to debug my audio driver using BRK debug , I had to set the sample rate to single Hz to make debug messages to appear on the terminal slow enough to not hog the cog and the terminal.
I have thought that for some real-time processes, the only way to use DEBUG for them is to have another cog issuing the DEBUG commands, based on status data updated by the real-time cog(s).
Debugger essentially runs as INT0 and therefore takes priority over other interrupts, so "Yes" and "No"
Chip, as I've suggested before, you could at least halve the amount of data sent over serial by debug commands by adding a binary mode where it just sends the message index and its arguments in raw unformatted binary, and expects the other end do the formatting on its own time. You could support both modes: always start out in text mode, and have a way to switch to binary mode - either some magic debug command, or a message sent by the debug window to request the switch to binary mode. When switching to binary mode, the P2 would send its message formatting table to let the host know how to interpret the binary data. The host might need to be able to request a switch back to text mode or to re-request the message table in case it gets disconnected and then reconnected.
I exclusively use DEBUG as a terminal print tool to a generic terminal. I've never used any of the graphics features. Partly because Pnut's built-in terminal sucks as an actual terminal.
Would you like that TERM display to be interactive? Right now, it's just an output terminal.
Yes, I've thought about that. I would need to think more about how to recode the data. I have been thinking lately that a Base64 mode would be helpful. It would be less of a deep change to the system.
(I quoted the wrong post. See below.)
Yes, I've thought about that. I would need to think more about how to recode the data. I have been thinking lately that a Base64 data mode would be helpful. It would be less of a deep change to the system.
Don't worry, no, I rarely interact. I've come to prefer command line compiling and the resulting history. And terminal running in the console flows naturally into that. Which does exclude graphics but I only want it for diagnostics so text only is fine there.
One thing that bugs me is sharing the console IO with DEBUG as they tend to interfere with each other especially in flexspin which I mainly use. I guess you need to keep them on different pins or something. The problem is then you'd need additional HW to attach and P62/P63 is already a natural console and/or DEBUG port that's already attached to a PC via USB on P2-EVAL or a PropPlug on many other boards.
As soon as I add any debug I typically need to remove the console code and that can be a PITA if it's for the user interface. If a DEBUG console allowed reverse comms back into the P2 it might be possible to use that instead.
Use the compiler option
-ginstead of-gbrk. Then Spin debug()s get converted to printf()s and can coexist. Or at least can coexist with the C libs.Just some thoughts about this.
I now this, but when the debugger ist startet and the Interrupt routines not use COG-RAM $00-$0f, the interrupts maybe can be reenabled for the serial output the debug data.
Hi Chip,
one question for the new flash-image saving.
Is there any CRC or Checksum over the File.flash to check the integrity of the File before flash it to $000000?