This is a simple iOS debugging tool that will take no time to solder together. There’s even a chance that you already have everything you need on hand. The hack simply connects an RS232-to-USB converter to a breakout board for an iPod connector.
The hardware is aimed not at stock iOS systems, but as an aid to those who wish to run alternative operating systems on them. When the OpeniBoot package is run on an iPod Touch or iPhone it enables a serial terminal on pins 12 and 13. The FTDI breakout board takes these as RX and TX and makes them available to your terminal program of choice via USB. Speaking of USB, you may already have noticed the black cable leaving the right side of the image. Using the terminal doesn’t limit your ability to use the device’s USB functions.
The Bus Pirate is a fantastic development tool. It does an amazing job at a lot of different things. And as it has matured, community support has driven it to new areas beyond the original design. This is where its hardware holds back performance a little bit. For instance, as an I2C or SPI sniffer it has limited capture speed. That’s the type of thing that this board could improve upon. It’s a debugging tool based on an STM32 F4 microcontroller. That’s an ARM Cortex-M4 chip which runs at 168 MHz, and has 192 KB of SRAM.
[TitanMKD] has been working on the design but it is still just in digital form. Since there’s no prototype there is also no firmware for the device. That’s a tall mountain to climb and it’s one of the reasons we’re featuring the project now. [Titan’s] plan is to model this after the Bus Pirate interface. We think it’s a good idea since a lot of folks have already learned the syntax. We didn’t see a contact form on his site, but if you’re interested in contributing to the project you might want to leave a comment here or on his project page (linked above).
First off, if you’re looking at that title and thinking it’s flame-bait, please hold off. What [Ihsan Kehribar] is working with is another way to get some feedback for what’s going on with your Arduino project. Or really any AVR project that uses an ISP connection. He’s added text output for AVR programs similar to the printf function used for a lot of non-embedded C development.
So, we’d bet you’re asking yourself why he’s not just using outright debugging? The AVR line supports many different types of it. But that can be complicated, and usually requires a proper programmer. If you just want to watch to see what values are changing, and when functions are being executed, this isn’t a bad solution. He uses the computer to continually poll the chip. Whenever the sketch calls the his print library it answers back with the payload to be displayed in the terminal. The overhead shouldn’t be too high, and if you’re smart about it this can be flagged as a debug option at the top of the program file.
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.
If you haven’t done any debugging with microcontroller programs [Kphlight] posted a follow-along guide for debugging MSP430 chips. You can see above that he’s using the TI Launchpad and has chosen the free (but code limited) IAR Embedded Workbench that is one of the IDE’s that TI provides for the kit. The example builds a Pomodoro timer with just five LEDs and one resistor. You’ll flash the code to the chip, step through each line of the firmware, and learn how to manipulate register data during code execution.
It’s a great primer for the uninitiated, and we’d love to see one using open-source tools like DDD and GDB. If you do write one, don’t forget to send us a tip about it. If you want to give open source a try with this hardware check out our own tutorial.
A logic analyzer records bus communications between two chips. If you’ve ever had a problem getting two chips to talk, or wanted to reverse engineer a protocol, a logic analyzer is the tool you need to spy on the bus.
The Logic is a USB logic analyzer with eight channels and sampling rates up to 24MHz. Among hobby-level logic analyzers, the Logic has a good mix of features and decent sampling rates. We’ve been following Joe Garrison’s work on the Logic for a long time. If you’ve ever considered bringing a product to market, you can learn a lot from Joe’s blog that documents his development process.
When it debuted, the Logic was so popular that it was hard to buy one. It’s now widely available, and Saleae gave us one to try. Read our review below.
Continue reading “Tools: Saleae Logic, logic analyzer”