BOSTON--The battlefront among microcontroller makers is shifting up the stack as vendors wrap their silicon in middleware, said a Renesas executive in a wide ranging interview just prior to the opening of DESIGN East here.
Intel recently released a framework for embedded software based on security, management and Linux code from its McAfee, Wind River and PC divisions. Renesas made a similar move, cutting a deal to provide users of Renesas RX or RL78 MCUs with a license to Micrium’s software.
“A focus on the [MCU’s] instruction set architecture is misguided,” said Peter Carbone, vice president of marketing for Renesas Electronics America. “The model in the future is we need to provide both the hardware and software framework by market segments—that’s the game of the future,” he said.
Carbone praised Intel’s move as in line with the market trend, but noted no single software framework will serve all embedded engineers. “It would be nice to have one framework that fits all needs, but it’s not going to be the case, so we need to work with different partners,” he said.
For its part, Renesas will provide its RX or RL78 users a free, single production license for Micrium’s real-time kernel and middleware, including code for TCP/IP, USB and file systems. The license comes with a one-year maintenance and support agreement from Micrium. Renesas is working with other software partners for similar deals.
“In the microcontroller and embedded space, the real goal is to create a framework for customers that allows better hardware abstraction and reduces the dependency on the CPU instruction set,” said Carbone. “Customers have been doing this in house for cost reasons, but now they can focus on value added development,” he said.
Thirty-five percent of embedded engineers said middleware availability was a deciding factor in choosing a processor, according to an annual survey of embedded engineers conducted by UBM LLC, the publisher of EE Times. Middleware ranked fourth behind availability of software tools as the top criteria with votes from 70 percent of respondents to the survey taken in January.
At the hardware level, Renesas is ramping its 40-nm generation of microcontrollers, focusing on low power performance and integration. Its 8- and 16-bit lines draw as little as 141 microamps per megahertz and its 32-bit families consume as little as 200 uA/MHz.
“These days, even if a system is plugged into the wall, the OEM still wants to sell it as green and energy efficient,” Carbone said.
Capacitive touch interfaces and analog including RF and are two main focuses for microcontroller integration at Renesas. For example, one 32-bit RX chip includes a 24-bit delta sigma A/D to handle metrology for water and gas meters. Separately, Renesas is developing MCUs with integrated Bluetooth Low Energy and Zigbee Smart Energy 2.0 wireless support.
Renesas is also developing a suite of MCUs with programmable analog front ends. “We’re also investing in software-defined radios that can be updated in the field because protocols and stacks are constantly changing,” Carbone said.
As for memory, the Renesas 40nm MCUs will support up to 8 Mbytes flash at 120 MHz single-cycle access times and 512 KBytes SRAM.
On: “A focus on the [MCU’s] instruction set architecture is misguided,”
The problem for Carbone is that people focus on ISA only in the sense of ecosystem - few customers know a single instruction, but they sure know how many compilers and debuggers and RTOSes and stacks are available for a given ISA. That is a major factor in software cost since frameworks are one thing but your software engineers need tools to build the actual applications. Intel does not have that problem, Renesas very much does, especially with so many incompatible architectures.
Application developers waste a lot of time if they have to learn new tools and/or are forced to use tools that make them less productive. This why people pay attention to ISA.
Pkimelman, thank you for the comment. The best practice for modern tools is to seamlessly support multiple ISA. Case in point is Micrium. The same can be said for Threadx, FreeRTOS and CMX. The compiler manufactures (IAR, Greenhills, GNU) have done a great job to hide ISA. Segger J Link is another example for a debugger. The MCU architectures supporting the Eclipse IDE have taken it a step further to seamlessly support different suppliers compliers and debuggers. The real issue is not the ISA, but the peripherals. Therefore, there are on going efforts to provide HAL or API to reduce peripheral dependency such as with Renesas RPDL and STM with CMSIS along with code generation tools such as Renesas PDG or Applilet and Freescale Processor Expert.
"Therefore, there are on going efforts to provide HAL or API to reduce peripheral dependency such as with Renesas RPDL and STM with CMSIS along with code generation tools such as Renesas PDG or Applilet and Freescale Processor Expert."
And herein lies the dilemma--how would a proprietary middleware layer reduce peripheral dependency? Only CMSIS has a multivendor support, and it's ARM only.
That's why Open Source community-supported software is winning and will eventually take over. The manufacturers would do well to take heed and support a common code library with a significant developer community participation.
Przemek, I agree, agree and agree that the industry needs to support a common code library. My initial point is that this code library is and needs to be ISA independent. The other issue is that no two applications are alike and one size fits all, especially in the MCU world, has some major draw backs since MCUs have limitations on the amount of memory and CPU resources. Until we can makes MCUs for almost nothing with near infinite memory and CPU performance this debate will rage on.
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.