I found this enlightening post about programming AVRs & the Arduino IDE:
AVR vs Arduino - Which is right for me? (http://http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=91189)
The biggest difference is that with Arduino, you are somewhat forced into doing things "The Arduino Way", vs being able do things "Your Way" - or in some case the way the rest of the non-arduino world does things.
A key difference in using Arduino is that the Arduino wiring library has abstracted away all I/O pin operations. It is both Arduino's greatest strength and yet it is also its greatest weakness.
Because of this abstraction library, the real guts of the AVR are hidden/masked from the user.
Arduino uses naked constants, i.e. numbers 0 - n. to refer to I/O "pins" rather than AVR ports & bits.
While this is nice for some things, the current Arduino wiring library code implementation is ...SLOW....... compared to the speed you can achieve if you directly write to the AVR port to set or clear bits using constants. (Arduino code could be made substantially faster, by re-writing the library code, but it will never be as fast as direct AVR port I/O which can set or clear bits in a single instruction)
NOTE: for many applications, speed is not really an issue. But for things like high speed bit banging or say an I/O intensive GLCD, it does matter.
Also because of the pin oriented mindset, the Arduino wiring library has no way of writing more than 1 bit/pin at a time because it has no notion of AVR "ports". It was based around the idea of individual I/O "pins".
And even looking at Arduino Pin #s, it is very difficult to tell if 2 pins are even on the same AVR port. In fact there is no way to know, other than by manually visually looking at mapping table or write code that uses a look up table.
So in Arduino if you want to set more than a single bit/pin, you have to call their DigitalWrite() function for each "pin".
There is nothing to prevent you from using the direct AVR port bit/pin capabilties available by using the defines supplied with the avr-gcc compiler, but once you do that you are beginning to leave the Arduino world behind.
In the big picture, when you use Arduino and their libraries, you can benefit from their "canned" environment and code base. It can offer a quick path to bringing up new code, but there is a price to pay for all these conveniences.
Some of the price is speed/performance. Another price is the lack of source level debugging. If you want to do source level debugging of your code, you can't do that with the Arduino IDE. Another big factor is that some of the AVR or avr-gcc capabilities are masked/hidden away and not supported. The Arduino IDE will not let you set set specific compiler or linker options.
So say you wanted to use sprintf() and format a floating point number. You need to use a special linker option to get the floating point support. You can't set that option with the Arduino IDE.
Another example, Arduino does not come with support for directly printing strings stored in AVR program memory.
So if you do something like: [tt:]Serial.print("Hello Worldn");[/tt:]
While that string is stored in flash, there is also a copy stored in RAM. The arduino code only knows how to print strings stored in RAM.
Because of no source level debugging, printing strings out the serial port is a common way to debug Arduino code.
RAM is precious. And you can quickly overrun your ram with text strings when debugging on the smaller AVR chips if you aren't careful.
There are ways to avoid this duplication of string data in RAM, but Arduino does not support it. The Arduino team has focused on defining their interfaces to be generic and this type of stuff is very processor and compiler specific. IMHO, in this area and in a few others, the Arduino team have failed to address the realities of Harvard Architecture and RISC processors.
To remedy this you have to know how to write some "non arduino" avr-gcc specific code wrappers. And then you are slightly stepping outside of Arduino again.
A big plus to learning gcc and using real makefiles, is that this environment is very portable across OS platforms. The same toolset works on many processors from AVRs, to ARMs, to even PC application development.
As for GUIs, AVRstudio will provide a nice GUI but only for Windows. This is one advantage that the Arduino IDE has. Its GUI IDE is available on several OS platforms. There are other GUI based tools such as Eclipse that can be used across OS platforms.
As for GUIs, AVRstudio will provide a nice GUI but only for Windows. This is one advantage that the Arduino IDE has. Its GUI IDE is available on several OS platforms. There are other GUI based tools such as Eclipse that can be used across OS platforms.
This post has some good points. One thing to keep in mind -- The appeal of the Arduino is the low barrier to entry, especially for someone with no previous microcontroller experience (like myself). Being able to get a chip with a pre-programmed bootloader that eliminates (or delays) the need for a chip specific programmer opens up the project to a much wider range of people. I don't have any dedicated programmers for AVRs or PICs. Although I have a bus pirate, so I believe I have a number of options. I'll probably move to more AVR specific programming before I move to PICs, though I'd really like to experiment with the IR toy design.
Also, there is work going on to create Arduino 1.0 (http://http://arduino.cc/blog/?p=392).
We plan to stabilise the API and the current IDE so that for the foreseeable future the reference, the examples, the tutorials and the books you buy should stay consistent. This will help people who are teaching, wiriting tutorials and books to stay up to date for longer. We will obviously fix bugs and add new boards to the core as they appear and you should expect everything in 1.0 onward to work properly.
At the same time this allows us to open up other streams for developing experimental distributions that are more cutting edge that are more appealing to people with more experience that are willing to trade some stability with more performance and new features.
On the google code repository (http://http://code.google.com/p/arduino/issues/list?q=milestone=1.0) is the bug/rfe list.
--Rob
Sounds good. I've been looking at some AVR code and the jump to programming MCU's like the ATtiny2313 doesn't look too bad for small projects, obviously Arduino is the easiest way.
I also looked what the fuses were and they are not a complicated thing, they just can get in your way, but once you install the bootloader you don't touch them.
Which brings me to another point, using bootloaders without the Arduino's IDE. There's and interesting bootloader called Optiboot (http://http://code.google.com/p/optiboot/):
- Faster upload speed.
- More sketch space - the bootloader is a quarter of the Arduino bootloader size, giving 1.5K of extra flash space.
You need to put a file(s) in the Arduino IDE folder so I don't know if you can use it with AVRDude alone.
And there's BootloadHID and AVRUSBBoot. I would like to use BootloadHID with the ATtiny2313 so I'm still looking for an example on how to modify the sources so that the MCU can be programmed without using a jumper, just by accepting AVRDude's command to the bootloader during the first couple of seconds after reset (jumper-free firmware update).
The idea is to use a fast bootloader that allows pain-free updating of firmware (program) during the development phase.
The main problem with the Attiny2313A is it's rather limited flash memory(2KB).
To keep as much space as possible for your application you will want the bootloader
to be as small as possible. I have never used a bootloader for ATtiny2313/4313 but
I have used ladyada's Atmex (http://http://www.ladyada.net/techproj/Atmex/index.html) platform for quite a few simple ATtiny2313A projects.
The Atmex project (http://http://www.ladyada.net/techproj/Atmex/index.html)
- makes use of the free and well supported (GNU and Atmel) AVR development environment
- is well documented including a hardware and software guide and includes
- a small but very versatile PCB for the ATtiny2313A/4313 with a regulated power supply, reset button, RS232 interface, breakout header and a prototyping area
- a 500k (!) bootloader and a Java Client (JAvrProg) to communicate with the bootloader and to upload and verify firmware to/in the ATtiny2313A/4313 or you can program the ATtiny via a standard ISP header (requires an AVR ISP programmer when not using the bootloader).
Seeedstudio offers a Atmex V2 remix (enhanced) PCB that adds a USB->TTL (FTDI-compatible) header that can be used for communication with the development system/PC instead of the RS232 interface.
I have to say that the biggest issue I have with the arduino tool chain is it hides too much from the user, does a little magic, which I consider evil, and does not have a debugging interface. Programming without program lvl source debugging is unfortunate. On the other hand I still run into lots of fun little devices that claim to be mod-able and hack able, but no they used a 168 to save a cent, and as such the memory, and code space are too full to do anything. Given the cost differential I am considering boycotting any device that does not use a reasonable size chip, or which the runtime isn't less than 50% of the available memory and claims to be hackable.
I really love the gcc tool chain being available, and I have been running into more and more folks that have move beyond the arduino by using the standard pin defs, so they can set 8 pins at once. There is value in the easy with which a newbie can get started. I can send one to a niece or nephew and they get going right away. Unfortunately the magic and hiding of the tool chain often traps people so they do not realize how easy it is to move beyond it. I hope the other chip companies can see the value of supporting a gcc port of their architecture, and the value is supporting the standard libraries. It enables so much.
Ryde,
I agree with a lot if what you said... it's spot on... but I think it's only because you already "know better". You have the benefit of knowledge and exposure. We see newcomers to the Arduino community that barely understand what a resistor is and just want to know how to make an LED blink or have and RGB LED change colors. They think "wow... I'm good at this". This is why all the hard stuff... "boundaries to entry" is hidden away with Arduino.
The cool part is that you CAN actually get access to the GCC code that the Arduino IDE creates... so... when the Arduino user realizes that there is more... they can go so far as 1) ditching the bootloader 2) Study the GCC code and learn something new 3) get a full release of WINAVR (or what ever their platform supports) to get GCC and start using the Arduino HARDWARE as a flexible AVR building block... IE; stop treating the PINs the way a Parallax Basic Stamp does and start using the AVR ports/pins as marked in the DataSheet.
So when the Arduino "introduction" is over... maybe... just maybe... the student will learn to go the next step... If they had started with GCC... and AVR datsheets... they might have just given up.
I think Arduino really only ever meant to be a "microcontrollers 101" class. It just becomes so QUICK to develop a prototype idea with Arduino that alternatives are often skipped over... Ease of USE... wins out.
But the exposure can't be considered wasted... a GOOD Arduino programmer can easily take the next step to GCC if they ever find out about it.
Well said, I just regret the magic reorder of statements into one large unpredictable file that encourages bad habits, and hides what is really going on. I just don't see the value gain from what they do being worth the confusion it generates. Yes I have taught programming to high school and freshmen before, but I don't see the value in the magic they do. I tried putting a #define in a file, till I learned what nonsense they are doing and gave up.
Depending on your background and aspirations, the jump from Arduino to programming AVR's is not that big, and you might want to do just that in the long run.
The Arduino opens doors for other segments of the population, like artists, or people who want to explore new possibilities without getting too deep into MCU's.
I agree, to programmers, in particular those who have come a long way (+10, maybe even +20 years) programming in (various) assembler(s), Fortran, PL/M, Pascal, C, C++ ... Processing is weird and confusing as the Arduino environment is based on Processing and not directly on (ANSI) C/C++ (or Java) and the process of generating the executable code from source is pretty much hidden from the user. However, once you have adapted (i.e. from C) to Processing you will start liking it's strong sides ...
On the other side liyin's argument can't be ignored either. It is the intention of the Processing inventors and those who use Processing as an IDE for their platforms to get non-programmers interested in creating and implementing projects without the need to know all the underlying technical details (of the hardware and software) - artists, designers, physicists, psychologists, hobbyists and many more who consider conventional MCU development environments too complicated (and expensive) feel encouraged to put their ideas to work and are rewarded (in most cases) instantly (i.e. most succeed in getting the "blink LED" sketch to work without a problem). From there on it's learning by doing and examples for sensors, input, output etc. can be found on the web easily.
The success of Processing based platforms like (list is far from complete ;)
- Wiring (http://http://wiring.org.co/)
- Arduino (http://http://www.arduino.cc/)
- Funnel IO (http://http://funnel.cc/) (Arduino based)
- Pinguino (http://http://www.hackinglab.org/pinguino/index_pinguino.html) - it's PIC 18F2550/4550 based :)
- Butterfly (http://http://www.gadgetfactory.net/gf/project/wiringide/) (yes, Jack got the Processing/Wiring/Arduino IDE working for his FPGA based Butterfly boards with AVR8 emulation)
- LumiNet (http://http://hci.rwth-aachen.de/luminet)
- Atmex (http://http://www.ladyada.net/techproj/Atmex/index.html) - (it can be used with a slightly modified Arduino IDE, the LumiNet IDE) (http://http://www.seeedstudio.com/wiki/index.php?title=Atmex_v2)
along with the many artistic, scientific and fun projects created with these environments prove the concept of Processing to be achieving just what it is intended for ... attract people to make things they wouldn't do with a conventional MCU development environment.
Considering that all Processing IDEs use the WinAVR, Microchip MPLAB C Compiler for PIC18 MCUs or gcc tool chains as an back-end to generate the executable code users will eventually get motivated to "look behind the screen" and use the "raw toolchains" for more complex and challenging projects.
At first I rejected it for the same or similar reasons rhyde gave, today I see it as an approach "from the other end" that leads to the same result: give people tools to make something they imagine become real. ... so, it seems to attract many more than the "classic/old school" approach :)