Who should write embedded software?

[dannyf]

were lacking some basic embedded knowledge, like polling vs. interrupts

That's surprising. Probably due to the fact that they are students - not as experienced.

they have the edge

Well, embedded programming is programming so the software guys do tend to have an advantage, naturally.

[FrankBuss]

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".

And the hardware guys knew if it was polling or interrupts? LPCXpresso hides a lot of the low-level details, so unless you browse the library code, you don't know what is used.

BTW: I tried LPCXpresso and didn't like it, because code quality was not so good, see these examples:

https://groups.google.com/d/msg/fpgalink-users/rwHlnmUgtZY/dID7aDhq6W4J

And it was cumbersome to use in Eclipse (I prefer Makefiles).

Finally I found "mbed" for the LPC chips, which is a really nice object oriented framework. An example:

https://groups.google.com/d/msg/fpgalink-users/rwHlnmUgtZY/RsC-1HFEPHMJ

Can be used online with their website IDE and offline, too.

[dannyf]

BTW: I tried LPCXpresso and didn't like it, because code quality was not so good, see these examples:

https://groups.google.com/d/msg/fpgalink-users/rwHlnmUgtZY/dID7aDhq6W4J

Not sure how one could tell from that if "code quality" is good - what is "code quality" anyway?

And it was cumbersome to use in Eclipse (I prefer Makefiles).

That's subjective. An equally valid argument can be made the other way around.

Finally I found "mbed" for the LPC chips, which is a really nice object oriented framework. An example:

https://groups.google.com/d/msg/fpgalink-users/rwHlnmUgtZY/RsC-1HFEPHMJ

That's the "cloud" based compiler, I think. Not sure how it works when you are offline. Plus any IP / security concerns one may have in a corporate environment.

Any, not sure how it could have addressed your "code quality" concern.

For my own, I use CoIDE (eclipse) and loved it for the project wizard. No problem whatsoever. Knock on wood.

[FrankBuss]

BTW: I tried LPCXpresso and didn't like it, because code quality was not so good, see these examples:

https://groups.google.com/d/msg/fpgalink-users/rwHlnmUgtZY/dID7aDhq6W4J

Not sure how one could tell from that if "code quality" is good - what is "code quality" anyway?

Sorry, I thought it was obvious: Comments like "Current Fix for LPC17xx, havent checked for others" and "for (i = 0; i < (4 * 1000); i++);" for a fixed delay smells bad. And the USB implementation I was testing didn't work well. There were some buffer problems, too, like no error message when the buffer is full etc.

And it was cumbersome to use in Eclipse (I prefer Makefiles).

That's subjective. An equally valid argument can be made the other way around.

I know Eclipse and I've seen better integrations. There were lots of duplicated code and complicated project dependencies, which made it cumbersome to use, especially if you are targeting more than one LPC chip type.

Finally I found "mbed" for the LPC chips, which is a really nice object oriented framework. An example:

https://groups.google.com/d/msg/fpgalink-users/rwHlnmUgtZY/RsC-1HFEPHMJ

That's the "cloud" based compiler, I think. Not sure how it works when you are offline. Plus any IP / security concerns one may have in a corporate environment.

Any, not sure how it could have addressed your "code quality" concern.

You don't have to use their cloud service (which I didn't even test, but looks good). The code is all open source and you can compile your code locally: https://github.com/mbedmicro/mbed

Code quality looked better for me, because I added some missing features to the library, added another library for FPGALink and it was more clean for me than the LPCXpresso code. And the object oriented base made it easier to program for it. For example I derived my USB class from the framework class, so less code duplication than usually with C.

[dannyf]

Software delays aren't that big of a deal to me: as long as you know their limitations.

The (default) LPCxpresso set-up does require some dependencies (CMSIS for example). That's not inherent to Eclipse, and not even inherent to LPCxpresso - you can set up your projects without such dependency.

The debugging is a little slow and buggy. But that's minor. The IDE is a little bit bloated and slower than CoIDE. Too fancy for my taste.

I typically use Keil / IAR / CoIDE + jlink. Some LPCxpresso board comes with mlink and you can set them up natively in IAR.

[FrankBuss]

Compile it with the wrong optimize setting, and any "for" delays will be removed by the compiler, or even from one compiler version to the next. Once I fixed an interesting problem in the board setup code for an Atmel CPU, which didn't work anymore with a newer compiler, because of such bad coding practice. Any modern microcontroller has timers, so these should be used if you need a guaranteed minimum delay.

[diyaudio]

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.

Rather surprising computer science students cover operating systems.. concepts like No block-able I/O, threads, and Event Queues should be familiar to them... maybe the question was phrased wrong..
 

[dannyf]

because of such bad coding practice.

It is a bad coding practice because it is not fool-proof.

And you cannot write fool-proof code no matter how hard you try.

Any modern microcontroller has timers, so these should be used if you need a guaranteed minimum delay.

And you will find yourself in a situation where you have exhausted timers available.

You will not find an approach, any approach, that is preferred over / superior to another under ALL circumstances. Software delays have its pros and cons, and the same with hardware delays. You just need to figure out which is better for your particular applications.

As to "optimization"-resistant software delays, there are many easy approaches for that.

[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.

Rather surprising computer science students cover operating systems.. concepts like No block-able I/O, threads, and Event Queues should be familiar to them... maybe the question was phrased wrong..

Computer Science classes DO cover subjects like "Operating Systems", "System Software" and "Microprocessor Systems" (this is almost exclusively taught in assembly language and mostly with Intel 8085/6 and 386). But in my experience, the majority of the Computer Science students are much more interested in topics like C#.NET, Java, PHP, Python, SQL, databases...and similar. AI classes are increasingly popular lately, too.

I graduated in Automation, Robotics and System Engineering, where it was essential to learn the basics of embedded programming in order to do some useful work (motion/motor control, DSP, data logging, interfacing over UART, CAN....)

We hardly ever did any application software programming. Mostly it was some C# UI programs for interfacing with the computer's COM port for data logging over UART or similar.
And of course programming PLC's in ladder logic, but i was never a huge fan of that, i was always more into microcontrollers.

[Jeroen3]

Any modern microcontroller has timers, so these should be used if you need a guaranteed minimum delay.

Which is called Real Time, and there are Real Time Operating System you should use if you have those requirement. Do not confuse it with the literal meaning of realtime, "now".
http://en.wikipedia.org/wiki/Real-time_computing

Code quality is achieved by being consistent. Using delayCounter or delay_counter or sometimes even iDelayCounter (i as in integer).
And please do never forget:
/**
 * @brief Executes this
 * @note This has effect on that
 * @param[in] object structure
 * @return result of this
 */
and
delayCounter; /// counter for delay used with @p function()
Even if you do not generate doxygen pages at all. You must be able to read and use the code reading only the H (or sometime C) files. You do not want to jump to a pdf for each function description.

[calin]

No no he is right .. it is on Earth .. You just  have to jump the pond .. I mean the Atlantic. I am from Europe and I agree you will never get that "score" in Europe. Also depends by area where you are in US ... and other skill factors. But I can say is not that uncommon to get over 200K in US if you are good at this.


One rule .... make sure you never ever talk with HR bozo-s that literally have no idea what they read in a resume .




Quote from: nctnico on June 13, 2014, 05:15:56 AM

>Quote from: dannyf on June 13, 2014, 03:14:10 AM

Quote

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!

[Alexei.Polkhanov]

On which planet? Definitely not on earth!

Planet called US Pacific Coast. You just have to pay this kind of money to compete with every other company in the area.

After speaking with few companies and recruiters in Europe over last 4-5 years I have feeling there will be no good Software/ASIC/EE Engineers in Europe soon - they pay half of US/Canada and have double tax on top of that.

[madires]

After speaking with few companies and recruiters in Europe over last 4-5 years I have feeling there will be no good Software/ASIC/EE Engineers in Europe soon - they pay half of US/Canada and have double tax on top of that.

Yes, it's a funny business over here. The industry is moaning about a lack of engineers while the salaries don't reflect that. It seems to be just a strategy to keep the salaries down.

[nctnico]

No no he is right .. it is on Earth .. You just  have to jump the pond .. I mean the Atlantic. I am from Europe and I agree you will never get that "score" in Europe. Also depends by area where you are in US ... and other skill factors. But I can say is not that uncommon to get over 200K in US if you are good at this.

Interesting but living in the US? HELL NO!
I think I'll try and get some customers from the US. I quit my job and become self employed a few years ago due to low salary.

[Kjelt]

Planet called US Pacific Coast. You just have to pay this kind of money to compete with every other company in the area.

Well probably the cost of living is there also three times as high as in europe and probably the working hours will be at least one and a half times that of europe?
But still I think the salaries are too low if you follow the economic rule that demands raises prices, you can,t see any of that and companies keep on bitching that they can not find personell, well maybe if you paid higher salaries the status would increase and more students would choose a technical study.

[dannyf]

-but living in the US? HELL NO!-

do you have an invitation to live in the us?

otherwise, it is hard to turn down an offer before it is offered to you.

[dannyf]

-demands raises prices, you can,t see any of that and companies keep-

for a few long years, I spent half of my time recruiting. Even at those numbers we had a hard time getting 32bit people interested in us.

for a comparable 8bit programmer, 100-150k would be a very good figure.

so yeah, I would say that supply demand are working their magic.

[djacobow]

I'm an EE but spent most of my career as a computer engineer. I've never been as fond of writing software as I am of designing hardware, but I've certainly done plenty of the former.

For a rather long period of my career, I provided pre- and post-sales support to a microprocessor IP company that sold soft cores to be embedded in systems on chips. The HW folks, of course, wanted to get the constraints right so that Synopsys would generate a reasonable netlist and so that simulations would run correctly and they could see the machine boot and make successful bus transactions that covered every corner case.

The SW people just needed So Much More handholding. I easily spent time 10x more time with SWEs than HWEs as a result. A few trends were common:

- there was a sizeable contingent of SWEs who did not know how computers work, and had no interest in it. Buses, caches, etc, were all things that did what they did and there was no reason for a SWE to concern himself with them. This is not a recipe for embedded success.
- among those and probably among more, was a contingent who, in their life, had never once thought about what happens before main() or even were aware that anything happened before main()
- many had never given a moment's thought about how a program gets onto a machine
- few had experience with a non-OS environment, or even an unhosted environment
- concurrency: so many just didn't, couldn't get it
- on-chip peripherals were a mystery to most unless wrapped by someone else in friendly functions
- our architecture had an unfortunate quirk in that ISRs attached to interrupts above a certain priority level could not be written in C; They had to be in assembler, and you had to save and restore the registers you intended to clobber. This in theory was no great hardship, because usually with high priority interrupts, you wanted to get in and get out quickly, doing something simple. But the howls, HOWLS from developers about this limitation were endless
- SW folks did not like funky memory maps, disjoint memory spaces (like DSP "X/Y" memories) and other hardware tricks that segmented their view of the world.
- SW folks had a really hard time wrapping their heads around the idea that the hardware they were targeting might be buggy. After all, it was new, back from fab, and who knew what would be lurking there. But that never stopped any from trying, right out of the gate, to download their full multi-megabyte app to the target and being surprised that it didn't run. After all, it worked in the hosted simulator!

All that said, after all the moaning and groaning and a little bit of learning curve, they were able to produce working software, some of which did amazing things.

I guess my point is that in order to do embedded systems, you don't need to be an EE, you don't have to be comfortable with an oscilloscope, but you do need an awareness of how a computer system is organized. Computer Science programs did not seem to be teaching this. In fact, the most elite CS programs preferred to teach CS as a mathematics discipline, divorced from greasy, dirty hardware entirely. If graduates from such programs could not get off that mental track, they could not successfully program embedded systems.

Anyway, my $0.02.

[vvanders]

Planet called US Pacific Coast. You just have to pay this kind of money to compete with every other company in the area.

Well probably the cost of living is there also three times as high as in europe and probably the working hours will be at least one and a half times that of europe?
But still I think the salaries are too low if you follow the economic rule that demands raises prices, you can,t see any of that and companies keep on bitching that they can not find personell, well maybe if you paid higher salaries the status would increase and more students would choose a technical study.

Depends on the area, Austin and Seattle both have reasonable cost of living so you can make out quite well. Most of those figures match up with what I've seen in Seattle.

There's also been a huge issue with this in the Game Development industry. People regularly talk about the "UK brain drain". A good amount of the work is centered around London which also has obscene cost of living, why stay there when salaries are 2x stateside in an industry that already pays fairly low(anywhere from 30-50% less than standard SDE salaries).

[vvanders]

- there was a sizeable contingent of SWEs who did not know how computers work, and had no interest in it. Buses, caches, etc, were all things that did what they did and there was no reason for a SWE to concern himself with them. This is not a recipe for embedded success.
- among those and probably among more, was a contingent who, in their life, had never once thought about what happens before main() or even were aware that anything happened before main()
- concurrency: so many just didn't, couldn't get it

These 3 can be just as critical outside the embedded space and it's possible to get a CS degree without knowing any of it(or native code for that matter!). Caching is especially relevant if you want to get moderately reasonable performance out of modern CPU architectures.

[FrankBuss]

In fact, the most elite CS programs preferred to teach CS as a mathematics discipline, divorced from greasy, dirty hardware entirely. If graduates from such programs could not get off that mental track, they could not successfully program embedded systems.

There are a wide range of computer science areas. In theoretical computer science e.g. you prove some abstract properties of Turing Machines. Can be interesting and you can answer general questions about if something is programmable at all. Of course, usually students who do this can't program.

[djacobow]

There are a wide range of computer science areas. In theoretical computer science e.g. you prove some abstract properties of Turing Machines. Can be interesting and you can answer general questions about if something is programmable at all. Of course, usually students who do this can't program.

Indeed, and there's nothing wrong with it. But a person needs to have a sense of what they know and don't know. However, if you were attracted to the math and aren't all that interested in the machines, embedded development /may/ not be for you.

[djacobow]

Absolutely. People have defined embedded systems in a bunch of ways on this forum, but one somewhat humorous way I like to think of it is: if you are looking for the most computing power you can get for X dollars, you are probably not doing embedded and may not even be doing engineering. On the contrary, if you have minimum computing requirements and are looking for the minimum Y dollars that will satisfy them, you are probably doing embedded engineering.

To that end, wringing the most from the machine is important, and you can't get even close to it unless you have a good idea how the machine works. This means understanding the cache structure and any special capabilities (to lock lines or change associativity, or to put cache into a simpler "local memory" mode) as well any limitations, like no critical word first, or penalty performance for unaligned accesses, etc.

Regarding concurrency, it's a big problem, and your'e right, it's not just embedded. I'm starting to think concurrency education needs to start in preschool. along with shapes and colors. EEs are usually better than this because they intuitively get that everything is happening asynchronously and simultaneously all the time, anyway. It is only in the ordered world of the computer that one could even imagine life withOUT concurrency.

These 3 can be just as critical outside the embedded space and it's possible to get a CS degree without knowing any of it(or native code for that matter!). Caching is especially relevant if you want to get moderately reasonable performance out of modern CPU architectures.

[miguelvp]

Once we have to deal with 256 cores you bet we all get a hold of concurrency

Actually you probably have noticed a big jump in interest for functional languages over the past few years.

[Jeroen3]

Two cores is difficult enough. Or even an (RT)OS with two collaborating tasks.
But try vhdl, everything happens in parallel. Then you won't complain anymore.

- on-chip peripherals were a mystery to most unless wrapped by someone else in friendly functions
- our architecture had an unfortunate quirk in that ISRs attached to interrupts above a certain priority level could not be written in C; They had to be in assembler, and you had to save and restore the registers you intended to clobber. This in theory was no great hardship, because usually with high priority interrupts, you wanted to get in and get out quickly, doing something simple. But the howls, HOWLS from developers about this limitation were endless
- SW folks did not like funky memory maps, disjoint memory spaces (like DSP "X/Y" memories) and other hardware tricks that segmented their view of the world.
- SW folks had a really hard time wrapping their heads around the idea that the hardware they were targeting might be buggy.

@djacobow, Visual Studio and php people are not supposed to do the low level embedded software.
You must know how your C(++) compiles to machine code.
Test is simple, if they think Java or Microsoft Java ^C# are good candidates for low level embedded software, you find someone else.