At last, I’ve been vindicated. A semi-official study has shown that car alarms are wholly worthless, and that they actually may be a social and economic drain on the community at large. Not surprisingly, 99% of people who hear a blaring car alarm completely ignore it (which obviously defeats the purpose of the alarm), while the few souls who actually do report an alarm to the police don’t do it because they think the car is being stolen. No, they report it as a noise complaint. Even insurance companies, a group famously guided by hard-nosed statistics over mere anecdotal evidence, and with tens of millions of data points to rely upon, treat car alarms as worthless in preventing theft or damage. Worse than useless, in fact. The earsplitting noise just covers the sound of breaking glass, making it actually easier for bad guys to steal the car or its contents. Go figure.
This was all brought to mind as I attended Embedded Systems Conference MCMXXVII in Santa Clara, the umpteenth incarnation of the perpetually retitled and reimagined nerdfest for embedded designers. Crossing the parking lot, I was treated to the sound of many embedded systems bleating plaintively within the parking structure. Maybe the cars got lonely and were pining for their owners to return. Or perhaps that morning’s minor earthquake had set off a dozen false alarms. More likely, they were just malfunctioning, draining their lead-acid batteries and making the parking attendant’s job just that little bit more miserable.
Inside the show, things ran much more smoothly. Simplicity in engineering is a virtue, and the current instantiation of ESC is… simple. What would have been the overflow lobby in past years is now the entire show. The exhibitors’ booths were, indeed, booths, and not sprawling architectural confections with their own ZIP code and a mortgage. It made the show more personable — and also a quick visit. A boutique instead of a shopping mall.
Chief among said exhibitors was STMicroelectronics (they don’t like to be called STMicro), which ably demonstrated several new variations of its STM32 microcontroller line. To be honest, ST already has so many ARM-based MCUs in the STM32 line that it’s hard to think of a niche or application that’s not already served. But they’ve found a few anyway. First, there’s the STM32L4 series, which is a low-power subfamily whose Cortex-M4 heart putters along at 80MHz and below. Sleep modes are plentiful, and they allow you to trade off active current for wakeup time. I counted seven different operating modes before I ran out of fingers.
Other options include an LCD driver for simple 8×40 displays, a crypto block, and something ST calls an ART Accelerator. This last feature is a combined prefetch queue and branch cache that sits between the ARM processor core and the chip’s flash memory. The idea is to accelerate (or more accurately, just delay less frequently) the core’s interface to code storage. CPUs are generally a lot faster than memory, especially flash memory, and so the processor winds up waiting around an awful lot. Speeding up the CPU doesn’t help; it often makes the problem worse. To ameliorate some of that delay, ST invented its own buffer that lets the Cortex-M4 run more or less at normal speed.
Over on the other side of ST’s booth sat the new ST32F7 chips, a relatively high-end subfamily based on the Cortex-M7 core. These run at a quick (if seemingly arbitrary) frequency of 216 MHz, boast a megabyte of flash and 320KB of RAM, and carry Ethernet, a full TFT-LCD controller, HDMI, camera interfaces, and more. ST showed off its new part with a real-time audio-processing demo that responded to voice commands whispered at it from the noisy show floor. Impressive.
Rival Microchip had its own MCU newborns to show off, too. Even more so than ST, Microchip has such a crowded catalog that it’s pretty much impossible to make sense of part numbers that are seemingly assigned at random. Perhaps it’s a security measure or a test for applications engineers. Nevertheless, Microchip has grafted two new branches onto its PIC16 family tree, the ’F1579 and the ’F18877. All PIC16 devices are 8-bit MCUs – obviously – and the new ’F1579 chips are designed for, well, mood lighting. Not that there’s anything wrong with that. The chips come with clever PWM features that interface nicely to a new generation of networked LEDs that are becoming popular with builders, remodelers, and automakers. Any place you want a lot of colored LEDs controlled by one low-cost microcontroller. If the LIN or DMX bus standards mean anything to you, the ’F1579 is your MCU.
The new ’F18877 chips are a bit more complicated, and they come larded up with ADC inputs, DAC outputs, comparators, touch controllers, and lots of serial interfaces. The ADCs are particularly interesting because they come with some built-in intelligence that’s new to the PIC family. Rather than just converting analog inputs into digital values and passing the data off to the 8-bit CPU, these ADCs can actually massage some of the data themselves, even while the CPU is asleep. They can average inputs, for example, or provide low-pass filtering, accumulate samples, and perform other straightforward tasks. That eliminates software and either allows the CPU to sleep or permits it to do other things while the analog inputs are being read. A win all the way around. Prices for both part families are mostly in the 40-cent to 70-cent range, depending on package type and memory capacity.
Over on the RTOS front, Express Logic now supports the Andes processor, an up-and-coming soft CPU that we mentioned just a few weeks ago. The company’s RTOS and related toolchain has also been adopted by Renesas for its quick-start Synergy platform, based, of course, on the latter’s proprietary 32-bit MCUs.
Finally, Express Logic’s ThreadX RTOS is now MISRA-compliant. That’s something customers have asked for, since ThreadX is royalty-free and comes with all the source code. Most customers never looked at the source code, but those who did sometimes preferred to see MISRA-compliant code. Making ThreadX adhere to MISRA standards was a bit of a trick, given that the RTOS itself isn’t written entirely in C; some of it is assembly code specific to the processor or the platform. Fortunately, MISRA rules permit calls to assembly code, and the parts of ThreadX that are written in C (i.e., most of it) are now compliant with the rules. Maybe that will encourage makers of car alarms to think about rewriting a few routines.
