Enginursday: More Favorite Tools

More handy things from my workbench.

Favorited Favorite 0

Having the right tool for a job can mean the difference between a task that’s frustrating and completed poorly, and one that’s a pleasure. For my Enginursday post this week, I’m going to revisit a theme I’ve explored a couple of times previously: worthwhile tools.

If you’re interested in previous installments on this subject, here are a couple of my previous posts:

This time, I’m going to discuss two different tools, both of which have been getting a lot of use on my workbench. The first one is simple and inexpensive, the other is only a bit more expensive, though significantly more complex.

The Simple One

The first tool I’d like to show off today is the Metallic Silver Sharpie marker.

alt text

They’re very useful when you want to write on black surfaces. In the past I’d used paint pens for that, but paint pens can be messy – you have to pump the marker like a flux pen to get the paint to flow, and they often use toxic solvents, like toluene, to keep the paint in liquid form. The Silver Sharpie is simply a nontoxic magic marker, just uncap it and start writing.

One of its most frequent uses on my workbench is to mark wall warts, so I know what voltage they produce, or what device they’re intended to go with.

alt text

Silver Sharpies run a dollar or two from office or craft stores. If you store them as recommended, with the tip pointed down, they last a long time. Incidentally, the cap fits in one of the threaded holes of our third hand base to help keep it pointed tip-down.

There’s also a gold version, but I wouldn’t want to be ostentatious.

The Complex One

I’m going to step back to give a little historical perspective on this second tool. Understanding where it fits in the evolution of development tools makes it even more interesting.

History

The first job I took out of college was writing firmware for an embedded system based on the Motorola (now Freescale) 68000 family of microprocessors. The 68000 family was widely used - I’d previously used it when writing Palm Pilot apps in school, and it was also the heart of the Commodore Amiga and pre-PowerPC Apple MacIntoshes.

Developing for an embedded 68000 at that time involved significant investment in an In-Circuit-Emulator (ICE) system. The ICE was based around an HP Unix workstation that interfaced with the embedded platform via a module called an emulation pod. The pod plugged in to the processor socket, and controlled the system as if it were the regular processor. However, within the pod was a special version of the processor, with extra bond-wires to make the internals accessible.

ICE pic

Photo courtesy HP/Agilent/Keysight Technologies

This device allowed the operator to load code into the pod, then observe what was going on inside the processor as it ran. I could halt the processor, set breakpoints on particular routines, and step through machine code to see what was going on.

This device had advantages and disadvantages.

  • I could see how the code was executing, but only in assembly language. The software didn’t understand C, so I had to do manual translation by looking things up in the symbol table. A significant portion of the system was coded in hand-optimized assembly, so this wasn’t a huge drawback, though it did mean that I needed a strong grasp on the fetch-execute architecture.
  • The edit/compile/load/debug process was slow and cumbersome. The compiler ran on a different server, and I’d FTP the binary files to the emulator to debug them. If I was working quickly, I could maybe build and load four different versions in an hour.
  • The emulator was extremely expensive (around $25,000, as I recall), so it was shared among a team of four or five firmware engineers. If it was busy, I simply worked on something else and came back later.

The slowness of the compile cycle, coupled with the accessibility bottleneck, meant I often had plenty of time to carefully look my code over before running it. It turned out that by inspecting the code, I often found and fixed bugs before I got access to the debugger. I also learned that I frequently tended to write the same sort of bug over & over, and that I needed to be more diligent in a couple of specific areas. In particular, I was having problems when I intermixed signed and unsigned math, especially when mixing 16 and 32-bit integers…looking at the generated instructions, and stepping at the assembly level made those errors painfully obvious!

Even with the hassles that system presented, I still get nostalgic when I’m presented with a three-tone grayscale X-11 GUI.

A Small (but significant) Step Forward

The next platform I worked on at that company was the Motorola 68332 processor. These processors effectively obsoleted the ICE by moving the debug features into the chip – no dedicated workstation or pod required! This specific interface was known as “Background Debug Mode.” It solved many of the issues of the larger system:

  • It was comparatively inexpensive ($2500), so each developer could have a unit on their desk.
  • It could debug C, allowing us to interact with our source files.

I don’t recall that the compilation time changed much, since it moved from a Unix workstation to my local PC. Still, the other factors certainly helped the team’s productivity.

From History To The Present

If you’re familiar with SparkFun, you know we use the Atmel AVR family of processors in a lot of products. Most frequently, they’re deployed with a serial bootloader, so they can be reprogrammed with just an FTDI cable, as you would with AVR-Dude or the Arduino IDE. While it’s convenient, it leaves a lot to be desired in terms of debugging experience. To debug Arduino code, we simply pepper our sketches with Serial.print() statements, and iterate until we track down the bug…and then remember to remove all of the added diagnostics.

There is a better debugging interface on the AVR, though. It’s called DebugWire. In the interest of backward compatibility, it uses serial communication over the processor reset line, which is present in the 6-pin header found on many of our AVR boards. Through DebugWire, we can load code, start & stop execution, set breakpoints, and inspect registers, and memory. An interesting piece of this debugging package is that Atmel has teamed up with Microsoft for the software environment. The free IDE is a version of Microsoft Visual Studio, which targets Atmel’s AVR and SAM microcontrollers. It’s a large program (and similarly a large download), but it has a lot of the debugging features discussed above.

I’ve been using Atmel Studio for a year now, first with a JTAGICE3 module, but now with the $35 Atmel-ICE PCBA Only.

alt text

Photo courtesy Atmel

I used Atmel Studio when I developed the Servo Trigger, and it offered a number of features that helped me finish the firmware. The Servo Trigger is built around an AVR ATTiny84, which doesn’t have a serial port for printing out debug messages. An interactive debugger played a critical role in getting the code right.

alt text

A breakpoint on a particularly tricky function

If you want to try programming a Servo Trigger with the AtmelICE, you’ll notice that it’s got the 6-pin programming header next to the processor; just plug the ICE in there, or use a PogoPin Adapter.

Next Steps

Following the Servo trigger, I’ve got a couple of projects that needed a larger processor. I wanted to use an ATMega328 to build a DDS waveform generator.

The RedBoard has a 328 and the ISP header, but is more commonly used with the Arduino IDE. When I plugged my ICE into it, I found that I was able to use ISP to program the processor, but I couldn’t use DebugWire. A little googling turned up a blog post that explained the problem – there’s a capacitor I needed to lift to get things working.

alt text

RedBoard with C8 lifted to allow DebugWire

With DebugWire fully functional on the RedBoard, I’ve been able to get by DDS program working. Once again, I meet my old nemesis of intermixed signed and unsigned integer math, but I’ve got good tools in my corner, and know what I need to watch out for. The DDS portions are working, but there are many features I want to add. If you’re curious about it, the work-in-progress, bare-metal project is in my personal Github. This is definitely a case where having the right tools available makes the job much easier.


Footnotes

  1. If you’re familiar with Arduino, but Atmel Studio seems like a big step to take, you can ease your way in with VisualMicro’s Arduino IDE for Atmel Studio. It adds Arduino compatibility to Atmel Studio, so you won’t be completely disoriented. I haven’t had a chance to experiment with it, but Engblaze has written an installation guide for it.

  2. This article is getting posted while I’m on vacation. I’ll do my best to respond to comments below on my return.


Comments 5 comments

  • I can definitely add my approval to the silver Sharpie!

    • Same here! It gets used anywhere from the kitchen to the toolbox to the hardware workstation. The only problem is keeping track of it.

  • Hope you’re enjoying your vacation!

    A few weeks ago I happened to find a white Sharpie, though it was a “paint” one, at Michael’s. I didn’t find what I’d gone in there for, so I “squandered” my “50% off one item this week only” coupon and bought it. (I’ve yet to actually try it.) If you do go to Michael’s, be sure to check the newspaper and/or junk mail, because they put out coupons nearly every week.

    One of the things I do to mark wall warts is to use my label maker and make a label with the voltage (or other info) on it twice and put it around the cable near the connector so that it makes a “flag”. Makes it less likely to plug a 12V AC wall wart into a 5V DC input socket… BTW, this won’t work with the old fashioned embossing label makers, but I haven’t used one of those since before the turn of the millenium.

    As for the debuggers, with “good programming” (I realize that sort of leaves out anything with an M$ logo), it’s possible to do the debugger entirely in software, except for things like PWM controllers and the like. Basically, the debugger plants a “software interrupt” where ever the person requests something (usually it replaces one instruction, but the debugger keeps track of what was supposed to go there). The interrupt service routine then “talks” to the debugger to provide the human with the info. Doing this for code from a higher level language has a few subtleties, but IIRC, the gcc compiler has support for it (basically, it generates a table for each line of code saying what memory locations are associated with it).

    IM[NS]HO, based on 45+ years of programming, using a debugger to be able to “watch” key variables while “single stepping” through a program is one of, if not THE, best ways for beginners to learn programming. The one downside for doing this on something like the Arduino is that the flash memory can take a real pounding, as it does have a limited life in terms of number of write cycles any one location can handle, though they are cheap enough that I think it’s worthwhile to do.

    • I also bought that white sharpie with dreams of marking black equipment, but sadly it’s about as fine-point as a lipstick. I’ve since been using a gold sharpie with ostentatiously great results.

    • using a debugger to be able to “watch” key variables while “single stepping” through a program is one of, if not THE, best ways for beginners to learn programming

      I strongly agree.

      Having the option to see the source code and corresponding disassembly in the debugger is also illuminating, as well as stepping at the source-line or instruction levels.

      Sometimes just seeing the generated instructions helps you understand why code is broken (on the 68000, seeing that the compiler has generated .b [byte-wide] operations, when I knew I was handling .w [16-bit] data always helped get me back on track).

      Sometimes, seeing how the language constructs have been turned into machine-level instructions is also useful. You get a pretty clear understanding of pointers after watching addresses get loaded into index registers, offsets applied, and data read/written.

      You’re also right to warn about the flash lifecycle of software breakpoints on the AVR. The ATMega328P datasheet specifically warns:

      The Flash must be re-programmed each time a Break Point is changed. This is automatically handled by AVR Studio through the debugWIRE interface. The use of Break Points will therefore reduce the Flash Data retention. Devices used for debugging purposes should not be shipped to end customers.

      This isn’t necessarily true of all microcontrollers, though. I’ve worked with NXP ARM-7 processors that had a trap & break module. Rather than inserting break instructions into flash, the address would be set in the trap module. When the instruction was fetched, the processor would jump into a trap handler and communicate with the debugger, with no need to rewrite the instruction. It could also be configured for more general memory diagnostics, like detecting out-of-bounds memory accesses.

Related Posts

Recent Posts

Tags


All Tags