A serial monitor is an easy way to debug your projects. As we step through code, it’s nice to see a “Hey! I’m working, moving to next thing!” across the monitor, and not so nice to see nothing – the result of a bug that needs debugging. This has always meant needing a PC loaded with your favorite serial terminal program close at hand.
Most of the time this is not an issue, because the PC is used to compile the code and program the project at hand. But what if you’re in the field, with a mission of fixing a headless system, and in need a serial monitor? Why lug around your PC when you can make your own External Serial Monitor!
[ARPix] built this fully functional serial monitor based on an Atmega328 and a 102 x 64 LCD display. While it doesn’t have a keyboard port like this microcontroller based serial terminal, tact switches allow access to the user interface to start and stop the reading and set the baud rate. The Atmega328 has 2K of SRAM, which is needed for the project. Apparently, 1K was not enough to handle all the data. All code, schematics and a very well done parts layout are available, making this sure to be your next weekend project!
The stable version of OpenOCD (an open source On-Chip Debugging software package) doesn’t have support for the ICDI protocol used by the Stellaris Launchpad board. But it is pretty easy to build your own OpenOCD from source after patching it to use the protocol.
We’ve already seen an open source tool used to flash binary images to the TI ARM board. But that can’t be used with GDB. With the recent inclusion of USB-based ICDI in the OpenOCD development branches we gain all the features that come with the package. We’re quite happy hear about this as we use OpenOCD for many hardware architectures and this makes development for this board feel more like normal.
Our Stellaris Launchpad hasn’t just been sitting in the closet since we got it. We’ve learned a lot by using the lm4tools to program the chip as we work our way through the online workshop. We’re really beginning to like the Stellarisware peripheral library that has been provided. For us it works in a much more intuitive way than the one that STM uses with their ARM Discovery boards. We’d recommend taking a look at the workbook PDF (which is basically a verbose listing of what’s in the video series) and the library reference (called SW-DRL-UG-9453.pdf) which is in the docs folder of the Stellarisware package.
[via Dangerous Protoypes]
It looks as though Texas Instruments are really reaching out to the hacker community with their new ARM-powered Stellaris dev board. On the Stellarisiti forums, a member asked about the debugging options for the Stellaris board. The Stellaris already features an In-Circuit Debug Interface (ICDI), but unfortunately it’s a little hard to get working in Linux-ey environments.
One of the devs for the Open On-Chip Debugger was already talking with TI to get the ICDI spec released for the Stellaris board. TI released the info, and after quite a bit of work, everything is open for all to see.
Right now, OpenOCD support for the Stellaris is still incomplete, but there is an project up on the Gits that allows for multi-platform development for TI’s new board.
Needless to say, getting everything up and running is still a chore. That’s not really a concern, though; the Stellaris has only been around for a few months and it takes devs time to put all the required tools into nice, neat packages. We’re just glad TI is being so forthcoming with the relevant documentation, lest development becomes a million times harder.
As your embedded applications get more complicated an On-Chip Debugger will save you a lot of time when things don’t run quite right. On-Chip Debugging (OCD) is just what it sounds like — a way to run your program on the target chip that lets you pause execution to examine values and change them if need be. The Arduino has no built-in method of using OCD, but the AVR chips used by the boards do. The caveat is that you need a proper AVR programmer to access the Debug Wire protocol, or a JTAG interface for some of the larger chips. In this case I’m going to be using an STM32 Discovery Board to give you an overview of OCD. But this will work the same way for any chip that has hardware debugging capabilities. Many IDE’s have debugging support built right in so that you can use a nice GUI as you work. But often these are just a front end for the command line tools I’ll be using. Join me after the break and we’ll get started.
Continue reading “Beginner’s look at On-Chip Debugging”
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.