I am a crappy software coder when it comes down to it. I didn’t pay attention when everything went object oriented and my roots were always assembly language and real Time operating Systems (RTOS) anyways.

So it only natural that I would reach for a true In-Circuit-Emulator (ICE) to finish of my little OBDII bus to speed pulse generator widget. ICE is a hardware device used to debug embedded systems. It communicates with the microcontroller on your board, allowing you to view what is going on by pausing execution and inspecting or changing values in the hardware registers. If you want to be great at embedded development you need to be great at using in-circuit emulation.

Not only do I get to enjoy my mistakes in near real time, I get to make a video about it.

Getting data Out of a Vehicle

I’ve been working on a small board which will plug into my car and give direct access to speed reported on the Controller area Network (CAN bus).

To back up a bit, my last video post was about my inane desire to make a small assembly that could plug into the OBDII port on my truck and create a series of pulses representing the speed of the automobile for my GPS to function much a lot more accurately. While there was a wire buried deep in the multiple bundles of wires connected to the vehicle’s Engine control Module, I have made a decision for many reasons to create my own signal source.

At the heart of my project is the need to convert the OBDII port and the underlying CAN protocol to a basic variable representing the speed, and to then covert that value to a pulse stream where the frequency varied based on speed. The OBDII/CAN Protocol is handled by the STN1110 chip and converted to ASCII, and I am using an ATmega328 like found on a multitude of Arduino’ish boards for the ASCII to pulse conversion. I’m using hardware interrupts to control the signal output for rock-solid, jitter-free timing.

Walk through the process of using an In-Circuit Emulator in the video below, and join me after the break for a few a lot more details on the process.

The Hardware

I revised the board considering that the last video and removed the support for the various protocols other than CAN, which is the non-obsolete protocol of the bunch. By removing a bunch of parts I was able to change the package style to through-hole which is much easier for lots of home hobbyists, so you can leave the solder-paste in the ‘fridge.

Rev 2

Rev 1

The “Other Connector” on your Arduino

Unlike the Arduino which is ready to speak to your USB port when you take it out of the box, the ATmega chips arrive without any knowledge of how to go and download code, in other words it doesn’t have a boot loader. consequently I have the In-Circuit-Serial-Programming (ICSP) pins routed to a pin header on my board so that I can program the part directly.

On this connector you’ll find the Reset line, which indicates with this header I can use a true ICE utilizing the debugWIRE protocol. considering that the huge majority of designs that use an AVR chip do not repurpose the reset pin for GPIO, it is a best pin to use for ICE. all of the communications during the debug process will take place on the reset pin.

Enter the ICE

When creating a computer from scratch there is always the stage where nothing yet works. simply put, a microprocessor circuit cannot work until nearly every part of the design works; RAM, ROM, and the underlying buses all need to (mostly) work before basic things can be done. As a hardware engineer by trade I would always reach for an ICE to kick off the implementation; only after the Beta release would the ICE start to gather dust in the corner.

In the case of the ATmega, the debugging capabilities are built into the microcontroller itself. This is a much a lot more straightforward implementation than the early days when we had to have a second isolated processor running off-board with its own local RAM/ROM.

One note pointed out in the video is that a standard Arduino’ish board needs to have the filter capacitors removed from the RESET line to allow the high speed data on the line for its debugWIRE usage.

The ICE I am using here is the one made by Atmel, and is compatible with Atmel Studio, there are also other models available such as the AVR Dragon.

ICEyness

The ICE allows us to download and single step our code while being able to observe and overwrite RAM and I/O Registers from the keyboard. We are able to enjoy the program step by step or look underneath at the actual assembly code generated by the compiler. We can enjoy variables and locations directly in RAM or enjoy the C language counterparts. It’s also possible to jump over a sub-routine call in the instance of just wanting to see the result without all of the processing.

It’s worth your time to see even a look of the capabilities of an ICE in action. I recommend that you enjoy the video where the debugging begin.

Final Words

This video was really about finishing the OBDII circuit so I didn’t really have the time to discuss everything an ICE can do, maybe I will do a post dedicated to just the ICE and development environment next time.