It's true what you say, Andreas, about multicore not necessarily improving the performance of single-task execution, and that there's only a gain if an app is tuned (threaded) specifically for multicore. The other thing that strikes me is, hard as multicore programming is in the "regular" computer and DSP space(s), it'll be something fairly new to embedded developers, so they'll have a steep(er) learning curve to come up.
Some other disadvantage not mention quite often is, that developers have sometime only access to software for single-core processor development and that such developed programs finally run in the worst cast much slower on the multi-core platform. Multi-core systems also do not improve automatically the performance of single task execution, so discussing about multi-core platforms, developers should also have a deep understanding of multithreading and multitasking. For example only the question if you want to run multiple threads on different cores can cause a lot of work and problems.
Programming multicore is hard. Traditional IDEs are merely graphical front ends for compilers. This is no longer practical with multicore. The graphical interface must serve to minimize the nuts-and-bolts grind of low-level programming. TI has the right idea with Grace. Cypress also has this partially implemented with the PSoC IDE.
Ideally one should be able to allocate resources, activate peripherals, and set up pinouts by moving around the mouse. Only when, for instance, you want to do a running average, you might actually write some code.
Multicore MCUs have impressive capabilities, which vendors obviously want to highlight. Often unsaid is the fact that multicore parts are more expensive than their single-core cousins. From the users' perspective, it's all about selecting the right part for the job. If multicore capability is required, great. But if not, it's more cost-effective to go with a less powerful part.
In a bid to boost the viability of lithium-based electric car batteries, a team at Lawrence Berkeley National Laboratory has developed a chemistry that could possibly double an EV’s driving range while cutting its battery cost in half.
Using Siemens NX software, a team of engineering students from the University of Michigan built an electric vehicle and raced in the 2013 Bridgestone World Solar Challenge. One of those students blogged for Design News throughout the race.
Robots that walk have come a long way from simple barebones walking machines or pairs of legs without an upper body and head. Much of the research these days focuses on making more humanoid robots. But they are not all created equal.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.