The long awaited ARTIK 5 is now on sale!
The long awaited ARTIK 5 is now on sale!
ah, c’mon… java and groovy aren’t that bad.
You’ll note that the Arduino IDE was first on the list. Not one of my favourites either. If it had real time debugging then it would rate quite well as I like C/C++ anyway.
I never did see how you could call Arduino a teaching tool for programming, when printf debugging was all you have. The ability to examine your program while it is running is one of the best ways to understand what’s going on in there. Arduino IDE maybe quick and simple to install, but just throwing code over the wall to the MCU is hardly the way to teach programming.
Anyway, just a pet peeve - if you don’t have debugging, then you don’t have a complete coding environment, and important nuances of code execution are going to be invisible.
Well, some might think they don’t need a debugger … they think to know how to program :think:
I’ve met a few and they spend months on development instead of weeks.
Or vice versa :whistle:
Mbed has no debugging (not with their IDE anyway), either. You can pry my non-web-based IDE from my cold, dead fingers.
I just picked Peter’s response because it best summed it up.
I really would like your guys serious opinions on this issue. Just asking an honest question from “my” perspective to see you guys point of view on this because I seriously have never been able to understand it…
I started to learn how to program in assembler back in H.S. been coding ever since and now at 47 yeas old. So basically have tried most everything out there. In all my years doing this I never once said to myself Jeez, I should could use a debugger. I honestly cannot see the great benefit of having one. I know I am in the minority here on this, but I just do not see the benefit of it.
Anytime, I have ever had a issue with some section of code not providing the desired output I would just slap a printf in a few key places.
Never needed more than this to solve the problem.
Can someone give me a honest good reason why someone would ever need something more than a printf to debug ?
@ VersaModule - Try to debug a live app you can see and use the source but can not change it … you want to have a step-by-step walk through possibility to find the route cause and that for several runs since you won’t hit it for the first time …
Oh, and you have to solve within 15 minutes otherwise the package doesn’t leave the building and you’ll miss your plane you have reserved b4 etc. double cost on freight and handling. Stupid thing is the package is part of a shipment having an MM value and you paid for the insurance already … do I have to continue ?
This might have nothing to do with netmf but that is when real live kicks in about having a good debug / step through IDE is definitely worth it (you can forget the I for the Arduino tool, it is just a development tool)
I couldn’t live without a good debugging integration, and believe me I’ve even coded b4 assembly where we need to hack in the op-codes, there where no mnemonics yet)
And the code you have to check is not always your own … so I can’t assume any nice or sound structure. I’ve even had the case that people didn’t trusted the if … then … else … case and coded a kind of goto just b4 the else statement to make sure it was not executed by accident … makes you wunder however they got to programming if you can call it that …
Closer to home try llilum … no BP no debug.print … you’ll go blind there … so find out why i2c f.e. is not working, you’re my hero …
Bottom line, IMHO, one doesn’t deserve the I in IDE if there is no debugging on-board it is just a plain old unused by me Development Environment. I only use Arduino Tool for its easy serial port monitoring
Having breakpoints at critical places is also very helpful.
Once the breakpoint is hit, you can then examine almost every variable (provided it is in scope, of course) and then do a step-by-step run of your program/method and again see the result(s) in your variables.
It is also easiest to see the content of arrays and you can put a spy on some variables to better follow them. Using only printf() would be undreadable in such cases.
@ Bec a Fuel - So true and I’m happy to have it avail, I don’t need perse Debug.Print … it mainly helps me if in proto/alfa mode, after that you have to have some serious construction build in your SW to trap/monitor and have a maintenance friendly coding solution.
In VS I’m still hoping to find a good project template for that … probably have to produce one myself … :think:
Note also that both Debug.Print and printf introduce new synchronization states into your program. Both of these contain critical sections on the output stream and Debug.Print (with a debugger attached) will introduce at least one additional thread context switch (which is why sometimes netmf programs only run correctly with the debugger attached - your normal code is not yielding often enough). All of these printf-debug mechanisms change the operating behavior of your program.
printf debugging is great for watching simple stuff, but it is somewhere between useless and destructive for debugging synchronization (livelock, deadlock, and timing) problems.
Breakpoints can cause all threads to stop in a synchronized fashion without introducing new inter-thread dependencies or introducing additional context switches. They don’t work for all types of sync problems, but they work better than printf. Modern debuggers make it easier to trace causality chains (task-based programming) and a good suite will include memory and cpu profiling, because ‘it doesn’t crash’ != ‘it’s good code’
I’ll add that trying to debug a data stream is harder with just debug.printf. You need to write code to print out the buffer etc. With debugging and breakpoints you can simple stop and check the memory location and read what is in the buffer and single step you code to see if it reads the data correctly.
I used to debug without back in the days of machine code but since I started with the likes of JTAG and USB debugging I refuse to do it any other way. It’s just too slow and cumbersome.
Thanks guys for all your input. I personally dont use .netmf for anything. Gave it a whirl back when GHI was a greenhorn, and it was just to buggy for me. To be honest I have not tried it again since. Primarily because for me (and notice the “for me” part) embedded Linux is the way to go.
So maybe adding printf in .netmf is not the thing to do, I honestly would not know.
For all my other compilers I use, a scope, logic analyzer, and printf’ing a variable is all that was ever needed. Maybe in this instance I am one of those cant teach an old dog new tricks :
I have tried debugging a few times many moons ago, but what I noticed was it did not allow the code to run full speed as if it would without the debugger. So when the debugger was running things worked (because things were slowed down), and when debugging was off and it ran full speed that is when the problem cropped up. Now, this was many years ago, so things may have changed.
In any event, Thank you all for taking the time to explain your point of view to me. Cheers.