It is funny how almost everything has its own set of problems. Rich people complain about taxes. Famous people complain about their lack of privacy. It probably won’t happen us, but some Kickstarter campaigners find they are too successful and have to scale up production, fast. We’d love to have any of those problems.
[Limpkin] found himself in just that situation. He had to program several thousand Atmel chips. It is true that you can get them programmed by major distributors, but in this case, he wanted unique serial numbers, cryptographic keys, and other per-chip data programmed in. So he decided to build his own mass programming workbench.
Turning an Arduino of virtually any sort into a simple AVR 6-pin ISP programmer is old hat. But when Atmel came out with a series of really tiny AVR chips, the ATtiny10 and friends with only six pins total, they needed a new programming standard. Enter TPI (tiny programming interface), and exit all of your previously useful DIY AVR programmers.
[Kimio Kosaka] wrote a dual-purpose TPI and ISP firmware for the ATmegaxxUn chips that are used as a USB-serial bridge on the Unos, and constitute the only chip on board a Leonardo or Micro. The catch? You’re going to have to do a little bit of fine-pitch soldering. Specifically, [Kosaka-san] wants you to get access to an otherwise obscured signal by drilling out a via. We’d do it just for that alone.
The Apple II was one of the first home computers. Designed by Steve “Woz” Wozniak, it used the MOS technologies 6502 processor, an 8-bit processor running at about 1 MHz. [Maxstaunch] wrote his bachelor thesis about emulating the 6502 in software on an AVR1284 and came up with a handheld prototype Apple II with screen and keyboard.
Originally, [maxstrauch] wanted to build an NES, which uses the same 6502 processor, but he calculated the NES’s Picture Processing Unit would be too complicated for the AVR, so he started on emulating the Apple II instead. It’s not quite there – it can only reference 12K of memory instead of the 64K on the original, so hi-res graphic mode, and therefore, many games, won’t work, but lo-res mode works as well as BASIC (both Integer BASIC and Applesoft BASIC.)
[Maxstrauch] details the 6502 in his thesis and, in a separate document, he gives an overview of the project. A third document has the schematic he used to build his emulator. His thesis goes into great detail about the 6502 and how he maps it to the AVR microcontroller. The build itself is pretty impressive, too. Done on veroboard, the build has a display, keyboard and a small speaker as well as a micro SD card for reading and storing data. For more 6502 projects, check out the Dis-Integrated 6502 and also, this guide to building a homebrew 6502.
We’ve seen tiny microcontroller-based computers before, but nothing like this. Where the usual AVR + display + serial connection features BASIC, Forth, or another forgotten language from the annals of computer history, this project turns an AVR into a Lisp machine.
The μλ project is the product of several decades of playing with Lisp on the university mainframe, finding a Lisp interpreter for the 6800 in Byte, and writing a few lisp applications using the Macintosh Toolbox. While this experience gave the author a handle on Lisp running on memory-constrained systems, MicroLisp is running on an ATMega328 with 32k of Flash and 2k of RAM. In that tiny space, this tiny computer can blink a few boards, write to an OLED display, and read a PS/2 keyboard.
The circuit is simple enough to fit on a breadboard, but the real trick here is the firmware. A large subset of Lisp is supported, as is analog and digitalRead, analog and digitalWrite, I2C, SPI, and a serial interface. It’s an amazing piece of work that’s just begging to be slapped together on a piece of perfboard, if only to have a pocket-sized Lisp machine.
It probably doesn’t matter much for the hacker who sleeps with a bag of various microcontroller flash programmers under the pillow, but for an end-user to apply a firmware upgrade, convenience is king. These days that means using USB, and there are a few good AVR USB bootloaders out there.
But [Dmitry Grinberg] wanted more: the ability to encrypt the ROM images and verify that they haven’t been tampered with or otherwise messed up in transit. Combined with the USB requirement, that meant writing his own bootloader and PC-side tools. His bootloader will take unencrypted uploads if it doesn’t have a password, but if it’s compiled with a key, it will only accept (correctly) encrypted hex files.
Since the bootloader, including the USB firmware, is on the hefty side at 3.3 kB, [Dmitry] included hooks to re-use the bootloader’s USB code from within the target application. So if you were going to use V-USB in your program anyway, it doesn’t actually take up that much extra space. It’s a cute trick, but it ties the bootloader and user program together in a way that gives us the willies, without specifically knowing why. Perhaps we can debate this in the comments.
If you need an AVR USB bootloader, but you don’t need the encryption, we like Micronucleus. But if you need to deliver updates to users without them being able to modify (or screw up) the code in the middle, give [Dmitry]’s setup a try.
It’s not just an LED-blinker, though. He added in a light-detection function so that it only switches on at night. It uses the Forest Mims trick of reverse-biasing the LED and waiting for it to discharge its internal capacitance. The point is, however, that it gives the chip something to do instead of simply sleeping.
Although he’s an AVR user by habit, [Thierry] finds in favor of the PIC because it’s got a lower power draw both when idling and when awake and doing some computation. This is largely because the PIC has an onboard low-power oscillator that lets it limp along at 32 kHz, but also because the chip has a lower power consumption in general. In the end, it’s probably a 10% advantage to the PIC on power.
If you’re competent with one of the two chips, but not the other, his two versions of the same code would be a great way to start familiarizing yourself with the other. We really like his isDarkerThan() function which makes extensive use of sleep modes on both chips during the LED’s discharge period. And honestly, at this level the code for the two is more similar than different.
(Oh, and did you notice [Thierry]’s use of a paper clip as a coin-cell holder? It’s a hack!)
Surprisingly, we’ve managed to avoid taking a stray bullet from the crossfire that occasionally breaks out between the PIC and AVR fans. We have covered a “shootout” before, and PIC won that round too, although it was similarly close. Will the Microchip purchase of Atmel calm the flames? Let’s find out in the comment section. We have our popcorn ready!
We often see “logic analyzer” projects which are little more than microcontrollers reading data as fast as they can, sending it to a PC, and then plotting the results. Depending on how fast the microcontroller is, these projects range from adequate to not very useful.
At first glance, [esot.eric’s] logic analyzer project has an AVR in it, so it ought to be on the low end of the scale. Then you look at the specs: 32 channels at 30 megasamples per second. How does that work with an AVR in it?
The answer lies in the selection of components. The analyzer uses a 128MB SDRAM DIMM (like an older PC might use for main memory). That makes sense; the Arduino can’t store much data internally. However, it isn’t the storage capacity that makes this choice critical. It seems [esot.eric] has a way to make the RAM “free run”.
The idea is to use the Arduino (or other host microcontroller) to set up the memory. Some of the memory’s output bits feedback to the address and data lines. Then the microcontroller steps aside and the SDRAM clocks samples into its memory by itself at the prevailing clock rate for the memory.