Guide to the Arduino software internals?

I'm looking to dive into learning about the guts of the Arduino software libraries and I was wondering if there's a good place to start. I know the public interface of the library very well. I've written lots of sketches and also a system for programming the Arduino in Ruby ( Ruby Arduino Development: GitHub - atduskgreg/rad: Ruby Arduino Development: a framework for programming the Arduino physcial computing platform using Ruby ). I'm an intermediate C programmer looking to become more advanced by learning about (and possibly contribute to) this exciting project.

Is there an overview of the Arduino software online anyway? Any blog posts or wiki pages I could start in? Also, what's the best place to follow ongoing development? I watch this forum and subscribe to the blog, but I haven't been able to find a mailing list or any other place to join the continuing development discussions. Am I missing something?

Thanks, in advance, for any tips. I'm lookinf forward to learning more about the Arduino software.

There's some information in the hacking section of the site. In particular the build process page explains how a sketch gets compiled and linked, which can be useful for understanding how Arduino code turns into C code (there's very little done, actually). Development is discussed on the developers mailing list; feel free to send ideas or suggestions to it.

Thanks, I'll take a look at those links. I've been diving into the Arduino code a bit and I bet with some of those tutorials -- and maybe a little help on this forum -- I'll be able to understand what's going on. I'll try to document what I learn for a future blog post or wiki entry for others as well.

Well, I've hit my first roadblock: understanding the use of the AVR_ENHANCED constant. I'm seeing it on line 332 of pgmspace.h

#if defined (__AVR_ENHANCED__)
#define __LPM(addr)         __LPM_enhanced__(addr)
#define __LPM_word(addr)    __LPM_word_enhanced__(addr)
#define __LPM_dword(addr)   __LPM_dword_enhanced__(addr)
#define __LPM(addr)         __LPM_classic__(addr)
#define __LPM_word(addr)    __LPM_word_classic__(addr)
#define __LPM_dword(addr)   __LPM_dword_classic__(addr)

I'm trying to follow the implementation of digitalRead all the way down to the bottom so that I understand it and it's led me here, but I can't seem to find a definition for this constant anywhere. What does it represent? What makes our avr chip enhanced or not?


Beats me. I'm not sure you need to worry too much about the contents of the avr-libc files, beyond reading the avr-libc module reference.

Ah, nice. Someplace I can stop diving down. Excellent. Turns out the avr-libc docs reveal that pgm_read_byte() -- the function I was investigating that lead me from that Arduino code (it's called in the definition of digitalPinToTimer(P) within pins_arduino.h) -- is just a macro that avr-libc supplies as part of its system for allowing you to store things in program memory as well as data memory. Basically, it takes an address within program space and returns the value located there. In this case, you hand it the address of array digital_pin_to_timer_PGM[] which stores the correspondence between pins and and timers, using the pin number as an offset so that you get the value within that array for your desired pin.

I think now I've gotten to a real question: how do these timers actually work? There seem to be seven of them labeled from 0A through 2B. Do these correspond to different registers? Different slices of the clock cycle? How does the atmega168 output the 7 different analog values?

The best place to look for an answer is the atmega168 datasheet and look on google for "avr timer tutorial" there are 2 or 3 that explain it quite well

if you can't stop digging you have now to learn the datasheet by heart :slight_smile:


Without actually digging into it, I'd assume that AVR_ENHANCED tells the code that that particular AVR has (or might have) more than 64K of flash memory, and therefore needs pointers larger than an int for data stored in program memory...