 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
| Author | Message | ||||
| EDNEDN Senior Member  Joined: 18/02/2023 Location: United StatesPosts: 185 |
Attached are the first betas of the PicoMite V6.01.00D firmware. This firmware is 100% compatible with PicoMite V6.01.00b18. The difference is it has MMDebug waiting to wake up and help you with your debugging needs. The 'D' suffix means a particular release has the same functionality as the non-'D' release except it also has MMDebug available to the user. The goal is to work through all the kinks and corner cases and have those resolved such that when the final version of PicoMite V6.01.00 is released, the PicoMite V6.01.00D version can follow quickly. All 12 permutations of the PicoMite firmware are in the attached .ZIP files. There is also a 'Quick Start Guide', a Cheat Sheet, a '10 Minute Tutorial', and the MMBasic program for use in the 10 Minute Tutorial. I was unable to upload the files within a single .ZIP file. So the upload was done in two parts. The first .ZIP file has the well tested and known working firmware versions. RP2040-PicoMite, the RP2350-PicoMite, the RP2040-WebMite and the RP2350-WebMite are all extensively tested. They are solid. The second .ZIP file has the less tested USB, VGA and HDMI versions of the firmware. The vanilla VGA and HDMI releases appear to work but do not have extended test time on them. The USB versions of the VGA and HDMI firmware are less certain. If you load up these versions please post what your results are. Please note: You need a VT100 terminal attached as the console to use the debugger. You need to be able to type commands on your keyboard and have the PicoMite respond to your VT100 terminal. Known_Working_PicoMiteV6.01.00b18D.zip Less_Tested_PicoMiteV6.01.00b18D.zip Edited 2025-10-09 09:06 by EDNEDN |
||||
| lizby Guru  Joined: 17/05/2016 Location: United StatesPosts: 3428 |
This is a super contribution. I started something similar nearly 5 years ago in covid times, but with MMBasic for DOS--it required only a few lines in the source code to make a hook for the debugger. I also had VT100 output. The PicoMite is a much more useful platform. I had several large programs which needed the debugger, but they are now pushed so far back on my to-do list that I'm not sure I will ever return to them. Could you post a video of the debugger in action? PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 185 |
That is probably the next thing to do. It will not be very difficult to move this code to the MMBasic for DOS version. That is a good idea. In the meantime, if you load up the 10 Minute Tutorial it will let a person see all of the important features the debugger provides as it steps through the sample program. And the 'Cheat Sheet' does let a person see what it looks like and how to do various things within the debugger. Edited 2025-10-09 10:36 by EDNEDN |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5326 |
Hi EDNEDN, This is super !!!. I find it amazing you have integrated this in MMBasic. Really useful. I immediatly installed the code on a bare 2040 pico and started playing with it on my Ubuntu Linux system running Putty. And I found some issues.. 1/ Putty did not adapt to 45x145 screen format as in option list. But manually I could set it to 45x145. This may not be something you can fix. It may be Putty. 2/ After I tried modifying a variable value, it was not obvious how to exit the window. ... until I simply clicked outside the variable edit window. 3/ Variable names are shown in upper case (may be confusing if you have names like "ThisVariableIsAnInteger". What is good is that it shows the type. Basic can be confusing in that (option default not set) and the debugger helps you with that. 4/ When you quit the debugger, there is a "[M#=" string sent, that Putty shows at the command line. 5/When you debug a program with many variables the debug window becomes blanked. This is a real bug (actually, the only one found so far). I have attached a zip that shows the behavior in 5/ if you simply step through it. I really see this as a great tool. It may need a lot more testing, and I am very curious if the debugger uses a lot of RAM memory (especially important in the VGA version since these are most critical on RAM usage .. there is only little left if you add framebuffers). EDNEDN This is really great. I am very enthusiastic about it.. fm_vt100_noVGA_02031_bf.zip Regards, Volhout Edited 2025-10-09 19:25 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 185 |
Thank You for spending the time to check it out and write up the issues you found! And I found some issues.. 1/ Putty did not adapt to 45x145 screen format as in option list. But manually I could i set it to 45x145. This may not be something you can fix. It may be Putty. Putty seems to think it is best for the user to set the screen size via the properties page for the program. The 'official' VT100 Escape Sequence to set the screen size to 45 x 145 is: ESC [ 8 ; 45 ; 145 t It is strange it won't honor that given it respects all the other Escape Sequences. It would be very interesting to know if the TeraTerm for Linux supports the automatic screen size changes. I suspect TeraTerm will, but I don't know that. And for that matter, I wonder if MMCC for Linux will automatically support the screen size change. It does on Windows. 2/ After I tried modifying a variable value, it was not obvious how to exit the window. ... until I simply clicked outside the variable edit window. The planned and designed method to close out and leave the 'Edit Value' command box is to give it an 'Enter' key with nothing else at the command prompt. Depending on what happened with the last command that was given, that can be a single 'Enter' or it might be three 'Enter' keys in a row. I understand that is a little cryptic at first. But I am open to suggestions and once a person gets trained to just hit a blank 'Enter' command it is pretty quick and natural. Perhaps making a Mouse Click anywhere outside the 'Edit Value' box to 'unfocus' and remove the box is the right way to handle that? Or perhaps, recognizing either a blank 'Enter' or Mouse Click outside the box would make more sense? I'm more than willing to alter this behaviour. Let's get some more discussion and figure out what the community gravitates towards as the 'answer'. 3/ Variable names are shown in upper case (may be confusing if you have names like "ThisVariableIsAnInteger". What is good is that it shows the type. Basic can be confusing in that (option default not set) and the debugger helps you with that. Yes... I agree with your thoughts on this. The reason it is like this is MMBasic capitalizes all variables that it adds to its list. It would be almost trivial to keep the variable's name around in a list exactly as it was first encountered in the program. The problem with doing this is each variable can be up to 32 characters long and with a list of up to 20 variables in the 'Watch List' that burns an extra 640 bytes of SRAM. MMDebug was designed and written to have as minimal impact on SRAM as possible and keeping the original case of the variable's name around seemed a little bit too expensive. Incidently... One thing that can be added to a future version of MMDebug is the ability to malloc() and free() its local SRAM usage. If you never activate MMDebug, it would only have a pointer to its storage and that pointer would be NULL. That is probably worth the editing to do just so it has as light of touch on the MMBasic environment as possible. 4/ When you quit the debugger, there is a "[M#=" string sent, that Putty shows at the command line. Mouse Clicks are kind of a Linux add on to the VT100 specification. The original VT100's did not have Mouse Clicks. As a result, Mouse Clicks have been kind of implemented in different rogue ways. Some terminal programs respond with a Mouse Click Down and a Mouse Click Up. To make matters worse, I really wanted both TeraTerm and MMCC (MMEdit's companion) to work. MMCC has a buggy implementation of Mouse Clicks and reports Mouse Click Up when in fact it is a Mouse Click Down. Anyway... What you are seeing is a 'Mouse Click Up' being sent after MMDebug has already exited. If it is too annoying, the exit of the debugger could be delayed until the Mouse Click Up gets ate by the code. Once again... It would be interesting to know what the Linux version of MMCC and TeraTerm do. It would be good to find a complete solution that handles all cases. 5/When you debug a program with many variables the debug window becomes blanked. This is a real bug (actually, the only one found so far). I have attached a zip that shows the behavior in 5/ if you simply step through it. I'll load that up and see what you are seeing. I see that @matherp has released yet another beta. I'll get the debugger moved over to PicoMiteV6.01.00b19 and fixing this bug will be at the top of the list. And I'll post a PicoMiteV6.01.00b19D with this bug fixed. I really see this as a great tool. It may need a lot more testing, and I am very curious if the debugger uses a lot of RAM memory (especially important in the VGA version since these are most critical on RAM usage .. there is only little left if you add framebuffers). EDNEDN This is really great. I am very enthusiastic about it.. Thank You. The debugger was written to minimize system resources. It has a very light memory footprint. Its memory footprint is the same regardless of which version of the PicoMite firmware you are using. And shrinking its SRAM footprint down to a single NULL pointer when the debugger is not being used is on the list of things to do. There are other ways to reclaim some memory. I haven't pushed hard in that direction yet just because I am making a very conscious effort to be 100% compatible with the base level PicoMite firmware. But some of the easy things that can be done is reclaiming arrays that are 'Const' but sitting in SRam. The keyboard handlers have a lot of this. And I'm of the opinion nobody can type fast enough that having those tables in SRAM is noticable. Edited 2025-10-10 00:10 by EDNEDN |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5326 |
Hi EDNEDN, Refer to above 1/ MMCC changes to 45x145 on Linux. It is just Putty that doesn't with the configuration I have in it. Maybe I can make Putty do it by changing translation. 2/ I like closing the variable edit window with mouse click. I only did not know until I tried. 3/ Understood. It is okay the way it is implemented. Don't waste RAM on it. 4/ Understood. In this case I would wait for the mouse-up to close the debugger. That is behaviour that I see more often, and it allows to "re-think" (you can move the mouse while the button is pressed, away from the focus, thereby avoiding the action that you half way started). 5/ When you would make memory requirements zero when the debugger is not used, that would be great. Then even the most memory demanding applications would still run unaltered. Peter might even adopt the debugger for all versions as a feature (when you agree, it is your IP after all). Volhout PicomiteVGA PETSCII ROBOTS |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 185 |
2/ I like closing the variable edit window with mouse click. I only did not know until I tried. OK. I'll figure out how to make that 'official' and always cleanly exit the window. 4/ Understood. In this case I would wait for the mouse-up to close the debugger. That is behavior that I see more often, and it allows to "re-think" (you can move the mouse while the button is pressed, away from the focus, thereby avoiding the action that you half way started). MMCC only does a single Mouse Click, so that complicates things. But 'Quit' is kind of a unique function. It might be acceptable to have a 250 ms. pause to eat characters there. I'll try to figure something out. 5/ When you would make memory requirements zero when the debugger is not used, that would be great. Then even the most memory demanding applications would still run unaltered. Peter might even adopt the debugger for all versions as a feature (when you agree, it is your IP after all). It would be best for the community to have the debugger as an integrated part of MMBasic. I'm fully in support of this. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10462 |
Definitely would be happy to once it is stable and as long as the various hooks don't impact performance |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 185 |
There is almost zero performance impact. A single check of a short integer against zero value is done at the top of the ExecuteProgram() function in MMBasic.c while(1) { if(*p == 0) p++; // step over the zero byte marking the beginning of a new element if ( MMDebug ) // Fastest way to confirm debugger is not needed and // // let BASIC program continue on its way. As far as 'stability' goes... It is very stable and solid right now. And I'll iron out all the little quirks that show up like Putty Mouse Clicks showing up when you Quit the debugger. I'll deal with all of Volhout's (and anybody elses) promptly. How about we consider dedicating the PicoMite V6.02.00 version to supporting an embedded debugger? As you work through the Release process for V6.01.00 you will get to see the V6.01.00D version track it faithfully and any issue that comes up gets dealt with and resolved immediately? Edited 2025-10-10 01:08 by EDNEDN |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1576 |
Presumably not compatible with interrupts? |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 185 |
It is not really possible to break point inside some interrupt handlers. For example, the little demo program for the WebMites has a Sub WebInterrupt function. You can break point inside that. But it is almost impossible to keep the TCP/IP stack happy because it times out on the response. Debugging interrupts requires extra effort to work around the time constraints of what ever the interrupt is dealing with. |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1576 |
Sorry, I wasn't clear enough; Inside the ISR is not an issue, I was imagining the ISRs not happening at all(?) Ideally, I'd like my MATH PID ISR to run whilst debugging the main code. |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 185 |
Yes... That is all fine. It is just setting break points inside an ISR drastically affects the timing of whatever the ISR is supporting. So you need to be aware of that when you do that. And infact... Even if you can't continue the normal program logic once the ISR finishes because the other software stacks (that caused the ISR) have timed out, it is still possible in most cases to single step much of the ISR and see what is happening. I was single stepping much of the Sub WebInterrupt ISR function in the WebMite demo program. |
||||
| AlbertR Regular Member  Joined: 29/05/2025 Location: GermanyPosts: 46 |
Hi EDNEDN, Great work,  I'm also impressed by how it's implemented in the terminal. Until now, I've always used “printf” debugging and also tried using ‘stop’ as a breakpoint and “continue.” But that only works in the main program. Also, only global variables can be “printed.” So, everything's great for me! I had never dreamed that this would be possible in MMBasic. You already evaluate keys for changing the width and height, maybe you could also add a key for “step”. With the mouse, I think you have to concentrate more on hitting the button, but with the key, you can just leave your finger over it. What is the preferred transfer method for the programs? Up to now I used XMODEM, but I had problems with the debug version. The progress stopped after 512 Bytes  Albert |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1576 |
 Excited (again  ) |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 185 |
Ultimately, we probably need a full manual. But in the 'Cheat Sheet' it says:  I typically use MMEdit (and MMCC) to get stuff moved onto the Pico's. If you load the MMBasic program into MMEdit, you can just click the transfer button to move it. But MMCC is a little buggy on the transfers. It does lockup sometimes. The other thing you can do is use TeraTerm and from the MMBasic command prompt say > Edit At that point you can cut and paste MMBasic programs. But you need to tell TeraTerm to 'Paste things slowly' with line delays. Edited 2025-10-10 05:27 by EDNEDN |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
