You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go to http://www.ganssle.com/tem-subunsub.html or drop Jack an email .

Jean Labrosse's books about his uC/OS-II and uC/OS-III real-time kernels are reputedly the most popular books ever written about embedded systems. Now they are free in PDF form on Micrium's web site . Also free are Christian Légaré's books about uC/TCP. These are great references about RTOSes and the protocols behind the Internet.

In fact it is possible to accurately schedule a project, meet the deadline, and drastically reduce bugs. Learn how at my one-day, fast-paced Better Firmware Faster class, presented at your facility. There's more info here .

How do you get projects done faster? Improve quality! Reduce bugs. This is the central observation of the quality movement that totally revolutionized manufacturing. The result is a win-win-win: faster schedules, lower costs and higher quality. Yet the firmware industry has largely missed this notion. Deming et al showed that you simply can’t bolt quality onto an extant system. But in firmware there’s too much focus on fixing bugs rather than getting it right from the outset.

Ken goes on to say that Martin Moene had a similar idea, published here . Ken welcomes feedback to kgsmith@gmail.com.

Ken Smith has a different take on accessing hardware registers in C++. His paper about this is here and Ken's description is: Everything about a hardware register is listed in the datasheet for the processor or peripheral. We know its address, its offset with the word if any, and we know whether the register is readable, writeable or both. Therefore, we know how to refeine a register or any of its subfields at compile time. Many register manipulation techniques exploit some of these pieces of a priori knowledge to ensure safety and efficiency but none I have seen so far exploit them all. This article presents an approach for hardware register access in C++ that puts all of this a priori knowledge to use to help ensure safety without sacrificing efficiency.

Caron Williams wrote: Even though it's now about 40 years old, 'The Mythical Man Month' [Fred Brooks] still has many very relevant and powerful things to say to electronics and software engineers. I'm sure you've read it, and I'm pretty sure you endorse my statement. However none of the newly graduated engineers I've interviewed in the past 20 years have heard of it! As you said: none, nada, zilch, etc. I would make it required reading for anyone about to embark on a software project, and the lessons it contains are applicable to hardware design too.

Datasheets are getting huge as the number of peripherals grows. But it has been a long time since they were mailed on paper (another part I know needs almost 5000 pages - print that and you'll use an entire box of paper). PDFs make production costs zero. Vendors do us a grave disservice when hand waving and marketing "product briefs" substitute for cold, hard numbers.

(Execute out of external memory and no matter how fast the thing can swallow clocks it may be slowed to a crawl. One eval board here runs at hundreds of MHz but the external flash is 70 nsec, and the RAM not much better at 55 nsec. That makes the cache-less single-cycle CPU loaf along at an effective rate of less than 20 MHz. There are some very interesting technologies used to improve this in some cases - ST's adaptive real-time accelerator being an example. But estimating performance has become very complex. Clock rate alone means little.)

What about clock rate? Sure, that's specified and, with enough patience a superhuman engineer will master the enormous number of modes and registers needed to control the various clocks. But what does clock rate even mean? Execute out of the on-board flash and will wait states be injected? The datasheet gives no hint. I ran some experiments and found that with the part screaming at it's rated 200 MHz the thing fetches 55 million instructions/second from internal flash. Now, as an old-timer who was once content with 2 MHz devices that needed several T-states to handle each instruction, that 55 million is a very impressive number. But it's a lot less than one might be led to believe going on the raw clock rate.

One ARM part I've been playing with has a 1100 page user's manual. There's plenty of information about programming the various registers to use the low power modes - but not a peep about exactly how many micro- or milliamps will be consumed.

It's all about the code - unfortunately. As mentioned above it's hard to get concrete information about the Kinetis' L series power consumption. But that's a common problem today - datasheets increasingly lack the electrical information a design engineer needs to both select a part and properly design it in.

This component doesn't issue a CPU reset; it's designed to monitor external hardware and sends a reset signal out of the MCU to those circuits outside of the K50 chip. It, too, can be used in a windowed mode, and servicing it requires writing two different values to the EWM registers within 15 clocks of each other.

If desired the WDOG can be configured to generate a non-maskable interrupt, followed 256 cycles later by a hard reset to the CPU. For a variety of reasons a crashed system may not be able to service the interrupt, so this option ensures the WDOG will do its duty. But if the gods are smiling the interrupt provides an ability to leave some debugging breadcrumbs behind. Interestingly, a register gives a count of the watchdog timeouts that have occurred.

An intriguing debug mode lets you configure the WDOG as normal, but keeps it from timing out. And self-test operations are included to comply with certain regulatory requirements.

You can, if desired, set it up in a windowed mode of operation. This means the WDOG must be tickled at least every so often (as is usual for WDTs), but not faster than some other interval. The times are programmable. This makes it much less likely that a rogue program will service the watchdog and keep it from timing out.

First, let's start with the refresh. To tickle the WDOG one writes two different words to it within 20 clocks of each other. That's a very safe and narrow window, which suggests that one must disable interrupts during the refresh.

It's easy to complain about WDTs inside controllers that have a myriad number of faults. But sometimes a semiconductor vendor gets things right, and that's certainly true in the Freescale Kinetis series. The K50, for instance includes not one, but two watchdogs. The first is a somewhat conventional though unusually-well-thought-out device they call the WDOG.