what about debugging?

I seem to find little mention of debugging techniques here.

Is the arduino IDE simply a compile and upload facility?

avrdude allows access to flash and EEPROM but not the volatile memory it seems.

There does not seem to be any access to RAM and the registers which is necessary for any serious development.

Playground mentions debugging but only in the context of Visual Studio it seems.

So what are the options for full debugging in this environment? I was under the impression that AVR allowed development platform free from expensive development kits and hardware.

Maybe I'm just not looking in the right place but there seems oddly little talk of how to do debugging here.

Thanks for any pointers.

You're working on a tiny, slow microcontroller with limited memory, but with largely well-tested libraries.
How much serious debugging do you envisage?

(FWIW, I work on much faster processors, with very many times more memory, more, complex peripherals yet still use pretty much the same techniques to debug as I use on the Arduino)

Basically, you're back to the world of the 80s. Printf (Serial.print), logging to a file (if you have an SD card) are your primary tools. Forget breakpoints, watching variables etc. If use of the serial port impacts your program's timing too badly, you have I2C and SPI. Lighting LEDs is used as a low impact debugging indicator, though it obviously doesn't tell you much. Signal analyzers and Oscilloscopes can help too.

Consider this though: the code you'll write for most arduino sketches isn't going to be that complex usually, so debugging them even without the fancy IDE tools, isn't especially difficult if you know what you're doing.

If you really want that stuff, take a look at the netduino: C# and a fully functional debugging IDE.

The libraries may be well tested but my use of them is not. If something does not do what I expect I need to look to see why not rather than just have another stab in the dark upload.

I'm not aiming to use the hardware to flash LEDs on and off, I need to control external hardware real time, reading ADC ports, monitoring the state of the external hardware and outputting control signals.

I would expect to do this by setting break points and checking registers etc.

"yet still use pretty much the same techniques to debug as I use on the Arduino"

Which is what in the most simple terms, print to serial port?

thx

Which is what in the most simple terms, print to serial port?

Well, it's a very, very fast serial port, but yes, pretty much that's what we do.

Graphics, DSP, I/O (lots of I/O), all get debugged through the serial port.
I haven't debugged with any kind of ICE in over ten years.

ardnut:
I seem to find little mention of debugging techniques here.

Is the arduino IDE simply a compile and upload facility?

Yep, pretty much.

Maybe I'm just not looking in the right place but there seems oddly little talk of how to do debugging here.

Thanks for any pointers.

For any real sort of real debugging (which I assume you mean at the source level with variables, break points etc...)
you will want to use gdb or some GUI wrapper around it.
And to do that you will probably want/need to use makefiles to make sure you set
up everything the way you want it.

The Arduino IDE is simply too wimpy and didn't use Makefiles underneath so it is pretty
painful to use the debugging tools with the Arduino IDE.
You can choose to abandon the IDE (there are some makefiles out there that come close to working similarly)
or leave Arduino and its libraries behind and write your own code using avr gcc with makefiles,
or use AVR studio
You can use AVR studio if you are still using windows and want a GUI solution for Windows based OS's.
Alternatively you could use something like eclipse - I think they have some Arduino plugins now.

You will also then need some additional hardware that can access the chip on behalf of the
debugger. The AVR dragon is probably the most cost effective device for source level debugging.
It can use the ISP port, JTAG pins, or can use the reset line (debug wire mode) to access the internal chip resources.
Debug-Wire is very cool as it only uses a single pin that usually is not used for anything else anyway.

As far as "back to the world of the 80s" type debugging goes.
Boy do I wish it was that good on the AVR. By the late 80's gdb was already fully
working in many embedded environments
and true source level debugging with breakpoints and access to variables
was easily accomplished over a serial port
with the simple addition of a gdbmon to your embedded target code.

Today, on the AVR, life is not so simple nor as good. The Harvard architecture really throws
a wrench in things, (much of this issue has work arounds) but as far as having a gdmon goes
that allows source level debugging over a serial port goes, it is non existent.
There are some technical issues in making something like a gdbmon interface fully work
on the AVR so at this point everyone that wants
source level debugging is using a h/w tool that can be controlled by a debugger - usually gdb.
Tools like the AVR dragon or JTAGice are used. This is what avr studio and packages like DDD use)

I've often thought about doing a gdbmon for the AVR. Break points and single stepping
can be made to work but are ugly under the hood as you have to steal one of the interrupt pins.
I've just not had the time and an AVR dragon using debug-wire is actually better anyway.

For now, you are kind of stuck with a few options.

• use IDE "as is" and revert to using primitive debugging techniques like
  "printf()", toggling pins, LEDs, etc...
• switch over to a more advanced build/development environment and use a h/w debugging tool
  like the AVR dragon or JTAGice

If you switch build environments, you will have to decide if you want to stick with
the Arduino s/w environment or leave it behind as well.
If using a windows platform, AVR studio is a pretty nice tool set and offers full debugging
as well as a simulator.
You could use AVR studio with some "Arduino" makefiles to allow using AVR studio and its
debugging tools with the Arduino s/w environment and libraries.

You can also ask questions over on the AVR freaks site about AVR (non Arduino) development:
http://www.avrfreaks.net

For realtime runtime debugging even having a source level debugger may not help.
For example you may need to see a certain stream of events in real time.
A break point won't help in that situation as it halts the processor.
For sure anything like a serial port transfer will kill the realtime timing.
kiss i2c goodbye it is WAY slower than a serial port, even SPI can be too slow.
For these situations, I use multiple output pins and a logic analyzer.
You can assign an event to a pin or use a collection of pins along with a "strobe" indicator pin
to indicate the event. On the AVR, this allows indicating an event in as little a single AVR clock cycle
since if you pick your pins carefully you can update them all in a single write to the port register.
This is very unobtrusive to timing.
I've used this output pin strobing technique on many systems over the past 30 years especially for very
realtime systems where you simply can't do much of anything or something bad can actually happen
(like corrupt the format of the hard disk - in the case of disk controller)

It is very easy to implement, uses a very small amount of code in the target
and gives you realtime visibility into the code flow.
It is great for profiling routines as you can do strobes around portions of code to time it.

--- bill

Until recently I've used two spare pins and a logic analyser for low intrusiveness and printf if I can afford the time. I have felt no real need for a debugger.

That said, over the last two days I've been working on a system with full debugging capability and it's been a dream. For example I had a hard fault exception, the debugger showed the stack frame so I clicked on the last executed line of code and immediately found a bad index into an array of function pointers. That would probably have taken half an hour of dicking around placing pulses to see how far the code got etc.

I still plan to use the pin-pulse method for time-critical stuff, but apart from that I'd say "Use a system that allows real debugging". Hopefully the new Due will.

Rob

ardnut:
Which is what in the most simple terms, print to serial port?

That is usually my first fallback. Then there are other methods:

It's all very well setting breakpoints etc. but often this sort of imbedded microcontroller is doing something timing-dependent, and setting breakpoints doesn't really help with that.

I've been spoiled with AVR Studio and JTAGICEmkii for so long before Arduino. I like to use simulate or monitor what going on if I feel that something is not happening correctly. I made a simple SPI pod for my logic analyzer it has helped me. Serial.print is very useful too.
Setting and clearing output also.
Don

Thanks Bill, that's exactly the kind of detailed information I was looking for.

It seems calling the Arduino IDE an IDE is over selling it a bit. The "I" in IDE stands for integrated. The integration being that of code generation and debugging.

Can you oversell something that is free?

Check this out:

The open-source Arduino environment makes it easy to write code and upload it to the i/o board.

It claims to be easy to write code and upload it. Which I believe it achieves.

Frisky:

I've been spoiled with AVR Studio and JTAGICEmkii for so long before Arduino.

JTAGICE can run atmega168 and atmega8 , both of which can run in the UNO , as far as I have been able to determine.

JTAGICE is not cheap ($300) but that would provide one route to having a full debugging evironment for Arduino, unless I'm mistaken.

Can you oversell something that is free?

Overstating it's capabilities if you prefer. I don't consider something with no debugging capability to be an IDE Though if you want to be pedantic you could always say the have "integrated" code generation and an uploader.

For what it does it seems to be a pretty good tool. But calling it and IDE is rather misleading.

ardnut:
But calling it and IDE is rather misleading.

My point was that on that page the letters IDE only appear once ("Previous IDE Versions"). It represents itself as "The open-source Arduino environment".

We mustn't lose sight of Arduino's provenance and original purpose, which (at least as I see it) was to let a bunch of lay folk write code and get it into a processor in a bit of a quick-n-dirty way so they could make stuff happen in the real world. And today my daughter- who would never otherwise have developed any kind of interest for this stuff- does exactly that when she writes simple C code to drive her 2-motor Magician chassis with an Uno and a MotoMama board.

That said, it has of course evolved and seems to have become a genuine embedded control platform used by professionals. Professionals need better tools than amateurs like 16yo schoolgirls, since they have time constraints and get paid to make stuff quickly and cleanly (not quickly and dirty 8) ).

So perhaps there's place for a (maybe even no longer free?) Arduino IDE**-Pro** to sit alongside the current and always free Arduino IDE**-Am**

JimboZA:
Professionals need better tools than amateurs like 16yo schoolgirls, since they have time constraints and get paid to make stuff quickly and cleanly (not quickly and dirty 8) ).

I smiled when I read that, because the implication is that, somehow, if you pay for something you get a better product.

I have some software running on my Mac (I'm not going to name it because the exact product isn't relevant) which I find doesn't do exactly what I want, or if it does, I don't understand how to make it do it. I paid good money for this, so I expect professional support.

I joined their forum, and posted a polite message describing my problem, and asking for a solution. On July 3rd 2012. That's a week ago. Not a single response. Nothing.

Meanwhile, on this forum here, for the "free" software, you generally get a response within an hour, if not 10 minutes.

And as for "dirty" ... I have stuff running here (on the Arduino) in this house. It runs for months without rebooting. It works, and works perfectly. I would not characterize it as "dirty".

Perhaps go and get a professional tool, like the Atmel development environment? I tried to use that with the latest version (AVR Studio 5 at the time) and found it would not go into parallel programming mode on the AVR Dragon. So I submitted a support ticket in May this year. No response of any kind from Atmel. And then the ticket was quietly closed.

So, yeah, go buy your expensive development environments. They better do exactly what you want, because if they don't ... forget about getting support.

Ticket 639270: "Cannot do parallel programming with Dragon"

And as for "dirty" ... I have stuff running here (on the Arduino) in this house. It runs for months without rebooting. It works, and works perfectly. I would not characterize it as "dirty".

Why only months? Isn't it reliable?

I'm not being cheeky, just wondering. I have an ARM based system running linux and it the only time I can recall it rebooting without me telling it to was when there was a massive thunderclap directly overhead.

My installation was designed with much though to making it lightning proof, so the short coming is mine.

Shouldn't Arduino based hardware run indefinitely rather than just "for months" ?

BTW I agree that paying does not always guarantee support.

With as little memory as an Arduino, if the code makes it over the millis rollover, there's a pretty good chance that nothing else is going to stop it, unless you've got a memory leak that drips only every rollover.

Jimbo:

We mustn't lose sight of Arduino's provenance and original purpose, which (at least as I see it) was to let a bunch of lay folk write code and get it into a processor in a bit of a quick-n-dirty way so they could make stuff happen in the real world.

Yes, I mentioned Visual Basic above in this thread. VB allowed people who could not program to press a few buttons and make a .EXE , the results were so disasterous that I evenually refused to waste any more time installing and evaluating anything based on the VBRUN runtime libs.

Making an easy entry path into making things work will be very inspiring and certainly get a lot more people hacking and experimenting. I hope the similarity with VB ends there ...

The idea of making it quick and easy to get some results and the hardware abstraction provided by the libraries are great features. But for more serious development I'd prefer full debugging capabilities.

Anyone able to confirm my idea that using an atmega8 or 128 in a UNO should allow full debugging with ATJTAGICE II ?