Who should write embedded software?

[vvanders]

The software folks tend to think in classes named AbstractObjectGeneratorXMLFactoryProxyDelegate and therefore produce bloated and overly generic code.

I observed this tendency with large frameworks (typically Java based) but not in embedded code.  Java and the refactoring tools of its IDE's make it very easy to add those layers of abstractions. It make sense when you write the code but more difficult for new comers to lean the code and understand the flow.  This is typically the tension, between easy writing or easy reading of the code.

One example is Juice, it's manages the dependency injection and simplifies the unit testing but almost impossible to follow.

We like to call the AbstractObjectGeneratorXMLFactoryProxyDelegate "enterprise quality software". Someone did an excellent FizzBuzz implemenation:
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

WRT the original question I don't think there's a clear distinction. I've seen hardware people learn the ins and outs of software. I've also seen software people be successful in moving down the stack closer to hardware. I will say that on the software side people who tend to care about performance and memory size(ususally real-time applications) tend to do better in the transition.

[SirNick]

Any discipline can be broken down into an arbitrary number of sub-classifications.  And, at the same time, the line between historically distinct industries becomes far less defined as technology merges.

See: IP telephony.  You mean I have to understand the mechanics of call handling, TDM, and networking?

Quite likely the IP phone runs Linux too. 

[Alexei.Polkhanov]

I think many engineer see a difference between software as embedded and non-embedded from whenever it is intrinsic or hidden within system or if user interacts with software itself (through UI) rather than the system it is part of (like pushing break pedal).

Over past 20 years I worked on many software projects - I find that difference between how software is designed and built depends little on wheather it is embedded or not . On other end there are huge differences between how HARD REAL TIME, time critical and fault tolerant systems are built and the rest. For example most programmers that work with real-time systems would be familiar with terms like Rate Monotonic Analysis, N-version programming, lock-step execution. Many engineers that work with general-purpose systems never even heard of terms like RMA. Same situation is in low-level graphics programming used in video games for example, or networking - lots of specialized knowledge required even to start.

Clearly embedded software does not require any special skills or knowledge from developer just because it is embedded, but other aspects that I mentioned above do.

[clarkzh]

Writing ANY nontrivial software well demands not only a knowledge of software techniques, but at least some familiarity with the application area.

Also, writing almost ANY nontrivial software well demands a knowledge of the environment in which the software runs.  In embedded software, especially the stuff that runs on small chips without an operating system, one may need to know details of the hardware environment and work very close to the hardware, keeping track of pin assignments, interrupts, etc.  That's a challenge, but it's a different challenge than application developers of non-embedded software who have the challenge of writing extremely portable software that runs on a huge variety of platforms with varying resources and operating systems.

One of the problems discussing embedded software is that it's such a broad topic.  My first exposure to it was seeing a presentation given by some guys who were writing software for the engine controllers that controlled large jet engines.  Those guys had to know software development, their hardware environment, and they also had to have some understanding of how the engine itself worked.  A mistake in the software could cause a plane to crash and/or damage a multimillion dollar engine, so they were encouraged to review and test their software before deploying it on an actual engine.  Because their computing hardware had to operate in an extreme environment of temperature and vibration, they used rugged old slow chips that were very constrained in memory, and had just enough computing power to get the job done.

The challenges there are a bit different than the task of writing embedded software for an infrared TV remote control.  And I'm not minimizing the challenges of a TV remote, trying to optimize hardware cost, make the best and most intuitive user experience, etc.

Even if you consider non-embedded software running on modern networked computers, most programmers need to know not only programming, but also something about their application area.  Writing a good finite element modeling program to help mechanical engineers compute stress and strain using 3-d models of mechanical parts requires a different set of knowledge and skills than writing an efficient and fast large-scale e-commerce site, which is different from writing a good compiler, which is different from writing an engaging and popular action game for PlayStation, Xbox, and the like.  And all of these are different from embedded software to run a microwave oven, or a pacemaker implanted in a person's chest, or a newspaper printing press, etc.  Software isn't all the same.


Who should write embedded software?  The people who know the area well.

excellent writing!!!

also the people should have the skills suited for the job. I mean, programming skills, hardware skills.

I am from china. here, most firmware is written not by PC software background people. most of them from hardware guys.  you should be able to solder components. use oscilloscope. DMM. draw PCB. debug circuit.
then, write the firmware.

mostly, here we develop simple , using no OS embeded system. but if using OS, like WINCE,linux. That is cake for the PC software background guys.

[T3sl4co1l]

I'm a hardware guy.

I write software very well (if I do say so myself, but I'd like to think, good enough that I'd be willing to provide examples without feeling embarrassed about it).

I don't want to have to do it.

I'm very slow and methodical at writing.  I can't just bang out a simple use case.  I am unable to ignore all the side effects and edge cases that, well, makes all software such a notoriously vulnerable target to hacking.

Not that hacking need be a particular concern, but it's the same to me as leaving ESD diodes off a loose input, or something like that: not part of the required spec, but something's going to get fucky if it goes outside that, so are you going to do something about it or not?

Tim

[calin]

Been reading the thread and there are indeed many colors to - embedded software - a short name for a long and wide area/domain.

If it is to be sarcastic I can say "those who know" .. but that wold be an a$$ of a response

Now on a more serious note these "masochist" as you call them are probably the ones that are most likely to write low level embedded code - heck I am one of them - my diploma says "engineer in computers and systems science"  pretty damn close to masochist definition. I know programming well and enough electronics to read a data sheet, understand how a bus protocol  works, timing etc. , i know to use a scope and logic analyzer, so yeah ... masochist  .  So the masochists are the guys tat put life in the chips and ee engineers are pretty damn close to that definition but you need guys that know to model an OS kernel etc to bring things to the next level - write an RTOS , design a compiler etc. Everyone has its place in the mix.

There are many types of masochists; the ones that write firmware-s and drivers (you think those BSL-s get born out of nothing) ; the ones that create the OS , write a compiler backend etc - each specialized in their area. For example I know low lever firmware and OS design inside out .. put me to write a compiler backend and I start looking like a moron. So you need a team .. always. Remember what Bhor said - "An expert is a person who has made all the mistakes that can be made in a very narrow field." .. You need few of these to get a full circle.

The AbstractProxyFrameworkInstatiatingBuilderFactory type of progammers that use angular JS and backpack to post tweets , or PERL or whatever functional HasNotEverHell heard about language which uses "functional object oriented encapsulation" (that's made up) are so high in the food chain that they forget about what they are running on . All they know is that "is a quad core Snapdragon" chip and yes runs Android and is optimized for HTML5. But hey , surprise, you need this kind of programmers too ... a masochist is just too expensive to pay him to do HTML5. He will probably do it but on a pay rate that will turn the boss in a "masochist"
[/size]
[/size]I know this is not even near to a decent answer but if you look at today's environment and products is clear that the term "embedded" is very large ... and to bring to life a successful product you need a team of specialists working together.

[dannyf]

a masochist is just too expensive to pay him to do HTML5.

From an employment point of view, you cannot be making a lot of money as long as you are actually writing code. I would expand that further to say that you cannot be making a lot of money as long as you are actually doing engineering - that's just the sad state of our society now.

Among the people who are indeed writing code, I  would think that those working with OS-level applications (for example, smartphone apps, or internet applications / plumbing) are making far more money than people writing code for embedded applications.

[Kjelt]

Among the people who are indeed writing code, I  would think that those working with OS-level applications (for example, smartphone apps, or internet applications / plumbing) are making far more money than people writing code for embedded applications.

Big companies have outsourced this kind of work mostly to India 
The western programmers still doing this are self employed or relatively small companies.

[andyturk]

From an employment point of view, you cannot be making a lot of money as long as you are actually writing code. I would expand that further to say that you cannot be making a lot of money as long as you are actually doing engineering - that's just the sad state of our society now.

You can make good money (over time) if you own stock in your employer, and the company is sold or goes public.

[Bassman59]

I recently saw an add for an "Embedded C Developer" and the requirements were: "Excellent knowledge of C and Linux Kernel Development".
Can this be thought of as embedded software?

Oh, yes, certainly. I used to work for a company that did VME and Compact PCI CPU boards, and these boards were of course installed into backplanes which were then embedded in a customer system (which could be a helicopter or whatever).

The boards ran VxWorks or Linux, so knowledge of how to build kernals and make BSPs was absolutely a requirement.

I suppose the distinction one might make is whether the computer is, from the intended customer application point of view, a multipurpose machine like our desktop PCs and Macs, or whether it's designed to go into a system and do one thing for its lifespan.

[Kjelt]

Personal adds set up by HR after interviewing 3 or more managers are silly they always ask for the sheep with 6 legs, 20 years of experience and not older then 30: 
If you would be an alien and fullfill 100% of all those requirements in those adds you could easily get >$200k a year because you are the only one on the planet but they then offer $50k.
After a year those adds are still open and the company has no clue why they can't find this perfect candidate 

[gocemk]

Personal adds set up by HR after interviewing 3 or more managers are silly they always ask for the sheep with 6 legs, 20 years of experience and not older then 30: 
If you would be an alien and fullfill 100% of all those requirements in those adds you could easily get >$200k a year because you are the only one on the planet but they then offer $50k.
After a year those adds are still open and the company has no clue why they can't find this perfect candidate 

 

Right now i am experiencing exactly the same, looking through the adds while searching for a job in the embedded software industry. Many times i am asking myself the question whether i am lagging too far behind, or is there someone who really can fullfil all those requirements and is unemployed and searching for a job. 

P.S. Sorry for the off-topic.

[dannyf]

you could easily get >$200k a year

That (more around $225 - 250K) has been the going rate for Cortex-M programmers for sometime now, and even at that rate, it can be hard to hire and retain them.

Cortex-A programmers are slightly more expensive.

Programmers for 8-bitters are dime a dozen, on the other hand.

[dannyf]

I suppose the distinction one might make is whether the computer is, from the intended customer application point of view, a multipurpose machine like our desktop PCs and Macs, or whether it's designed to go into a system and do one thing for its lifespan.

That probably is a better definition of embedded computing than OS vs. non-OS definitions some people use. More and more embedded work is on at OS levels.

However, that distinction can be difficult to draw sometimes. Like smartphones: what "applications" there are embedded?

[nctnico]

you could easily get >$200k a year

That (more around $225 - 250K) has been the going rate for Cortex-M programmers for sometime now, and even at that rate, it can be hard to hire and retain them.

Cortex-A programmers are slightly more expensive.

On which planet? Definitely not on earth!

[FrankBuss]

For me it seems as as if the embedded software people are falling back in terms of software technology. I haven't come across any embedded software developer who knew of functional programming.

Then you haven't met me I can program microcontrollers:

http://www.frank-buss.de/joystickadapter/index.html

Linux on embedded systems:

http://www.frank-buss.de/io-expander/index.html

but I know functional languages like Haskell as well, and even tried the functional programming paradigm (higher order functions, clsoures etc.) in Common Lisp:

http://www.frank-buss.de/lisp/texture.html

Any good programmer can write embedded software after some learning of the constraints and special aspects of the target platform, which might need some weeks for the first embedded system, but is faster for the next embedded system. But in my experience hardware developers can't write good embedded software (maintainable, bug free), without first some years of learning good programming practices.

[dannyf]

Any good programmer can write embedded software after some learning of the constraints and special aspects of the target platform

Agreed. Programming is programming. How hard can it be?

[SeanB]

Programming is easy, writing good code is harder, and writing bug free is even harder.

[nctnico]

Any good programmer can write embedded software after some learning of the constraints and special aspects of the target platform, which might need some weeks for the first embedded system, but is faster for the next embedded system. But in my experience hardware developers can't write good embedded software (maintainable, bug free), without first some years of learning good programming practices.

The latter goes for eveybody. Learning to program well takes 10 years and a couple of good mentors. Regarding writing embedded firmware: In my experience software people tend to struggle when it comes to hardware because they lack the knowledge on using test equipment.

[FrankBuss]

Right, an embedded systems developer needs at least some basic understanding of electronics so that he doesn't forget to connect GND and wonders why the I2C signal looks so very noisy on the scope. Best is a team with experienced hardware AND software people working together.

[gocemk]

Few months ago, a local software company organized a 2-day embedded seminar for the students who are in Computer Science and Electronics classes. The microcontroller we worked on was LPC1769 on the LPCXpresso board and the LPCXpresso IDE was used for development. The tasks were to build something using the UART and the I2C peripherals on the MCU. Then, "judges" (Senior Embedded Developers from the company) will review the code and give grades. The two main criteria were: 1.Is the code working as it should be; 2. Code style and consistency.

The software guys Computer Science) overall were quicker than the hardware guys (Electronics), and overall they produced some more readable code. But, when they were asked the question "Does your UART/I2C driver uses the polling method or interrupts? ", their answer was "I don't know, we just used the examples provided by LPCXpresso". Also, i think i was the only one in the group that asked for an oscilloscope to debug the I2C bus, others just used "trial and error", and got the job done.

This showed me that although the software guys weren't quite familiarized with the MCU used, and were lacking some basic embedded knowledge, like polling vs. interrupts, they got the job done quicker and maybe better (more readable code) than the hardware guys. Mainly i think this is because they have more experience writing various kinds of software, and now when embedded programming is becoming more and more high-level, i think that they have the edge.

[WarSim]

As a person with experience and qualifications on both side.  Both disciplines seem to have some strange assumptions about the other. 
For example there is a thread that seems to claim that an optimizer is required to create optimized code.  Therefore the only way to create the best code is through an optimizer. 
Another example is software focused people don't seem to understand the importance of analog nor the importance of an efficient cct.   


Sent from my iPad using Tapatalk

[WarSim]

IMHO both disciplines are required to do the best job.  But there is no reward for producing excellent products, good enough products as fast as possible. 


Sent from my iPad using Tapatalk

[nctnico]

As a person with experience and qualifications on both side.  Both disciplines seem to have some strange assumptions about the other. 
For example there is a thread that seems to claim that an optimizer is required to create optimized code.  Therefore the only way to create the best code is through an optimizer. 

As others and me pointed out: you clearly have a wrong view on what an optimiser does. Compiling code consists of several phases where the last phase is removing unnecessary (machine) code and re-ordering instructions to optimise the execution pipeline. How that job is done depends on whether the user wants the most compact code, the fastest code or code which still debuggable. However: an optimiser won't turn a dump algorithme into a smart algorithm. Coming up with a smart algorithme is up to the programmer.

[WarSim]

I know exactly what an optimizer is.  I am not going to discuss qualifications and experience.  When you say someone who has experience creating the optimizers you use that he/she didn't understand what they are is just stilly.  To help you out in this regard I will stop responding. 


Sent from my iPad using Tapatalk