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.
Wednesday, April 14, 2010
Tuesday, April 13, 2010
Avoid Ostrich Behavior, Understand RTOS POSIX Standards
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.
http://www.embedded.com/
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/
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.
Sunday, February 7, 2010
Proprietary Lock in With Software
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.
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?
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.
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
Tuesday, September 8, 2009
SH2A - A Killer MCU
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.
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
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.
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.
Monday, July 20, 2009
LED lighting control is a very hot area!
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.
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.
Subscribe to:
Posts (Atom)
