标签: MCUs

Frequent correspondent Charles Manning shared a link to a question  on Nordic Semiconductor’s site. The entire question, verbatim, is “What BLE profile would suit a ECG signal best and is there any example code for ADC in to that profile? Have searched for a while and cant (sic) find any.”   Charles – and I – were stunned. Someone is building a critical bit of medical equipment with what appears to be limited knowledge of the communications protocol they’ll use. He is also planning to build this upon vendor-supplied reference code.   It’s probably unfair to read too much into this question, despite the possibly-chilling repercussions for users. I don’t want to knock the forums; they are a great way of sharing knowledge. Pre-Internet we all pretty much had to figure things out on our own, which was terribly inefficient. I can remember flying to vendors’ facilities to talk to chip designers to get the inside scoop on some poorly-documented or broken bit of functionality.   And, believe me, I’m all for reuse, and think it’s really our only hope of salvation as systems get bigger and more complex.   But reference code is notoriously-buggy and incomplete. It’s usually meant to show a developer how to use chip features. Most experienced developers have scars from episodes of figuring out just why some of this code doesn’t work. Some of it is simply ghastly. Charles uses a Nordic part and claims their code is a cut above the rest but is still just reference code.   The person who phrased this question may be an extremely competent developer who will analyze the code before using it. But this is a symptom of two problems with the industry today.   The first is the aforementioned often-crummy quality of vendor-supplied code. In some cases it’s so bad a semiconductor company will put a large team of their own engineers into a customer site to help get a product to market. Of course, this only happens for those buying enormous numbers of chips so the little folks, or even those buying hundreds of thousands, are stuck.   In some cases I know that the work these engineers do never makes it back into the reference code supplied to everyone else. There’s never time to address any issue other than the immediate crisis, so doing an update is out of the question.   One has to have some sympathy for the vendors; after all, their mission is to sell chips. Reference code is free and therefore perceived as a loss leader. The stuff has to exist to push silicon out the door, but never gets the attention it needs. Modern MCUs are really complex. Even the bus fabric can baffle. Peripherals run in innumerable modes. Hundreds or even thousands of registers have to be set exactly right. Datasheets run 500, 1000 or more pages today. Reference software really can’t address every mode and configuration. The cost to develop this stuff is enormous, the price is zero.   The second problem is the perennial issue of time to market. Customers simply don’t have the time to figure out the nuances of handling all of these peripherals so rightly want solid code they can drop their applications on top of. Reusable reference code is a solution. If this were a perfect world, reuse would be at the object code level, all of the reused code would be qualified, and customers would have complete confidence in the code.   One wonders with the explosion of IoT devices coming our way if this problem will only get worse.   Unfortunately, there’s a subtle meta-problem as well. Suppose a semiconductor vendor builds reference code that is absolutely perfect. No bugs, brilliantly documented and a testament to fine software engineering practices. Who would believe them? Decades of problems has create a general distrust. How would a vendor convince the skeptical that, now, for sure, they have produced what we really want?   When it comes to reuse it pays to think about the pyramids. They were built on incredibly strong foundations. In the firmware world, all too often that’s inverted.   What is your experience with reference code?

I have a close friend who is a serious part-time investor. He watches Cramer every night, researches companies thoroughly, and spends quite a few hours per week managing his investments. He does well at it. I can't be bothered. To me, the process is not terribly interesting and I have little knowledge of these issues. So I mostly stick with index funds. In one of the Back to the Future movies Biff gets a book of sports results from the future and bets his way to riches. I wish I had had such a book for stock picks. Consider this: in December of 2008 the stock of Arm Holdings (NASDAQ:ARMH) was going for a bit under $4/share. As of this writing ( November 20, 2013 ) it's $46, better than an order of magnitude increase. The dumbest thing I never did was to not buy ARMH five years ago. The following graph ( from finance.google.com ) shows ARM's spectacular rise. The blue is ARMH; for comparison check out the Dow in orange: ARM Holdings' vs the Dow. In 2012 ARM Holdings earned about $260 million ( using today's exchange rates, as the annual reprort is in Pounds ). With 1.4 billion shares issued that's a P/E of an astonishing 248. Compare that to the average of 18 in the Dow Industrials. The company is valued at $64B yet total revenue was under a billion dollars last year. The results are amazing for any company, but especially for one that doesn't make anything. Digi-key lists over 6000 different ARM-based microcontrollers. Sure, some are just small variations like different packaging options. But that represents two-thirds of all of the 32 bit MCUs Digi-key offers. 4800 of those 6000 ARM MCUs are Cortex-M series parts. I think the success of the M-series is one of the most exciting developments in the last decade. The M0 is a quite minimal 32 bitter that can be sold very inexpensively. At the high end the M4 can have an MPU, SIMD and even hardware floating point. And you're still only talking a few bucks per part. Some licencees are doing amazing things. NXP's LPC4370 has an M4 and M0, letting designers split the workload up, or put the M4 to sleep when the work only needs a more power-frugal M0. A second M0 id dedicated to some of the I/O. Freescale's Kinetis series is a carefully mapped out set of CPUs covering a broad range of applications. NXP, ST and a ton of others sell huge varieties of M-series parts. ARM projects that by 2016 the current 26 billion microprocessor chips sold will grow to 40 billion per year. IDC predicts that the Internet of Things will be an $8.9 trillion dollar market in 2020 with 212 billion different devices connected. Others, notably Fairchild Semiconductor, claim there will be a trillion sensors deployed by that date. How many ARM cores will be in this fabric of connections? For years I've felt the industry suffered because of the huge array of different processor architectures. The outcome is a smaller market for tools for each CPU. The increasing use of ARM cores means more users, so vendors have the incentive, and money, to optimise their offerings. Fewer architectures means less retraining when switching processors. What do you think? Is the ARM juggernaut likely to displace most of the 32 bit MCU architectures?  

I get tons of email, and the most common query is " How can I become an embedded developer? " Alas, that's tough to answer. I learned about it the same way we learn about the birds and the bees: talk to your friends, run a few experiments, and iterate. Efficient? Probably not. Reading about the subject is critical (uh, about embedded, that is). There are a lot of great books available. A new one by Rob Oshana and Mark Kraeling (Software Engineering for Embedded Systems) is highly recommended. But experimenting is just as important. In the old days it was costly to get the tools, but that has changed a lot. Some IDE companies make limited versions of their tools available. IAR, for instance, has a size-limited free version of their Embedded Workbench that is excellent. It's amazing how many low-cost evaluation boards have come out in the past few years. One of my favourites is the relatively-new FRDM-KL25Z from Freescale, which is populated with two of their Kinetis ARM-based microcontrollers. One manages the USB interface and acts like an uninteresting component. The other, a Cortex M0+, is a full-blown 32 bit MCU with 12k KB of flash and 16 KB of RAM that you can program to learn about ARMs and embedded engineering. I have a couple of these and find them useful for all sorts of experiments. The best part? The board costs just $12.95 and is available from distributors like Digikey. Thirteen bucks to get a development system is amazing. When I got started in this business a development system was an Intel MDS with a floppy disc drive. We paid $20k then, which an inflation calculator says is $105k in today's dollars. Gas was $0.30/gallon in those solid-dollar days; it wasn't uncommon to stock up the VW with just a quarter's worth. Geezing aside, Freescale has done a great job of building a line of Cortex M-series MCUs in their Kinetis line. The naming conventions are a bit confusing as all start with a "K", and one of the lines is called the "K series", but the part on the FRDM board ( Figure 1, below ) is a KL25Z128 (from the "L" series), a 2 buck part (in hundreds) which has gobs of peripherals, including a 16 bit SAR ADC and 12 bit DAC. A comparator is driven by a six-bit DAC, which suggests some intriguing applications. A capacitive touch sensor is included as well.   Figure 1: The KL25Z128 MCU. The FRDM board is sparse; it doesn't take much to support the MCU. No headers are included, so to use the I/O you'll have to add them or solder directly to the board. Add headers, and the board is compatible with Arduino shields. The MCU's capacitive sensor is brought to a touch slider making it easy to experiment with this newish interface. I particularly like the board's accelerometer, though haven't actually used it for anything worthwhile. But it sure is cool to play with.( Figure 2, below )   Figure 2: The FRDM board driving a Logicport logic analyser. One of the nicest features of the FRDM board is not something you'll find on the PCB. It is supported by the mbed folks , a site that contains lots of example code, drivers, and a completely free web-hosted compiler. It's an odd thing: there's no IDE installation. Just write code in the window, press "compile", and an executable binary downloads to the FRDM board ( Figure 3 below ). Your embedded program starts running after pressing the reset button. This means debugging is crude, but for small prototypes and experiments your code is up and running from flash in a flash. I've never encountered a development environment so easy since Dartmouth Basic.   Figure 3: Accelerometer program. The code shown in Figure 3 is shamelessly lifted from the mbed site and is a complete program to read the board's accelerometer and change LED colours based on the data. The important thing to note is that the LEDs are being PWMed and there's practically no code involved. The mbed libraries do all of the work once the code associates the LEDs with pins. One is left with making an application work, rather than figuring out how to set up dozens of control registers. There's a huge variety of Cortex M-series MCUs available from a lot of different vendors. The FRDM board makes it simple to dive into this expanding and important world. What do you think? What eval boards do you like?  

According to the recent reports, the wireless sensor networking chip market increased by 300% in 2010 and is doubling yet again this year. More important for embedded systems developers, wireless-enabled sensor spending grew by 80% in 2010. This increased interest in embedded wireless connectivity is also reflected in the 2011 Embedded Market Study.   But with great opportunities come great challenges. In Ron Wilson's recent column on wireless networks he pointed to the serious problem of wireless security, especially as more of these networks use or interface to the wider Internet via the IPv6 protocol. In "Sensor Fusion brings situational awareness to health devices," Supreet Oberoi points out another serious problem: how do you collect, organize and respond to the information you are getting from the wireless sensors?   Elaborate, data-centric networking methods in the form of the Data Distribution Service and the Java Messaging protocol will go a long way toward solving the data management problem.   Then there is the problem of real time and deterministic performance over wireless sensor networks, given the fact that the IPv6 protocol many of these devices will connect to is still asynchronous, with no real global clocking mechanism. Specifications such as IEEE 1588 have emerged to deal with this but adoption is moving happening slowly. To fill in the gap, wireless network-specific protocols such as WirelessHART, 6LowWPAN, and AODV have been proposed.   Then there's the new IPv6 protocol which makes available unique URLs that are counted in the billions of billions of billions. Even if every human on the planet had his or her own URL address, the number of URLs still available is essentially infinite, raising the prospect that almost every embedded device in the world will have its own URL. Will sensors with 8- or 16bit MCUs be up to this challenge, or will 32bit MCUs dominate?   These are questions that I think need to be addressed and I look forward to hearing from you with your ideas and contributions.