The Dearth of C Training

4/7/2008 2:00 AM EDT

Quite interesting!

My company provide services to telecom companies. Specifically for semiconductor companies and handset companies.

Personally I have been involved in interviewing engineers for doing the work. Usually while interviewing, I do not pay attention to the programming languanges one has used but towards the way of thinking. I have found that the ones who are good at that pick up any language.

This is my personal experience. To put it in other words - Language used is just an expression of your ideas.

Now comes the anticlimax. Most of my customer want engineers with experience not only in a specific language but special adaptions of those for the mobile phones.

This is what precisely creates the gap you mention above. If an engineer knows how a C program works on a specific OS or no OS environment for a a given embedded system, then he can manage to run any program under given constraints on it.

It is the manager who need to carefully look at job description, if you want to cover this gap now. Otherwise pretty soon we need to design embedded systems with resource pool as reach as a PC.

regards,

Jagmohan

4/7/2008 3:38 AM EDT

Yep, you're pretty much right on with this article. The problem is that schools find it easier to teach the memory-managed languages, and even C++ is being phased out (ie: dropping on the language rankings) in many computer science programs. Here's an interesting take on this issue from two professors:
http://www.stsc.hill.af.mil/CrossTalk/2008/01/0801DewarSchonberg.html

It's strange that these days, every chip has an embedded ARM or 8-bit micro, and firmware engineers are needed now more than ever. However it seems like it is getting harder and harder to find good people that can create these drivers and stacks. You can even see this in the recent driver debacle with Creative Labs, where an indepedent modder fixed the bugs in the company's firmware drivers, and the company publicly criticized him for it.
http://blog.wired.com/gadgets/2008/04/daniel_k-who-fi.html

Firmware is only getting more important, and semiconductor companies are suffering because they can crank out chips quite quickly using IP cores, but customers won't touch them without the required drivers and protocol stacks. The software schedules add an extra six months to a year to the time it takes for the company to be able to sell the chip to customers.

It looks like the pool of capable firmware engineers is shrinking and the demand is increasing. It's a dangerous combination.

For my part, I'm working on open source embedded firmware which I think is desperately needed by the industry. Open source benefits the customers by providing them with a community they can turn to if they experience software problems. It also benefits the manufacturers by giving them access to hardware independent software that they can immediately download and implement without paying $50-100k and signing mountains of NDAs and software license agreements.

If you're interested in checking my project out, I'll shamelessly plug it. I keep a development blog so that people can see what kinds of decisions and pain go into creating a software protocol stack (Zigbee). You can take a look at my open source Zigbee development blog here:

http://www.freaklabs.org

Akiba

4/7/2008 8:39 AM EDT

In the old days a lot of low level Assembly- and C-programmers originated from near-by fields of electrical engineering or mechanics.

Since we now live in times where it is cheaper to place a microcontroller with a couple lines code than a transistor and a capacitor, there will always be "overspill" from other engineering disciplines close to the physical ground. In Europe special attention is given to embedded systems engineering by multi-national research initiatives, but also by introduction of new curriculum at engineering schools, like "mechatronics" which deal on the low level interaction between mechanics, electronics and software.

While the "pure" computer science software is growing in complexity, the low level programming is feasible for many not so thoroughly trained persons, who are rather masters of their real-world application than deep into KLOC counting. Tools which enable efficient low level programming for non-computer specialists, will always have a market.

4/7/2008 11:09 AM EDT

I expressed my initial thoughts above. Few other questions and thoughts are:
1. Is it sufficient today just to know C for embedded software? (My answer: No. C is necessary but not sufficient. Scripting language as well as OO languages are necessary. Perhaps a mix of C and little aseembly is what will go into the Flash. But for testing and development knowledge of other languages is required.)
2. What constitutes an embedded software engineers? (My definition: The activities of the embedded software engineer include 35% development, 35% testing, 15% hardware, 15% system level tasks.)
3. What is the purpose of advancements in embedded controllers being used in today's embedded systems? (You can also read this question as: Are tools the answer to embedded software?)(My answer: To enable more features on the embedded systems.)

4/10/2008 12:33 AM EDT

Where will developers of resource-constrained systems come from? From teaching-oriented universities like mine (www.gvsu.edu) that don't chase trends but instead focus on what's best for our students' careers. All of our engineering students learn C in their freshman year. In their sophomore years they apply (and expand) their C knowledge to programming Atmel AVR's. CE's and EE's do further embedded programming in their junior year, and our Computer Engineering students learn ARM assembly in their senior year, plus they learn C++ and Java in their CS courses.

I encourage Dave Smart and other program leads who want competent embedded system programmers to look at our engineering program.

4/10/2008 12:45 AM EDT

Recently, embedded systems tools and "huge amount of resources" have made things so easy that, there is not much difference in developing a software for an embedded system or for a PC.
In PC or embedded systems, it is always a good idea to be thrifty in resource (memory and processor) usage. May be, in good old days, when the 8008 was used, people like Jack had no option but to be thrifty. These days too people writing firmware for the small 8 bit controllers have no choice.
Guys writing embedded software in those tiny automotive embedded system still delve in assembly and 'C. They can be seen hanging around with Logic analyzers, and oscilloscopes. But those guys writing the JVM, UI's, MP3 players, etc will need less of 'C not to mention assembly.

4/10/2008 7:44 AM EDT

I forwarded a link to this article to one of the profs at my alma mater. His response was "We teach C and assembly in our [electronic] engineering program." The assembly is for a MIPS processor. That's not going to help an 8-bit application very much!

No wonder we have such a hard time hiring good engineers!

4/10/2008 2:20 PM EDT

It's funny how many people want universities to be trade schools, teaching directly relevant skills (like C, or C for embedded, or C for embedded 8 bit microprocessors, etc.) rather than more general knowledge and principles that can be applied throughout one's career and life. When I attended university 35 years ago, I learned Fortran and Snobol in the computing courses I took. Perhaps not too useful in today's world! However, in the intervening years, by applying the knowledge and principles about computing and languages that I was taught, and of course by continued attempts to learn more over the years, I picked up and applied working knowledge of Algol 68, Algol 60, Cobol, Pascal, C, C++, SystemC, and a variety of scripting languages including the well-remembered IBM ReXX. And enough exposure to a variety of languages enables me to at least appreciate the concepts behind other languages, and move on from syntax to semantics. Maybe I have been fortunate in my employers, in that they never confused an ability to learn with a specific knowledge of very specific skills applicable immediately, and gave me the chance to stumble around a bit with each new experience - and learn in the process.

4/10/2008 7:02 PM EDT

I humbly submit that teaching C is a good idea not because it is a "trade skill," but because it provides a foundation for the nitty gritty aspect of all computer science. That it's a directly relevant skill for embedded programming is a fringe benefit.

Joel Spolsky, who writes about distinctly non-embedded programming, agrees with me and puts it much more eloquently:
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

It's not the language itself that's valuable, but the background learning it provides you.

4/12/2008 7:29 AM EDT

C is not just another "trade skill". This is what Alex Stepanov (inventor of STL) said more than 10 years ago:

"Let's consider now why C is a great language. It is commonly believed that C is a hack which was successful because Unix was written in it. I disagree. Over a long period of time computer architectures evolved, not because of some clever people figuring how to evolve architectures---as a matter of fact, clever people were pushing tagged architectures during that period of time---but because of the demands of different programmers to solve real problems. Computers that were able to deal just with numbers evolved into computers with byte-addressable memory, flat address spaces, and pointers. This was a natural evolution reflecting the growing set of problems that people were solving. C, reflecting the genius of Dennis Ritchie, provided a minimal model of the computer that had evolved over 30 years. C was not a quick hack. As computers evolved to handle all kinds of problems, C, being the minimal model of such a computer, became a very powerful language to solve all kinds of problems in different domains very effectively. This is the secret of C's portability: it is the best representation of an abstract computer that we have. Of course, the abstraction is done over the set of real computers, not some imaginary computational devices. Moreover, people could understand the machine model behind C. It is much easier for an average engineer to understand the machine model behind C than the machine model behind Ada or even Scheme. C succeeded because it was doing the right thing, not because of AT&T promoting it or Unix being written with it."

(From http://www.sgi.com/tech/stl/drdobbs-interview.html)

4/12/2008 8:12 AM EDT

Where will developers of resource-constrained systems come from? Same place they always did: hobbyists and hackers.

Schools promulgate the status quo; good schools inspire their students to keep learning, long after graduation.

Creativity and innovation are not "skills" that can be "taught"; great programmers are self-motivated, with a passionate enjoyment for the challenge of solving "impossible" problems...


cheers, - vic

4/13/2008 1:19 PM EDT

Looking at the comments posted, I would also like to bring your attention to another important point. I am in no conflict with the thought that C is great language as far as programming for embedded systems is concerned. I also agree that teaching C in the context of embedded systems is the best way to prepare the embedded systems programmers that industry needs. However, below I am trying to bring your attention to "resource constraints". I have two points to make regarding this
1. Advancements in the resource availability (more memory, more speed, better tools) need not a reason that embedded systems progrmmers should use for forgetting about resource constraints.
2. Dealing with the resource constrains is an essential embedded systems programming skill. Time and again it has been seen that when in resource constraints some great software has emerged.

Let me make an attempt to explain based on my experiences.

I started working in the EDA tool development company where we had a combination of Sun machines with different resources. There was one specific Sun machine which had 100MB disk. It was the machine maximum in demand. Observing that we use it most of the time for the compilation of our software rather than testing, one of the manager (he was also our professor in the institute) told us about his days as a PhD student. The institute had a miniframe and the compilation, linking and running of the program was all done using deck of punched cards. He said that, multiple compilation was a crime as the machine used to work in a batch mode. Therefore even for a single compilation error, after fixing it one had to wait for a few hours for his deck to get compiled again. It was a big lesson for us - we were using the advancements in the technology for the luxury of multiple compilation most of which were avoidable. Several of us took it quite seriously and started working towards becoming, what we named as "single pass compilers" - meaning those programmers who never compiled the code till the end and it was compiled in that one run without any compilation errors. [A few like those who were even single test case programmers - meaning that they will create only one test case or just a handful to test there software. Most of the time the test case will pass in first run. After that they will make a release of the software and howsoever one tried that software never failed to deliver its intended functionality.]

The reason for sharing this is just to remind most of us that - not too many years ago we had desktop systems which were full of resource constraints. Imagine - even today's desktops are resource constrained. For example, it may be that the applications which we run or think today are not capable of putting enough challenges for the resources available on today's desktop.

Coming to my second point: Challenges put forth by the resource constraints is most of the time a source for great software or great programmers to emerge: Here is another story, which I believe most of you would have already read - This is an interview with Bill Joy where he told the story about the vi editor. (http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_gift/) Whenever I read the article I always think that -it was an embedded system they were dealing with and not with desktops.

I feel therefore, that C training is not an end in itself, but just a mean to meet the necessities for creating programmers of embedded systems. It does provide a way to think about finding a solutions for embedded systems. However, more important is training the programmer to deal with resource constraints. May be 'C' is the best language to be taught for dealing with resource constraints.

4/30/2008 2:57 AM EDT

I agree with jagmohan,which language is used in project is not important, and language just a tools to express your idea.

8/17/2009 10:58 AM EDT

As a trainer of embedded engineers in advanced technologies, I have found that there are a growing number who don't know C and have a hard time following hands-on classes that teach the algorithms to impliment such protocols as USB, TCP/IP, etc using existing commercial stacks. I have had to go back and start teaching classes in remedial C/C++ and IDEs as part of my training classes(http://www.tadatraining.com). I'm with Dave - I am also a 'dinosaur' that still remembers op codes for the 8080 and 6800 used to patch binaries in 2716s - but there will always be a need for understanding the basics before you can excel with the latest shortcuts.

8/18/2009 9:20 AM EDT

I don't understand the frustration with universities for implementing Java based CS degrees.

When you're talking about pointer math on linear memory spaces and I/O register setting for hardware subsystem configuration (i.e. hardware timers or UARTs or whatever), you're talking about electrical engineering. You're talking about defining the time domain behavior of a certain form of hardware as constructed by Atmel or Intel or whatever. You're talking about pipelining behavior of parallel, transistor based, logic elements. This is clearly electrical engineering.

Dijkstra said: "Computer science is no more about computers than astronomy is about telescopes."

So the notion that you need to understand data types and low level topics like pointers or precision or the existence of a hardware multiply in the ALU on this certain architecture doesn't really track for a CS degree. What those people need to understand is the logic behind time and space complexity of an algorithm or of recursion. Whether you have hardware multiply or software floating point just adds a constant where time complexity is concerned and is utterly disregarded in the calculation. N^3 vs exponential time doesn't care how long it takes to do one of those calculations.

C and assembly seems to be a useful option for low level implementation of optimized code on a harvard architecture RISC device (or otherwise) if you're trying to optimize code for deterministic behavior or fast execution.

But the notion that CS programs need to get people into pointer math is silly. That's hardware nonsense. Leave that to the EEs like me. Recursion, concurrancy, and algorithms are described in pseudocode in your CS courses. Whether it runs on the JRE or by directly calling opcodes on an 8-bit microcontroller doesn't change that.

8/18/2009 12:27 PM EDT

There is sufficient space in a curriculum for both high-level and low-level programming concepts. As both an EE embedded DSP practitioner and professor I see a strong need for both in both curriculum and practice. I teach CS courses using Java for introductory programming, data structures, algorithms, etc. But for my real-time systems course I use C with QNX Neutrino/POSIX for higher-level concepts and C plus assembly for low-level concepts (using a dsPIC and no OS). I feel that to do meaningful CS it is important that students understand how a computer works! I find that having too much abstraction in CS results in grotesquely inefficient and unreliable systems. Understanding the underlying system helps in the development of efficient software systems with fewer bugs (and better understanding of bugs, including bugs in libraries).
Over my nearly 30 years with C, I have found that C is the best tool for many projects and that many other applications require some of the other 20+ languages that I have used. The language needs to suit both the application and the resources.
For small systems that will be used in high-volume applications, C is often represents the best tradeoffs between code size, resource usage, execution efficiency, and maintainability. But it is always important to employ good software engineering practices and often to use object-oriented software design implemented in C.
Long live C!