Microchip didn’t become a leading microcontroller vendor by accident. The company built its PIC microcontroller business from nothing to significant market share over two decades by cultivating developers, starting with college undergraduates. The company did this by offering a broad product line, inexpensive tools, and plenty of support. Microchip’s latest offering, a programming and debugging tool that sells for less than $30, continues that winning strategy.

Despite having far too many words in its product name, the MPLAB PICkit Basic In-Circuit Debugger provides embedded developers with a combined debugger and programmer that handles most of Microchip’s microcontroller portfolio – including devices in the PIC and PIC32, AVR, dsPIC, DSC, and SAM product lines. The only devices the MPLAB Basic In-Circuit Debugger will not program are devices that require a high-voltage pulse to initiate the on-chip programming sequence such as low-pin-count AVR devices with UPDI. The long, long list of supported Microchip devices is 80 pages long. The MPLAB PICkit Basic In-Circuit Debugger connects to the host PC over a USB 2.0 connection with a Type-C connector and supports multiple protocols and connections to the target system including 4-wire JTAG, Serial Wire Debug (SWD), UPDI, PDI, SPI, debugWIRE, and TPI programming. The debugger is also backward compatible with 2-wire JTAG and ICSP and includes an adapter to convert from the 8-pin inline to the standard 10-pin Arm SWD connector. You get all of this for the low, low price of $29.95.

Microchip’s MPLAB PICkit Basic In-Circuit Debugger provides embedded developers with a combined debugger and programmer that handles most of Microchip’s microcontroller portfolio – including devices in the PIC and PIC32, AVR, dsPIC, DSC, and SAM product lines – for $29.95. Image credit: Microchip

You operate Microchip’s MPLAB PICkit Basic In-Circuit Debugger through the MPLAB X Integrated Development Environment (IDE), which is available as a free download for PCs running Microsoft Windows, Linux, or macOS. As a debugging environment, MPLAB supports multiple hardware and software breakpoints and allows you to debug your application on the target hardware in real time. In short, the MPLAB PICkit Basic In-Circuit Debugger does exactly what you’d expect for microcontroller software development work and sells for less than the price of dinner for two at a mid-range restaurant, or the Chuck-a-Rama buffet, for that matter.

This announcement reminded me of my friend, Jack Ganssle, who founded an in-circuit emulator company named Softaid back in the 1980s. I decided to interview Jack to finally get the story of how he founded Softaid. Despite being “super retired,” Jack agreed to the interview and, as it turns out, there are more than a few connections between the new Microchip MPLAB PICkit Basic In-Circuit Debugger and the Softaid story.

Steve Leibson: So, let’s get the story of Softaid.

Jack Ganssle: I started Softaid back around ’82. I was selling a multitasking Basic compiler that I’d written. It was not an interpreter, but it acted like an interpreter. It looked just like one, but when you hit run, it would do a full compile. That was very successful. I was also doing some consulting on the side. Actually, I was consulting for the CIA. And we were doing a project with the NSC800 chip [an 8-bit CMOS microprocessor from National Semiconductor], and there were never any tools for that. So, I figured, well, I’ll just build an emulator board. I kind of threw one together, and it worked pretty well on that project. I thought, “Wow, this could be a product.”

So, that emulator turned into one for the [Zilog] Z80 and one for an [Intel] 8085. We sold those for $600, which was insanely cheap for an emulator back then.

Steve Leibson: How did you make it for such a cheap price?

Jack Ganssle: Well, you know, emulators back then had hundreds of chips, and this one only had 17. What happened was, I was able to do an exquisite blend of hardware and software, with the two totally interacting with each other. And I cut out a lot of chips that way.

Another reason was, everyone had breakpoints, but they would use a comparator to compare against the address bus. So, if you wanted five breakpoints, that took a lot of hardware. I just used a 64Kx1-bit RAM hanging on the bus and I put a 1 in the appropriate location wherever you wanted a breakpoint. I was able to cut a lot of parts out of the emulator board that way.

That product sold really well and caused a kind of a problem. We were operating out of my house. Pretty soon, I had employees coming and going and the neighbors were not happy, so we moved into an industrial park. I hired more people and sold a ton of those emulators. We called that emulator the Icebox.

And of course, you know how it is. People wanted more features, so we came up with more features. We added real-time trace, for example, which needed a whole ‘nother board and resulted in more versions of the product. We had very different versions of the product covering more processors. We eventually re-engineered this thing into something we called the Universal Emulator, which was big. It wasn’t big physically, but there were hundreds of chips in that product. It was very capable. It had performance analysis and all kinds of other features.

Steve Leibson: Were these all 7400-series chips, which could have all been replaced with one FPGA?

Jack Ganssle: You know, we were one of the first Xilinx users. And yeah, we’re using a Xilinx part. And their software was crap back then. You know, nowadays it’s all VHDL, but back then, we designed with schematic capture. The Xilinx tools would turn a schematic into a netlist, and oh, my God! It crashed constantly. But you know, as a matter of fact, we had another big problem. The Xilinx parts wouldn’t boot from the boot ROM reliably. We finally put a Microchip PIC microcontroller in there just to watch the Xilinx FPGA, to see if it booted up. If it didn’t, then the microcontroller would kick it again to make it reboot.

Steve Leibson: So, was the FPGA in the original emulators, or were you converting over from 7400-series logic parts?

Jack Ganssle: This is one of the later emulators. This is back around the early 90s, and this was a much more competent box than the original box. What I found was that it was just as easy to sell a $6,000 emulator as it was to sell a $600 emulator. And, of course, the margins were a whole lot better on a $6,000 product. We wound up selling quite a few of those.

But you know, one of the biggest issues with a tool like an emulator is customer support, because you’re plugging into everybody’s CPU socket. What we found is that a lot of these engineers didn’t really understand anything about electromagnetics, signal propagation, or things like that. So, we had to provide a lot of support, which required a lot of travel to customer sites. We wound up helping many customers re-engineer some of their products to be reliable. You know how it is. Sometimes they say, “It works. Ship it.” But then, you know, does it work over temperature? Does it work If the moon comes out? You know, the real engineering side of things.

Steve Leibson: Right.

Jack Ganssle: That was pretty interesting. I really enjoyed the troubleshooting and figuring out how everybody’s systems operated and what the problems were.

Steve Leibson: You must have documented that, because over the years you’ve leaked all that knowledge out in your various writings in the Embedded Muse [Ganssle’s embedded engineering newsletter].

Jack Ganssle: Yeah, I guess. So.

Steve Leibson: Or did you hold it all in your head.

Jack Ganssle: You know, I used to keep a pretty detailed journal about everything, and not just about the business. I also journaled other aspects of life and whatnot. A lot of experience went up there, but a lot of it was sort of just buried in my head and wound up in articles, like you say, the Embedded Muse and whatnot.

But you know, being exposed to other customers is very interesting. I found out that I would send my engineers out into the field and they would oftentimes hate it because of what happens when an engineer is in the field. They call back to the office, and you tend to blow them off. You say, “Oh, come on. It’s just Joe out there.” But if everybody in the company is doing this, then suddenly everyone starts putting the customer’s interest at heart, to help Joe get back to the office as quickly as possible. It was a real education for everybody.

Steve Leibson: So, you started off with microprocessors, and that made your life easier because the address and data lines and all the other important pins are externally available. But as I recall, you did get into microcontrollers as well, and that must have been a real headache.

Jack Ganssle: Yeah, we got into microcontrollers with the Universal Emulator, the bigger product. We were involved with a number of microcontrollers, and you know, even something like the 80186, which is not a microcontroller, but it had a prefetch buffer in it. That means that all the stuff coming into the address bus is not well correlated with what’s going on inside the chip. So, for chips like that, Intel was never very helpful to 3^rd-party emulator people. They didn’t make any special chips available. We would have to write software to emulate the processor’s operation, so that our real-time trace would actually be a real-time trace. We would see what was on the bus, and even though what was on the bus was sort of scrambled, we could reverse- engineer it in our code to properly reconstruct what the trace should be.

On the Microcontroller front, companies like Hitachi and NEC were really good about supporting us. They would give us bond-out chips with hundreds of pins that would give us access to what the processor was really doing. But things kept getting worse and worse. People started throwing cache memory on the parts. With cache, it’s really hard to know what’s going on inside.

Then they started cranking up the clock rates. At 10 MHz, things are pretty civilized, but at 100 MHz, everything is bad. Try to propagate signals over a cable at 100 MHz and you’ll find that it’s really difficult. So, we would move a fair amount of the emulation logic onto a little board that plugged right into the processor socket, and then we’d bring a cable off of that and back into our box.

Around the mid-90s, it became apparent that in-circuit emulators were not going to be around forever. People came out with these background debug modes, what’s now called JTAG. Now with JTAG, or many other different interfaces, the processor has a lot of the emulation logic on the chip, because transistors are “free.” With a couple of cheap ICs, perhaps $3.00 worth of parts, you can interface the processor to the serial port on a PC. [That’s an apt description of Microchip’s MPLAB PICkit Basic In-Circuit Debugger.]

One of the emulator companies came out with one of these background debug mode things and sold it for thousands of dollars, which made no sense to us. For a prank at one of the Embedded Systems Conferences, we made up about a thousand or 2,000 of these little debug things and gave them away, which ticked off a lot of people.

But because of the processor speeds and the ugly stuff going on inside the chip that we couldn’t really see, and many other things, I realized that this is going to be a dead business. I got an opportunity to sell to a company called Avocet.

Steve Leibson: So, that’s a great story that leads up to the fulfillment of your prediction that the emulator business is on its way out, and that it’s going to result in a $30 box.

Jack Ganssle: Yeah, I mean it makes sense. The industry kind of had to go that way.

So, there you have it. Jack’s insights from 30 years ago have proven to be correct. As a result, you can now get incredibly powerful development tools for very little money.