Tips on building & debugging embedded hardware & software designs: Part 2
You can’t pick up a magazine without reading about “time to market.” Managers want to shrink development times to zero. One obvious solution is to replace masked ROMs with their OTP equivalents, as producing a processor with the code permanently engraved in a metalization layer takes months - and suffers from the same risk factors as does OTP. The masked part might be a bit cheaper in high volumes, but this price advantage doesn’t help much if you can’t ship while waiting for parts to come in.
Part of the art of managing a business is to preserve your options as long as possible. Stuff happens. You can’t predict everything. Given options, even at the last minute, you have the flexibility to adapt to problems and changing markets. For example, some companies ship multiple versions of a product, differing only in the code. A Flash or OTP part lets them make a last-minute decision, on the production floor, about how many of a particular widget to build. If you have a half million dollars tied up in inventory of masked parts, your options are awfully limited.
Part of the 8051’s success came from the wide variety of parts available. You could get EPROM or masked versions of the same part. Low-volume applications always took advantage of the EPROM version. OTP reduces the costs of the parts significantly, even when you’re only building a handful.
Microcontrollers do pose special challenges for designers. Since a typical part is bounded by nothing more than I/O pins, it’s hard to see what’s going on inside. Nohau, Metalink, and others have made a great living producing tools designed specifically to peer inside of these devices, giving the user a sort of window into his usually closed system.
Now, though, as the price of controllers slides toward zero and the devices are hence used in truly minimal applications, I hear more and more from people who get by without tools of any sort. While it’s hard to condone shortchanging your efficiency to save a few dollars, it’s equally hard to argue that a 50-line program needs much help. You can probably eyeball it to perfection on the first or second iteration.
Again, appropriate technology is the watchword; 5000 lines of assembly language on a 6805 will force you to buy decent debuggers - and, I’d hope, a C compiler.
You can often bring up a microcontroller-based design without a logic analyzer, since there’s no bus to watch. Some people even replace the scope with nothing more than a logic probe.
An army of tool vendors supply very low-cost solutions to deal with the particular problems posed by microcontrollers. You have options—lots of them—when using any reasonable controller—far more than if you decide to embed a SPARC into your system. Some companies cater especially to the low end. Most do a great job, despite the low cost. I recently looked at Byte Craft’s array of compilers for microcontrollers from Microchip, Motorola, and National. Despite the limited address spaces of some of these parts, it’s clear a decent C compiler can produce very efficient code.
One friend cross-develops his microcontroller code on a PC. Using C frees him from most processor dependencies; compile-time switches select between the PC’s timer/UART, etc., and that contained in the controller. He manages to debug more than 80% of the code with no target hardware.
Working in a shop using mostly midrange processors, I’m amazed at the amount of fancy equipment we rely on, and am sometimes a bit wistful for those days of operating out of a garage with not much more than a soldering iron, a logic probe, and a thinking cap. Clearly, the vibrant action in the controller market means that even small, under- or uncapitalized businesses still can come out with competitive products.
Loading comments... Write a comment