Embedded Systems Engineering Standards Column vol 13.7 October 2006 Ingredients and chips. By Chris Hills

 

These are my own personal views and not those of my company Phaedrus Systems. The full version of this column resides at www.phaedsys.org, under the Technical Papers button.

Well, last months column about Gcc compilers certainly got a reaction… Next month I will review some of the comments, rants and arguments that came back. Partly to give my self time to read them and make a sensible reaction and partly because I will be at the Embedded Systems Show on the Phaedrus Systems stand (743) when this column is published and I want to survive the show! As usual I will have coffee on my stand but bring your own doughnuts.

This year the Embedded Systems Show is larger than last year, (http://www.edaexhibitions.com/ess/ ) which was larger than the year before. So things are looking up. I am also informed from various recruitment agencies that things got busy again from May/June and I have also noticed an increase in the number of new projects too. I am also getting asked more often for Engineers, contractors or design/production resources. So things may not be as bleak as people were thinking over the last 12 months. As a side point this should mean more freebies on the stands at the show. Yes more pens, tins of mints, mouse mats, mugs, clocks, USB sticks and those little fury things with an advertising tail you can stick on “something”. I wonder how much ends up with the kids and never even makes it in to the office the following day. At the Nuremberg show this year one of the marketing people on a well known stands said that for next year they were going to do a freebie aimed specifically at wives and children.

Back to the up-turn in projects in the UK: There does seem to be a sea change in the way projects are done. Some 10 years ago at an ACCU ( www.accu.org ) AGM a speaker, Alan Lenton I think, said that software was one of the few industries where everything was built from scratch and this was silly. Mechanical Engineers use standard nuts and bolts and carpenters use standard screws. They don’t custom make fastenings every time. Also they tend to start with standard sizes of wood e.g. 4 by 2 and 2 by 2 etc and standard metal bars, rods and girders. Ie they use components. This can go to extremes… I stayed in a “hotel” a few years back for ESS in Excel (Docklands, London) and the whole toilet, shower and basin was formed from one single piece of glass fiber! This is even more surprising when you realize that the module formed two rooms, one for the shower and one for the toilet. Mind you it was more of a backpackers hostel than a hotel. So much for the glamorous life at trade shows in London!

With software things appeared to improve a little in some areas but probably no more than we had previously when we made our own library modules in C and standard routines in assembly language. However, in the last couple of years things have taken a big step forwards.

Partly it has been time pressures and partly the drift to 32 bit processors (see following topic) the time pressures along with the requirement to be connected…. “Everything” is now networked. It may be to the next MCU along or the wider world by USB, Ethernet and more commonly wireless links.

Working on 8 or 16 bit systems is not too difficult and in the past the 32bit systems with networks and lcd screens tended to be the preserve of larger companies with big teams of specialists. Now small companies and even one-man development teams are taking on complex 32 bit designs with USB, lcd, wifi etc. Therefore they need something to get them started on a steep learning curve.

The other problem is that many new graduates, I am talking generally and I am sure I will get email from the exceptions, these days tend to have a background of C++ and Java on hosted systems. That is development on an OS not in C on a bare MCU. Therefore there is more of expectation of using an OS, and the 32bit platforms can run them.

The result has been pressure on the Silicon vendors to provide more, and more complex, examples on development kits. Specifically with examples and code for all the peripherals. Compiler companies are also finding that customers are expecting lots of ready-made projects for all the popular dev kits that are available. Examples for that can run from either RAM or FLASH with the flick of a switch, boot-loaders and Long gone are the days when a compiler was half-a-dozen command line programs! No IDE or often no editor, let alone ranks of examples.

Apart from the trend to “require” working examples for everything to get started there is a tendency to take this a step further and start using ready-made modules.

This comes in two flavours. One is a tendency to get the project spec and cobble together source modules found on the Internet. Apparently this is becoming common in some areas. I picked this up at a discussion in an industry seminar. The report was that most of the development time is spent in getting modules to work together and debugging. There was also a tendency to the attitude that problems can be fixed in the next release. This method requires fewer programmers. What needed 10 programmers for three months can now be done with 2 programmers in two months… that is two paid programmers. No one pays for the free stuff they find on the net. I don’t just mean GPL and Open Source, but all the other free source that is floating around. There is a lot of source code around that is just “public domain” as we used to call it. However, the quality of the source varies and most is unsupported by the authors, if you can find them. There is also the possibility, though fairly remote of viruses or malicious code hidden in the source, though, in reality the danger is unintentional bugs and errors.

This can be the problem of just grabbing source off the net and fixing it to work with other software of equally unknown provenance. However for some commercial products at the low-end software bugs seem acceptable and there is the idea that you can fix things in the next release. Another problem mentioned recently, in another place, was that with some consumer items e.g. entry level digital cameras (though not from the leading names it was said) is that there is only one run of the device. i.e. 100K cameras in a run. Bugs don’t get fixed later. The next “revision” is the next product.

At the other end of the market there has been an increase in the use of commercial RTOS and other software components such as TCP/IP, USB stacks and graphics libraries that are properly ported and tested and fully supported on specific targets. In this case there is a commercial decision that good quality code modules can be bought in. In this case you get well documented and fully specified code. In many cases you can get the modules modified. This is like having some contract programmers turn out the modules for you but it is far more cost effective. You are unlikely to get a similarly specified product from doing it in house at a similar cost. In many cases the commercial products are smaller, faster and far slicker than doing it in house because the companies specialize in these specific areas. Much as in the same way we don’t start a project by writing a compiler and IDE.

So it looks like the embedded industry is finally starting to use software components rather than building everything from scratch. I recently came across a tool whose time has now possibly come. It is a stage on from version control and is designed to build software from components. Perhaps we are now at a turning point in the way software is developed. However as any good chef will tell you: it all depends on the quality of your ingredients.

I mentioned the rise in the use of 32 bit processors for the embedded market. Recently I have been to some distributor meetings, usually held under NDA’s so I can’t talk about specific things but they all had one thing in common, apart from spin, free USB sticks with all the presentations on, strange buffet lunches and coffee. Oh and of course the special reasons why they are The Best. That is the survey of the usage of 8, 16 and 32 bit MCU. The data from several sources, all seem to agree in general terms (i.e. numbers and trend).

Some surveys give numbers of parts shipped and some give value of parts shipped. To my mind the value of parts shipped is misleading and a poor guide. Prices of parts vary depending on the quantity you want and the deal you can do. Some 32bit MCU cost less than some 8bit MCU. Number of parts shipped is fixed and gives a better guide.

The overall picture from a year or two back was the 8bit market was about twice the size of the 16bit market and the 32bit half the size of the 16bit market. The 16bit market had been growing as the 8bit has slowed somewhat. Some were predicting that the 16 bit market would overtake the 8 bits at last.

Over the last 2 years the 32bit market has increased dramatically and overtaken the 16bit market, which is now decreasing as fast as the 32bit is growing. By the end of the decade most surveys show the 16bit market all but disappearing. “All but” because some parts like the MSP430 will always have a niche market that no one is going to take away from them.

By 2010 all surveys show the 32bit market overtaking the 8bit market. The 8bit market now seems to have reached a stable point. Some show it increasing slightly others dipping slightly and some staying level. However there is no suggestion that it is going to disappear any time soon so PIC, AVR and 8051 engineers have nothing to worry about for a decade.

Some 7 years ago Philips predicted, at one of their seminars, that “in a decade” the 8 and 32 bit markets would squeeze out the 16bit market. At the time this seemed like a strange message from a company with a major interest in the 16bit market with the XA processors and, at the time, no 32bit MCUs.

Incidentally the 16bit XA, despite being a very good part and being heavily pushed by Philips as the natural upward path from the 8051, never really gained widespread appeal. Though it will be around for a while as it is used in several large-scale applications that required it to be available for some years to come.

One problem that has gained some prominence recently is Language Vulnerabilities. ISO has formed a Working Group. The US and the UK are of course divided by a common language, just like C is erroneously said by some to be a subset of C++… The UK team thought we were looking at ways of making languages safer and more secure but the US was more worried about security and the ability of hackers to get into systems. They seem paranoid about buffer overflow and variable length arrays. So whilst the UK was concerned with making sure the air traffic control system was reliable and safe the US was worried about hackers taking control of it. This echo's the comments by some in the US that there might be a backdoor in Linux. There have been two meetings of the UK panel and two international working group meetings. We have now got a structure for the base document. It will look at the vulnerabilities in general e.g. buffer overflow and how it is handled for a wide range of languages in specific. The languages will include Ada, C, C#, C++, Cobol, Fortran, Java, MUMPS and SPARK(ADA). There is more than the C family out there. Yes, there are still billions of lines of COBOL still out there.

There are liaisons with outside groups such as ECMA and MISRA as well as the ISO language groups and the MOD. To save reinventing the wheel the ISO Vulnerabilities group will be working with the MISRA teams to add the additional security rules to MISRA C and C++. This is because any “security” problem they find will also be a problem for the correct behaviour of a critical system. We hope to have these rules in MISRA-C3 and MISRA-C++1. This should also ensure that these rules are likely to have tool support.

Moving on to the MISRA panels: The MISRA-C example suite is complete on a first pass. We just have to sort out the formatting and method of delivery. We also have to sort out the TC and we hope to have both completed for Christmas. MISRA-C++ is also pushing an aggressive schedule. Let’s just say I have booked the chair of the MISRA C++ panel for the IET Automotive conference (7/8 March in Warwick). Also the MISRA Safety Documents should be available by then (but don’t quote me ? )

The MISRA-UML team is still sorting out what people actually need from it for embedded, not just automotive, use. If any one is interested email me and I will put them in touch with the team.

The UK/BSI C panel is still without a convener and any method of communication. Hopefully BSI will sort this mess out soon as the International C Working Group will meet in London in April 2007. The C++ panel on the other hand is celebrating that they managed to stop ECMA fast tracking its C++/CLI standard though the ISO System. However it is only a temporary reprieve. Most of the ECMA standard has already been implemented by Microsoft, who drove a lot of it anyway. In reality the C++/CLI will be the ECMA and de-facto standard whether ISO like it or not. All they can do, like the House of Lords, is delay a bit and modify.

Should I survive the Embedded System Show, next month I will pick up the comments on the Gcc tools. As usual praise, comments and death threats to chills

 

 

Author Details and contact

 

Eur Ing Chris Hills BSc CEng MIET MBCS MIEEE  FRGS   FRSA is a Technical Specialist and can be reached at This Contact

 

Copyright Chris A Hills  2003 -2008
The right of Chris A Hills to be identified as the author of this work has been asserted by him in accordance with the Copyright, Designs and Patents Act 1988