Saturday, November 29, 2014

Debugging Interrupt Service Routines

I have been spending some time writing AVR Interrupt Service Routines of late and have decided to share some debugging techniques that I have found useful.

When writing ISRs, especially those used to service timer interrupts, as the timer period shortens, it becomes necessary to be especially prudent about the amount of code you place in the ISR.

Obviously, the ISR routine cannot execute longer than the timer period or timer interrupts will be missed.  When an ISR is entered, interrupts are disabled so that the ISR itself cannot be interrupted unless interrupts are explicitly re-enabled in the ISR itself.  This is something that should be done very carefully (if at all) after understanding all the ramifications.

It is a mistake to put Serial.print() code in your ISR code as such code takes a very long time to complete when interrupts are disabled.  It may appear to work for a while with very short output messages, but you are fooling yourself as to the usefulness of this output.

So, how does one debug ISR code?  I find it very useful to use an oscilloscope connected to a digital pin and to toggle that pin when events of interest are seen.  For example I might set the pin high when entering the ISR and low when exiting the ISR.  Along with allowing me to see that my interrupt service routine is in fact being called, I can see how often it is called by measuring the time between pin transitions from low to high.  Additionally, I can see how long the ISR itself is taking to run by measuring the time between the pin going high and it going low again.

By way of example, I have set up timer2 on an ATMega2560 to interrupt every 32 microseconds. 

// Setup timer2 with prescaler = 1, PWM mode to phase correct PWM
// Timer will count to maximum and then back down again (effectively a divide by
// 512 since timer2 is an 8 bit counter.  This will generate an interrupt every
// 32 us.  16000000 / 512 = 31250 = 32 us (.000032 seconds)
// See the ATMega datasheet for all the gory details
void timer2Setup()

  TIMSK2 = 0;
  TCCR2A = _BV(COM2A1) | _BV(COM2B1) | _BV(WGM20);
  TCCR2B = _BV(CS20);

And then enable timer2 when I am ready for the timer to start.

  // Useful macros for setting and resetting bits
  #define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
  #define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))

  sbi (TIMSK2, TOIE2);      // Enable timer 2.

To handle the ISR, I have created a trivial handler that merely sets digital pin 8 high and then sets it back low.

  // Timer 2 interrupt service routine (ISR).
    digitalWrite(8, HIGH);
    digitalWrite(8, LOW);

Now, looking at this on the scope, we see a positive going pulse on pin 8 every 32us indicating that the ISR is being entered at that rate.

But another very interesting fact is revealed by this scope trace.  The amount of time it takes the ISR to simply toggle a pin high and then low is an amazing 7.6us.  This is a freaking eternity in the relative scheme of things.  Out of 32us I have to perform all of my ISR code, just toggling a pin high then low takes 23% of the available time.

If your ISR code is very short and sweet, this may be a non-issue.  However, everything you can do to shorten ISR code length should be done because the ISR runs with interrupts disabled.  Nothing else can run until you return from your ISR.

A silly example would be an ISR that runs every 32us and takes nearly 100% of the available 32us to complete.  This would mean that precious little time would be available for your main loop to run in your Arduino sketch.  In this particular example, there is no code in the main loop, so it is of no consequence.  However, this is not the norm and you want to minimize the time spent with interrupts disabled as much as possible as a general rule so some time spent on optimizing your ISR code can pay big dividends on overall performance.  Any section of you code can be timed quite accurately using this method allowing experimentation of different techniques to speed up your code or at least understand the effect on performance of any code change.

So, what can we do to optimize this simple two line ISR routine?  Ditch the use of digitalWrite and manipulate the port directly.  The beauty of digitalWrite is that it allows you to abstract the notion of "digital pin 8" from the particular hardware you are running on.  If you are running on a Arduino UNO (or any ATMega328 device) then digital pin 8 is PORTB bit 0 (PB0).  However, if you are running on an ATMega2560 as I am, then this same digital pin 8 is PORTH bit 5.  The digitalWrite implementation hides all of this mess from you very nicely, but at the expense of code speed.

So, let's take the knowledge we have of what processor we are running on and what port and bit the digital pin is assigned to and optimize this code a little.  I am running on an ATMega2560, so digital pin 8 is PH5.  Modifying the code to manipulate the desired bit directly means the code is hardware specific, but we gain a significant speed improvement in the code.  This code is for the ATMega2560.

  // Timer 2 interrupt service routine (ISR).

Now looking at the scope, we see that the setting and resetting of the pin only takes 320ns to execute, a significant savings.

If running on an ATMega328 such as found in the UNO, change the ISR as follows:

  // Timer 2 interrupt service routine (ISR).

Hopefully you will find this technique useful in your general debugging as well as when debugging ISR code in particular.  As always if you need assistance, drop me a line at ko7m at arrl dot net and I will be happy to assist in any way I can.

Wednesday, November 12, 2014

VNA fixture PCB available from

Due to a number of requests to share my VNA fixture design, I have made them available at using the following link.  Boards can be ordered directly at that link in multiples of three very inexpensively (about $11).  Drop me a note at ko7m at arrl dot net should you encounter any difficulty in obtaining them.

The tactile switches used on the board are available at at this link.  As always, I would be happy to help you succeed in implementing this board should you so desire.

Tuesday, November 11, 2014

Characterizing Crystals

Still learning how to use the VNA.  Grabbed a handful of Crystals and clipping them to the VNA fixture described in my previous post, I collect the following information:

I am not sure that I am doing things correctly, and certainly am not yet in a position to interpret the results seen above.  More study and experimentation will be required, but it looks like I will certainly have the necessary information to design filters.

More to come...

Monday, November 10, 2014

VNA fixture

In a previous blog post I mentioned purchasing a batch of 20 MHz crystals from China with the intent of building some crystal filters.  I am facing the need to be able to characterize my new collection of eBay crystals.  I have looked at many of the suggested techniques and out of them all, I like the idea of using a vector network analyzer for the task.

A few years ago, I purchased one of these units from SDR-Kits.

I purchased this at a time when support on Windows platforms for the necessary drivers was quite sub-optimal and as a result this device has not seen much use over the years.  However, I have dug it out, dusted it off and upgraded the firmware and USB drivers, which are now nicely supported on all versions of Windows.

Now, I need a nice fixture that can be used to characterize a batch of Crystals. Leveraging the fine work of Eldon (WA0UWH) I have built a fixture that can be used with this VNA for the task at hand.

The idea behind this is to provide a couple places where components can be connected to the fixture and swept with the VNA to be able to visualize its characteristics over a wide frequency range.

The 8 pin header is provided with three ground attach points, one signal attach point and two pins on each side that connect together.  The idea is to be able to create simple networks of discrete components and be able to sweep them or to just sweep individual components.

The buttons provide the ability to short or terminate the VNA with a 50 ohm load.  As part of the calibration process when the fixture is attached, you want to remove the effects of the fixture itself from the measurements so the VNA is calibrated with a short, through, open and load conditions before attaching components to be measured.

The two resistors are 100 ohm 0805 units that are connected in parallel across the SMA when nearest button is depressed providing a 50 ohm load.  The bottom button shorts the SMA connector when depressed.

The bare copper area at the bottom of the board allows for placing surface mount components across the gap.  These can be held in place with a non-conductive clothes pin or a conductive clip as appropriate.  When measuring surface mount crystals for example, a conductive clip will allow grounding of the crystal case as the back side of the board is an open ground plane while holding the connectors firmly against the top side of the board.

Hopefully this little fixture will help expand the usefulness of the VNA in my projects.  I will share my experiences using this characterizing crystals in a separate post.

Friday, November 7, 2014

At the tone...

Fun with Arduinos and scopes in XY display mode...  Looks good on good old analogue and high end digital scopes.  Not so much on my $400 digital model.

Dual channel 8 bit DACs and a bunch of table look-up data, and a cheap RTC if you want accurate time.

Commercial versions of hardware able to produce such a display are available.  

Thursday, November 6, 2014

New Minima-like build

My good friend Wayne NB6M has kindly loaned me his Minima-like build using my controller shield for the Arduino.  His front panel is very similar to his original Minima build, but is now sporting a 20x4 display.  He has removed the reset button from the front panel and added input for paddles in anticipation of me actually finishing the integration of my keyer code to the Minima code base.

Looking at the back of the panel, we can see the Arduino Uno and my controller shield mounted on the back of the display board.  Wayne has used #12 bare copper wire soldered to the front panel to provide attach points for the Uno and shield.  My shield will be modified to provide through-hole plating and solder pads so that it can be soldered in place.

The display board has been converted to i2c with a backpack board and the rotary encoder uses pins freed up by display being converted to i2c.  The current shield design does not incorporate the proposed pins for the encoder from the discussion list, but will be modified in the final run to be compliant.

Wayne is using a pretty conventional IF strip from the Minima, but has chosen to replace the KISS mixer and BFO mixer with ADE-1 devices.  His audio section is from a pre-existing project re-purposed for this project.  The two SMA connectors connect to the VFO and BFO Si570 outputs from my controller shield.  No low pass filter sections yet.  The current configuration makes a pretty nice general coverage receiver.

I have handed off Wayne's other Minima build to Eldon so he will have a working radio to test with during his software development efforts.

Saturday, November 1, 2014

Arduino Yun

I recently was given an Arduino Yun and have been playing around a little with this guy.

It is quite a little improvement over the basic Arduino UNO.  I have only begun to explore the possibilities, but it looks like it will be fun.

Yun is based on the ATMega32u4 microcontroller, but also is distinguished by the presence of an Atheros 9331 processor (the bit under the metal can above) that runs concurrently with the AVR processor a Linux distribution based on OpenWrt called OpenWrt-Yun.

The board has built-in Ethernet and WiFi support, as well as a USB-A port, micro-SD card slot and 20 digital I/O pins of which 7 can be used as PWM outputs and 12 as analog inputs.

The AVR processor can communicate with the Linux distribution to leverage capabilities of that platform such as networking, shell and python scripts.  The AVR side of the house has no need for a separate secondary processor as is found in the UNO to handle USB communications as it is built in.

The Yun device can appear to a connected computer as a mouse and keyboard in addition to a virtual serial / COM port.

A block diagramme can be seen below of the architecture.  The bridge component facilitates communication between the two processors allowing sharing of abilities such as running shell scripts, access to network interfaces , USB host functionality and the SD card.

Out-of-the-box the Yun is WiFi enabled and it acts like an access point.  You can connect your computer to the access point and then configure the Yun network.  I joined it to my home WiFi network, rebooted it and now I can upload scripts to it over WiFi.  Here is a shot of it sitting on top of a 10,000 ma/hr battery that is powering it as a stand alone unit that I can program from my laptop connecting via WiFi.

Here is a screen shot of an ssh session to the Linux side of the device and the normal Arduino IDE side-by-side.

 It will be fun to see what new ideas will result from this enhanced functionality.