I think much of this discussion suffers from the lack of terms for certain items.I've brought this up a few times in the past.For example what does "Arduino" mean?While accurate, people may get a strange look on their face when you say something like:I used Arduino to program my Arduino with a program written in Arduino.

And that is the problem. There are no separate terms to referto the individual components such as the IDE, the tools, the board, the bootloader, the chip, the "language".Because of this, people tend to throw around the term "Arduino" and yet it can mean different things todifferent people.

To me, this makes things very difficult to have a discussion like the one occurring in this thread.

Much of the ease of use with respect to "Arduino" has very little to do with the Atmels AVRor AVR architecture.It is the GUI tools and libraries, documentation, examples etc, and most of that is in noway tied to AVR.In a sense it is the easy to use eco system around a pre-built board,rather than any sort of specific chip or board thatmakes "Arduino" a good fit for many people, including people with no embedded programmingexperience.

Because the s/w eco system is open source and in no way tied to AVR, it has been ported and is now availablefor use on non AVR based processors. ARM, and pic32 based boards now both have "Arduino" IDEs and "Arduino" corelibraries available for them.

So to me the Arduino vs non Arduino argument doesn't have anything to do with AVR but rather whetheror not to use the "Arduino" eco system or not. And the "Arduino" eco system includes, boards, shields, s/w libraries,an IDE to build the code and documentation with support forums to tie it all together.

More advanced users can selectively pick and choose which of the various components of that eco system to useand not have to use them all.

I do think that for advanced users with lots of embedded development experience,there can be many issues and frustrations with the IDE and the build methodology, but thenthe Arduino s/w is not really aimed at them.

I just wish there were some established terms to refer to the specific components within the eco system tomake discussions like this easier, as to me right now there are just too many things all called "Arduino".

--- bill

Bill - Arduino means all those things. As in all language, context is everything. The board is an Arduino board (of which there are several versions, using several realted, but different processors.) Arduino is also the Arduino IDE which is where you load Arduino sketches to compile and transfer them to the Arduino Board. WHat is meant by a given use of the word - Arduino - is dependent an on context.

The Arduino environment is a gret way to get started and to test things out. It might be great for producing finished code, or the ATMel AVR Studio might be better. The Arduino IDE is well integrated and has quite a bit of knowledge rattling around on the web and most questions can be answered rather quickly (quickly is relative, especially when you just figured out the problem, but have no clue as to a solution...) and lets you program in C. AVR Studio will also let you program in C, but I used it to do a little programming in Assembly. Faster, Tighter code, but less help from the web.

Ans as in anything, the initial learning curve can be a bit steep. Some of that will depend on your background and some on age. I am 54 years old, but I have a background in programming from the days of the Z80. The learning curve was a bit less steep and I had a few clues about what questions to ask. A different background and that initial learning curve can look a lot different. Biggest thing is to learn how to phrase the question. (I use AutoCad. If you don't already have an idea about the tool you want to use, you spend a lot of time just figuring out what tool to ask about. Once you know what the tool name is most of the questions are answered...) Read some and try some things and ask some questions. Someone will probably have been trying something similar and will be able to help you figure out what the question really is. Most of learning is just figuring out the questions.

Of course, the day when questions like "I'm not using an actual Arduino board, or the actual Arduino IDE, or an AVR processor. Why doesn't my program work?" start to outnumber the actual "Arduino" questions, will be a sad one.

You have been advised. That error is not being generated from the Arduino IDE program, but rather it's an error from some 3rd party PC based AVR simulator program. There very well be no one on this forum that has used that simulator so it's hard to help you with whatever that error means. Have you attempted to contact the supplier of the simulator program about the error you are getting?

Please advice how may I load the compiled file (HEX) to simulator. where the HEX file is generated

I haven't used the simulator. I prefer to work with real microprocessors. However I went to their web site and there is extensive documentation. Without seeing what you did, I don't know if you followed it.

I suggest you post to their site, or forum, as this is really nothing to do with the (real) Arduino. It's to do with a bit of software that emulates Arduinos.

Please post technical questions on the forum, not by personal message. Thanks!

You have been advised. That error is not being generated from the Arduino IDE program, but rather it's an error from some 3rd party PC based AVR simulator program. There very well be no one on this forum that has used that simulator so it's hard to help you with whatever that error means. Have you attempted to contact the supplier of the simulator program about the error you are getting?

Lefty

Dear Lefty,Thanks for the reply

I simulated sample code provided by Arduino (Blink), so it is running very well, then I wrote the same program and compiled and load the sketch to the same simulator, unfortunately the above error was encountered .

For example, I travel a lot. Blinking leds, naked pcb boards and 7-segment leds are huge attractions going through the various "check points" on my journey. Plus, I do tons of cross-platform development it isn't always feasible to have everything with me.

Thus, simulation is vital to me. And it has been a great productivity enhancer, as long as you understand what they cannot do so you can use them for what they can do.

For example, I travel a lot. Blinking leds, naked pcb boards and 7-segment leds are huge attractions going through the various "check points" on my journey. Plus, I do tons of cross-platform development it isn't always feasible to have everything with me.

Thus, simulation is vital to me. And it has been a great productivity enhancer, as long as you understand what they cannot do so you can use them for what they can do.

I think simulators have their place, and many also include or work with some source level debuggingtool but most of the embedded projects I do require talking to actual hardware runningin real time, so a simulator has virtually no value.Even when I was writing a Windows Phone APP or Android APP, the simulators were of limiteduse - I gave up trying to use them and went to running the source level debugger on the real hardware.

I think a much bigger productivity enhancer than a simulator is source level debugging. (gdb is a great tool)After the low level hardware is debugged (which can't be done on a simulator) most embedded projectswould get much better productivity out of getting the full gnu tools up and working rather than continuingon with simplistic debugging techniques like blinking LEDs, etc...Toggling pins and blinking LEDs has their use, I use it quite a bit, hand in hand with a logic analyzerfor low level real time debugging and timing/profilingbut that is generally not the bulk of the type of debugging that needs to be done a project.Accidental logic errors and race conditions are much more common and those are more easily caught withsource level debugging and breakpoints.Having source level debugging allows you run in real time and then break under certainsituations and then poke around and look at the state of things.

gdb has been round for more than 20 years so I'm amazed that I still see so many developers out there, even using gcc, that don't take the up fronttime to get acquainted with modern debugging toolsand to get their source level debugging tools in order.The small amount of time to get it up and going is rapidly returnedover the project.

As far as traveling goes, you can set things up appropriately, so you can sourcelevel debug actual hardware form anywhere in the world.Back in the late 80's I was debugging firmware on a disk controller in a live systemthat was in California while I was in Texas.I even had access to the host system that was using the disk controller.It amazing what you can do over an IP session if you set things up.

Is there a gdb stub for AVR? I assume it would fit in the larger AVRs...(I wish Atmel documented the chip-level debug features, though. There's a lot that a debugging stub running on the AVR just can't do on an embedded processor like the AVR. (no dynamically settable breakpoints...))