 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 : How Do You De-bug Programs?
| Author | Message | ||||
| Andrew_G Guru  Joined: 18/10/2016 Location: AustraliaPosts: 871 |
Hi all, As I am completely self-taught at programming and electronics I sometimes need to ask simple/silly questions, knowing that the answers may not always be simple: 1) How do you de-bug programs? 2) Can you suggest any good reading / sources of ideas? I manage by checking my logic, inserting print statements at strategic locations End-ing programs and printing variables in direct mode. I don't use any features within MM or MMEdit (because I don't know what is there). Thanks, Andrew (I'm using my iPad via a phone until I get back to civilisation in a few days - A ) |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
I start with a pencil and paper to write the overall flow of the program. It is still the best way to end up with something that resembles what you started out to achieve. Plenty of PRINT statements throughout the program helps. If you do use MMEdit there are a few aids. Format - indents the code to make it easier to see incomplete loops. Variable report lists things like variables that only appear once - likely to be a spelling mistake. Jim VK7JH MMedit |
||||
| Alastair Senior Member  Joined: 03/04/2017 Location: AustraliaPosts: 161 |
For home projects I used to do as Jim suggests and map the program flow on pencil and paper. After many projects I find that once I start coding and testing the design changes as the realities of making things work strikes home. I now have a number of standard approaches which I find one matches well a new project and I tend to use the bones of a previous project as a starting point. Your specific question re debugging is difficult because it depends a lot on what you are doing. Realtime data capture and processing is quite different to display and control. My suggestion is for you as a beginner is to not try and write large chunks of code and then try and make it work. Write small chunks to get a particular thing going and then build it up from there. It is much easier to debug a simple routine than a complex program with interrupts that can and do interact. I find that using the print and debug in Mmedit are 2 things I use a lot. Also I would recommend using OPTION EXPLICIT as this tends to force you to get variable names and types correct. Without this you can have a simple spelling error being hard to spot and causing chaos. As Jim says the Variable report is helpful and exposes things you did not mean to create. Personally I find reading code written by others not helpful except for how they made some thing work. I have developed my own style, which you will, and find others have their own which is very different to me. I generally use one main DO... LOOP to run the program and then using subroutines to carry out a specific action. These are called either by interrupts, timers or logic statements within the LOOP. Having this sort of structure helps debugging a lot as you can use print statements to see what is getting called in what sequence. Just some thoughts based on how my aging brain works. Cheers, Alastair |
||||
| Andrew_G Guru Joined: 18/10/2016 Location: AustraliaPosts: 871 |
Jim and Alastair, Many thanks - some good suggestions. I've also just re-downloaded the MMEdit manual (to my iPad) to make sure I'm getting the most out of it. I can also start to look at Trace in MMBASIC. Cheers, Andrew |
||||
| greybeard Senior Member Joined: 04/01/2010 Location: AustraliaPosts: 174 |
I tend to pseudo code what I'm hoping to do, use that as comments and code from thaat. As far as debugging goes it depends on the hardware, anything from flashing an LED, CRO, print or serial o/p if available. The other big help I've found is walking through your code and explaining it to someone else as you go. That usually makes the defects glaringly obvious. If you can't find someone else I explain it to the brick wall I've been banging my head on.  |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
I often also use "Print XX", where XX with XX being NOT defined. Simple way to see if a given area of code is being executed. Other bonus is you can then Print the real variables at the time the code is forced to crash. Phil. |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Professionally you would use a programming language that has a programming environment that allows for single stepping through your code. Also adding watches to display contents of variables. Breakpoints to stop execution at certain points so you do not need to single step through all the code, just the parts you expect the bug to be. It is very efficient. Microblocks. Build with logic. |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
The most important thing is knowing where you are in your program when the weird stuff starts happening. I developed this approach for myself but everyone will have different requirements. my 2p |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
