Design Con 2015
Breaking News
Slideshow

Slideshow: 10 Embedded Design Trends

4/21/2014 10:30 AM EDT
22 comments
NO RATINGS
8 saves
Page 1 / 11 Next >
More Related Links
View Comments: Newest First | Oldest First | Threaded View
<<   <   Page 2 / 3   >   >>
rick merritt
User Rank
Author
Re: FPGA data a surprise
rick merritt   4/22/2014 9:03:31 PM
NO RATINGS
@betajet: I too was surprised to see the results given how hard the FPGA vendors have been pushig their devices down in size and cost.

Your comment on the FPGA tools is interesting...can you document or is it a subjective impression?

 

betajet
User Rank
CEO
Re: In-house versus out-house operating systems
betajet   4/22/2014 7:11:13 PM
NO RATINGS
RoweBots1 wrote: RTOS vendors spend millions on product development, even smaller vendors.  How can an in-house effort possibily do better unless they spend similar amounts?

A RTOS vendor has to write an OS for a general customer base.  An in-house OS only has to support the features needed for the product.  An in-house OS may be as simple as a single main thread plus interrupt service routines, with no preëmptive multi-tasking and little or no memory management.

RoweBots1 also wrote:Think about the cost of documentation and testing as well as the lost time if you throw away the documentation because your project is taking too long.

Funny you should mention documentation.  My main experience with a vendor RTOS was for a datacom product that originally had its own "OS": single thread plus ISRs.  All the code was developed in house.  We needed to add a vendor stack for an optional feature, and that stack required an RTOS.  However, the RTOS had a per-unit royalty, so we only wanted to ship the RTOS if it used the optional comm feature.  The solution was easy: if we wanted the RTOS present we simply ran our main thread as one of the OS tasks.

Our product was originally based on a Motorola (now Freescale) 68360 QUICC.  The RTOS had excellent documentation for 68K and it was easy to link in the main thread and ISRs because the ASM-level ISR conventions were clearly documented.

A couple of years later we switched to PowerQUICC.  Well, for PowerPC the documentation was terrible -- no documentation of the ASM-level ISR conventions.  The vendor wanted you to use one of their "board support packages" and we weren't on the list.  Plus, the vendor wanted you to buy their C compiler.

So I ended up creating my own "documentation".  Specifically, I had to disassemble the task switch machine code to see how they were saving registers and all.  Once I had this information, it was straightforward to get it working.  But I learned to get out the salt  shaker when an RTOS vendor tells me that the RTOS will save time to market.

Just my experience, YMMV.

RoweBots1
User Rank
Freelancer
Re: In-house versus out-house operating systems
RoweBots1   4/22/2014 4:52:39 PM
NO RATINGS
@in house vs out house OS

I think that it is easy to change something you know and understand for sure.  For sourced operating systems I think that high quality technical support fully addresses (or should fully address) any feature additions and changes.  We certainly make sure this happens and happens in a timely fashion.  It is easy for an RTOS vendor to make these changes and this leads directly to a solution to change the OS for a customer.

The real cost of in house is the delay and expense of lost time to market.  The market share that is lost costs far more than the purchase price  of the RTOS so you immediately end up loosing money doing your own RTOS before you have started development.

RTOS vendors spend millions on product development, even smaller vendors.  How can an in house effort possibily do better unless they spend similar amounts?  Yes with in house you can change it easily but you don't have to if you have purchased a quality product with support.

Think about the cost of documentation and testing as well as the lost time if you throw away the documentation because your project is taking too long.  You need to think about how much better your product will be if you focus on your value added application and use the rich feature set that you can purchase.

The economics clearly are not there for build your own OS except for very specialized cases.

 

betajet
User Rank
CEO
In-house versus out-house operating systems
betajet   4/22/2014 3:35:49 PM
NO RATINGS
I see an interesting correlation in the trends.  It seems to me that the increase in the use of out-house operating systems correlates with the increase in project lateness.  Personally, I prefer in-house because if there's a problem or a necessary change, you're familiar with the code so you can get in there and make the change with minimal impact elsewhere in the code.  With out-house, it might be very difficult even to find where to make the change, and the side-effects of the change could be hard to predict.  It seems to me that estimating how much effort is involved would be quite difficult, making it hard to maintain the schedule.

JMO/YMMV

betajet
User Rank
CEO
Re: FPGA data a surprise
betajet   4/22/2014 3:24:45 PM
NO RATINGS
I was shocked when I saw this data at the ESC session.   The reasons behind this were also interesting, so I hope we'll have a follow-up 'blog on the FPGA results alone.

I do FPGA design professionally, and what I find is that a lot of design organizations are scared of FPGAs and don't have people who know how to design with them.  In a way that's good for a free-lancer like moi, but cuts down the overall volume of work.  One effect I think is happening is that IDEs and development boards with good communities are making it easier for people to use embedded CPUs, but the same is not happening with FPGAs.  My own experience is that each new release of FPGA tools is harder to use and runs slower.  Perhaps that's only because it does more, but if my impression is true it could be one of the reasons you're not seeing as many FPGAs getting designed in.

It could also be that what people are designing these days has shifted away from FPGAs.  For example, all these Internet of Digital Things products just need a standard SoC with standard interfaces.  It's not like a data comm box that has to speak strange protocols or have extremely high data channel density, which is an excellent fit for an FPGA.

So tell me, did the FPGA vendors find out about this result ahead of time and decide not to exhibit at the show? :-)

kfield
User Rank
Blogger
FPGA data a surprise
kfield   4/22/2014 2:31:34 PM
NO RATINGS
The FPGA data was a surprise to me - given the interest we see at our events and the near price parity in some cases, I would have assumed the opposite.

RoweBots1
User Rank
Freelancer
Re: Trend 11? 12?
RoweBots1   4/22/2014 11:45:11 AM
FreeRTOS is not an RTOS it is only a small kernel thar runs on virtually all mid size and larger MCU devices.  Written in C is is very portable and because it has no I/O and higher level protocols or significant demos,   There is not much else to know.  SafeRTOS was the 12 function call version of this the last time I looked.

I think that the popularity of this reflects the general lack of business training in the community with respect to time to market,  software reuse and software engineering economics.  

FreeRTOS is really a build your own RTOS with a free kernel and months of effort put into I/O models, I/O drivers, testing, integration, and documentation before you start your actual development.  Engineers do like to build their own solutions but this is definitely a money loosing strategy unless you see engineering time as very low cost.  

For a few thousand dollars, you can purchase quality offerings which provide standard APIs, connectivity of your choice, documentation, testing and integration of modules and support for the entire offering.  What is the benefit of spending tens of thousands more and months of development time to ernable FreeRTOS or worse still SafeRTOS development with a poorer quality alternative?

If you know anything about FreeRTOS, this is what you should know and understand.  Free is definitely very very expensive if you really understand the costs involved.

I should mention that I work for a company that sells complete RTOS solutions.  The facts are the same for a FreeRTOS vs an actual RTOS comparison regardless of which RTOS you choose.

 

rick merritt
User Rank
Author
Re: Trend 11? 12?
rick merritt   4/22/2014 6:55:07 AM
NO RATINGS
Good comments from boblespam andf LarryM99:

Embedded vision is really big now, especially among component vendors. And more analysis on use of Linux variants would be interesting, too.

Keep this good input coming, folks!

boblespam
User Rank
CEO
Re: Trend 11? 12?
boblespam   4/22/2014 2:41:32 AM
NO RATINGS
Something you probably missed, along with virtualization is code generation (Matlab Simulink and others).

Embedded vision is something going up too.

I didn't know FreeRTOS was so successfull, I really need to look at this OS more seriously.

LarryM99
User Rank
CEO
Re: Trend 11? 12?
LarryM99   4/21/2014 7:08:42 PM
NO RATINGS
@Rick, I was struck by the number of Linux variants in the group. Add them up (arguably, even including Android) and it becomes a very large percentage. I would also be curious as to how many are using buildroot, Yocto, or the other Linux kernel personalization systems to create tailored distributions. That used to be the realm of the specialists, but now they are very mature and approachable.

<<   <   Page 2 / 3   >   >>
Radio
NEXT UPCOMING BROADCAST
EE Times Senior Technical Editor Martin Rowe will interview EMC engineer Kenneth Wyatt.
Top Comments of the Week
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Times on Twitter
EE Times Twitter Feed
Flash Poll