[Chris] wrote us to share a neat technique he has been using to program the Arduinos he uses in his projects. He likes to build bare bones Arduino clones rather than sacrifice full dev boards, and instead of programming them via traditional means, he is using his computer’s sound card.
He builds a simple dead bug Arduino (which he calls an Audioino) using a handful of resistors, a pair of caps, an LED, a reset switch, and most importantly – an audio jack. After burning a special audio bootloader to the chip, he can connect the Arduino directly into his computer’s speaker port for programming.
Once the microcontroller is connected to his computer, he runs the IDE-generated hex file through a Java app he created, which converts the data into a WAV file. With the Arduino put into programming mode, he simply plays the WAV file with an audio player, and the code is uploaded.
He says that this method of programming comes in handy in certain cases where he builds things for friends, because they can easily update the software on their own without a lot of fuss.
If you are in the market for a PIC microcontroller programmer, you may want to consider a model with an In-Circuit Debugger (ICD). [Rajendra] put together a great tutorial on using an ICD when debugging PIC firmware, which makes a pretty convincing argument for owning one.
In his tutorial, he happens to be using a MikroElektronika PICflash2, but he says that there are plenty of other ICDs out there if you are not keen on this particular model. The PICflash2 not only acts as an ICD, but as the name suggests it works as an ICSP as well.
[Rajendra] walks us through a short debugging session using some simple code that reads data from an LM34DZ temperature sensor, displaying the results on an LCD screen. While he isn’t actually hunting for bugs, he does show how easy it is to step through the PIC’s code one statement at a time, evaluating variables and registers along the way.
[Rajendra] does point out that using an ICD does occupy a few I/O pins while running, limiting your resources just a bit. We think that being able to debug code as it runs is pretty reasonable tradeoff if you don’t necessarily need each and every pin available for use.
Microsoft just released the beta of the Kinect for Windows SDK. Although, “Microsoft does not condone the modification of its products” it appears Microsoft have changed their tune and released APIs for C++, C# and Visual Basic seven months after the Kinect was officially hacked.
We’ve seen libraries being developed since the launch of Kinect, culminating in the OpenKinect project. The Microsoft release covers the same ground as the OpenKinect project, and will hopefully improve on attempts to get audio out of the Kinect.
We’ve seen Kinect hacks run the gamut from telepresence, to robotics, to 3D modeling, so the Kinect seems like a great tool in the builder’s arsenal. The Kinect is a wonderful tool, and even though most of the functionality has already been replicated by the open-source community, it’s nice to know there’s official support for all the great projects we’ve seen.
In his line of work, Hackaday reader [Pedantite] often has to monitor the build status of several continuous integration servers throughout the day. One afternoon, he got the idea to install a set of stop lights in the office in order to monitor the status of the servers, but filed it away as a “wouldn’t it be cool if…” project.
After some time had passed, he was bitten by the idea bug again and decided he would build a physical device to display the status of his build processes. This time around, he brainstormed on a smaller scale and the result is the “Indictron” you see above.
He built a simple LED board made up of four rows of four LEDs to display the build processes. Different LEDs are lit depending on the project’s current build status as well as the results of the previous build. The board uses an ATmega88, and interfaces with a compiler watchdog application using a virtual USB package made specifically for AVR micro controllers.
The end result is a simple, yet useful status board that “just works”. He does not seem to have code or schematics posted on his site at the moment, but we’re pretty sure he would share them upon request.
If you’re interested in a bit more of [Pedantite’s] work, check out his “Good Times” parental timer we featured last week.
[Pyra] was looking for a way to reprogram some ATtiny13 microcontrollers in a SOIC package. He’s re-engineering some consumer electronics so adding an ISP header to the design isn’t an option. He had been soldering wires to the legs of every chip but this is quite tedious. What he needs is an adapter that can make physical contact with the legs just long enough to program new firmware. After looking around he discovered that a PCI socket can be used as a progamming clip (translated). It shares the same pitch as a standard SOIC package but is not wide enough for the chip. He cut out 4 rows of the socket and the section of motherboard it was soldered to. Then he made a cut down the middle of the plastic and bent the two sections apart. The image above illustrates this, but not shown are the eight wires that he later added to connect to the device.
We wonder if this can be adapted to program SOIC parts without removing them from a circuit board. That would be a handy tool for finishing up the LED lightbulb hack.
In the last installment of our tutorial series we built a simple circuit on a breadboard and programmed an ATmega168 to make it run. That proves that you know how to follow directions, but the eureka moments of doing everything yourself are on the way. This time around you will get down and dirty with the datasheet, learning where each line of the sample code came from, and give your recently installed compiler a test drive. We will:
- Talk about bitwise operators and how they work when coding for microcontrollers
- Discuss C code shorthand
- Review the sample code from Part 2 and talk about what each line of code does
- Learn to compile code
If this is the first you’ve heard about our AVR Programming series, head back to Part 1 and start from the beginning. Otherwise, take a deep breath and we’ll being after the break.
Continue reading “AVR Programming 03: Reading and compiling code”
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.
Continue reading “AVR Programming 02: The Hardware”