Activity at Embedded World and elsewhere this week has resulted in the arrival of many new options for MCU developers. Here's a quick rundown of the ones that popped up on my radar screen:
Atmel issued a dual-topic press release covering both tools and MCUs. The company has introduced its Studio 6 IDE, which now supports both the company’s ARM Cortex-M series and 8/32-bit AVR series products. This new tool will give developers all the tools they need for either product family in one place. In addition to the tool, the company announced an expansion of its SAM3 ARM COretex-M3 processor family. There are now 40 new members, providing more options for package size, peripheral mix, and memory resources.
NXP released not a new MCU, but a new development kit developed in conjunction with partner Embedded Artists. The Android Open Accessory Application development kit provides developers with a bridge to Android-based mobile devices. The kit helps simplify development of applications for interface to or control of embedded systems using an Android platform. So, you can not only create "an app for that," you can create the accessory that the app is to control. The kit also supports use of the CAN bus, Ethernet, and 802.15.4 interfaces. It even has a nifty break-away section on the kit's PCB for creating a remote CAN peripheral.
Renesas Electronics announced its new RH850 family of 32-bit MCUs for automotive applications. The new family will include features for functional safety supporting all ASIL levels. Samples won't be available until Q3 of 2012, though.
Texas Instruments has announced its
"Wolverine" platform, which it claims uses half the power of any other MCU in the industry. Based on FRAM, the devices boast a standby current of only 360 nA. TI expects to have devices sampling in June, 2012.
I thought you would like to know about these. Any comments?
notarboca 4/12/2012 8:35:46 PM User Rank Program Manager
Re: TI's new offerings
I will be fascinated to see real world measurments from the TI Wolverine platform come June or thereabouts. Interesting use of FRAM "new-old" technology.
ASEEMOV 3/27/2012 12:40:46 PM User Rank Program Manager
Re: STDIO (Standard IO) Support via the ICE
In situations where STDIO is not supported, one other option/trick I use is: Tcl API extensions. My experience so far is that Tcl API extensions are mostly supported in IDEs. I use the API extensions to read / modify the memory content on the fly, initialize arrays in MCU memory by reading the initialization data values from files stored on PC (and vice-versa). However, having STDIO support would have greatly helped, using Tcl is sort of a workaround - not so clean though but gets the job done.
Rich Quinnell 3/20/2012 3:47:16 PM User Rank Blogger
Re: MCU simulator support in development tools::
Curt, I agree that simulation of an MCU seems to be of limited value given how quickly you can get a real one up and running. Then, too, there is the problem of making sure the simulator has all the integrated peripherals properly mapped out. And given that some cores have more than 300 variations of MCU based on them, simulation becomes a major hassle.
I agree fully that there's a place for simulation AV -- where would the industry be without SPICE and VHDL/Verilog/SystemC?
But at the MCU hardware level, I think you're going to end up with a working prototype anyway, and it's become awfully easy to reprogram and reconfigure MCUs these days. Those factors, in my mind, seriously discount the the value of constructing, verifying and applying a simulation model -- all other things being equal.
But of course, all other things are NEVER really equal :-), so what do you think I'm overlooking in that argument?
Given a choice between a vendor-supplied model of his device, or an evaluation board that you can poke at with your scope probes, connect to your real live hardware environment (those bouncy switches I mentioned) and control/monitor via a USB port on your PC, which would you rather have, really?
Caveat: an MCU embedded in a FPGA fabric is going to beg for simulation tools, I think.
ASEEMOV 3/20/2012 11:59:29 AM User Rank Program Manager
STDIO (Standard IO) Support via the ICE
Hello,
I strongly feel that IDDE (Integrated Development and Debugging Environment) should support this feature of providing the Standard IO support as long as there is no obvious issue seen with memory usage. This support in simulation mode and also in emulation (on the actual target) mode via JTAG ICE is very useful. This helps process huge amount of input data (stored on PC hard disk) and later write the results back to a FILE (again on PC hard disk) - all this STDIO support provided via the JTAG ICE interface. So, even before customers try to implement a real time system using the on-chip serial/parallel data IO peripherals, an extensive amount a testing and code development+debugging could be performed using the STDIO library while the actual data processing algorithm runs on the MCU. Once the algorithm is ported, system designers can then start using the device peripherals to make the custom system run in real time. Some tools do have this support while some don't. I think this is a very attractive feature to have in all IDEs.
ASEEMOV 3/20/2012 11:42:40 AM User Rank Program Manager
Re: MCU simulator support in development tools::
Hello Curt,
What I see is that now a days almost everyone is trying to include application specific / domain specific hardware accelerators. Some of these on-chip hardware do behave like accelerators and some others behave like offload engines. Most of this gets usually prototyped on FPGA platforms to serve two things: 1. customer demo/evaluation platforms/software application development and 2. pre-silicon validation using the FPGA platforms. One thing I'm sure about is that chip designers do use and rely on "C" models for design and verification. The question is how well these "C" models can be reused by the IDE tool developers and integrate them in the development tool chain such that they now form a part of the simulation platform in addition to the MCU core simulation platform. I don't think customers would be infinitely concerned about cycle accuracy issues here but would rather appreciate such a platform that would help them simulate a complete signal chain.
Secondly, from code generation perspective, some of this can actually be ustilized to develop Simulink models which customers can use for system simulation or even to generate the MCU code. Obviously, the code generation (for accelerators) portion is only a matter of configuring the appropriate control registers to create a specific signal chain through accelerators or other SoC peripherals.
I think a lot of this can really help customers evaluate the MCU features before they decide to buy the actual hardware...
The last time I made serious use of a simulator, it was with an 8051-class device that I couldn't reprogram in-circuit (remove device>erase>program>reinstall device>find bug>remove device>...). Simulation saved a lot of time in that environment -- but I don't think the cycle is an issue for anyone anymore.
I also never really liked trying to simulate peripheral modules and the electrical environment they connect to. You can spend a lot of effort trying to build a useful simulation model of something as simple as a switch that bounces at a more or less random frequency and for a more or less random time, for example.
Finally, it takes a significant amount of effort to master a simulator, and the simulator suppliers never (in my opinion) did a very good job of providing a good learning platform for people that wanted to use them.
That said, simulation is bound to become highly relevant again to MCU designers (as contrasted to, say, chip designers) as some of the peripheral modules move into FPGA-like structures and more of the electrical interface moves on-chip (IMHO of course).
Rich Quinnell 3/19/2012 3:12:55 PM User Rank Blogger
Re: MCU simulator support in development tools::
Aseemov, good question. Will simulators continue being an essential part of MCU design, or if not, why not? ANyone on site that works for tool companies, feel free to chime in with your opinions here.
ASEEMOV 3/19/2012 2:00:41 PM User Rank Program Manager
MCU simulator support in development tools::
Hello,
Having worked on Digital Signal Processor IDDEs for a while, I was a bit disappointed to see not so great simulator support for MCUs in their development tools. In fact, I believe there are some development tools which only support running the code on a real target - No simulator at all. The DSP companies did a pretty good job on developing cycle accurate simulators and even included peripherals (such as the SPI, SPORTs etc) in their simulators. But over a period of time, the complexity of controllers and peripherals increased. And now, there are a lot of hardware accelerators coming in picture as well. I believe most companies have now stopped simulator support for the hardware accelerators, complex on-chip controllers etc but still manage good core simulators. Not sure in case of MCUs, simulators would improve in functionality and features or would they slowly fade out over time..?
To save this item to your list of favorite Microcontroller Central content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
