While tablature-based music probably annoys “properly” trained musicians to no end, it has given many musicians and musical-hobbyists their first introduction to the world of guitar. The [Tabstrummer] takes this to a whole new level, allowing chords to be programmed into this instrument and played back. Once pre-programmed chord is set, the “conductor-strings” are strummed to allow the chord to play.

This device is based around an Atmel microcontroller and features a MIDI output as well as an audio-out jack. Besides the interesting electrical hardware, the housing seems to be quite well-built featuring what appears to be an acrylic or polycarbonate body. Although not quite the same thing, possibly some influence was gained from the [Keytar]. It’s heyday may be past, but not forgotten.

Check out the video below for a Christmas-themed jam played on the [Tabstrummer] or check out their video page for several more songs. This “hack” is being considered as a commercial product, so the inventors would love to hear your feedback!

A few years back Atmel announced a new line of chips, the XMega series. We see the name bouncing around here and there, but when [Michael Kleinigger] mentioned that he’s seen very few project using these chips we realized that not only is he right, but we know next to nothing about them. Just give his XMega review post a whirl and you’ll be up to speed in no time.

He compares an XMega128A1 side-by-side with an ATmega1280. For those that abhor reading paragraphs full of words, there’s a table that can give you the quick facts like how the XMega costs less and runs faster. But we know from past discussions (like the one on PWM) that [Mike] knows his stuff so the whole thing’s worth a read. He’ll lead you through the programming tool chain (which hasn’t changed), a bit about the new event system, and then finish with a demo program on the Xplained development board.

Reader, [Michael Rubenstein], sent in a project he’s been working on. Kilobot, as stated in the paper(pdf), overcomes the big problems with real world swarm robotics simulations; cost, experiment setup time, and maintenance. The robot can be communicated with wirelessly, charged in bulk, and mass programmed in under a minute. Typically, robots used for swarm research cost over a $100, so large scale experiments are left to software simulation. These, however, rarely include the real world physics, sensor error, and other modifying factors that only arise in a physical robot.  Impressively enough, the kilobot comes in far under a hundred and still has many of the features of its costlier brothers. It can sense other robots, report its status, and has full differential steer (achieved, surprisingly, through bristle locomotion). There are a few cool videos of the robot in operation on the project site that are definitely worth a look.

We’ve already added the components needed to build [Rucalgary's] tiny POV device to our next parts order. The little device sets a new standard for tiny persistence of vision boards. Instead of relying on the user to find the best speed and timing for swinging the board around, [Rucalgary] used an accelerometer. This is the point at which we’d usually groan because of the cost of accelerometers. We’re still groaning but this time it’s for a different reason.

The accelerometer used here is a Freescale MMA7660. It’s an i2c device at a super low cost of less than $1.50. The reason we’re still groaning is that it comes in a DFN-10 package that is a bit harder to solder than SOIC, but if you’ve got patience and a good iron it can be done. An ATmega48 drives the device, with 8 LEDs and one button for input. On the back of the board there’s a holder for a CR2032 coin cell battery and a female SIL pin header for programming the device.

Check out the video demonstration embedded after the break. We love it that the message spells and aligns correct no matter which way the little board is waved.

[Thanks Paul]

[Mathieu] has bee working to refine the code running on an LED matrix, and added some neat display tricks along the way. He wanted to make the display directly addressable from a computer. The 96×64 bi-color LED display is powered by an Atmel FPSLIC and already used double-buffering. Enabling a PC to write directly to one of the buffers was not too hard, requiring just a bit of optimization to get the timing right. From the look of the video after the break, he nailed it.

The video feed is generated from a webcam stream using Matlab to process each image. Just 50 lines of code captures a frame, sizes it appropriately, converts the result to black and white for edge detection, then finishes the job by compressing image data for transmission to the embedded processor. We’d like to say it’s easier that it sounds but we’re pretty impressed with this work. The display manages about 42 Hz with the current setup.

[jonh] religiously tracks the miles he rides on his bicycle. When his odometer’s battery started getting low, he wanted a way to run the miles up to where they were before, since replacing the battery resets everything to zero. [jonh] used an Atmel microcontroller to run up the miles on his bike computer so he could pick right back up where he left off. There is definitely a Ferris Bueller’s Day Off joke in here somewhere.

The bike computer itself is designed to plug into a base that connects to a magnet-triggered reed relay. It uses a wheel-mounted magnet to count the number of revolutions made and thus the distance traveled. [jonh] hooked up a simple microcontroller-driven circuit to these connectors to trick the bike computer into thinking it was moving, and moving fast! Since he knew the number of miles he wanted to sandbag onto the odometer, he was able to program it to run up the proper amount of miles and then stop. There’s no source code listing for the project, but this shouldn’t be too hard to reproduce. He provides a pencil-drawn schematic for the connection to the cyclometer from the microcontroller. At the end, there’s also some sage advice for those of you who are interested in building a decent hardware hacking lab on the cheap.

Here at Hackaday, we see microcontroller based projects in all states of completion. Sometimes it makes the most sense to design systems from the ground up, and other times when simplicity or a quick project completion is desired, pre-built system boards are a better choice. We have compiled a list of boards that we commonly see in your submitted projects, split up by price range and with a little detail for reference.

After reading our list, sound off in the comments or on this forum post, and we may include your board in a follow-up guide at a later date. We will also be giving away 10 Hackaday stickers to the most insightful, the most original, and most useful advice given on the forum, so if you haven’t registered yet, now would be a perfect time. Winners of the sticker giveaway will be selected from the forum thread, and the final decision for prizes will be judged by the wit and whim of the Hackaday writing team. More prize details to follow in the thread. Read on for our guide based on past project submissions.

The Cheap ($0-$50):

When it comes to cheap boards, users can expect a simple breakout board, usually with some debugging facilities and minimal extra components. These boards tend to be aimed at hobbyists and the education crowd rather than companies who can afford full featured development setups for their engineers. Unfortunately, boards that come directly from manufacturers tend to have locked down or overly simplified IDEs or debugging software, though low price points often inspire the open source communities to write their own to take advantage of all the features.

• TI’s MSP430 Launchpad: Coming in at $4.30, TI’s Launchpad board is definitely a bargain. For your money, you get a set of 16-bit MSP430 processors, a mini-USB debugger and programming interface, and a set of Windows IDEs to choose from. Not much more to write home about, but we have featured a number of projects with this family of microcontrollers running the show.
• STMicroelectronic’s Discovery: Costing you a paltry $11.85, This 32-bit ARM processor may be one of the best performance to cost values. Similar to the Launchpad, the Discovery has a mini-USB interface, a breakaway programmer and debugger, and a few locked down IDEs to select. For students or professionals looking for experience with the ARM architecture, this Cortex-M3 based system would be a great place to start.
• The Arduino Family: Needing no introduction, these 8-bit AVR based systems have been displayed by us numerous times. Due to an open source hardware and software design, these boards are available for as low as $20 or so for Arduino Compatable clones, or any price range up depending on included peripherals. Because of the simple IDE and coding environment familiar to anyone familiar with C, C++, or Java, the Arduino is a common choice for beginners, non-engineering types, and professionals alike.

Mid-Range Boards ($50-$150):

For a little more money, more can be expected from a development board. Often featuring higher I/O pin counts, more complex interfaces such as host USB ports, Ethernet, or Video-Out, these boards are a great place for a little computational and functional muscle. However, with a higher cost, it is more difficult to just throw one of these boards at any one-off project. More costly boards are often supported better as well, because they are used by engineers who will decide on important purchasing decisions. This area is also a transition area from more hardy microcontroller type boards into the more powerful microprocessor type systems (such as shifting from the Cortex-M to the Cortex-A series of ARM processors).

• The Arduino Mega: For all the same reasons as the original Arduino, the Arduino Mega has its place in a prototyping or development environment. For a bit more money than the original, extra code space, processing power, and I/O pins are gained, with the same comfortable, familiar, and similar development tools. The Arduino Mega runs at $65, which makes for a costly 8-bit system.
• The Chumby Hacking Board: An interesting example of a product going from production to prototyping as an afterthought, this board is based on the guts of the Chumby One, featuring a 32-bit Freescale i.MX ARM processor at 454 MHz. This system has video out, as well as a trio of USB ports for all the peripherals you can find or write your own drivers for. The Chumby Hacking board clocks in at a reasonable $90 or so, though supplies seem to be dwindling, so act fast if interested.
• The Original BeagleBoard: At the top of the price range, the BeagleBoard (Revision C4) features a 600 MHz Cortex-A8 ARM processor capable of running a number of Linux systems, including Angstrom and Ubuntu. Designed to interface with cool toys like touchscreens, this board also features a powerful DSP chip for crunching numbers, as well as processing video and sound. For a newly discounted rate of $125, this compact powerhouse could be yours.

The Upper Crust ($150+)

At this price range, these boards often contain ARM processors from the Cortex-A series, and have more in common with high-end smartphones than the microcontrollers usually seen on Hackaday and in day-to-day life. Boards like these are a real investment, and often cost and perform similar to many older or low-end PCs and netbooks at a considerably more efficient performance to power use ratio in most cases. These boards tend to run Linux-based operating systems, including Android as well as others.

• The BeagleBoard xM: Coming in at just around $150, this big brother to the first BeagleBoard adds parts such as onboard Ethernet, an additional 2 USB ports, and a bump to a 1 GHz processor. Although the MSRP is listed at $149, a high demand has pushed the cost well above that at places where stocks are even available. Because of a strong similarity to the original BeagleBoard, the existing community is strong, and full of examples and guides to get the board going
• The PandaBoard: With features as far away from an 8-bit microcontroller as imaginable, this board comes dressed to the nines featuring a dual-core 1 GHz processor capable of handling 1080P video stream. We realize this is probably out of the ballpark of just about any “hack” level project at $174, but we know there are some engineers out there very excited to see this.

In Summary:

We know that brand and experience preference can be a strong motivator, so be productive with your advice and sound off in our forum with your picks for our follow-up post(s). We will do our best to wrap up all the information you provide into a more definitive, and hopefully even more informative guide for beginners and professionals alike.

Most of the dice related hacks we run into have to do with pseudo random number generation, but today we saw something different. This sleek looking jumbo die is actually a prize holding box opened by a secret sequence of rotations. Using an accelerometer and an ATmega 328 with a sub-micro servo to control the locking mechanism. Worried about the batteries going flat and losing your treasure indefinitely? Good news! The batteries are accessable without giving away the secret inside.

It also turns out that this is an update to an earlier project from the same laboratory, so be sure to check that out as well to see where this build came from. Code is available for anyone looking to make their own, as well as a useful parts list.

[via Hacked Gadgets]

Those who are familiar with Atmel’s line of 8-bit AVR microcontrollers should already know that some of them have support for external RAM. But have you ever actually used this feature? We haven’t. Now you can learn how it’s done by reading through this guide. It touches on all of the hardware, but doesn’t dwell on it. Instead, you’ll get the background you need on how to write to, read from, and test an external module like the one sticking up in the image above. The test routine shows how to make sure everything’s working correctly with your memory mapping before you begin developing firmware around this increased capacity.

[Thanks Spman]

You may be able to write the most eloquent code in the history of embedded systems but without a way to run it on the hardware it will be worthless. In this installment of the tutorial series we will:

• Look at some of the available AVR programmer options
• Place the microcontroller on a breadboard and connect it to a power supply and a programmer.
• Use programming software to send some example code to the microcontroller

If you missed Part 1 take a few minutes to review that portion of the tutorial and then join us after the break.

Series roadmap:

• AVR Programming 01: Introduction
• AVR Programming 02: The Hardware
• AVR Programming 03: Reading and compiling code
• AVR Programming 04: Writing code

Programmers

As I said before, if you want to get it on the chip you’ve got to have a programmer. There are a huge number of options, but I’ll cover a few of the easiest and least expensive. We are focusing on In-System Programming (ISP) which means that you can program the chip without removing it from the circuit.

DAPA Cable

A Direct AVR Parallel Access, or DAPA cable, is an incredibly simple and cheap programming method. You can build one very quickly for a few bucks worth of parts, but the convenience comes with a few gotchas. The first is that you must have a parallel port on your computer; something that modern laptop and some modern desktops don’t have. But if you’ve got an old PC around that has one this will get you up and programming in no time.

In fact, the first AVR prototyping I did was with one of these cables. That is, until I discovered another gotcha. This will only program low-speed chips. If you try to run the chip’s clock at full speed (by changing fuse settings… more in Part 3) you won’t be able to use a DAPA cable to talk to it any longer. There’s also the possibility of damaging your parallel port or worse if you do something wrong. But if you want to go for it anyway, here’s how I built mine.

It connects to a computer using a DB25 connector. As you can see in the schematic, I’ve used 1 kilo Ohm resistors on the Reset, SCK, MISO, and MOSI pins for current protection. I did not use a resistor on the ground pin. I used a piece of ribbon cable, soldering one end to each of the five signal lines shown in the schematic. On the other end of the ribbon cable I used a connector housing with six slots, filling one of them with a blank so that I could keep track of the signals. This is easy to plug into a pin header or connect to jumper wires as shown above. In retrospect it may have been a better choice to use a 2×3 IDC connector and route the signals using the AVR ISP standard (from AVR: In-System Programming PDF). If you go this route chances are you’ll upgrade before long so don’t agonize of the design details.

Arduino

I would be remiss to skip over using an Arduino as a programmer. They’re ubiquitous with the embedded systems crowd and if you don’t already own one, you can try to find someone to lend you theirs for a little while. All that is required is to write an AVR programmer sketch to the Arduino and make the programming connections. We’ll take a look at this method later in the post.

USBtinyISP

The USBtinyISP is an In-System-Programmer based around an ATtiny2313 that uses a USB connection (see where the name comes from?). It isn’t a bad choice for your first programmer. If you are confident in your skills you can build the circuit circuit yourself and use a DAPA cable to get the programming firmware onto the chip. Or you can just buy it from Adafruit Industries. But if you think you’re going to be serious about AVR development, you should consider shelling out the extra bucks for a professional programmer.

Professional programmers

The Ateml programmers are the gold standard. They offer something that none of the other hardware we’ve covered has, the ability to recover a chip that you’ve messed up. If you want to use the reset pin as I/O, you will need to use High Voltage Parallel Programming to talk to your chip. Even if you don’t decide to do that, at some point you’re going to screw up and you’ll need to recover a process, which helps offset the extra cost of a professional programmer. It is possible to use an Arduino for High Voltage Parallel Programming to recover your AVR, but that’s another hack in itself.

We use an AVR Dragon for pretty much everything. But the STK500 is a very popular board even though you need a serial port to use it. It has chip sockets, buttons, and LEDs for on-board prototyping. The Dragon leaves options open with unpopulated socket footprints, and it uses a USB connection.

If you’re in this for the long haul there’s no substitute for one of these choices.

We should at least mention the MKII, a programmer that offers ISP in the same way that the USBtinyISP does, but also provides JTAG, debug wire, and few others. We have no experience with this unit so you’ll have to do your own research if you’d like to know more. As for the other programmers out there, use Google or check the comments to this post as people usually don’t like to keep their preferred programmer choice a secret.

Bootloader

A bootloader is not really a programmer, but a way to get around using one. A bootloader is a set of code already on your microprocessor. It handles basic input and output neccessary to write your code into the chip’s memory. The bad news is that they do take up programming space, but you won’t have to buy a hardware programmer.

Programming a chip with a bootloader on it is beyond the scope of this tutorial. But it’s not hard to learn to do. In fact, this is how it is possible to program an Arduino without a separate hardware programmer.

Setting up our test circuit

Enough talk, let’s build something! We need four things: A microcontroller, something to power it, some way to program it, and something to show us it’s working.

Hardware:

• Solderless breadboard
• Jumper wires
• ATmega168 microcontroller
• 78L05 voltage regulator
• 100uf electrolytic capacitor
• 10uf electrolytic capacitor
• LED
• 180 Ohm resistor (any resistor between 180 and 330 Ohms will work fine)
• A programmer (we’ll show both a DAPA and an Arduino)

What we’re doing

In a  nutshell, we’re going to blink an LED as our first embedded program.  This takes a few components: a power supply, the microcontroller itself, and the LED and its current limiting resistor.

The power supply consists of a voltage regulator which will take an input voltage above 7v and output a constant voltage of 5V. In order to work correctly, this circuit requires two filtering capacitors. The capacitors act like storage tanks, absorbing small fluctuations on the power rail to provide a steady source of electricity to keep our microcontroller safe and happy.

As an output we are going to use an LED. We must include a resistor to limit the amount of current that will flow when the software lights it up. Without this current limiting resistor, current would flow at levels that are unsafe for the LED, the microcontroller, or both.

The circuit schematic

Above is the circuit we are using as an example. The a simple 5v regulator circuit using an LM7805 linear regulator and two filtering capacitors is on the left, separated from the rest by a dotted box. If you already have some type of regulated 5v supply save yourself some time and use that.

You may also notice that the chip in the schematic is labelled AVR-MEGA8. The ATmega168 that we’re using is pin-compatible with at ATmega8. That means that you can swap one for the other and all 28 pins will be where they’re supposed to be, so this will cause no issue.

It is a good practice to add a few components not seen here. There should be two 0.1 uF capacitors for decoupling; they filter out fluctuations on the power rails called noise. One between VCC and GND, the other between AVCC and AGND (as close as possible to the pins). There should also be a pull-up resistor on the reset pin with lets an incredibly small amount of current trickle into the pin at a 5V level. This the chip from resetting by accident when it’s floating (not connected so there’s no clear 0 or 5V value). I’ve omitted these parts for simplicity and it shouldn’t be an issue with this simple project. But as your projects get more complicated, neglecting these considerations will come back to bite you.

The circuit built on a breadboard

I started building the circuit by adding the voltage regulator to the breadboard. Then connect the ground leg to the ground rail on top of your breadboard, and the output leg to the voltage rail of your breadboard. I have also added two wires that I will eventually connect to the positive and negative terminals of a 9V battery.

It is important to read the datasheet for your voltage regulator (example: LM7805) to figure out which lead is input, ground, and output. Your regulator may look different from mine as they do come in different packages. In the image above, the input lead is on the left, the ground is in the middle, and the output lead is to the right.

Now I’ve completed the power supply by adding the 100 uF capacitor between the input leg and ground leg of the regulator, and the 10 uF capacitor between the output leg and ground leg. Pay careful attention to these capacitors, one lead should be marked as negative (a band with a minus sign) on the case of each capacitor. Before adding the microcontroller it would be a good idea to check the voltage output using a multimeter. Too much juice can destroy your new chip.

After checking to make sure I had a steady 5V source, then disconnecting the battery, I added the ATmega168 microcontroller to the board. Note that the dimple is pointing to the left. This is important, as the standard orientation and lead numbering of a DIP package shows that pin 1 is now on the lower left, letting us easily find the other pins that we need.

Power and ground have been connected to the chip as well. Pin 7 (VCC) and Pin 20 (AVCC) have been connected to 5V. Pin 8 (GND) and Pin 22 (AGND) have both been connected to ground.

The final step is to connect the LED to output 0 on Port D. Our schematic tell us that we want to connect the positive lead of the LED to Pin 2 on the ATmega168, and the negative lead should go to an unoccupied row on the breadboard (make sure you don’t attach it to Pin 1). LEDs usually have a small notch flattened on one side of the plastic case to denote the negative leg of the device. The final piece of the puzzle is to connect the negative side of the LED to ground by using our resistor.

In the image above I’ve hooked up a 9V battery , but nothing happened. That’s because there’s no firmware on the chip to make the LED blink yet. We’ll need to fix that in the next step.

Programming our test circuit

Check all of your connections one more time and let’s get ready to program the microcontroller.

Connecting to a programmer

You only need to make six connections in order to program our chip:

• Voltage
• Ground
• Master In Slave Out (MISO)
• Master Out Slave In (MOSI)
• Reset (RST)
• Slave Clock (SCK)

This is true for any programmer that is using In-System Programming. There’s even a standardized 6-pin header that I design into most of my circuits so that you can easily reconnect your programmer to a circuit board and update the firmware down the line. But for this example we’ll just use some jumper wires to make the connections. One thing to keep in the back of your mind is to only use one voltage source when programming. You should either disconnect the power to your circuit while programming, or do not make a connection to the voltage line on your programmer.

Connecting an Arduino as a programmer

Using your Arduino as a programmer is super easy. The first thing you’ll want to do is open up the Arduino IDE, and then open the example software: ArduinoISP.pde (in the examples/ArduinoISP folder). Flash it to your Arduino in the normal fashion. Now follow the directions for targeting an AVR on a breadboard (bottom of that page). Important: Choose one power source. That is to say, either connect the voltage on the Arduino board to your breadboard, OR connect the battery to the power supply we wired up. Doing both has the potential to damage your hardware.

Here’s how mine looked once I had it hooked up.

Now that everything is ready to go, jump to the next section: Flashing firmware with AVRdude.

Connecting using a DAPA cable

Depending on how you constructed your DAPA cable, it should be pretty easy to make the five connections we need. Notice that the DAPA cable doesn’t have a Voltage connection. The target processor must have its own power source (like the power supply we built on the breadboard) during programming. Here is what my DAPA cable looks like once connected.

If you’re unsure of the connection that need to be made, go back and compare the DAPA cable design to the circuit schematic. Match up our five connections: MISO, MOSI, RST, SCK, and GND.

Flashing firmware with AVRdude

If you did your homework from Part 1 of this series you should already have the cross compiler tools installed. First, download the firmware package and navigate to that directory in a shell, or at the command prompt. The following commands can be used on Linux and OSX systems to program the chip.

Arduino as the programmer:

avrdude -P usb -b 19200 -c avrisp -p m168 -U flash:w:main.hex

DAPA as the programmer:

avrdude -P /dev/parport0 -c dapa -p m168 -U flash:w:main.hex

AVR Dragon as the programmer:

avrdude -P usb -c dragon_isp -p m168 -U flash:w:main.hex

USBtinyISP as the programmer:

avrdude -P usb -c usbtiny -p m168 -U flash:w:main.hex

You can get help from the AVRdude program by running:

avrdude -h

That will print out a list of available commands, or you can read the online documentation. Windows users will need to change the /dev/* portion of the command to match your connection. You should find the Windows page of the online manual particularly helpful for this. Standard Windows port names include com0, com1, etc. for serial ports and lpt0, lpt1, etc. for parallel ports.

As for the other flags used in the programming commands above:

When using the Arduino as an ISP programmer you must specify the speed, using ‘-b’. That value is set in the Arduino sketch and should be 19200 by default.

You will always need to specify what kind of chip is connected to the programmer. Here I’ve used ‘-p m168′ for our ATmega168. Get a list of all compatible microprocessors by typing

avrdude -p ?

The same is true for specifying a programmer. You can change the ‘-p’ to ‘-c’ in the command above to get a list of programmers.

The final option in the commands we used tells the programmer to write (that’s the ‘w’) the file ‘main.hex’ to flash memory. Part of the command is used for many things, including changing the fuse bits on the chip. I’ll talk about this in Part 3 of the series.

Debugging

Your LED should be flashing away quite happily at this point. What’s that? It’s not? Time to start the real learning. Here’s a list to get you started:

• Did you successfully program the chip? You should get the message: “258 bytes of flash verified” and “avrdude done. Thank you.”
• If you had an error during programming, check first to make sure there is power going to your chip.
• Try the programming command again using ‘-v’ in place of ‘flash:w:main.hex’. This will just attempt to talk to the chip instead of writing to it, and is very handy when working out programming bugs
• Recheck your programming connections to ensure you’ve got the correct signals connected to the right pins
• Make sure you have the correct port on the computer and that you have permission to use that port. Linux users may try talking to the chip with the -v flag as ROOT to discover if there is a permission problem. If this works you need to add your user to the group that has permission to access the port the programmer is connected to
• If you did successfully program the chip you should recheck your hardware. Is the LED installed backwards, preventing it from lighting up?
• Take a trip to Google and start searching… this usually plays a roll in the development process so don’t feel bad. A lot of folks have already experienced the trouble you’re having and they made it through okay in the end.

Conclusion

You’ve done it, your first embedded circuit is alive! For now it will just flash to let you know everything is working. But next time we’ll talk about how this was accomplished, what we can do to make it behave differently, and how to use the compiler to translate our code changes into a file that the microcontroller can run. Thanks for reading and we’ll see you back here for the next installment.

Follow Me

@szczys

Resources

Firmware package: Package download or Github page

Atmel AVR ATmega168 Datasheet (PDF)

AVR dude online documentation

AVR In-System Programming Application Note (PDF)

AVR ISP Programming Header:

This little box remembers all of your user names and passwords. Inside you’ll find an Atmel AT89S5131 microcontroller which has built-in USB capability. When the box is plugged into a USB port it identifies as a keyboard. Manipulating the buttons on the top and side will select and print out various stored usernames and passwords. Passwords are generated on-chip from a random seed and the device itself requires a passcode after power up as a security feature.

[SigFLUP's] included a pretty nifty configuration algorithm. It doesn’t rely on a terminal connection, since the device is a keyboard you can communicate with it in an editor window (which should make it platform independent). There’s no code available, but trying to write your own to the spec outlined in the demo after the break will make for a fun weekend project.

(We almost made it to the end of the post WITHOUT saying “Setec Astronomy“)

[Mathieu] built this display in hopes that he can play pong on it. You can imagine the headache that awaits when trying to figure out how to drive the 6144 bi-color LEDs. I must have worked out because the thing looks great in the video after the break. The solution he chose was a bit unfamiliar to us though. He used a Field Programmable System Level Integrated Circuit produced by Atmel, or FPSLIC. This is a kind of mash-up of components we’re more accustomed to.

The AT94K is a single chip that houses an 8-bit AVR microcontroller, and FPGA, and SRAM. This project uses that FPGA to handle the multiplexing of the display via code written in VHDL. The AVR core receives data via a USB port, stores two images in the SRAM (one for each LED color), and then outputs it to be drawn on the display. On second thought, this project sounds like fun and it’s a great way to get start learning that VHDL you’ve been putting off.

Are you hardcore enough to build your own 32-bit ARM powered gaming console AND use point-to-point soldering to accomplish this? [Craig Bishop] did just that when building his GameSphere console project. First thing’s first, click through the jump and watch the game play video. He wrote that game in the C language in less than a day which in itself is quite remarkable. On the hardware side of things he’s got an interesting mix; an Ateml AT91R40008 chip drives this system with PIC 18F4682 for VGA signal generation and a PIC 18F2685 to interface with the N64 controller. We like what he’s done so far and would love to see this end up in its own game cabinet.

Elaborating on an item previously mentioned among last weekend’s Cornell final projects list, this time with video:

For their ECE final project, [Adam Papamarcos] and [Kerran Flanagan] implemented a real-time video object tracking system centered around an ATmega644 8-bit microcontroller. Their board ingests an NTSC video camera feed, samples frames at a coarse 39×60 pixel resolution (sufficient for simple games), processes the input to recognize objects and then drives a TV output using the OSD display chip from a video camera (this chip also recognizes the horizontal and vertical sync pulses from the input video signal, which the CPU uses to synchronize the digitizing step). Pretty amazing work all around.

Sometimes clever projects online are scant on information…but as this is their final grade, they’ve left no detail to speculation. Along with a great explanation of the system and its specific challenges, there’s complete source code, schematics, a parts list, the whole nine yards. Come on, guys! You’re making the rest of us look bad… Videos after the break…

[G’day Bruce]

Basic object tracking:

Human Tetris:

Brick Breaker:

Whether you’re burning a new bootloader to an Arduino board, or doing away with a bootloader to flash Atmel chips directly, an in-system programmer (ISP) is an indispensable tool for working with AVR microcontrollers. If cost has held you back, it’s no longer an excuse: FabISP is a barebones USB-based AVR programmer that can be pieced together for about ten bucks.

FabISP was created by [David Mellis] as a product of MIT’s Fab Lab program, which provides schools with access to design and manufacturing tools based around a core set of fabrication capabilities, so labs around the world can share results. But the FabISP design is simple enough that you don’t need a whole fab lab. It’s a small, single-sided board with no drilling required; the parts are all surface-mounted, but not so fine-pitched as to require reflow soldering. Easy!

There’s still the bootstrap problem, of course: you need an AVR programmer to get the firmware onto the FabISP. This would be an excellent group project for a hackerspace, club or school: if one person can provide the initial programmer to flash several boards, each member could etch and assemble their own, have it programmed, then take these out into the world to help create more. We must repeat!

[Thanks Juan]