[ACCEPTED]-Is low-level / embedded systems programming hard for software developers?-firmware

At the end of the day, everything is an 45 API.

Need to write code for an SPI peripheral 44 inside a microcontroller? Well, get the 43 datasheet or hardware manual, and look at 42 the SPI peripheral. It's one, big, complex 41 API.

The problem is that you have to understand 40 the hardware and some basic EE fundamentals 39 in order to comprehend what the API means. The 38 datasheet isn't written by and for SW developers, it 37 was written for hardware engineers, and 36 maybe software engineers.

So it's all from 35 the perspective of the hardware (face it 34 - the microcontroller company is a hardware 33 company filled with hardware/asic engineers).

Which 32 means the transition is by no means simple 31 and straightforward.

But it's not difficult 30 - it's just a slightly different domain. If 29 you can implement a study program, start 28 off with Rabbit Semiconductor's kits. There's enough software 27 there so a SW guy can really dig in with 26 little effort, and the HW is easy to deal 25 with because everything is wrapped in nice 24 little libraries. When they want to do something 23 complex they can dig into the direct hardware 22 access and fiddle at the lower level, but 21 at the same time they can do some pretty 20 cool things such as build little webservers or pan/tilt network cameras. There 19 are other companies with similar offerings, but 18 Rabbit is really focused on making hardware 17 easy for software engineers.

Alternately, get 16 them into the Android platform. It looks 15 like a unix system to them, until they want 14 to do something interesting, and then they'll 13 have the desire to attack that little issue 12 and they'll learn about the hardware.

If 11 you really want to jump in the deep end, go 10 with an arduino kit - cheap, free compilers and libraries, pretty 9 easy to start off with, but you have to 8 hook wires up to do something interesting, which 7 might be too big of a hurdle for a reluctant 6 software engineer. But a little help and 5 a few nudges in the right direction and 4 they will be absolutely thrilled to have 3 a little LED display that wibbles* like 2 the nightrider lights...

-Adam

*Yes, that's 1 a technical engineering term.

The best embedded programmers I've worked 7 with are EE trained and learned SW on the 6 job. The worst embedded developers are recent 5 CS graduates who think SW is the only way 4 to solve a problem. I like to think of embedded 3 programming as the bottom of the SW pyramid. It's 2 a stable abstraction layer/foundation that 1 makes life easy for the app developers.

"Hard" is an extremely relative term. If 9 you're used to thinking in the tight, sometimes 8 convoluted way you need to for small embedded 7 code (for example, you're a driver developer), then 6 certainly it's not "hard".

Not to "bash" (no 5 pun intended) shell scripters, but if you 4 write perl and shell scripts all day, then 3 it might very well be "hard".

Likewise if 2 you're a UI guy for Windows. It's a different 1 kind of thinking.

Why embedded development is "hard":

1) The 35 context may switch to an interrupt between 34 each machine instruction. Since high level 33 language constructs may map to multiple 32 assembly instructins, this might even be 31 within a line of code, e.g. long var = 0xAAAA5555. If 30 accessed in an interrupt service routine, in 29 a 16 bit processore var might only be half 28 set.

2) Visibility into the system is limited. You 27 may not even have output to Hyperterm unless 26 you write it yourself. Emulators don't always 25 work that well or consistently (though they 24 are way better than they used to be). You 23 will have to know how to use oscilloscopes 22 and logic analyzers.

3) Operations take time. For 21 example, say your serial transmitter uses 20 an interrupt to signal when it is time to 19 send another byte. You could write 16 bytes 18 to a transmit buffer, then clear interrupts 17 and wonder why your message is never sent. Timing 16 in general is a tricky part of embedded 15 programming.

4) You are subject to subtle 14 race conditions that occur only rarely and 13 are very difficult to debug.

5) You have 12 to read the manual. A lot. You can't make 11 it work by fooling around. Sometimes 20 10 things have to be set up correctly to get 9 what you are after.

6) The hardware doesn't 8 always work or is easy to damage, and it 7 takes a while to figure out that you broke 6 it.

7) Software repairs in embedded systems 5 are usually very expensive. You can't just 4 update a web page. A recall can erase any 3 profit you made on the device.

There are 2 probably more but I've got this race condition 1 to solve...

This is very subjective I guess, his reasons 28 could be many. But if he's like me, I know 27 where he's coming from. Let me explain.

In 26 my career I've dedicated 6 years to the 25 telecom industry, working a lot with embedding 24 SDK middleware into low-end mobile phones 23 etc.

Most embedded environments I've experienced 22 are like harsh weather for a programmer, you 21 constantly have to overcome limitations 20 in resources etc. Some might find this a 19 challenge and enjoy it for the challenge 18 itself, some might feel close to "the real 17 stuff" - the hardware, some might feel it 16 limits their creativity.

I'm the kind who 15 feels it limits my creativity.

I enjoy 14 being back in Windows desktop environment 13 and flap my wings with elaborate class designs, stretch 12 my legs a few clockcycles extra, use unnecessary 11 amounts of memory for diagnostics etc.

On 10 certain embedded units in the past, I hardly 9 had support for fseek() (an ANSI C standard 8 file function). If lucky, a "watchdog" could 7 give clues to where something crashed. Not 6 to mention the pain of communicating with 5 the user in single-threaded preemptive swamps.

Well, you 4 know what I'm getting at. In my opinion 3 it's not necessarily hard, but it's quite 2 a leap, with potentially little reuse of 1 your current experience.

Regards

Robert

There is a very real difference in mindset 18 from user-level application development 17 (ie, general purpose PC or Web applications) to 16 hard deadline, real-time response application 15 development (ie, the hardware/software interface).

Interrupts, instruction 14 sets, context switching and hard resource 13 constraints are relatively unknown to your 12 average developer. I'm assuming here that 11 your 'average developer' is not an Electrical/Electronic 10 or other Engineer by training.

The transition 9 for this developer you mention may be well 8 outside his comfort zone. Some of us like 7 stretching like that. Others of us may 6 have decided the view isn't worth the climb.

Likewise, folks 5 who've been in the hardware area (ie, Engineers) often 4 have difficulty with the assumptions and 3 language of software development.

These are 2 gross generalities, of course, but hopefully 1 give some insight.

He needs to be comfortable with the low-level 13 stuff, but mostly for debugging and field 12 issues. There is a serious learning curve 11 depending on the architecture, but not impossible. On 10 the other hand, the low-level code takes 9 (in general) more time and debugging than 8 higher-level code. So if you need to be 7 going back to low-level all the time, then 6 perhaps something isn't right in the design. Even 5 for the embedded controls I've built, I 4 spend the vast majority of time in high-level 3 code. Although when you have issues, it is extremely 2 advantageous to have a very good low-level 1 knowledge.

I am an EE turned Software Engineer. I 36 prefer programming low level. Most software 35 developers classically trained that I know 34 do not want to operate at this level they 33 want apis to call. So for me it is a win 32 win, I create the low level driver and api 31 for them to use. There is a "new" degree, at 30 least new since I went to college, called 29 Computer Engineer. Hmm, it might be an 28 electrical engineering degree not computer 27 science, but it is a nice mix of software 26 and digital hardware basics. The individuals 25 that I have worked with from this field 24 are much more comfortable with low level.

If 23 the individual is not comfortable or willing 22 then place them somewhere where they are 21 comfortable. Let them do documentation 20 or work on the user interface. If all of 19 the work at the company requires low level 18 work then this individual needs to do it 17 or find another job. Dont sugar coat it.

I 16 also think they will enjoy it once they 15 get over the hump, the freedom you have 14 at that level, not hindered by operating 13 systems, etc. Recently I witnessed a few 12 co-workers experience for the first time 11 seeing their software run under simulation. Every 10 net within the processor and other on chip 9 peripherals. No you dont have a table on 8 a gui (debugger) showing the current state 7 of the memory, you have to look at the memory 6 bus, look for the address you are interested 5 in, look for a read or write signal and 4 the data bus. I worry about the day that 3 silicon arrives and they no longer have 2 this level of visibility. Will be like 1 an addict in detox.

Well, I cut my teeth on hardware when I 47 started reading Popular Electronics at age 46 14 – this was BEFORE personal computers, in 45 case you were wondering and if you weren’t 44 well, you know anyway. lol

I’ve done the 43 low level bit-bang stuff on the 8048/51 42 microprocessor, done PIC’s and some other 41 single chip variations and of course Rabbit 40 Semiconductor. (great if you're into C). That’s 39 great (and fun) stuff; Yes, there is a different 38 way of looking at things – not harder, but 37 some of that information is a bit harder 36 to come by as it isn’t as discussed as the 35 software issues. (Of course, this depends 34 on the circle of friends with which you 33 associate, eh).

But, having said all of 32 this, I want to remind you of a technology 31 that started to bridge the gap for programmers 30 into the world of hardware and has since 29 become a very MAJOR player and that is the 28 .NET micro framework. You can find information 27 on this technology at the following;

http://msdn.microsoft.com/en-us/embedded/bb267253.aspx

It 26 addresses some of the same issues that .NET 25 web development addressed in that you can 24 use some (quite a bit, actually) of your 23 existing PC based knowledge in the new environments 22 – Some caution, of course, as your target 21 machine doesn’t have 4 GIG of RAM – it may 20 only have 64K (or less)

Starting in version 19 2.5 of the .NET micro framework, you have 18 access to networking and web services – way 17 kewl, eh? It doesn’t stop there … Want 16 to control the lights in your house? How 15 about a temp recording station? All with 14 the skills you already have. Well, mostly 13 -- Check out the link.

The SDK plugs into 12 your VisualStudio IDE. There are a number 11 of “Development Kits” available for a very 10 reasonable amount of cash – Now, what would 9 normally take a big learning curve in components, building 8 a circuit board and wiring up “stuff” can 7 be done reasonably easy with a dev kit and 6 some pretty simple code – Of course, you 5 may need to do the occasional bit bang operation, but 4 more and more sensor folks are providing 3 .NET micro framework drivers – so, the hardware 2 development may be closer than you think…

Hope 1 it helps...

I like both. Embedded challenges me and 11 really gets me going in a visceral way. Making 10 something that affects the macro physical 9 world is very satisfactory. But I've had to 8 do a lot of catch up on the electrical/electronics 7 end, since my bachelor's is in computer 6 science. I've a pretty generalist background, where 5 I studied ai, graphics, compilers, natural 4 language, etc. Now I'm doing graduate work 3 in embedded systems. The really tough part 2 is adjusting to the lack of runtime facilities 1 like an operating system.

Low-level embedded programming also tends 8 to include low-level debugging. Which (in 7 my experience) usually involves (at least) the 6 use of an oscilloscope. Unless your colleague 5 is going to be happy spending at least some 4 of the time in physical contact with the 3 hardware and thinking in terms of microseconds 2 and volts, I'd be tempted to leave them 1 be.

Agreed on the "hard" term is quite relative.

I 6 would say different, as you would need to 5 employ different development patterns that 4 you won't use in other kind of environment. The 3 time constraint for instance could requires 2 a learning curve. However being curious, would 1 be a quality for a developer, wouldn't be?

You are right in that anyone with enough 17 knowledge not to feel completely lost in 16 an area (over the hump?) will enjoy the 15 challenges of learning something new.

I myself 14 would feel quite nervous being moving to 13 the level of instruction sets etc as there 12 is a huge amount of background knowledge 11 needed to feel comfortable in the environment.

It 10 may make a difference if you are able to 9 support the developer in learning how to 8 do this. Having someone there you can ask 7 and talk through issue with is a huge help 6 in that sort of domain change.

It may be 5 worth having the developer assigned to a 4 smaller project with others as a first step 3 and see how that goes. If he expresses enthusiasm 2 to try another project, things should flow 1 on from there.

I would say it is not any harder, it just 2 requires a different knowledge set, different 1 considerations.

I think that it depends on the way that 23 they program in their chosen environment, and 22 the type of embedded work that you're talking 21 about.

Working on an embedded linux platform, say, is 20 a far smaller jump than trying to write 19 code on an 8 bit platform with no operating 18 system at all.

If they are the type of person 17 that has an understanding of what is going 16 on underneath the api and environment that 15 they are used to, then it won't be too much 14 of a stretch to move into embedded development.

However, if 13 their world view stops at the high level 12 api that they've been using, and they have 11 no concept of anything beneath that, they 10 are going to have a really hard time.

As 9 a (very) general statement if they are comfortable 8 working on multithreaded applications they 7 will probably be ok, as that shares some 6 of the same issues of data volatility that 5 you have when working on embedded projects.

With 4 all of that said, I've seen more embedded 3 programmers successfully working in PC development 2 than I have the reverse. (of course I might 1 not have seen a fair cross section)

"But when I talk to him about doing low-level 5 programming, he simultaneously express interest 4 and also doubt/uncertainty about joining 3 the project." -- That means you let him 2 try and you prepare to hire someone else 1 in case he doesn't pass the learning curve.

i began as a SW engineer i'm now HW one 2 ! the important is to understand how it 1 works and to be motivated !