 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 betas
  Page 3 of 4   |
|||||
| Author | Message | ||||
| ville56 Senior Member  Joined: 08/06/2022 Location: AustriaPosts: 259 |
Hi EDNEDN, 1) can you please have a look at this code as it crashes (pico reboots) at the function call when I "STEP" through the code. Are there some restrictions I did not obey? Btw, the string size doesn't matter. Option EXPLICIT Option DEFAULT NONE Dim integer stat Dim string put_str put_str = String$(250,"~") Do stat = rb_write(put_str) Pause 100 Loop End Function rb_write(in_str As string) As integer End Function and 2) using MMCC as client, the mouse cursor is not reacting when EDITing the program. The cursor keys do work. 73 de OE1HGA, Gerald |
||||
Mixtel90 Guru  Joined: 05/10/2019 Location: United KingdomPosts: 8228 |
Have you tested that on a non-debug version of MMBasic? Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 225 |
I did! And @ville56 is absolutely correct! It was very helpful to have the failure case reduced to such a simple example! I don't know what is going off the rails... But I'll get it figured out. |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 225 |
Probably for now disabling the SETTICK or setting the period high enough you have time to execute other logic before it triggers is best. But I'll take a look at stopping the tick timers while sitting in the debugger. Do you have any thoughts on whether the SETTICK subroutine should be executed proportionally the same amount as it would with program execution without the debugger active? Or should the SETTICK subroutine logic be executed based on real time that has passed? The big rub on SETTICK is it is used for time sensitive things. But it takes time to paint the debug screen and even more time for the user to look at things and understand what is being communicated. So your thoughts on what the 'correct' thing to do would be much appreciated. Edited 2025-10-13 23:24 by EDNEDN |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5367 |
Hi EDNEDN I would not manipulate the tick. I was just looking for a way to skip execution of the settick command (as matter of fact, skip any command) while debugging. You can also imagine skipping a file access command (i.e. kill "...") so you can see what happened. In case you alter the source (commenting out) you have to keep real good track of what you changed to revert it back. When you can skip commands, you do not alter the source code. Volhout PicomiteVGA PETSCII ROBOTS |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 225 |
OK! Understood! How about we consider making Step-Over look at what is being Stepped over and stopping execution when that point is reached? If we took that approach it would be easy for people to understand that a lot of lines of code gets executed between the mouse click on Step-Over and when the user gets control back. AND... some of that logic can be the subroutine that SETTICK's point at. A user would still be able to break point inside a SETTICK's subroutine. It would just be that the subroutine isn't very noticeable within a debug session. It does all that work in the background and hidden from the user. Can you please give that a little bit of thought. Would that address what you are trying to do in your program and work well when you are 'debugging' it? |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3437 |
With some debuggers (I think VBA) you could reset the "next line" pointer. That ability could allow you to skip a problematic line or group of lines so you could continue debugging with single-step. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 225 |
Just to help people know what is going on. I currently have four things on the 'To Do' list. - Fix Volhout's function call crash. Fixing it won't be very difficult at all. It will be finding it and figuring it out that is going to take some time. - Make the Mouse Clicks behave better when leaving the debugger and doing an 'Edit' - Make SETTICK's better behaved within the debugger. There is plenty of room for user suggestions and comments on this topic! Please don't hesitate to offer an opinion! - Migrate the MMDebug beta to PicoMite V6.01.00RC0 |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 225 |
Oh? That is an interesting idea. In other words, you could jump past a particular line of code and continue execution on the other side of it? Or I guess from the words you said it would be possible to do things like just jump to near the end of a function call and not execute the normal code path? Do I understand that correctly? |
||||
| ville56 Senior Member Joined: 08/06/2022 Location: AustriaPosts: 259 |
@EDNEDN, I've further narrowed down the crash with functions issue. It only occurs if a single string or a single element of an array is passed. Whole string arrays do no harm ... as well as float and integer are no problem, be it single elements or arrays. 73 de OE1HGA, Gerald |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 225 |
OK!!! That is super helpful information. That will speed up the resolution. THANK YOU! |
||||
| ville56 Senior Member Joined: 08/06/2022 Location: AustriaPosts: 259 |
just a thought on debugging interrupts: coud it be feasable to selectively disable/reenable interrupts and maybe manually trigger them additionally. This would allow the user to decide which interrups should be processed and manually trigger an disabled interrupt. I understand that this would require more interaction with the debugger. But maybe the default is all enabled. I cannot judge how complicated this would be to implement. The user interface would certainly be more of a challenge as there is a long list of interrupts that can be used. Maybe a more command-line oriented way to set this could be helpful.... only my five cents .... 73 de OE1HGA, Gerald |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 225 |
I like this idea. It would be a lot of work to implement. Let's think about this some more and what exactly the user interface would be. The big problem with interrupts is they are very important to the program's execution logic. They are there to do very real things that are needed by the program. But in a debugger environment they are often times just causing chaos. So being able to turn them off would stop that side of the chaos. And letting them execute occasionally under the user's control would in many cases give the program logic the updates it needs to properly execute. |
||||
| ville56 Senior Member Joined: 08/06/2022 Location: AustriaPosts: 259 |
Certainly the user interface, maybe the logic in the debugger is less demanding if kept simple enable/disable logic. Manual triggering is something to consider, as the invocation of an ISR under user control is also relevant for debugging. But of course the ISR can be debugged independently and then integrated as "known good". I think implementing enable/disable as first step could be already a big step. And then there is still the discussion about the granularity of the enable/disable. E.g. pin interrupts generally or down to a single pin, timer interrupts generally or down to a single timer, .... I'm just bringing into the discussion what I've seen with a different debugger (MCS Basic,a compiler with a simulator/debugger) and the issues are similar, of course. Edited 2025-10-14 02:02 by ville56 73 de OE1HGA, Gerald |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4098 |
Debuggers fairly often allow GO FROM (location) or of course RUN FROM ... CONTINUE FROM is alternative syntax I suppose. Debugging an ISR? I wouldn't worry about it much - they should be very short and simple which dramatically reduces any need to debug them. John |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 225 |
That is a good point. |
||||
karlelch Senior Member Joined: 30/10/2014 Location: GermanyPosts: 273 |
Hi EDNEDN, I did not have much time to test the newest version but here is the feadback so far: 1) Xmodem works now without any trouble - thanks! 2) OPTION DISK LOAD only works if the options were saved with the same firmware version - I guess this is normal. When I tried to load options from a file generated by an earlier (non debug) version, it failed w/o error - the safed options simply were not restored. 3) Similar for LIBRARY DISK LOAD - it works when using a file created with the same firmware version (including the debug version). I tried to load a library file created with a different (non debug) firmware and the Pico 2 ended up in a boot loop. 4) I use libraries and at first glance, the debugger steps correctly in and out. 5) I noticed that with a full FOR loop in a single line, the debugger cannot step out of it. This is not a big deal but something to be aware of. Points 2) and 3) are observations - I have not systematically checked if this happens with all firmware version combinations. But these issues are probably to be expected across different iterations of the release version. Best Thomas |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 225 |
Step-Out only applies to nested functions and subroutines. (And the special case of being in library initialization code) With that said, I would expect Step-Over to work on a single line For/Next loop. But it is currently setup to step over the entire line of logic without really paying attention to the fact there is a For/Next loop there. Step-Out makes use of the Function/Subroutine depth count (which is displayed on the lower right of the debug window). A single line For/Next loop isn't going to change the Function/Subroutine depth count unless you are calling functions from the inside of the loop. And in that case, I would expect the Step-Out to return you to the middle of the line somewhere. Step-Out should generate an Error message on the bottom line if you try to Step-Out and you are not nested inside a function or subroutine. Edited 2025-10-14 07:01 by EDNEDN |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2786 |
My understanding is the library is tokenized and tokens for commands etc. can change between firmware versions. LIBRARY LIST will display de-tokenized code that you can compare with the original source code. You may see some commands are not what they were. Perhaps a similar thing happens with Option Disk Save / Load. |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1581 |
Just a quick test. I have MATH PID running @1KHz and in the main program, I increment "cntr" variable, using the slower cntr=cntr+1 MATH PID ISR also increments a variable and stops at 1000 (1 second) I then print the cntr variable to see how many increments happened: Standard firmware: 115380 Debug firmware: 109260 My earlier standard firmware was ~107000 so something has sped-up recently. cpuspeed 378000 KHz |
||||
| Page 3 of 4 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
