http://arduino.cc/en/Main/ArduinoBoardEthernet

has anyone else has troubles uploading sketches to am arduino ethernet with an ftdi cable? I know my cable is good but ide fails to communicate with it. I've tried reburning optiboot (successfully). I've got the custom board profile selected, and the appropriate comm port selected. I'll ring out the pins tonight, but I'm pretty stumped a of right now.

Considering it, trying to figure out of the USB thing is a show stopper...

Would it be legitimate for me to make a product that includes the ATMega8U2 running the firmware from the Arduino UNO, unmodified, and sell it? Or would I have to also go off and purchase my own VID/PID? This topic seems remarkably complicated in my cursory background research so far. I'm hoping I can get some straight answers and discussion here!

I'm still curious as to why they used the QFN package on the UNO, was it just a matter of a smaller footprint was needed, or was it cheaper at the time / at the production volume,something else?

Yea I tend to agree. I think it might just be a typographical error in the datasheet at this point, but on page 2 it shows "CTS / HWB..." on pin 13 of the QFN package, but "/ HWB /" (missing the CTS) on pin 13 of the QFP package for example. I very likely am just over-reacting to a typo.

Is there any reason I couldn't use the ATMEGA8U2-AU (TQFP32 package) to make my own Arduino UNO? My intuition says it should be fine, but I'm seeing some pin function exclusions (at least in name) in the datasheet, so I thought I'd check with the forum first...

Hi all - I'm (the other) half of Wicked Device... I just wanted to close the loop, so to speak, on the source code question with respect to the Wicked Node / Receiver. The code running on the transmitter microcontroller (ATTiny44A) has been posted at http://node.wickeddevice.com/?page_id=6, under the heading "Node Code". It's written for the avr-gcc compiler, and it's decently commented. That being said, I'm more than happy to answer questions about it, and to incorporate suggestions as made by the community, but this thread is probably not the best place for it...

I have got to say, DCDW is pretty darned cool peice of engineering. Kudos! I'm really looking forward to the DCDW vs DCSW Shootout http://arduino.cc/forum/index.php/topic,63138.0.html with AltairLabs. I think we'll both have our strengths and weaknesses, but in the end it's a really great opportunity to learn from each other! See ya there... at high noon (sorry couldn't help myself).

Does anyone know of a way to conact Michael Margolis? Email? Twitter?

I respect your opinion on the matter. However I would really like to come up with a solution where using a programmer is not a barrier to entry.

I think that's the biggest advantage of the Arduino architecture. You can buy one and all you need is a computer to start hacking with it. I could be wrong, but I think it's not so overwhelmingly difficult as to not merit giving it a shot. If I invest a little bit of my own pain and suffering to make it easier for the community to use, I'm hoping I can reach more people. I mean that's what Arduino is all about right?

In review, I posted to this forum for advice on (1) whether it was a problem of porting an Arduino subset to an ATTiny was solvable (am I crazy?), and (2) if so how to go about doing it... I've gotten some good feedback so far, and I'm looking forward to more! Thanks everyone so far!

My rationale for wanting a bootloader is so that people can program and target my board using the Arduino IDE. Sorry I thought that was self-evident.

To your point about interrupt vectors. There would be nothing stopping me from say remapping the interrupt vector addresses at bootloading time in principle... on the other hand, I could simply not support custom interrupt vectors as a simpler option.

I'm sorry, what is the "interrupt page" you are referring to? I realize it's a bit of a maintainability issue, but by compiling the boot loader code, and looking at the lss file, you know in principle where the boot loader code ends in memory. You could use that information to decide where to point ap_start, could you not? Then the rest of the bootloader code would be more or less the same, except you would have to add this known location as an offset to the address targetted by the Arduino IDE...?

Udo, interesting... can you define more precisely what is "bootloader support" defined as?

The ATTiny44A has self programming capability... are we talking past each other? See chapter 18 of the Datasheet titled "Self-Programming the Flash"...

Hi I'm interested in creating/porting an Arduino Bootloader / Platform for an ATTiny44A. I've read through the source code for the Mega168 bootloader that comes with the Arduino IDE. I believe that bootloader relies on hardware support (e.g. BOOTSZ and BOOTRST fuses, and separate memory space for bootloader code), that the Tiny AVRs do not generally have.

I was thinking I could use the implementation of AVR307 to use the USI as a half-duplex UART (uses Timer0 interrupt, and pin-change interrupt). Can anyone offer guidance on how to go about writing/porting the bootloader code for a chip that doesn't have hardware support for bootloaders?

I presume I would put my bootloader code at the normal location for address main (e.g. 0x029e or wherever the compiler puts main). I would then make it so that 'address' in the bootloader code added an offset that put me just past the end of main, and have 'app_start' set to that address. Am I thinking about this correctly or am I totally missing something? Thanks!