Possible Career Change

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I'm currently a software developer/architect (of 14 years) and am
considering a move into the embedded/real time programming arena. My
question is this...how much electronics experience is actual needed
for embedded programming (I have an electronics qualification...but
have never done any commercially)? If there is little electronic
requirements then what are companies expectations on
experience...would the fact that I can program in a lot of languages
(C, C++, java, vb etc) aid in getting my foot in the door or are
companies only interested in people who have programmed within an
embedded environment.

Thanks in Advance,
Dan

Re: Possible Career Change

Quoted text here. Click to load it


Most companies will want a very solid C programmer with good hardware skills
(reading schematics, can use an oscilloscope etc...)

Java and VB may be useful for PDA or cell phone development, but C and
assembly are still mainly used.

Jamie



Re: Possible Career Change
Hi,
I am in a similar situation as Dan except for the fact that I am just
finishing my MS in CS and trying to enter embdded systems field. My
question is are there areas of work where you would be given
specifications and you are required to do just programming part? I
mean without requiring to work with oscilloscope and waveforms.
Is it enough to know the architecture of a processor to do programming
using  C/C++?
How fierce is the competetion in this market as far as jobs go? Is it
a stable job market?
How does the future of embedded systems look with upcoming market of
cell phones and  Wi-Fi?
Is it wise to enter this field at entry level? what are things to be
considered?

I am sorry to ask too many questions. But these are unanswered
quetsions in my mind.
thankin you in anticipation.
Abhi


Quoted text here. Click to load it

Re: Possible Career Change
There certainly are jobs out there where the hardware is a known entity, either
because it's been in use already or is made from off-the-shelf boards/cards.
I've had contracts where the firmware was being upgraded with more software
features. You might be able to get started doing that.

I'd get some sort of hardware background though. When the project needs to add
or modify or move to new hardware, you'll be that much more valuable to
companies. Knowledge is a Good Thing.


Re: Possible Career Change

Quoted text here. Click to load it

Sure, maybe cellphone companies or PDA development but "just" programming
will really limit you in the embedded field... It makes sense to get some
hardware knowledge (at least know how to read a hardware schematic)...
Embedded software engineers in my experience work very closely with the
hardware engineers.  If you only want to code, you are not going to be very
helpful...

Quoted text here. Click to load it
Sure, until you run into a problem.... what are you going to do when a
someone tells you to check it on the scope...

Quoted text here. Click to load it
Fierce is a term used for the dot com bunch... IMHO is you get a job in the
embedded field it will be much stabler than other markets...

Quoted text here. Click to load it
Cellphones and Wi-Fi are not upcoming... they are here...

Quoted text here. Click to load it
I don't think that you will find an entry level position...

Quoted text here. Click to load it
Good luck, my only advice is not to be afraid to pick up some electronics
training...

I work with embedded systems for research instrumentation.  In my field the
timing of the system is everything... All measurement routines are initally
tested on a scope, if there are bottle necks we analize them and sometimes
do it smarter in assembly...  If we were hiring we would not be looking for
someone to only code...

Jamie



Re: Possible Career Change
Quoted text here. Click to load it

Yes, but they are not the bulk of embedded work.  At some
point, there will be bugs involving the HW/SW interface and
how the two affect the operation of the entire system, and
everyone will be in your office asking why it's broken.

Quoted text here. Click to load it

Yes, but for embedded work you will be interfacing with
other parts on the system board, and other boards in the
box, and other boxes; and these interfaces are rarely
all networked (so you can just use socket programming).

Quoted text here. Click to load it

I killed three guys today who wanted my job.

Quoted text here. Click to load it

Only a matter of time before we all move to Bangalore
to find $5/hr jobs doing exactly what we're doing now.

Quoted text here. Click to load it

Upcoming?  Those things have been part of the business
for years.

Quoted text here. Click to load it

Entry level is cheaper, so it's probably easier to get in.
Hiring managers often care less about qualifications than budget.

                --Blair
                  "Now I'm in a good mood."

Re: Possible Career Change

Quoted text here. Click to load it


haha :)  jokes.

Re: Possible Career Change
Quoted text here. Click to load it

Wishful thinking, that that were merely a light joke.

--
egr



Re: Possible Career Change
Quoted text here. Click to load it

While I suppose this is theoretically possible, I wouldn't give $0.02 for
the
reliability of the resulting software.

I have spent too much time, as a "hired gun", cleaning up messes created
when
embedded software was left to CS graduates, with no real understanding of
the
hardware.  I have seen the comment,  in code I reviewed,  "Don't touch
this--
changing anything breaks it, and I have no idea why!"  [1]

Needless to say, this was the very code I had to redesign, from the ground
up,
to resolve a major performance bottleneck in the target system. This
required
a detailed analysis  of instruction-to-bus timing relationships of the uC
(an
8051 derivative, running in "paged" mode),  and the timing requirements  of
a
rather finicky piece of display hardware.  The result was a software PLL
driv-
ing a uC timer, to ensure that transfers to the display device would occur
in
a very narrow timing window, without consuming too much CPU bandwidth.

The moral of the story is, if you can't understand the hardware, without an
en-
gineer holding your hand,  stay away from embedded systems--or at least,
away
from anything remotely like "bare-metal" programming.  Go play in a nice,
safe,
Java sandbox, where I (or someone like me) will not wind up cursing you,
while
cleaning up the mess you made!

Quoted text here. Click to load it

Emphatically NOT!  In fact, the processor architecture is often irrelevant,
by
comparison to the hardware constraints, except on those occasions when one
has
to connect to the outside world  via a microprocessor bus (instead of
discrete
I/O's).  In these cases, the bus protocols become important; but these are
not
a part of the programmer's model of the CPU architecture.

Moreover, it is necessary to know C/C++ well enough to predict what a
compiler
will generate, not in terms of specific instructions, so much as allocation
of
resources (stack/register/static storage, time/space tradeoffs, etc.). This
is
not generally covered in CS programs I have encountered.  It is also
necessary,
in some cases (C++, especially), to know *exactly* when and how dynamic
alloca-
tion occurs, and the impact of class inheritance on RAM requirements (since
it
is generally a scarce resource, in most microcontrollers).

Quoted text here. Click to load it

The competition seems to be very fierce, right now--at least in the USA.  I
am
presently searching for new work, myself; and the pace of responses to my
résu-
mé submissions is down considerably from a few years ago (when I could
general-
ly find a new post within a week or two,  through one of a handful of
contract
shops).

Quoted text here. Click to load it

Sorry to be a "wet blanket";  but I believe that to encourage anyone
unwilling
to look at a waveform on a 'scope to pursue a career in embedded systems
would
be both foolish and unethical.

YMMV. Others will have their own opinions. HTH. HAND.

-----

[1] If I ever see it again, I will have to hunt down its author, and
personal-
    ly strangle him or her with my very own, two, bare hands. Call me a
BEEFH,
    if you like, but that's the way I feel about it.  }>-{>

--
egr



Re: Possible Career Change
Quoted text here. Click to load it

Sorry about the bad breaks!  Didn't use the right "ruler" as I was com-
posing, and my user agent neither breaks on-screen as I write, nor lets
me post a replacement message. (Leave it to $WEBORGMAKEPCSOFTWARE to ig-
nore MANKSA, let alone GNKSA "standards", completely.)

Quoted text here. Click to load it

While I suppose this is theoretically possible, I wouldn't give $0.02
for the reliability of the resulting software.

I have spent too much time, as a "hired gun", cleaning up messes creat-
ed when embedded software was left to CS graduates, with no real under-
standing of the hardware. I have seen the comment, in code I reviewed,
"Don't touch this--changing anything breaks it, and I have no idea why!"
[1]

Needless to say, this was the very code I had to redesign, from the
ground up, to resolve a major performance bottleneck in the target
system. This required a detailed analysis  of instruction-to-bus timing
relationships of the uC (an 8051 derivative, running in "paged" mode),
and the timing requirements  of a rather finicky piece of display hard-
ware.  The result was a software PLL driving a uC timer, to ensure that
transfers to the display device would occur in a very narrow timing win-
dow, without consuming too much CPU bandwidth.

The moral of the story is, if you can't understand the hardware without
an engineer holding your hand,  stay away from embedded systems--or at
least, away from anything remotely like "bare-metal" programming.  Go
play in a nice, safe, Java sandbox, where I (or someone like me) will
not wind up cursing you, while cleaning up the mess you made!

Quoted text here. Click to load it

Emphatically NOT!  In fact, the processor architecture is often irrele-
vant, by comparison to the hardware constraints, except on those occa-
sions when one has to connect to the outside world via a microprocessor
bus (instead of discrete I/O's).  In these cases, the bus protocols be-
come important; but these are not a part of the programmer's model of
the CPU architecture.

Moreover, it is necessary to know C/C++ well enough to predict what a
compiler will generate, not in terms of specific instructions, so much
as allocation of resources (stack/register/static storage, time/space
tradeoffs, etc.). This is not generally covered in CS programs I have
encountered.  It is also necessary, in some cases (C++, especially), to
know *exactly* when and how dynamic allocation occurs, and the impact
of class inheritance on RAM requirements (generally a scarce resource,
in most microcontrollers).

Quoted text here. Click to load it

The competition seems to be very fierce, right now--at least in the USA.
I am presently searching for work, myself; and the pace of responses to
my résumé submissions is down considerably from a few years ago (when I
could generally find a new post within a week or two,  through one of a
handful of contract shops).

Quoted text here. Click to load it

Sorry to be a "wet blanket";  but I believe that to encourage anyone un-
willing to look at a waveform on a scope to pursue a career in embedded
systems would be both foolish and unethical.

YMMV. Others will have their own opinions. HTH. HAND.

-----

[1] If I ever see it again, I will have to hunt down its author, and
    personally strangle him or her with my very own, two, bare hands.

    Call me a BEEFH, if you like, but that's the way I feel about it.

    }>-{>

--
egr



Re: Possible Career Change
I am a computer science graduate and new to embedded system. I want to know
more about allocation of resources by compiler (as you mentioned) and memory
management in embedded system. Is there any good web site?

Manda

:3f2a1e8f_4@newsfeed...

Quoted text here. Click to load it
irrelevant,
allocation
This
(since
Quoted text here. Click to load it




Re: Possible Career Change
I don't know if there are any good websites on the topic, in general;
but looking over a few microcontroller databooks might be helpful, for
giving an idea of the range of memory constraints.

For uC's with onboard code and data store, it is not uncommon to be
limited to 64-512 bytes (on machines with 8-bit data paths) RAM, and
16-48kB ROM. I have seen uC's with 4-bit data paths, and a mere 16
digits of RAM--the code store was something like 128, 13-bit words
deep. (As is commonly said, "I have slept since then".)

Dynamic allocation is generally avoided, if possible, because many (if
not most) embedded applications have hard realtime requirements, and
dynamic allocation algorithms tend to be nondeterministic (although a
few are at least well-bounded). Moreover, dynamic allocation can fail,
and to stop the systems and scream "Oh, my $DEITY, something is wrong!"
is not an option.

In any case, I don't encourage CS grads to pursue embedded work, un-
less they also have electronics experience, of some kind--not merely
enough to read a schematic, but enough to be comfortable with only an
oscilloscope or logic analyzer for debug tools; and enough to be able
to recommend *specific* hardware changes to simplify software or to
improve the ability to detect system faults.

--
egr

We've slightly trimmed the long signature. Click to see the full one.
Re: Possible Career Change

Disclaimer. I'm talking here from personal experience of candidates I've
interviewed for jobs working on embedded systems (RTOS, networking) products
largely in the automotive sector. Our working environment is almost
entirely C with some target-specific assembly on target systems and C++
on Win32 and Posix systems for offline tools and middleware.

Quoted text here. Click to load it

It varies, but certainly an appreciation of things like how clocks are
generated, properties of things like PLLs, some knowledge of things like
debouncing, sampling, etc. would always be beneficial. The ability to
read and understand a circuit diagram and a datasheet for a mixed-signal
or analogue part is useful.

Quoted text here. Click to load it

In general, the more languages I see the less I'm impressed by a
lot of candidates - often looks like CV inflation. From my point
of view, VB might *very* occasionally be marginally useful for quick
hosted hacks.  Java....  feh. Cuts very little ice in my neck of
the woods. Our experience of Java programmers is that they've been too
shielded from 'the machine' to understand what's going on under the hood.  
We have historically looked for evidence of (or obvious potential for)
Ultra-strong C, enough C++ do to offline tools work, and exposure
to a couple of assembly languages on different processor families.

A good grasp of discrete mathematics helps too - certainly an
appreciation of recurrence relations, set theory, propositional logic,
and Boolean algebra.

Your architecture skills could be interesting to some employers,
particularly if you can offer good UML and CASE experience.

Quoted text here. Click to load it

It varies. Some candidates have impressed us so much that they've been
offered positions based on obvious intellect and ability to pick things
up quickly (one of our best embedded guys came from a formal methods/HCI
background), but they're exceptional and in general for embedded
roles we've looked for people who could demonstrate convincing
experience and had the right attitude.

pete
--
snipped-for-privacy@fenelon.com "there's no room for enigmas in built-up areas" HMHB


Re: Possible Career Change
dans snipped-for-privacy@hotmail.com (Dan) wrote in message

Quoted text here. Click to load it

If your experience is mainly in HLLs and "ultra-HLLs" like VB and
Java, you might find it most profitable to explore opportunities with
extremely complex user interfaces; cellphones, POS terminals,
multimedia kiosks, etc. Of course, it is up to you to decide just how
different this job is from what you're doing already.

Embedded systems span everything from bit-banging in a 4-bit
microcontroller with six nibbles of RAM up to all-singing-all-dancing
systems running Linux or Windows - so there is definitely a place for
someone with your skillset, it's just a question of focusing on the
appropriate opportunities. You're not very likely to land a job
writing cycle-exact machine control applications in an 8051 with the
background you described; it's possible, but not likely.

Re: Possible Career Change
Hi All,

Your input has really overwhelmed me and I am thinking of putting it
together and making a document out of it. So that I can think over it
and post it for any other neophyte looking for information.
Thank you very much for all this information.

Abhi


Quoted text here. Click to load it

Re: Possible Career Change
dans snipped-for-privacy@hotmail.com (Dan) wrote in message
Quoted text here. Click to load it

You could visit some trade shows like the embedded conference boston
or whatever city its in (if your in the US), I usually get free exibit
invites. There may well be others, see also the Xilinx fpga shows
which bring in alot of interesting developers a bit more on the
computing performance side. Its a way to get face to face with
engineers and see if you can find common interest, or feel for whats
out there.

But HW/rtOS/asm/real_math knowhow is definitely valuable, hide the
VB/Java under "others". Cpus that are on the up n up are ARM ofcourse,
MIPS, PPC and even x86. But any knowledge of one is transferable to
others. Also note that cpus can also be soft cores and embedded in
FPGAs at will or hardcore embedded like ARM/Altera or PPC/Xilinx. Also
you can get entry level boards to learn more about cpus or fpga or
both for very little ($100+), and the fpga tools can be free. But that
India/China thing I wouldn't worry about yet even though its taking a
toll.

Re: Possible Career Change
Thanks for all the feedback...it's certainly given me something to think about.

Regards,
Dan

Site Timeline