 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : PicoMite V6.01.00D release candidates
  Page 2 of 3   |
|||||
| Author | Message | ||||
| ville56 Senior Member  Joined: 08/06/2022 Location: AustriaPosts: 290 |
Tried the updated verison and it works for me. Also EDIT now works with the pg up/dn keys as expected. Many thanks, great job! Gerald 73 de OE1HGA, Gerald |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 265 |
Thanks for the feedback!!! Things are pretty stabile right now. If there are any suggestions please voice them here. For example, Is the initial screen size of the Debugger good? The user can adjust it bigger or smaller in either the X or Y direction. But is the initial size a good choice? Is the placement of the Menu Buttons at the bottom ideal or are there reasons things should be moved around? Both Left and Right Mouse Clicks (and both Down and Up) are now available in MMCC and Terra Term. Are there some other features that are desirable that can be done with the 'Extra' click-ability ? I have two things on my 'To Do' list. I can shrink the amount of SRAM used to less than zero if the Debugger is never used (or the Quit button is used to exit it). MMDebug would malloc() the memory it needs but not do that unless it is actually activated by the user. That helps people that have fully consumed their PicoMite's resources. The other thing that I want to do is add the ability to Break Point on an arbitrary user entered expression becoming true. The one big problem with doing this feature is the expression would be evaluated for every statement and the execution speed would be noticeably slower (when the feature is actually in use). Probably the answer to that concern is "If it hurts too much, don't do it!" It would be a very powerful debugging feature to be able to say things like Break Point when "some_variable < sqr(xyz / 3) AND i >= 27" |
||||
| bfwolf Regular Member  Joined: 03/01/2025 Location: GermanyPosts: 87 |
I think, this would be to complicated and decrease speed too much!  What would be sufficient, would be the ability to set "data watchpoints" on variables - optional even on reads and when on writes perhaps combined with a constant value and optional combined with a bit-mask. This would't give so much speed-penalty.  An other idea: How about swapping away the "debug window" by a "hot-key" to see, what program-output in the console is behind? Or is this already possible?  Many thanks for your excellent work!  Regards |
||||
| lizby Guru  Joined: 17/05/2016 Location: United StatesPosts: 3481 |
A perhaps less costly why to do that is through a variable watch. If a watched variable equals, or is less than, or is greater than a user-given value, then you break. For that case, you only have to check when a watched variable changes, and you're already having the expense of watching the variable. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 265 |
One thing I considered doing was capturing the screen and saving it prior to over writing the upper right corner of the screen with the Debug window. The problem with doing that is both speed and memory. It would be possible to save the entire user's screen but it would take a huge amount of back and forth chit-chat with the terminal program to do that. It maybe there are alternatives. MMCC is much slower than Tera Term. So for long debug sessions with lots of Stepping, Tera Term is better. One simple thing we could do in MMCC (if we twist Jim's arm a little bit) is to honor an ESC Sequence that saves the current screen locally in the MMCC's program memory. And then another short ESC Sequence to restore the entire screen when the debugger gives control back to the user's program. Or for that matter, maybe it would be easier for MMCC to just open up a 2nd window that the debugger uses for its output. Something like this would make MMCC more desirable than Tera Term for long debug sessions. |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 265 |
This would be almost trivial to do. And if done for one watch variable, the same logic could be applied to more than one. Let me think about this for a day or two. |
||||
| bfwolf Regular Member Joined: 03/01/2025 Location: GermanyPosts: 87 |
Don't know much the internals of the variable-handling if MMBasic: Perhaps there are "some bits" free/unused in the maintaining structure, which could be used as an index to a watchpount table and as a flag "watched" if index!=0 or something like that? This could be used to trap the variable-search when a variable is used in an expression. I think it wouldn't be a too great a restriction, to limit the count of allowed watchpoints. Even the cortex-core doesn't offer unlimited.. BTW: Couldn't the Cortex-Debug be used?? |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 265 |
@lizby Do you have any thoughts on how the user would indicate that and give the data to the debugger? (I have some ideas for this part of it but would like to hear other people's ideas!) The bigger and more important question is how would this information be displayed in the debugger? The most obvious way would be to add a 3rd and 4th column to the watch window to display the entered 'less than' or 'greater than or equal' or 'not equal' along with the value. But this adds a lot of bulk and size to the window for something that would be rarely used. One idea might be to have the comparison information for a variable or two to grow from the bottom of the window (just above the Line Up / Page Up buttons) towards the unchanged variable watch area. The problem with doing this is the variable's information would be split between two lines. One up above in the watch area and one below in the 'active comparison' area below. |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 265 |
@bfwolf I've been thinking about the possibility of using the actual built in debug registers for the Cortex. This is an interesting idea. One problem with doing this is they are going to trigger at the machine level. What I mean by this is the MMBasic interpreter might be executing a 'Let' statement that sets the variable to a value that triggers the Break Point. We could set up the code such that it triggers the Cortex debug registers. But the problem is this would be in the 'middle' of a MMBasic's execution of the BASIC statement. The BASIC statement isn't done 'Executing'. It isn't a clean point in execution sequence. There is the other problem that from a 'reliability' perspective setting up interrupts (using the Debug registers) that cut into the middle of MMBasic's execution is much more difficult to do in a way that everybody believes is 'correct' and not causing any problems. Currently MMDebug's operation is almost entirely isolated from MMBasic's operation. If there is a bug it is very clear which side of the fence it is on. The way this is accomplished is a single unsigned short is checked against zero just before each BASIC statement is 'executed'. There are not magical Cortex debug interrupt routines firing and doing things during the middle of the BASIC statements execution. |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3481 |
This seems a wise way to do the hook. Is there a way in code to turn the debugger on and off, e.g., mm.debug=1 or mm.debug=0? Or do you rely on something like "run" vs "run to breakpoint". PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 265 |
Yes, just as you can set > Option Break 3 you can do > Option Debug 4 And the logic in the keyboard interrupt handler understands that if the user has done > Option Debug 0 that means the debugger is never supposed to be activated. (just like how the Break key is handled.) Here is the complete logic used by MMDebug to hook into MMBasic. There is also 3 lines of code in the keyboard interrupt handler that sets the DBG_BREAK bit of the MMDebug unsigned short to activate the debugger. The other bits in MMDebug are used by the debugger to control more specific actions. (For example, keeping an eye on a watch variable to see if it changed). But it is easy even at a novice level to see that if MMDebug stays at a zero value, it is having no effect on the normal, approved and tested operation of MMBasic. And the only way for the MMDebug variable to leave the zero value state is via the 3 lines of code in the keyboard handler where it checks for Ctrl-C or Ctrl-D. The hook is deliberately done in such a way everybody can have confidence that if you don't activate the debugger, it isn't impacting the logic of MMBasic. I chopped off some comments so the lines wouldn't wrap and mess up the code block. void __not_in_flash_func(ExecuteProgram)(unsigned char *p) { int i, SaveLocalIndex = 0; jmp_buf SaveErrNext; memcpy(SaveErrNext, ErrNext, sizeof(jmp_buf)); skipspace(p); while(1) { if(*p == 0) p++; // Start of MMDebug hook if ( MMDebug ) // Fastest way to confirm debugger is not needed and let BASIC program continue // // on its way. if ( p < (unsigned char *) 0x20000000 ) // make sure we are in the user's code. // either library or main program if (( MMDebug & DBG_BREAK) || // If we get to here, the debugger is needed (((MMDebug & DBG_STEP)) && (MMDebug_Level_Change >= gosubindex)) || ( MMDebug & DBG_WATCH_ACTIVE) || // ( MMDebug & DBG_EXPRESSION_ACTIVE) || // Soon!!! But not yet! (( MMDebug & DBG_BREAK_PNT_SET) && MMDebug_Brk_Pnt_Addr==p) || (( MMDebug & DBG_BREAK_PNT_SET) && MMDebug_Brk_Pnt_Addr==p-1 && *p==T_LINENBR) || (( MMDebug & DBG_STEP_OUT) && (MMDebug_Level_Change >= gosubindex))) { if ( ( MMDebug & DBG_WATCH_ACTIVE) ) { if ( Debugger_var_value_has_changed( MMDebug_watched_var.index) ) { WDTimer = 0; // turn off the watchdog timer ShowCursor(true); p = Debugger( p ); if ( *p == 0) p++; } } else { WDTimer = 0; // turn off the watchdog timer ShowCursor(true); p = Debugger( p ); } } // End of MMDebug hook if (*p == 0) p++; // step over the zero byte marking the beginning of a new element Edited 2025-11-01 05:17 by EDNEDN |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3481 |
Nice. Thanks for the explanation. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 265 |
You know??? I was asking what other nice features could be added? Check out: https://www.thebackshed.com/forum/ViewTopic.php?FID=16&TID=18353&LastEntry=Y#246445#246445 Would it make sense for MMDebug to hook the watchdog timer? If the user could drop into the debugger when the watchdog timer fired, at least they could poke around and get a clue what was going on??? |
||||
mclout999 Guru Joined: 05/07/2020 Location: United StatesPosts: 492 |
clikable link for above They call me Shai-Hulud (The maker) |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 265 |
MMDebug can now capture Watchdog Timeouts. And of course, you can see where the program was executing and inspect variable values when the Watchdog triggered. You can also continue execution with Step, Step-Out and Step-Over commands. It can't tell you why your program failed to reset the Watchdog timer. But by knowing where it happened and having the ability to inspect variable values, you are halfway to figuring that out. The source to PicoMite-v6.01.00RC9 is not published yet. So this is based on PicoMite-v6.01.00RC8. Included in the Documentation .ZIP file is a program called watchdog_test.bas. You can use this to checkout the new functionality. - Load the firmware onto the PicoMite. - Load the watchdog_test.bas program onto the PicoMite - Type Run ctrl-D - Click the new Watch-Dog button on the lower part of the screen to authorize the debugger to capture Watchdog Timeouts. - Click the Go button to start program execution. - Press any key on the keyboard to increase the loop count the program is doing between Watchdog timer resets - At a loop count of about 30 on an RP2040 you will trigger a Watchdog timeout. - Use the debugger to examine why the timeout happened. PicoMite-v6.01.00RC8D---Documentation.zip PicoMiteV6.01.00RC8D---Firmware.zip Edited 2025-11-03 08:26 by EDNEDN |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 265 |
MMDebug based on the savory PicoMite_v6.01.00RC10 release. There are currently no known issues with MMDebug. PicoMite-v6.01.00RC10D---Documentation.zip PicoMite-v6.01.00RC10D---Firmware.zip . Edited 2025-11-06 03:34 by EDNEDN |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 265 |
MMDebug based on the PicoMite_v6.01.00RC11 release. Significant changes to MMDebug! MMDebug now only uses a handful of bytes of SRAM unless it is activated. And MMDebug gives back any memory it has allocated and used when the program quits or the user tells MMDebug to Quit. It is very possible the move to reduce the Debugger's use of SRAM memory to almost zero might have caused some issue I haven't found yet. But so far, I don't know about any new issue. So, for right now... There are no known issues with the PicoMite_v6.01.00RC11D release! PicoMite-v6.01.00RC11D---Documentation.zip PicoMite-v6.01.00RC11D---Firmware.zip . |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 265 |
PicoMite_v6.01.00RC12D with Turtle Graphics! Would it make sense to setup his workstation with PicoMite-v6.01.00RC12D so he can Single-Step his turtle() movements? You would get to see firsthand the debugger is solid, stabile, and very helpful. PicoMite-v6.01.00RC11D---Documentation.zip PicoMite-v6.01.00RC11D---Firmware.zip . |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 265 |
PicoMite_v6.01.00RC17D uses less than zero SRAM if not activated. It also gives back any used memory when the user Quits the debugger or the user's program ends. There are currently no known issues with the debugger. PicoMite_v6.01.00RC17---Documentation.zip PicoMiteV6.01.00RC17D---Firmware.zip . |
||||
| ville56 Senior Member Joined: 08/06/2022 Location: AustriaPosts: 290 |
EDNEDN, many thanks for providing us with an updated version of MMDebug. I have a question: got the message "Options were not correctly set for MMDebug. That is fixed now". What options are this and were set to which value? environment is: PicoMiteHDMI MMBasic USB RP2350B Edition V6.01.00RC17D OPTION SERIAL CONSOLE COM2,GP20,GP21 OPTION FLASH SIZE 16777216 OPTION COLOURCODE ON OPTION KEYBOARD GR OPTION PICO OFF OPTION RESOLUTION 640x480 @ 252000KHz OPTION HDMI PINS 1, 3, 7, 5 OPTION SDCARD GP22, GP6, GP7, GP4 OPTION AUDIO GP26,GP27', ON PWM CHANNEL 5 OPTION MODBUFF ENABLE 192 OPTION PLATFORM OLIMEX USB btw, had to nuke the pico to change from RC17 to RC17D to be able to edit and save a program. Otherwise I got an error erasing the flash when saving. Gerald 73 de OE1HGA, Gerald |
||||
| Page 2 of 3 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
