I have a SVN checkout of the google code Arduino repository, and after the last update "Mega" showed up in the "boards" menu, and stuff seems to compile for the 1280...

eg: http://code.google.com/p/arduino/source/detail?r=565

Mega support has shown up in the source repository...

Here's some PWM code in C (actually from a PIC12f675-based project, but it should work fine on Arduino given appropriate implementation of getbright(), led_all_on(), and ledN_off...

Code:

  while (1) {  // forever
      getbright();
      for (level_delay = 50; level_delay != 0; level_delay--) {
         pwm1 = bright1;
         pwm2 = bright2;
         pwm3 = bright3;
       pwm4 = bright4;
       pwm5 = bright5;
       led_all_on();
         for (pwm_delay = 128; pwm_delay !=0; pwm_delay--) {
           /*
            * We have a random number in each PWM between 1 and 128
            * and we're going to have 128 cycles of delay.  So each
            * decremented output can only cross zero once, at which
            * time we toggle the output state.
            */
             if (--pwm1 == 0) {
               led1_off;
           }
             if (--pwm2 == 0) {
                 led2_off;
             }
             if (--pwm3 == 0) {
                 led3_off;
             }
             if (--pwm4 == 0) {
                 led4_off;
             }
             if (--pwm5 == 0) {
                 led5_off;
             }
         } /* time for new PWM cycle */
      } /* time for new brightness */
   } /* while forever */

The heatsink tab is actually used as the ground pad.

Note that while the heatsink is the third regulator lead, it is NOT always ground.  It is typically connected to the output voltage for "low drop out" (LDO) regulators, like the one used on Diecimila (and later.)

Oh!  I couldn't find that function either...

Thanks!

int analogPin = 13;
   :
void loop()
{
  int maf = analogRead(analogPin);

Pin 13 isn't a pin that supports "analogRead."  You can only do analogRead of 0 through 5.  It looks like you're reconfiguring ALL the analog pins  as digital pins ("digital" 14 through 18 are analog 0-5), so you need to either move a relay to digital13, or get rid of one of them.

You dislike soldering but are prepared to etch your own PCB? (and deal with the difficulties that a homemade PCB ADDS to soldering?!)  For your first efforts, I think you should just buy a bare board or two.  $2.75 shipped (although... Germany...  Don't know...)

I have a couple conversions of the RBBB (whose PCB design was released to the public domain!) done in EAGLE, including one that is almost single-sided (two jumpers to the programming connector), but they haven't been tested.

Ah.  I hadn't realized you were looking for a non-kit.  The BoArduino is a kit, too (or the iDuino can be ordered in quantity less than 5, if you buy the kit; it looks like the 5 piece minimum is only for assembled boards.)
OTOH, I'm sure Adafruit can ship you a kit with a 328 in place of the 168; She was one of the first people to offer 328 "upgrade" chips.

Wanting USB eliminates most of the breadboard-compatible clones; they're generally set up to use an external USB/Serial cable (and have only TTL Serial on the board.  pretty much halves the chip cost; the USB chip and the AVR are about the same price.)
There is the iDuino from Fundamental Logic (already mentioned) and the "USB BoArduino" from Adafruit; they look pretty similar...

[compiling]

How about this: When compiling small programs, the size of the resulting binary code can be larger than you might expect, because in addition to the code that you have written, the compiler brings in additional code needed to implement any functions you envoke, plus other "support functions." This "hidden" code is usually loaded in "clumps" (library files) and each clump may include more code than is strictly needed to implement your program.   As programs get larger, these libraries are reused, and any unused portions are more likely to be used anyway, so the "overhead" you see in a small program becomes a smaller percentage of the total size of a large program.

This is in contrast to a "interpreter" like the Basic Stamp, where the equivalent of the overhead code is built permanently into the chip, and the "binary" of your program consists only of references to that already-existing code (in one form or another.)

This is also in contrast to writing software in assembler or "machine code", where you would have to write EVERYTHING that the microcontroller would have to do, but wouldn't have to go one instruction beyond that.

Also, the arduino environment and libraries are somewhat optimized for "clarity of expression" rather than making small programs very small.  You COULD write a "blink" program using the compiler behind Arduino that was much smaller than the ~1500 bytes of the blink sketch, but it wouldn't be understandable by most of the arduino community...

So let's look at that output of "avr-nm -S" in reply #6 in more detail.  (This is essentially the "map" output that your co-worked was talking about.  It might be slightly clearer for other implementations of "map file", but in general telling a beginner that a map file will show him where the memory went is about like telling your grandmother that you use the internet to send email...)

Code:

000002fc 00000054 T delay
00000400 00000096 T digitalWrite
0000008b 00000014 T digital_pin_to_bit_mask_PGM
00000077 00000014 T digital_pin_to_port_PGM
0000009f 00000014 T digital_pin_to_timer_PGM

This first set of functions is the code that implements the "delay" and "digitalWrite" functions.  Almost 300 bytes, since Arduino does some pretty complicated things to make digitalWrite work on all the possible pins, and Delay deals wirth 32bit numbers (on an 8bit CPU) for the time values.

Code:

0000057a W exit
00000350 00000074 T init
0080010a 00000004 b intFunc

This is the code that initializes the arduino to the state that it is expected to be in when a sketch starts...  About 100 bytes worth.

Code:

00800100 00000002 D ledPin
0000010a 0000002e T loop

This is the loop function from "blink."  (and the ledPin variable.)  This is a much more reasonable (compared to the size of the source code) 46 bytes.

Code:

00000144 0000000e T main
000003c4 0000003c T pinMode
00000072 00000005 T port_to_input_PGM
00000068 00000005 T port_to_mode_PGM
0000006d 00000005 T port_to_output_PGM

library functions that implement the pinMode() function.  (and some more stuff that goes with digitalWrite)

Code:

0080011e 00000080 B rx_buffer
0080011a 00000002 B rx_buffer_head
0080011c 00000002 B rx_buffer_tail
00000496 00000010 T serialWrite

library code for dealing with the serial port ("Serial.print()") that shoudn't really be in your sketch, and won't be in v15 (probably)

Code:

00000138 0000000c T setup

The setup() function from your sketch.  12 bytes.

Code:

00800112 00000004 B timer0_clock_cycles
00800116 00000004 B timer0_millis
0080010e 00000004 B timer0_overflow_count

More of the code that implements millis() and the timer for delay()

So as an experiment, I tool the "Blink" example and exactly doubled the size of the sketch by adding "ledPin2" that gets the same things done to it as ledPin.  This cause the sketch (compiled with the arduino environment on Mac) to increase in size from 1414 bytes to 1470 bytes (56 bytes)
(With the patched 14, it when from 954 to 1010 bytes; same increase!)
(with version 11, which has a compiler that is "well known" to produce smaller code, the change was from 1092 to 1148; same increase, so this is apparently not the sort of code whose size changed!)

1) A map is of somewhat limited use when most of the functions are invisible to you.  However, there is a utility "avr-nm" (display name list) that sort-of shows the info you want.  Here's (edited) output from "avr-nm -S blink.elf" using the basic blink code as an example.  The second column is length:

Code:

000002fc 00000054 T delay
00000400 00000096 T digitalWrite
0000008b 00000014 T digital_pin_to_bit_mask_PGM
00000077 00000014 T digital_pin_to_port_PGM
0000009f 00000014 T digital_pin_to_timer_PGM
0000057a W exit
00000350 00000074 T init
0080010a 00000004 b intFunc
00800100 00000002 D ledPin
0000010a 0000002e T loop
00000144 0000000e T main
000003c4 0000003c T pinMode
00000072 00000005 T port_to_input_PGM
00000068 00000005 T port_to_mode_PGM
0000006d 00000005 T port_to_output_PGM
0080011e 00000080 B rx_buffer
0080011a 00000002 B rx_buffer_head
0080011c 00000002 B rx_buffer_tail
00000496 00000010 T serialWrite
00000138 0000000c T setup
00800112 00000004 B timer0_clock_cycles
00800116 00000004 B timer0_millis
0080010e 00000004 B timer0_overflow_count

2) New algorithms envoked in 14 let the linker omit code that used to be included.  Unfortunate, that was expected to REPLACE the previous library-based omit-code techniques, and it doesn't quite.  (so you see above that blink includes some serial code even though it doesn't use it.)  It's easy enough to get the old code back (in addition to the new code), and ardunio-15 will contain the patch.  Giving (for blink):

Code:

text    data     bss     dec     hex filename
 1090       2       4    1096     448 Blink.elf   [arduino-0011]
 1122       2       8    1132     46c Blink.elf   [arduino-0012]
 1218       8     148    1374     55e Blink.elf   [arduino-0013]
 1406       8     150    1564     61c Blink.elf   [arduino-0014]
   952       2      12     966     3c6 Blink.elf   [arduino-0014 with patch]

An empty sketch is down to about 500 bytes with 14+patch.  Note that the size is also dependent on compiler version; there was a significant jump in the size of code produced going between ardunio 11 and 12 with no obvious cause.  The gains in patched 14 are due to being able to leave code out, not due to smaller code :-(  The compiler writers (NOT the arduino team) can change their minds at any moment, resulting in significant changes in behavior; compiler writers do that :-)

3) The size of a small sketch is irrelevant.  This is a microcontrolller, and you're not sharing system resources with other users or other tasks.  Either your sketch fits, or it doesn't fit.  There is no advantage to having 12k of program memory free vs having 2k free.  There's also no used optimizing the size of "empty" sketches, because empty sketches aren't interesting.  The "real" measure of how well things are working is the slope of the line:

Code:

y = mx + b
codesize = ( compilerefficiency * sourcesize ) + overhead

That means, when you double the size of your sketch, the amount of memory consumed in the AVR does NOT double.  It's not like a basic stamp where nearly ALL of the overhead is "hidden" where you can't see it.

4x .1ufd (104) ceramic, 25 V Capacitors (.1ufd???? is that the same as a 0.1µF)

Yep.  0.1 microFarad bypass caps.  Exact value not too important...

2x  400x 1amp power diodes (400x 1amp????)

Should be "1n400x" for clarity.  The 1n4001 (50V) through 1n4007 (1000V) are common 1A rectifiers.  Since the voltage in this case is low, any of them would work.  Or any similar silicon rectifier diode of about 1A rating.

I'd like to point out that these days there are all sorts of adaptors that provide 5V on a USB female A connector, aimed at charging mp3 players and cell phones and PDAs and portable game systems;   USB is rapidly become a standard power interface, compatible power supplies can be found that are astoundingly cheap ( http://www.meritline.com/apple-iphone-3g-262-237---p-31362.aspx for example)
Something like this should happily power an arduino via a USB cable.  (Of course, it won't provide 9V on the other power pin, nor does it provide any intelligence or communications via USB.)

Similar devices designed for in-car use may be one of the better ways of powering your Arduino in a car, as well.  No power dissipation worries (these are almost all "switching" power supplies), and a nice layer of insurance between the nasty automotive power environment and sensitive electronics.

I've even been wondering whether it'd be time to get rid of the regulator and external power jack on board like the arduino.  Regulated wall warts are a lot more common, and a lot cheaper, than they used to be...

Aside from Mike, has anyone ever tried to publish anything in these magazines?  Despite complaints from other camps, most magazines are at the mercy of what is submitted to them.  And writing a magazine-quality article on anything is tougher than it might look.  (shucks, getting something "ready" to be on a web page or on Instructables is hard, and there's no editor to keep happy.)