Electronics > Microcontrollers

how do you debug the code?

<< < (30/32) > >>

tellurium:

--- Quote from: dunkemhigh on July 04, 2022, 01:38:41 pm ---Can be, but it can also be very satisfying - there is to ego boost of having fixed an issue but without the guilty conscience of having written the bug in the first place :)

--- End quote ---

Provided you didn't implant a few more, along with a fix :)

Mechatrommer:
sometime its not a bug, its just that the original code doesnt work the way i want it but surely works for others. or sometime i just want to know how did they do it, how much memory is going to involve etc. the last time i did it on marlin code for 3d printer. interactive debugger isnt available in that retarded arduino ide so i have to do it by pencil and paper. otoh the funniest thing to me is that every program that i've made (for my own), and i mean every single one of them, when i want to upgrade later in like 3-10 years time is going to be like someone else's code, so i have to retrace and upgrade the code like one... so at some point of time ago, i know how much important the commenting is...

gnuarm:

--- Quote from: pcprogrammer on June 28, 2022, 03:17:05 pm ---
--- Quote from: gnuarm on June 28, 2022, 02:29:16 pm ---Know I not backwards thinking it is.  Actually, many people object to the one tiny bit of syntax it has, Reverse Polish Notation, RPN.  That is not entirely accurate, really.  The interpreter simply interprets a word at a time, rather than waiting for a line to be digested and turned into machine code.  So the operands are normally first. 

That's not always the case.  A string is created with a word S" which then scans the input for the next quote marking the end of the text.  Many words that create words, look for their input after the word. 

Or did you mean backwards in the Appalachian back woods sense?  I prefer a simple tool.  I'm not designing systems with 27 interrupt priorities.  I design systems to get the job done while making the software easy to debug.  I'd much rather use a screwdriver or hammer, than a pneumatic fastener tool.

--- End quote ---

I was hinting to the RPN way of how it operates.

Agree with you that a simple tool to do a simple job is the way to go. Always choose the right tool for the job, but sometimes you have to use what is at hand and try to make the best of it. For example if all you have is a knife and you need to strip a wire and screw it into a terminal it can be done with just the knife.

--- End quote ---

Yes, I much prefer to solve simple problems rather than complex problems.  That's why I try to create only simple problems.  I create designs without complex problems and are only left with simple problems.

Even simple problems can be hard to find if your methods are complex.  So simple debug methods are also preferred.

MikeK:
I usually use very simple methods of debugging, like turning on an LED.  But I also made a simple version of this a while ago.

nigelwright7557:
You can write loads of code then set about debugging it.
Set breakpoints and create watch variables to see what is happening.
LED's on output pins and use of an oscilloscope if timings are important.

I tend to use incremental debugging.
I write a small module of code then fully debug it before going onto next part.
Its much easier to debug a small piece of code.

Navigation

[0] Message Index

[#] Next page

[*] Previous page