RoweBits

MCU and MPU Survey Results - Few Surprises

2011-08-12T22:31:00.000-04:00

I recently reviewed the 2011 survey on embedded systems sponsored by EETimes, EmbeddedSystems and others and was surprised that there were no real surprises. Well, not no surprises, just very few.

Of course, I am very interested in MCUs and how they are changing in the market. It seemed to indicate that the processors were getting the peripherals right or better anyway and hardware designers liked this. It is no surprised that ARM is doing better and better; however the weak showing by Renesas, particularly after the NEC merger was a bit of a surprise. It is clearly a North American dominated survey.

There was a couple of other surprises. The rise of embedded Linux is no surprise - I expect this trend to continue and I also think that this has directly lead to the decline of other larger embedded operating systems like VxWorks, QNX Nucleus and Integrity.

The continued popularity of TI's OMAP is significant. It is clear that they have the correct mix of ARM and DSP functionality for a broad set of applications combined with the right tools and pricing. I expect that the Sitara and Integra lines will do well too - levering off this success with more specialized versions.

The apparent growth of freeRTOS - which isn't an RTOS but is just a kernel, combined with the growth of roll your own RTOS was to be expected. The reason for this is the very high pricing of the two best known MCU RTOS brands coupled with the lack of understanding of the true costs of integration, debug and test. The survey put test and debug numbers at 25% of the overall effort. It is likely closer to 50% and if managers computed the real lost market share for this period of delay, it is very likely that this would change.

Another related set of comments were made that the RTOS market was moving towards domination by the semiconductor vendors providing their own RTOSs for MCUs. Some even thing that they will move into hardware. It seems that the volume for most applications does not justify the loss of flexibility so hardware implementation will be limited to specialized applications.

Freescale has include the MQX RTOS free with its new MCUs. It is provided as a software component and it is likely that others may follow this trend. The real story here though is that many offerings of "free" this or that part of the total solution have been made: a free OS (and I mean a real OS) with an IDE sold by seat is one example. In any case, the offerings are always tied to something: a silicon vendor's hardware, an IDE lock-in and cost per developer, or extensive user development which masks the real cost. There is no free lunch!

Along with all of this, we see that users often don't pay attention to the real total cost of ownership, the largest component of which is time to market delay. Lean product development and platform based designs focused on open standards will still win the day for small, medium and large company development.

Myopic MCU Software Approaches - Part 1

2011-08-04T03:38:00.003-04:00

I talk to people doing MCU software everyday and the variance in the skill set and understanding of the key issues is large. I spend my days educating others on what is really important for their product development and companies in terms of MCU software.

With an MBA and an MEng along with 25 years of experience applying these skills in embedded software, I have an advantage over most others. I've been there and done that 100 times and seen all the mistakes several times. For the next few weeks, I thought that I would highlight the repeated mistakes I see others making in the marketplace.

The biggest mistake that I see is that technical people often don't understand the effects of time to market. Even very experienced and accomplished managers who apparently understand time to market often miss apply this knowledge because the decision criteria are complex.

Basic ideas on Time to Market costs are found here.

On a company basis, managers have to plan for Total Cost of Ownership minimization for lines of products. This involves lean product development or a platform based approach. This approach should not lock them into a single vendor if done correctly, or may do that but with unlimited rights, it is not expected to be an issue for many years. Most understand and strive towards this but fail to make sure that the decision minimizes time to market for upcoming projects.

Often, managers don't understand software engineering. Their experience is in hardware and are less familiar with software due to the technology shift in the market. Some managers know enough to listen and others do not. By using open standards in software, we have learned for the past 30 years that costs are minimized because we can quickly adapt the software to fit new customer requirements. This leads directly to minimal time to market for development. It is an often missed issue.

The reasons people use for locking their company into a single vendor, proprietary solution are varied. Generally they ignore Total Cost of Ownership and Time to Market. Here is a sample:

- The operating system is free with MCU-X and it is so expensive from other vendors we should just do this and the overall project cost will be minimal. This ignores the cost of training and development for a proprietary system as well as the main benefits of open systems - software reuse.

- We don't need an operating system - the application is simple. Here, the manager is thinking about past implementations on MCUs where the software was minimal. This is not the case today. As users demand new features, the lack of operating system will push out time to market and hamper the introduction of competitive features.

- A kernel is an operating system. Actually, most don't even know the difference between a kernel and an operating system. They start with a kernel, which the vendor may call an operating system even when its not, and then find out later that they are wasting many person years of time because they did not get the correct platform to develop their products. An operating system includes a complete set of standardized I/O modules and drivers along with other libraries to provide high level abstractions which eliminate many person months of effort.

- Performance of the kernel/operating system doesn't matter, they are all the same. Driven by hardware oriented thinking, software performance is often ignored. Managers are unaware that the cost of optimization for a specific function is often 10X the cost of a non optimized solution. Out of the box modules optimized for size and performance can save huge amounts of time, minimizing time to market. If the kernel is inefficient, this inefficiency can drive performance optimization everywhere with big delays and lost market share.

- We don't need feature X today; a minimal solution is enough, we will add it later. Although this is apparently a good choice today, the long term cost of adding feature X may be significant. By using an operating system which has provisions for adding a broad set of features, time to market is minimized as customers demand new and unexpected features.

By simply planning ahead and using the same ideas that have minimized time to market and total cost of ownership for larger systems, optimal results can be achieved for MCU based products as well. Here is a short list of things to do in order to minimize time to market and total cost of ownership for your product line.

- Use mainstream languages and tools.
- Use open standards where practical.
- Pay attention to off the shelf solutions which minimize time. The cost of purchase is far less than the cost of development in 99% of cases if time to market is considered.
- Fight not invented here - software reuse is your friend while in house development is extremely expensive.
- You can use an OS provided by a vendor, just make sure you have hardware options and other sources for the OS to avoid lock in.
- Get off the shelf features if possible.
- Planning is required even with a few developers. Make a good project plan.

-

A POSIX RTOS vs Lemming and Ostrich Behaviors

2010-04-14T17:32:00.010-04:00

I've been thinking about why engineers that develop MCU based systems don't do their homework on software alternatives while analyzing hardware decisions to death. I think in part that they are just happy to find a solution that works because traditionally, only the hardware was a problem. Today, MCU based systems are 80% software. Engineers must recognize and use new approaches to maximize company benefits.

Software engineering economics is an important area when building MCU based systems. Often technical people ignore the business side because they are more comfortable with the technical side. Sometimes they ignore the technical side. When they ignore both the business and the technical side, the company pays big time.

One key area that engineers have completely ignored is total cost of ownership or TCO. This concept has been well known and used in IT systems and now is entering the realm of embedded systems. The concept of TCO is simple: when making software decisions consider the total life cycle costs for your OEM development and minimize costs thereby maximizing profit.

TCO should be like apple pie and homemade bread - so universally appealing that everyone loves it; however this is seldom done today. Why is this the case?

Lemming behavior is most common. If a solution becomes fashionable, often others pick it up and use it without analysis of their requirements. The current case of Lemming behavior in the MCU world is underway with a well known proprietary kernel. Its consistently abysmal and disappointing performance and proprietary API should preclude its use on any system except a hobby system where development time, longevity, engineering costs and TCO are all subservient to immediate out of pocket costs.

When are these engineers going to realize free is not necessarily free? Why didn't they calculate TCO before the commitment rather than after the fact?

Ostrich behavior is common too. In this case, engineers use obsolete and proprietary technologies when they should know better. The world is built on open systems and compatibility. For the MCU world and the RTOS world, two key factors which should influence all software development are discussed here.

The first fact is that the world has moved to POSIX for every major operating system and RTOS excluding those RTOS solutions in the MCU world. This should not be surprising - we have known for 20+ years that software reuse and portability of software are critical and POSIX delivers on this. In addition, it minimizes training, eases access to trained people, ensures robust and reliable systems and much more.

The MCU world is now adopting POSIX solutions quickly for all the same reasons that we use them in larger systems. Up until the announcement of Unison and DSPnano, a native POSIX solution was not available for MCUs, but today a broad set of MCUs is supported.

The second issue is the use of a single loop of control or a "scheduler", use of a kernel (not to be confused with an RTOS), use of a proprietary rtos and use of a POSIX based RTOS. For MCU developers this tradeoff has been complex because many developers failed to understand system complexity. For trivial systems, an RTOS is overkill but for anything but a trivial system, a POSIX micro-kernel architecture is the best you can get. You can use just the kernel if that is all you need, or you can add a complete I/O system - all absolutely free.

The third issue which is often ignored is time to market. Being late or being locked into a proprietary product which limits your ability to change with the market can cost significant market share. The entire profitability of the product line is often at stake. POSIX micro-kernels and commercially supported products minimize time to market and maximize your profits.

Just because it will work eventually and the download is free does not mean that the TCO will be optimal and time to market will be minimized. By thinking ahead and doing your own analysis you can save your company substantial time, money and effort.

Avoid Ostrich Behavior, Understand RTOS POSIX Standards

2010-04-13T10:29:00.009-04:00

Recently I saw that many naive users are using a proprietary real-time kernel. It makes no sense to me and I really wondered why. I've been trying to get more data on this and it seems that it based on ostrich theory.

http://www.embedded.com/224201284?cid=NL_embedded

MCU developers need a real-time kernel and simply follow others into a poor solution because this solution is free to download. Users completely fail to understand the real costs associated with a choice like this, largely because they don't understand the economics and don't think about better alternatives. (Learn more)

First, standards like POSIX mean that you can hire people that know how to use it right away; actually, most well educated engineers on you staff will already know this and have used it. In terms of both cost and risk, POSIX offers a significant reduction. Every major OS now uses POSIX as an API. All the RTOS solutions that run with an MMU also use this as an API simply because it reduces cost and risk. POSIX is the mainstream of APIs for RTOS.

For RTOS solutions without an MMU, there is a variety of choices for POSIX based solutions. Generally the RTOS vendors push their proprietary solutions to lock people in; however, they are available in POSIX flavors, albeit with a performance hit.

There is no reason you can't use POSIX.

Second, if you move to a proprietary solution you loose the ability to reuse software easily. With a non POSIX RTOS you must do extensive work to make it operational on your system. Why would you intensionally create extra cost and risk for current and future development on your project? It makes no sense.

Third, all MCUs now come with source code to support peripherals. In the Unison environment, it is fast and easy to port any driver source code that is well done to Unison or DSPnano. It is so inexpensive that we offer this service at the cost of a single license; provided the vendor has quality code to port. If you don't want us to do it, you can do it yourself. This means drivers are not a risk item as they have been in the past.

Forth, ease of use is very important to get up and going quickly. In the Unision and DSPnano world, the Quick Start Guide gets you up and going with eight to twelve demos (FREE version) in less than 10 minutes each. Many drivers are out of the box and no development is required. Typically Unison and DSPnano come with complete API documentation and eight to twelve demo programs (commercial version has 33+ demos) with a detailed Quick Start Guide which covers all demos and options.

Fifth, optimization to meet real-time needs is one of the most expensive things that you can do as a developer. For this reason, you want a very fast RTOS (with POSIX standards). Unison and DSPnano are the equal of the fastest MCU RTOS on the market and substantially better than most. Simply by choosing this solution, you have reduced your risk and increased your chances for success substantially.

http://www.embeddedstar.com/weblog/2008/01/31/express-logic-threadx-mcu/

Sixth, DSPnano and Unison are FREE for version 4. All of these benefits are completely FREE without cost or risk. Do some research and get the very best free solution that you can. An ostrich avoiding threats in the environment is not a pretty site.

Try here for DSPnano and Unison.

Proprietary Lock in With Software

2010-02-07T23:18:00.003-05:00

The other day I became aware that a vendor with a proprietary RTOS for MCUs is busy locking in clients with full featured but proprietary offerings. They are doing so with the help of a major semiconductor vendor. The typical asking price is $120 000 US for the license. There is another vendor that does the same thing with a $65 000 license but without the semiconductor vendor.

Can you imagine finding out two years later that you were completely locked in to a set of APIs that everyone else in the industry is abandoning? When they discover that they can't hire trained people and can't easily reuse software that their competitors can, how will they feel. For good reason, the customers will be pissed.

I don't know what the semiconductor vendor is thinking. They will surely loose customers as they shoulder the blame months later.

The customers of the 65K product can only blame themselves.

Who works on SuperBowl Sunday?

2010-02-07T22:59:00.003-05:00

I was surprised today. I was expecting to be one of the very rare few online responding to emails and was shocked to find colleagues working too. You know who really gets things done when their work week starts on Sunday afternoon or evening.

I could name all the people that I knew that weren't working but I'd much rather give credit to those that were.

Reed Hinkel - TI
Kevin King - Renesas
Ellen Miller - Ellen Miller and John Lindsay, Chartered Accountants
Polly Yuehe - LED Lighting Manufacturing
Terry Higgins - Aviaeology

Great job one and all!

SH2A - A Killer MCU

2009-09-08T16:30:00.003-04:00

Recently we had requests for SH2A from Renesas. It has a single chip version with both Flash and SRAM and a 200MHz clock delivering 480 Dhrystone MIPS per MHz.

There is SH versions with an MMU and external memory. They run some POSIX or Linux Operating system; however, versions can't run the single chip version without external memory.

On the other hand, Unison is tiny and offers all the same standards. Along with this small size it has great performance for a SoC MCU without external parts. The hardware interrupt mechanism has bank register switching with multiple banks for lighting fast interrupt processing. It is very impressive.

In addition SH2A has great hardware floating point on board for some versions and hardware fixed point on all versions. It should be a great signal processing and communications engine.

For any high end application short of video compression, this looks like a great choice. If you haven't looked at SH2A yet, and you need a high performance MCU, it is difficult to go wrong here.

Wireless Everywhere - Even Power

2009-09-08T09:46:00.004-04:00

It is a very exciting time. Twenty years ago I was discussing wireless with a colleague (Spruce Riordon, VP At Carleton University) and we concluded that everything needs to be wireless - even power.

Now, looking back, we are there. There is wireless communications on virtually all devices if you want it and today there is wireless power pads and even wireless room power.

Today, Unision and DSPnano are being refined with various wireless communication options including bluetooth and wifi. Low cost wireless for data channel communication is expected too.

Along with this wireless communication comes power on self test (POST), diagnostics, and flash downloading and updates. Today, virtually all products are expected to maintain themselves in the field with some operator intervention. Just like wireline systems do today, wireless systems will have to offer this in the future; however this update represents more of a challenge in wireless (extra size, security issues, ...).

Unison is ideally suited for applications like driving power pads; however, I wonder how safe they really are. A pad with localized magnetic induction for power is not a problem as long as the field is weak; after all we live in a constant magnetic field created by the earth. I do wonder about the effects of these magnetic fields at the room level.

Why do crops grow poorly near power lines? This is a well known phenomena. The fields must be partially responsible (both magnetic and electric). Have we really thought this out? Show me five independent studies that demonstrate that it is 100% safe and then I'll consider wireless power for my home. Its time we added responsibility for people's health to the list of design requirements for all of these devices that substantially alter our environment.

LED lighting control is a very hot area!

2009-07-20T09:09:00.003-04:00

Lighting control is a very hot area and in particular in office environments. It has the capability to reduce lighting costs by 70% or more simply by doing intelligent things like managing external light sources (light harvesting), managing local lighting (individual control in office environments), and providing fast and easy installation.

How does all this work? Well first, LEDs are longer lasting and more efficient. This means that users immediately benefit from energy savings. Second, by putting in wireless networks, local control of lighting can be a simple system feature. It can support control from desktop or notebook computers, cell phones and universal remote controls. It can also support wall controls and sensors where ever the user chooses to place these controls.

The big benefit from the wireless control aspect in retrofit office environments means that the installation cost is much lower. Contractors can simply install new fixtures and the wireless connections provide control while the existing power is supplied as before. A building control system might want to control floor level switching of power while the local control can be done by computers, cell phones, wireless wall panels and remote controls. This reduces the installation cost by 50%.

RoweBots operating system solutions have all the necessary pieces to support this approach, allowing users to quickly and easily develop wireless LED lighting systems using minimal MCU or microcontroller hardware. It includes complete networking, low cost networking options, fat file system and much more.

Microcontrollers Everywhere

2009-06-29T08:20:00.002-04:00

We have been making good progress porting our Ultra Tiny Embedded Linux compatible solutions to new MCUs. During the past months we released:

R8C
M16C
R32C
Arm Cortex M3 for TI Stellaris

It has been very rewarding to see all these components come to market.

In addition we've added a number of new components which have not been released yet. These components are geared towards adding low cost networks and networking to building automation, shipboard automation, and home automation applications. They are intended to support features like fat file system integration to allow developers to work in pc environments and have supporting tools to move files back and forth and set up high quality user interfaces.

Other steps are being taken to support automotive and automotive networks more thoroughly.

In all it has been a good few months for component based designers: there is many new options here. Our ultra tiny embedded Linux is more complete and moving to many more platforms. New add on components are cutting time and effort for users.

TI AES Integration of Luminary Microsystems

2009-05-25T11:45:00.003-04:00

We've been working with Luminary for some time and I thought that I'd comment briefly on the acquisition by TI and the integration into the AES division.

Jean Anne Booth did a fabulous job getting Luminary to the point where others could see the real value of the approach that she promoted. First, many kudos to Jean Anne and her team for a successful startup!

Second, its interesting to note that integrating the tools approach and other software offerings are going to bring new approaches to TI. For a start, Eclipse is the main development environment for Luminary products with CS and Code Red for many users. Does this mean that the 430 and 280 families will get new OS and tools offerings based on Eclipse? We'll have to wait and see but I suspect so.

Third, it illustrates the fact that TI upper management failed to realize the potential of microcontrollers replacing boards and their potential in tens of thousands of applications in spite of the fact that they were in markets all around this. They have dominate cell phone offerings, significant motor control offerings and the 430 is a significant player in the DSC markets, but they didn't do a family for the more distinct consumer/home goods market leading to this purchase.

There is still unique niches developing each and every day. I must say that I think this is a great move for TI because it puts them in a broader niche further from DSP/DSC their traditional base and fits very well with other lines. This should be great for customers and prospects and TI.

RTOS Software Reuse - Simply A Myth For Microcontrollers

2009-04-28T18:46:00.004-04:00

It amazes me that many users don't realize the power of reusing software that someone else has spent hours, days, months or even years optimizing and testing. By using a simple set of criteria, developers of the next generation of embedded systems can eliminate 80% or more of the work.

Today, for microcontrollers, users often code everything from scratch. They are going with what they understand; however the world of microcontrollers has changed quickly. Memory is more plentiful and using an embedded operating system saves huge amounts of effort. Yet many do not get it - these are smart people but they are used to banging bits and crafting a few lines of software rather than larger complex systems.

Their problems are created in part by the noise in the marketplace. There are many "real time operating systems" but many offerings are not even operating systems. There is a lot of I/O, extra libraries, testing, documentation and integration that goes into a complete operating system. It takes scores of test suites and thousands of hours of work to make sure that the system is reliable and easy to use while still conforming with industry standards. And yet users choose to do this themselves at great risk and expense rather than reuse available solutions.

Some situations are humerous. I was recently in a forum where kernel vendors were debating one narrow aspect of performance like this was a major consideration in the system design. They were ignoring all other aspects. Surely any system must be evaluated on the basis of all the various features and processing capabilities that it offers. Some systems will be better for some things and some for others. Experienced embedded designers understand this.

The thing that amazes me the most is that in the microcontroller world, narrow performance benefits are touted as a major advancement at the same time these vendors are discarding tens of thousands of programs and millions of lines of code that could be effortlessly reused. For this reason, standards like POSIX and Linux along with software reuse are paramount. We offer this
but don't take our word for it - check out the largest vendor too and see what they offer now, albeit on larger processors!

The criteria to eliminate most time and risk for microcontroller development are really very simple: portable C code, an operating system standard (the broader the better) and as much off the shelf software as possible including a complete RTOS. It takes no more than that to be a hero in your organization.

Vista and Quality

2009-01-26T17:05:00.002-05:00

Well, it happened today. A blue screen of death appeared momentarily for the first time in over a year of use. I can remember the days when we counted these events per day and Microsoft had a reputation for very unreliable software.

In the past few months I've grown to like Vista a great deal. It offers good features and is very reliable. In this instance it recovered itself in about 5 minutes. I don't expect it will happen again. I did have one other problem in the last year but a system restore took care of this problem related to a virus. The world has changed completely. Windows is now as reliable as Solaris it would seem.

Now, when Linux gets there, we'll be in great shape.

ST Software and Cortex M3

2008-12-01T20:43:00.002-05:00

I've been looking around at other cortex m3 platforms and I was really pleased by the ST offerings. They have great DSP libraries (optimized and C) as well as a full suite of motor control. The motor control suite comes with an application generator which sets all the parameters including closed loop tuning parameters using a variety of configurations.

It seems that the era of self tuning of motors is upon us. When traditional methods were used to tune processors using step responses, load tuning was a big part of the work. I suspect it still is if you want to get 100% out of the motor and driver for a specific application. These tools should make it easier though, getting you into the center of the envelope with zero effort.

But still, why no loop tuning option in the tools? Likely it introduces too many dependencies like host target communication, real time data collection and recovery and many more.

Great work ST

International Product Life Cycle for Software

2008-11-26T10:56:00.003-05:00

I was surprised to learn how many executives do not understand international product life cycle as it applies to software products. This short description is intended to describe international product life cycle in an abreviated fashion and then discuss how software's portability make it a unique case which promotes more rapid off shoring.

First, international product life cycle states that innovation starts in a home developed country and becomes successful as a product. Then it competes in other developed countries with products from within these countries. As the technology matures, it moves into the developing world by means of export. Then the developing world starts manufacturing for home use and eventually manufactures and sells back into the developed countries.

There are many examples of this. It transpires because of the dynamics of the theory of comparitive advantage as it occurs over time.

For software, the twists are the following:

a) It is much easier to move production off shore to reduce costs associated with add ons. For this reason this happens relatively early.

b) Because the knowledge associated with developing add on products and services allows the developing country to develop the same or better skllls as the parent, often the entire product or idea can be copied to provide a much lower cost version off shore sooner rather than later. If the product enhancement is done as a branch of the parent company, IP is protected. If the enhancement is done to an outsourcing company, it is very likely that the company is creating a vehicle to copy it's product.

Comments?

Disruption of Microprocessors by Microcontrollers and Its Long Term Effects

2008-11-26T10:37:00.003-05:00

I was fascinated to discover that the mpu vendors were being disrupted by mcu vendors by virtue of the fact that the increase in functionality of the parts and free memory is leading to ever expanding features, features that users don't necessarily need for many applications.

As Christianson predicts with the Innovators Dilema model, microcontrollers came in on the low end and started competing on a new parameter - system on a chip solutions. Ten years ago they could run a few assembler instructions. Today they can put enough memory on the processors to compete with mpu and board level solutions of 10 years ago. They are currently capturing this business.

Microcontrollers are gaining ground because mcu technology is being commoditized into consumer goods which are sold in very high volumes. This high volume is pushing prices down and microcontrollers are a natural solution. BOM costs can drop by substantial amounts resulting in a big improvement in profitability for the OEMs.

Too cool.... theory meets practice....

Comments?

CeBIT 08

2008-03-12T12:53:00.002-04:00

The CeBIT show was truly a spectacular event. I would compare it to the Comdex show of years ago. It was largely IT focussed, with many things being split off into separate shows now. This included:

- embedded systems totally moved to Embedded World
- consumer electronics largely moved to a Berlin show
- competing Auto electronics shows
- competing industrial shows

The coolest things for me?

- 3D Plasma TV - not shabby, good view angle
- Lane change and wander warning electronics for cars
- A rack of Sun servers (complete rack, 19" style) running on 1095-1097W ... thank multicore.
- Low cost bluetooth chips from Korea ($4.80 USD in 10k without negotiation)
- 50 Chineese vendors charged for IP violations with a 5 year penalty in jail waiting for them!!!

I think trade shows are still fashionable in Europe - its too bad we don't have travel budgets for this in North America any longer. It was educational.

Embedded World 08

2008-03-12T12:39:00.003-04:00

Embedded World 08 was an exciting event - many thousands of attendees, all major exhibitors and much more. There was exciting new technology too - PIC32 was being pushed along with new MSP430 solutions and new offerings from nearly all the microcontroller vendors including: Renesas, Fujitsu, Luminary, Toshiba, NEC, and many more. Clearly microcontrollers, DSCs and DSPs are still hot.

One of the most interesting things I saw was the Luminary products. They are going to challenge the traditional microcontroller vendors with Arm M3 Cortex designs (32 bit design) at 8 bit prices. It should be interesting to watch.

The most interesting part for us was the fact that nobody knows that there is a tiny tiny embedded Linux compatible RTOS called Unison or DSPnano that they could use in the microcontroller space where other solutions simply don't exist. The microcontroller vendors understand the need but the customers don't know there is a solution. That is our challenge.

And Elke Antonia Bergmann, thank you for the great job at the show! You're the best! Now how can I hire more people with this attitude?

Technology Changes For Robots

2008-02-16T13:00:00.003-05:00

Robots need to be low cost but today's technologies are not getting us there fast enough. The main reason for this is that the architectural approach is incorrect. Robots need completely distributed systems to reduce cost and allow computational engines to become more specialized.

Typical robots today (of the experimental and service varieties) use a central cpu, often an x86 variant, and run Linux of some flavor. They may have some type of RTOS to try and provide better performance to replace Linux but the basic message is that they require a big board and have expensive processors.

A far superior approach is to separate the system into four subsystems. One subsystem is dedicated to motion control, a second is dedicated to power management, third is dedicated to sensors and the forth is the brain of the system. These four subsystems are interconnected and all must be there for complete functioning of the robot.

By separating the systems out, there is a big advantage in that the motion control and any lower bandwidth local sensors near them can be run by a single microcontroller. This single microcontroller can be extremely low cost and a distributed bus or network can be used to communicate among the controllers. This provides high precision motion control in a distributed architecture at very low cost.

In the case of low bandwidth sensors, they are layered on top of the motion network cutting costs. For high bandwidth sensors, a direct high bandwidth connection to the core logic processor is required. For example, Ladar and vision systems require high bandwidth connections to the core logic processor, presumably with integrated hardware based accelerators to speed this processing.

A power management system is required to control power sequencing, special mechanical locks, recharging, and various other power related features. This network can coordinate actions based on the oversite of the core logic processor. This off loads all the power management tasks from the core logic processor, avoiding real-time power management interrupts and improving power management response. Again this is a low cost $2-3 dollar processor for each supply including networking costs.

In terms of the core logic processor, this is a real challenge. The current approaches simply don't offer the kind of performance which is really required. In addition the cost for these processors is generally high. We all need to create new technologies to overcome this unknown.

Sometimes People Surprise Me

2008-02-16T12:46:00.002-05:00

When people are angry reasonable people do unreasonable things. For the past month I have been dealing with the fallout of a malicious attack on our internal systems web site and support server.

To our customers I offer my sincere apology for the demise of our web site for the past week. We have done our best to restore it quickly but all takes time. It will return very soon.

Initially I thought that these attacks were simply prompted by anger, but upon further investigation I discovered that fraud was at the heart of their plans. All our customers can rest assured that the perpetrators of these crimes will be dealt with by the courts and will be held responsible for their crimes.

To all of you out there, I recommend the following:

separate system administration from operational personnel
triple check all backups
never subcontract system administration work short term
automate changing all passwords so it can be done across your systems instantly if possible

RoweBits Year In Review

2007-12-31T18:15:00.000-05:00

The best of the year was:

- violin playing robots from Toyota started just 3 years ago
- Fanuc fast arms - prize winner in Japan
- utility experiment proving power negotiation pays - driving smart everything electrical in the future
- more and better robots everywhere

The best from RoweBots was:

- Launch of DSPnano v2 - DSP RTOS for tiny tiny Linux compatible DSP applications
- Completion of Unison v4 - RTOS for tiny tiny Linux compatible applications
- Tighter robotics focus with lower cost software solutions packaged for applications - coming soon!

Autonomous Robots Starting To Become Real

2007-08-31T09:24:00.000-04:00

A recent post related to portable supercomputers shows just how easy and inexpensive it is becoming to produce high performance computers capable of doing advanced analysis on their environment using smart sensors.

If you can build a machine so inexpensively ($2470) which can have twice the power of deep blue and be a checkable airline bag, we are definitely close to a breakthrough.

According to James Albus (of NIST) another two orders of magnitude should do it and service robots should be possible.

Coming to your home sometime soon....

And now the floodgates start to open... Tilera Ships

2007-08-20T19:10:00.000-04:00

Hey;

Finally the new Sun chip has some competition. There is a good link dealing with this product here.

I am a bit surprised that the chip doesn't just have memory, not L2 if it is intended for embedded applications. I think the real story is that it is intended to be more general purpose but the embedded market for H.264 and other applications seemed a bit easier to penetrate near term.

In the future expect to see chips like this optimized for embedded applications.

Microchip dsPIC and DSPnano Offer Ultimate Integration

2007-08-14T20:37:00.000-04:00

The Masters was great. I must say that meeting the CEO Steve was a real highlight. He is so practical and down to earth. I'm sure that he has had much to do with the great performance that they have seen over many years.

The DSPnano for dsPIC product is highly complementary to the offerings that they have created at Microchip. Their focus has been tiny I/O modules and debug tools. Our focus is open source DSP RTOS tools which offer POSIX compliance, DSP libraries and next generation development environments. As it turns out, we offer the glue that it takes to exploit many smaller components for dsPIC and build a total solution.

For example, voice processing, SPI, Lin, USB, TCP, I2C and much more can be quickly and easily integrated into the RTOS with the POSIX interface and all calls can be standardized. The development can use the latest Eclipse technology and debugging and display of target data levers off MPLAB, ICD2 and REAL ICE technologies.

The most amazing thing is that you can now cut your design time substantially. This combination along with 3-5 week lead times for parts accelerates your growth and lets you improve faster than your competition. Just ask Steve or read his book - this is a winning formula.

Microchip dsPIC Expectations High

2007-08-09T09:36:00.000-04:00

At the Master's 2007 its clear that Microchip is continuing to execute on its 16 bit strategy for micro-controllers and digital signal controllers. The number of applications is staggering for me and the chip volumes that are being shipped as well as the revenue generation from this company is staggering.

It was only just over fourteen years ago that they were on the brink of insolvency. Since this time they have transformed their business to dominate the low end micro-controller business worldwide. They are now number one in both volume and dollars.

Four years ago Microchip added the 16 bit line of products and they are doing as well or better from their introduction as the original PIC. The scenario is exciting because they are delivering superior price performance at the lower end and dominating first on volume and then on overall revenue. Congratulations to all those hard working people at Microchip!

The fallout from this for multicore is a bit obscure, but I don't see why they aren't considering using multiple dsPICs in a single core for very low power higher performance applications. They are great engineers so look for this in a couple of years.

Emotional Memory For Intelligent Machines

2007-08-01T09:30:00.000-04:00

As we try and build more and more intelligent machines it seems that their is many lessons to be learned from the human brain about how to avoid dangerous situations and how to use learning as a basis of computer memory models.

Today, our idea of an intelligent machine that can understand situations from the scenes that it sees is to do something like the following:
a) Create a taxonomy of all the objects expected in an environment
b) Create relationships between the objects and have some idea of purpose and function associated with objects.
c) Look at a scene with sensors of various kinds and correlate 2D representations of 3D models to develop a list of related scene objects from the taxonomy.
d) From the structure, understand the scene.
e) Modify the scene, update the structure and update the understanding.
f) All object matching, relationship establishment, understanding and so on is done from taxonomy information saved in a relational database and recovered by search mechanisms related to relational tuples in the database.

If we have Stanley (Stanford's robot Toureg) driving down a desert road without too much around where it has weighpoints along the way and maps for terrain, this kind of sort of works. If you miss a weighpoint (CMU's red team did this), big trouble may follow because the system isn't really intelligent. Stanley didn't have the same weakness because it was smarter but still had many limitations.

Now consider how the human brain solves the same problem. It is a very different scenario.
a) The brain learns from birth, building up its knowledge of the surroundings.
b) Strong emotional response related to danger, pain, happiness etc keeps training the brain to remember certain scenes and experiences.
c) Discussion of events reinforces these event memories.
d) High level extraction of abstract concepts are related to these strong memories which are tied to the detailed memories, allowing further refinement and evolution of the concepts build upon these memories.
e) The strength of the emotion at the time creates a window by which to filter memory response time.

Would it not be relatively easy to add emotional memory to the computer system to improve response? Then the system could use strong emotional memories to respond quickly to critical events and take more time when events are not so critical.

The cost of this extra processing would be the cost of creating an emotional measure for each scene as it changes over time. This could be done in many ways but must be related to the variable score over a broad set of emotional words for a given language. But why stop at just emotional words? Shouldn't we take a scene and create a scene understanding dialog rating the scene on all means of words related to the scene and use this as a key for identifying all future scenes?

Imagine leaning and feeling happy about what you're learning. The subject matter abstract concepts, emotional feelings and the fact that your basic activity is learning are all keys to finding similar scenes. Emotional response could be a quick first pass but all words with a meansure of strength could be good measures of the correlation between this scene and others with similar characteristics.

Has anyone seen any research in this area?

gdb and multicore are mutually exclusive

2007-07-23T11:07:00.000-04:00

I've spent the last few days looking at debugging technology for multicore chips with a view towards real-time embedded with volume applications. In this mix I'm including FPGA solutions which will soon offer the capability to have many cores on one chip, particularly given the Altera C to H compiler and NIOS as well as the offerings of their main competitor Xlinx.

My initial look for debugging solutions is clearly to have a debugger which supports many processors and has a simple user interface. After the last Multicore Expo it was clear that heterogeneous processors were necessary and that it was highly likely that collections of networked and shared memory processors would exist as part of a complex multicore processor.

First, I think the case where many cores are on a chip requires some hardware assist on the chip to support debugging. Multicore register access and a stop all cores capability will be added to most chips but this is largely unsuitable for many applications. Emulator people will be happy but real applications will have to run partially with some ability to control the rest of the application to support debugging. Emulator type solutions could do this but with a severe performance penalty that gets worse as the number of cores grow (using traditional approaches).

To do this type of debugging, a kernel must be running on the chip and there has to be some common debugger interface that talks to the system under test. The connection could be multiple or a single multiplexed connection - it makes little difference in most applications. The debugger on the other hand, must understand the processor type that it is debugging and talk to the common graphical user interface to provide debugging support across all the cores.

I was looking at gdb to solve some of these problems and it seems that it might do a half a job in the case where all the cores run some huge kernel, but it is completely unsuitable in the case where many independent cores running a small kernel are communicating to solve a problem.

For a start, it is highly complex for absolutely no reason. The remedy debugger meets almost all criteria to do this with 10% of the bulk of gdb and far less complexity. What went wrong here? How did the debugger get so large and complex with no apparent value added? It is not that remedy is much less functional, as a matter of fact, it offers support for 8 processor types and the user can select any one of them for any core on the fly. Doing a port for a new processor is much simpler too - the disassembler is separate, the register understanding and memory/stack unravelling is done with a few simple routines which are easily understood and the symbol table info is relatively standard.

It would be great if someone could provide some insight to me and others on this issue. I don't relish porting remedy to a raft of new processors that gdb already supports but it seems like it will be less work and better functionality in the long run.

I should add here that this is for this specific case that gdb seems less than attractive. For the case of debugging a single core, it does the job. The downside is that it likely takes months to do a new processor type instead of a few weeks because of all the extra complexity.

A Stunning Parallel Multicore Approach

2007-06-29T03:33:00.000-04:00

Having been at Multicore Expo a few months ago, I was stunned by what I read a few minutes ago. It was the "elephant on the table" that nobody talked about. Companies did not want to discuss it because of their vested interests and I can only imagine that the researchers were incredibly jealous or as ignorant as I.

Having worked in the area of multiprocessing for many years, the promise of automatic parallel behavior generated by a compiler was thought of as an ideal. We never got their in the 90s but it seems that we are making real progress today. A team at College Park have done some remarkable work to solve the fundamental parallelism issues that plague most computers with a technique called "explicit multithreading". You can find some details here and here. Wen and Vishkin both deserve a huge amount of credit for creating this solution.

The other approaches that approach this on a higher level from Peak Stream (now owned by Google) and Rapid Mind both assume that there is an automatic parallelizer to allocate chunks of work to processors and that all the parallelization is done for you. The disadvantage of their approaches is that everything must be an array. This approach is quite unnatural for most programmers although it is possible to learn it. Math majors would certainly like this approach.

Another disadvantage is that their efforts (Peak Stream and Rapid Mind) focus on trying to maximize resource utilization for standard Von Neuman machines in an attached processor model while this new approach seems much simpler and lends itself to static allocation because IPC times will be ignored.

The XMT approach doesn't use an attached model but assumes that the processor has inherent parallelism. The difference is that the scheduling seems to be much clearer and communication times become minimal. This approach also seems to suffer from the same limitation that resources go unused if there is nothing that can be done in parallel. In fact, it is this reason that has many semiconductor companies holding back on large multicore architectures.

I will look at the programming models in more detail next but it seems that this machine could benefit from both automation of parallel operations and the ability to explicitly code each parallel thread.

The future signal processors are going to be really fun if technology like this hits the market anytime soon. I wonder what the follow on to Niagara 2 will really look like?

Restarting And Marketing

2007-06-25T17:20:00.000-04:00

I've been restarting a products company and the marketing has changed so much over the past few years! For example, on the good side:

SugarCRM offers great value - open source, why spend 75K?
SEO tools (I hope google's not reading this) - open source
portals for Engineers - why leave your cube to find anything?
and the best help a guy like me could ask for ...
lots few trees cut down
more time with the family

At the same time, there is some downside as well:

the world has been replaced by voicemail
email filters kill many requests
shows are smaller and smaller
margins are thinner
channels are becoming lower cost
prices are falling
products are volume

It is sure a different place - and still lots of fun....

Comments

All Those Pesky DSP Functions

2007-05-29T07:26:00.000-04:00

As DSP becomes mainstream and we incorporate it into all systems, we are left with a dillema: "how can we make this functionality simple enough for all to use effectively?" In short, we can't.

Signal processing is difficult by its nature. It can be done in fixed point, floating point or double precision floating point. It involves many different algorithms. Often at the front end, processing is data independent, while at the back end it is data dependent. Different array sizes are passed between modules, concepts are abstract and require deep mathematical understanding, and time constraints on processing make all this more difficult.

One might say: "Oh, well we'll use a graphical tool and it will solve all our problems" but this is not the case even though it might help in special cases where processing is always regular and data dependent processing is not done. As soon as branching is involved and interrupt processing is required, the need for better tools becomes apparent. In general, if the problem is more limited then this can work, but if it is complex and demanding it tends to be less than optimal.

Or does it? You tell me. How would you recommend people solve these problems?

DSP and FPGA Implementations

2007-05-25T16:50:00.000-04:00

Hi All;

How many of you have looked at the rapidly dropping cost of fpgas and wondered how this is going to change the world of signal processing? I'd like to know too. I have some ideas summarized as follows:

FPGAs offer competitive advantages in hardware implementations of signal processing algorithms with the cost and difficulty of implementation being a barrier
DSPs offer competitive advantages where the algorithms are experimental and subject to rapid change or the ultimate idea is to push the processor to the limit by adding as many features as possible for the same hardware price.
DSPs offer integrated A/D and D/A support - something not included in FPGAs to date.
Serial D/A and A/D components can offer greater flexibility to designers of FPGAs.
Drivers for PWM are generally integrated into DSP's including dead band timing - lots of work might go into recreation of the wheel in the FPGA world.
FPGA prices relative to DSP prices are falling - this means that the cross over point from DSP to FPGA for development is changing - but how?

FPGA implementations are now cheaper but development is more expensive. And it is still not entirely clear what algorithms are possible with an FPGA compared to a DSP. For example, neural nets are computed on DSPs without difficulty even if it is time consuming. In comparison, this same algorithm would be extremly difficult to run in an FPGA if it was even possible.

How do we decide how to partition these problems? What thoughts to others have on this?

Pseudo Open Source

2007-01-24T12:44:00.000-05:00

In years past we had proprietary solutions and people protected their IP. Today, many solutions are open source based on some type of "copyleft" license while other models range from Freemium to partially protected software.

I think that GPL is the ultimate bait and switch strategy. Support costs money and has to come from somewhere - the community support models are not suitable for production systems unless the software is extremely stable or the systems aren't critical. People end up purchasing support which is the real cost of the software but are unable to protect any modifications that are done as an add on.

Why does the GPL insist on having all associated code in GPL? What are they afraid of in proprietary technology?

The freemium model is much better supported by other license agreements.

Sun's agreement seems like the best of many worlds offering great freemium model support, ecosystem support and protection for those who require it.

Peak Stream - A New New Array Processor

2007-01-23T21:11:00.000-05:00

The Peak team has great marketing. I really liked it and their new launch will be a great success I'm sure.

Myself, I prefer more standard calls that our industry has been working on for some time but it isn't a material difference. I do think that their tools are more limited than those of 20 years ago and their basic architecture is 30 years old or more for the most part. Why shouldn't we call it a new new thing - everyone else rehashes old technology into new all the time?

Myself, I would think that a combined programming model would be much stronger. After all, they have one multiprocessor application - why not make it all multi-threaded too and have the benefits of being able to program and debug on the underlying processors if requried? Why guess when it doesn't work - go and look (debugging rule number 6)? The dynamic allocation strategies and dynamic compiling (the new part) make this a bit tricky, but it should be possible.

I think that this will work well for many applications but we all really need some new thinking in the programming area. For real-time systems it seems much too limited in this form.