Huh, missed CrossRoads' post earlier.

Looks like AVR CDC is taking some liberties with the USB spec, beyond those already taken by V-USB.  They mention problems with USB 2.0 hubs plugged into USB 2.0 ports that require compromises in the driver, for instance.  Neat project, but quite a hack to make it work.  Although, for pure through-hole, I don't know how many other options you would have.

I think I would stick to the AVRs with on-board USB, if that were at all a possibility.

Most folks in Arduino-land aren't setting fuses to disable reset either.    It's an uncommon request with a very specific caveat.

Anyway, you were right -- you can be tricky and time a serial upload just after power-up.  But for flash programming the AVR will only enter programming mode while reset is held low.  I don't know how long I was flashing AVRs before I knew that, so it's worth pointing out that there is no alternative (until you brute force your way in via HV programming.)

It looks like you're already using direct I/O access according to the top defines and the "too slow" comment on the commented-out digitalRead call.  You just need to make sure you use the right PORTx and pin offsets.  See the io.h include for your specific device, and the datasheet pin definitions, for information on that.

Your bigger problem might be serial print if you're trying to move away from the Arduino library.  AVR libc does have some basic building blocks for this, but it's not quite as plug-n-play.  You can selectively include some of the Arduino/Wiring files if you're careful to resolve (or remove) any inter-dependencies.

If you happen to find an existing firmware image that does USB-to-serial on an ATmega8, I would love to know.  I haven't looked, but that would be useful.  Not so useful to go to the trouble of writing the code myself just yet though. 

I built this guy's project to hook up NES/SNES controllers via USB.  The physical interface portion would be useful to you, although it's hardly difficult to come by, so you've probably seen it or variations thereof if you've been looking at software USB stacks.  It works a treat.

Really 2.4A continuous though?  Without saturating?  If so, I can't imagine that not being enough.  If you're driving high-current loads than that you should probably be powering them separately.

Agree on the diode isolation and accounting for slight voltage drop in the feedback divider.  Next question.  :-)

A shift register and a bunch of buffered ZIF sockets would make an easy batch programmer.  I would opt for a scheme that uses the shifter to basically trigger an Enable pin for each socket.  Whether that controls Reset, Vcc, or transistors on the data lines is up to you.

If you had a commercial op and would be doing this a lot, I would even go so far as using a fleet of ATtiny's to write each socket in parallel.  The real hassle would be loading and unloading the chips.  Hacking together an automated robot arm could be a good complement for, or alternative to, parallel flashing.

I would never consider bypassing the verify stage.  The meager time you save on rushing the process will rob you of your lunch money the first time there's a bad flash cell, a noisy PSU, or bad RFI.  If you're serious enough to need to bulk program chips, you should be serious enough to do some QA.  Just MHO of course.  :-)

The ATmega8 doesn't have USB functionality.  You would need to either provide a USB-to-TTL converter IC, use one of the AVRs with built-in USB support (like the modern Arduino Uno), or dedicate an ATmega8 to the task using a software USB stack.  The last is somewhat of a cheat, since running an AVR at 12MHz just baaaarrely has the power to process low-speed USB bus messages, and can't actually pull off 100% support of the protocol.

Keep in mind, you're getting into components that are likely to require careful design and surface mount skills.  If you're looking for reference designs, cool.  But, if you're not at a skill level to come up with your own, you might be facing a steep learning curve.  Not impossible by any means, but you'll need to consider what it's worth.

I think the OP's referring to writing directly to flash, not uploading sketches.  Direct programming is required to put the bootloader on bare AVR chips, or to reprogram chips that don't use a bootloader.

On some chips, it may be the only way to access an entire hardware port.  If you're building a commercial project and need to do 8-bit parallel I/O, it might be worth scrapping the reset pin, which might otherwise be hard-wired to Vcc anyway.  Aside from maybe a single development board, you'll only need it for initial programming and any service work.  As fungus mentioned, if and when it came time to update the code, you would use a high voltage programmer to override it.

Things are different at the hobbyist level, and you're right, you should probably just use a chip with sufficient I/O to avoid having to repurpose the reset pin.  :-)

This article was helpful when I had the same question:

http://arduino.cc/en/Hacking/BuildProcess

The short of it being, the IDE tidies up the sketch by merging all tabs into one file, adding prototypes, including library files in the build, and so on.  But that's about it.  Most of the "magic" is actually just C++ wrappers to add friendly functions and defines so you don't have to know so much about the hardware registers.

Moving to AVR C is fairly easy to do with Atmel Studio.  You can even import the Arduino libs and write your programs in a "real" C++ IDE.  That's actually a good way to go, because IMO, the Arduino IDE is really a horrible code editor, but the platform is so handy.

The major hurdle to clear here is whether the timer can be reprogrammed between tasks, or if the timer can be programmed once and its events used by both applications.

For example, if you're using the overflow interrupt to trigger a generic ISR, then you can probably use it for more than one purpose.  Say, for library 1, you need to do something on every overflow, whereas library 2 needs to act on every fifth overflow.  That could be accomplished by incrementing a counter, and triggering library 2 when it's mod 5.

If you're using CtC mode (clear timer on compare match) to fire at a variable frequency, which would be common for tone generators, then the window between events becomes less predictable for the "other" library.  But, if you never need to generate tones while the other library has access to the timer, you can multiplex their use.  You just have to be careful to re-initialize the timer settings every time either library needs to use it.

So yes, it's possible.  It would be typically disastrous to publish such a library, since guaranteeing the state of a non-exclusive timer is inherently troublesome.  But, if it's your own code, or a common use-case where a certain combination of libraries will always be used in tandem, it's absolutely doable.

I'll give that a shot sonnyyu, thanks! 

I saw the Xmega line had some hardware crypto, but I'm looking for something through-hole for now.  At any rate, having enough to do full SSL would be really nice, but I think I might run into memory limitations in short order.  Probably better to send raw but encrypted data via serial to an RPi or BB, then tunnel that over SSL for remote processing.  A simple AES implementation should suffice for now.

Anyone know of any relatively simple encryption modules that can be interfaced with an AVR?  AES over SPI or something would be nifty...

In this case, have you considered using a 3.3v ATmega-based board instead?  There are a few Arduino options for running 3.3v.  Alternatively, you could build your own.  Many people consider it perfectly fine to run 3.3v @ 16MHz on an ATmega328P.

Mostly, I figure if you don't need the horsepower of the Due, then using one (where a simpler micro would work) is a waste of good hardware.  :-)

I'm looking through the datasheet and the Arduino library code, and it seems to me that the AVR hardware is set up such that (in receive mode) you have to tell the TWI interface whether to ACK the next byte before you see it.  I.e., there doesn't appear to be an event fired AFTER receiving a byte of data, but BEFORE sending ACK (while the TWI hardware holds SCL low.)

Am I right?  Is typical I2C byte transfer etiquette that you go ahead and accept every byte, without verifying the content is acceptable first?  I'm thinking of cases where you're accepting a value that might only be valid between 0-99 and you receive 150, for e.g.  It seems like you would want to throw a NACK to signify the data is invalid.  But it looks like the implementation forces you to accept the data byte and deal with validity communication on a higher level, maybe by returning a message in another transaction, or just silently discarding the request.

Thoughts?