This project started as a simple microcontroller replacement on this IR camera remote control PCB. But the soldering job went rather badly for [Balthamos] so he changed things up and designed his own simple AVR remote shutter release and intervalometer.
The DIP chip seen with most of its legs bent backwards is the ATtiny25 which makes the system work. It’s patched into the traces for the battery connections, button (on the other side of the board) and the IR LED he’s pinching with his left hand. Point it at a Cannon camera and push the button to snap a photo. But as you can see in the clip after the break it also serves as an intervalometer; letting him take several pictures with a user-defined pause between each. That mode is selected by first pressing and holding the button. Once released the chip waits for a second button press to register the delay. The new circuit still fits in the original case after just a bit of alteration to it.
Continue reading “ShuttAVR can snap a pic or serve as an intervalometer”
Ah, PIC vs. AVR, the never-ending battle of electronic design supremacy. Some people swear by Atmel’s AVR microcontrollers, while others are wrong. [majenko] is firmly planted in Microchip’s PIC camp, so he wrote up a nice comparison of Atmel’s AVR versus Microchip’s PIC family of microcontrollers. The results aren’t that surprising; PIC microcontrollers come out as a better product that no hobbyist uses because no hobbyist uses them.
Atmel and their series of AVR microcontrollers has seen a huge increase in popularity in the hobbyist market in the last few years, no doubt thanks to the Arduino and other AVR-powered dev boards. This isn’t to say Microchip and PIC haven’t seen their time in the lime light; there was a time when you could actually buy electronic components at Radio Shack, including kits containing Microchip’s very popular but somewhat outdated Basic Stamp.
After going over the capabilities of the Atmel AVR ATMega328p, the similarly equipped Microchip’s PIC PIC18F25K80, and TI’s MSP430G2533, [majenko] found the perennial favorite, the AVR, lacked in some very important categories. The AVR has a lower resolution ADC, fewer PWM pins, fewer 16-bit timers, while costing about $0.75 more.
Of course [majenko]’s analysis doesn’t take into account the intangibles of choosing a PIC over an AVR. Thanks to the Arduino’s adoption of the AVR, there are many, many more code and schematic examples floating around on the Internet for just about every project imaginable. The development tools for PIC are a bit more expensive than their AVR equivalents; A PICkit2 runs about $50 while AVR ISP programmers can be found just about everywhere for pocket change.
It’s a lazy Sunday, so all ‘yall can go on and argue in the comments.
We won’t call it useless, but we will ask why [Dan] wrote a brainfuck interpreter for the AVR
It’s not generating code for the AVR; think of it more as a bootloader. To run a brainfuck program, [Dan] uploads it to the EEPROM inside his ATMega32, after which the microcontroller takes over and starts performing whatever instruction the brainfuck program tells it to do. Because the whole thing runs off the EEPROM, the code size is limited to 1022 bytes. Enough for any brainfuck program written by a human, we think.
As for why [Dan] would want an AVR to build an interpreter for a language that is nearly unreadable by humans, we honestly have no idea other than the common, ‘because it’s there’ sentiment. There are some pretty cool projects out there that use brainfuck, including this genetic algorithm software developer. Right now, though, blinkey LEDs are enough to keep us happy, so you can see a video of brainfuck doing its thing on a LED bar display after the break.
Continue reading “Interpreting Brainf*#k on an AVR”
We’ve been following [CNLohr]’s process of creating an AVR-powered microscope slide running Linux and interfacing redstone circuits in Minecraft to real world electronic for a while now, but we’re really at a loss for words on how it works. Well, now there’s a video explaining everything you want to know about this amazingly complicated and overwrought thing.
The device is powered by an AVR microcontroller and Ethernet controller running [Fabrice Bellard]’s JSLinux in a browser. [CNLohr] added a few bits to JSLinux allowing him map the x86 IO ports emulated inside JSLinux to the AVR’s IO ports. This allows him to query the status – both analog and digital – using just a browser. Very cool, but [CNLohr] can also run his Minecraft server optimized for 8-bit devices on this microscope slide server to create a bridge between real electronics and redstone circuits.
In the video after the break, you can see [CNLohr]’s overly convoluted walk through of what’s going on with this microscope slide server. As a little bonus, you can also catch a glimpse of Hackaday at 00:20 in [CNLohr]’s most visited / new tab thingy in Firefox. We’re honored, really.
Continue reading “[CNLohr]’s Microscope Slide Linux AVR Minecraft… thing”
An awful lot of microcontroller projects use timers to repeat an action every few minutes, hours, or days. While these timers can be as accurate as a cheap digital wrist watch, there are times when you need a microcontroller’s timer to measure exactly, losing no more than a few milliseconds a day. It’s not very hard to get a timer to this level as accuracy, as [Karl] shows us in a tutorial.
The problem with keeping time with a microcontroller has to do with the crystal, clock frequency, and hardware prescalers of your chip of choice. [Karl] started his project with an ATMega168 and a 20 MHz crystal and the prescaler set at 256. This made the 78.125 interrupts per second, but the lack of floating point arithmetic means one second for the microcontroller will be 0.9984 seconds to you and me.
[Karl]’s solution to this problem was to have the ATMega count out 78 interrupts per second for seven seconds, then count out 79 interrupts for one second. It’s not terribly complicated, and now [Karl]’s timers are as accurate as the crystal used for the ‘168’s clock.
Here’s an interesting tip that can help improve your ability to write assembly code. In an effort to remove the complexity of assembly code for an AVR project [Quinn Dunki] figured out how to use macros when writing AVR code with the GNU toolchain. Anyone using AVR-GCC should keep this in mind if they ever want or need to pound out a project in assembly language.
If you look at the code snippet above you’ll see two commands that are obviously not assembly; PulseVRAMWrite and DisableVRAMWrite. These are macros that direct the assembler to roll in a hunk of code. But avr-as, the assembler used with this toolchain, lacks the ability to handle macros. That’s too bad because we agree with [Quinn] that these macros make the code easier to read and greatly reduce the probability of error from a typo since the code in the macro will be used repeatedly.
The answer is to alter the makefile to use GNU M4. We hadn’t heard of it, but sure enough it’s already installed on our Linux Mint system (“man m4″ for more info). It’s a robust macro processor that swaps out all of her macros based on a separate file which defines them. The result is an assembly file that will play nicely with avr-as.
Her implementation is to help in development of the GPU for her Veronica computer project.
[Steve] created an AVR programmer using an old USB keyboard. We feature a bunch of AVR programmers, but this one is made from parts that many people will have lying around. There are two components: the controller PCB from a USB keyboard, and an optocoupler for emulating key presses.
In order to send data to the AVR, [Steve] used the LED outputs on the keyboard. These LEDs can easily be toggled according to the HID device specification. They provide a 5 volt output with current limiting resistors, which means they can be connected directly to the target AVR.
Reading data is a bit more complex. The optocoupler tricks the keyboard into believing that a single key has been pressed, firing off a data transfer. The MISO pin on the AVR is connected to the row and column of the shift key, which is read by the driver.
On the software side [Steve] created an avrdude interface driver. This allows the programmer to be used with avrdude, just like any other programmer. [Steve] does point out that it isn’t the fastest programmer since the keyboard tries to debounce the MISO input, greatly limiting the speed. However, since it’s made from stuff you might have in your junk bin, it’s a neat hack.