 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 4 of 4 |
|||||
| Author | Message | ||||
| EDNEDN Senior Member  Joined: 18/02/2023 Location: United StatesPosts: 225 |
To be honest, I haven't done any performance tests. It is just the published CMake build script, and the only thing different in the main execution loop is the one check of a short int against zero that happens before any statement is executed. I'm also doing the build on a Windows 11 machine as opposed to Linux but most likely the GCC compiler is generating the exact same code. What does change a lot is depending upon which flavor of the PicoMite firmware you are using different stuff that gets executed a lot is put into SRAM or executed in place from the Flash memory. There is the possibility when the executable is linked that stuff ends up in different pages and at that point the number of cache misses is going to start showing up and be noticeable in the performance numbers. If exactly matching the performance numbers between versions becomes a big deal we could put the MMDebug code at the end of the image so almost the exact same stuff is in the same cache block to minimize that difference. But that would be like trying to pick fly turds out of the pepper and just not worth the effort. |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 225 |
Volhout, I understand what you are seeing with the SETTICK function taking over the debug session and causing chaos. It isn't ideal, but I think it is very possible you could still Step and Step Over program code by clicking on the White Line #'s on the left side of the screen. What I'm thinking is clicking on those numbers sets a Break Point at that location and it is very likely the SETTICK subroutines will just get executed as they should out of sight. If you can get acceptable results doing that in your program we could probably add some kind of Interrupt Mode where the Step and Step Over buttons understand there are interrupts happening in the background and for them to use the new mode to get similar behavior. I understand clicking on the White Line #'s is more difficult than clicking on the big Red Buttons, but if you can get acceptable behavior by doing that, maybe we can come up with another scheme to handle programs with interrupt firing in the background. Can you give it a quick try and comment on how good or bad that would be? |
||||
| lizby Guru  Joined: 17/05/2016 Location: United StatesPosts: 3437 |
Yes, basically, you could reset the next-line pointer to any line which would not upset things like the return stack, for example, you couldn't reset it from within a function to outside the function. But skipping over the entire code of the function after setting a variable to the value you want the function to return would be possible. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 225 |
The way MMBasic is implemented it would be almost trivial to implement a feature like this in the debugger. Rather than setting a break point at some address in the program it would simply change the 'Instruction Pointer' to the desired place. The big problem would be making sure people actually understood the ramifications of doing that. What ever code you jumped over did -NOT- execute. With that said, there is plenty of room at the bottom of the screen to add another Red Button to do something interesting like this idea. Edited 2025-10-15 02:18 by EDNEDN |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8228 |
I'm a bit dim... I can't see the point of debugging by missing out pieces of code. I can understand a debugger that steps to the start of a function, say, then executes that function at full speed and returns to the next statement. That would be as well as the option to step through the function. However, simply missing out the function seems pointless and misleading. You don't know if that's where the bug is and the next statement or something later may depend on something being changed in that function. 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 |
It would be an extra feature for Advanced Debugging problems. Having interrupts active and constantly pulling you into the interrupt subroutines just detracts from what you want to focus on. So the idea would be to allow a person to 'Skip' the line of code that was turning on the interrupt such as SETTICK. You would 'Skip' the line of code and as long as you were not debugging something dependent on the interrupt, you wouldn't have to deal with that extra chaos. But not to worry... I'm exploring other ways to not have SETTICK timer clicks causing chaos. I think there will be an acceptable answer to that issue. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8228 |
Surely, if you don't want SETTICK to trigger you just comment it out? Either do that or always use it with a constant and temporarily set the constant to zero while debugging. The latter is handy if your SETTICK is buried in the code and your CONSTs are at the beginning (where they belong). When I was debugging control panels the first thing was always to set all the timers to max if possible, or at least something long. That way a stray timer triggering doesn't upset your circuit tracing. You can then shorten them down to zero if you want to ignore delays before putting them to where they should be set. 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 |
Yes. Some compromises exist when operating in a debugger environment. But people will like using the debugger more if they have to make less compromises. I don't know what the options are yet to deal with the SETTICK issue. But if there is something simple that makes it better, I'm willing to spend the time to make it happen. I wasn't using SETTICK, but I was using the Debugger on the WebMite demo program that reads the temperature and humidity from the DHT-22 Sensor. The interrupts were a real nuisance. So I can sympathize how bad the SETTICK problem is. It maybe that we have to document and give clear guidance about using a constant to set the timer period and that the constant should be at the very top of the program so it is easy to find and turn off if you use the debugger. The problem is there will be other compromises that have to made and if there are too many of them people just won't use the debugger. That is my motivation for running the options to the ground. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4098 |
It might be useful for the debugger to ignore ISRs i.e. allow interrupts but not step into any ISR. So, ISRs would just happen and you'd be able to debug everything else. John |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3437 |
It may not make much difference with MMBasic, where editing and restarting is easy and quick, but if you've been debugging and have found a section of code that breaks something, it can be helpful to insert a needed value, skip the problematic code, and continue debugging. I first discovered this around 1978 when recompiling code on a mainframe might put you in a 4-hour queue. Inserting a value and then an assembly language jump past the problem could give you 4 or 5 times the turnaround that other programmers were getting. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4098 |
I relate to that (in spirit at least). John |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 225 |
MMBasic has the concept of Nesting Levels. It knows how deeply For/Next loops and Do/While loops are nested. It also knows how deeply Subroutines and Functions are calling each other. One idea might be to have a button Lock the current level to be as deeply nested as the user wants to go, and to have any deeper nesting just execute at full speed until the Function or Subroutine returns. There is going to be a solution... |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 225 |
All known issues have been addressed and resolved. There are currently no known issues. MMDebug has been moved to the PicoMite V6.01.00RC3 candidate. An additional file has been added to the Documentation .ZIP file It is an MMBasic program that uses SETTICK to help illustrate the complexity of Interrupt functions and how they are currently dealt with in the debugger. The file's name is: Settick_checkout.bas I would appreciate it if people that participated in the discussion about various ways to handle the chaos caused by Interrupts can load that onto their PicoMites with the current firmware release and check it out. And of course, offer comments about anything that can be made better or is a problem for them. The program's SetTick routine bumps a counter and displays the counter in a fixed position on the screen while the main program keeps displaying other information elsewhere on the screen. It is very easy to see the SetTick interrupt is firing and doing things while the main program is also executing. And the behavior of the 'STEP', 'STEP-OVER' and 'STEP-OUT' buttons can be checked for reasonable behavior. What I did was leave 'STEP' alone. If you use 'STEP' you will execute the next line of code and very often that will be Interrupt code because usually the timer period is set faster than a person can give commands to the debugger. If you want to trace into an Interrupt function, just use the 'STEP' button. What I did was change 'STEP-OVER' to understand about the current Function and Subroutine nesting level and consider anything at a deeper level to be something that the user desires to 'STEP-OVER'. That scheme works pretty well. At least for me. But I would appreciate others doublechecking things and make sure it works in the general case. PicoMiteV6.01.00RC3D_Documentation.zip PicoMiteV6.01.00RC3D_Firmware.zip |
||||
| Page 4 of 4 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
