Exact match. Not showing close matches.
'[PIC]Levels of proficiency in embedded engineering'
|I am currently seeking a position as an embedded engineer. A job
location in the Twin Cities region is greatly preferred. (One
advantage is that it's nearby. Another advantage is that I can
continue participating in Project Phoenix, an IEEE study group working
on an open source blood pressure monitor.)
I'd like to hear your suggestions on what else I need to learn in
embedded engineering in order to be a truly outstanding embedded
engineer. Engineering job ads (any discipline/specialty) always
equate proficiency with "years of experience". As you know, the
relationship is clearly not 1:1, and I know better than to assume that
having 3, 5, 7, or 10+ years of embedded engineering work experience
will automatically make me proficient enough to do embedded
engineering blindfolded. I want to be the person with 3 years of
experience who is just as proficient as others with 5 years of
experience, not the other way around.
So far, I have picked up on embedded engineering on my own, with the
aid of excellent microcontroller communities like this one. I thank
everyone who helped me through the various obstacles I ran into, and I
can't imagine how anyone got up to speed on embedded engineering
before there were great online communities like this one.
I understand that I have just barely scratched the surface of the
embedded engineering world. I know I need to learn more, as this will
make me more productive on the job and give me more material to talk
about in elevator speeches, cover letters, resumes, and job
Some highlights of what I've done so far are:
1. All of the basic stuff in the introductory exercises (simulating,
A/D converters, I/O pins, the open drain I/O pin, disabling LVP so
that the normal I/O function works for that pin) with the PICSTART
Plus programmer, PLUS the things needed for my SWR/wattmeter project
2. Both Assembly language (through MPLAB) and C (through PICC in MPLAB)
3. Using MPLAB in Windows XP and in antiX Linux through WINE
4. PIC16F84, PIC16F72, and PIC16F872
5. Unsuccessfully trying to use open source software to program
microcontrollers in Linux: I consider the open source software route
(GPSIM, Piklab, etc.) to be in a pre-alpha stage. I ended up running
MPLAB through WINE. This setup works in antiX Linux but not in Puppy
Linux. (I did notice that antiX Linux has a newer version of WINE in
What other embedded engineering skills do I need to learn? Until I'm
in a situation where something else has already been chosen or a PIC
is not viable, I intend to stick with PIC simply because that's all I
know. (From what I've heard, someone who knows PIC shouldn't take
that long to get up to speed on AVR, Atmel, etc.) Some things I'm
aware that I haven't done yet are:
1. ICSP: So far, I have only used the PICSTART Plus, which requires
moving the microcontroller back and forth. I know that this isn't an
option for surface mount microcontrollers, and an ICSP setup that
allows a connection directly to the target circuit is necessary.
2. I2C, SPI, UART, etc.: Most of the ads for embedded engineering
positions mention these standards.
What else should I learn?
|On 2/24/2010 8:09 PM, Jason Hsu wrote:
> I am currently seeking a position as an embedded engineer.
> So far, I have picked up on embedded engineering on my own, with the
> aid of excellent microcontroller communities like this one. I thank
> everyone who helped me through the various obstacles I ran into, and I
> can't imagine how anyone got up to speed on embedded engineering
> before there were great online communities like this one.
The internet: stay tuned, kids; it keeps getting better!
> I understand that I have just barely scratched the surface of the
> embedded engineering world. I know I need to learn more, as this will
> make me more productive on the job and give me more material to talk
> about in elevator speeches, cover letters, resumes, and job
Now you are ahead of 50% of your competition; you acknowledge that you
are a beginner but are striving to learn. Two thumbs up!
All those topics you mention can be learned project by project. ICSP?
Very important and easy to do. Look through the piclist archives and
Microchips forums (fora?) and then try it out. It's easier than it
looks. Olin has some good info on this topic as do many others.
By the way, when I said above 'project by project', I meant just that.
Think of some project, even if it is only flashing an LED. Build that
with ICSP and you will soon learn what is involved there. Document it;
print out schematics and take photos of your work to show prospective
This is something most other liberal arts majors do that engineers (or
prospective engineers) should do: BUILD A PORTFOLIO! Show what you have
done. If I was just out of school and applying for a position, I would
have the equivalent of three senior projects written up with 8 x 10
color glossy photos with circles and arrows and a paragraph on the back
of each one PLUS at least one of the projects in my briefcase to show
off. That sure beats a typed resume the other 199 applicants will show
up with. Where they come up with nothing but buzz words, you can show
"Yeah, this was a simple project with an LCD, a keypad and a sensor.
Here's what it looks like..." yada yada yada. Hiring engineers will
want to see what you have done and having some actual hardware will make
you look credible.
Finally: NEVER STOP. Keep doing projects. When you get hired, you will
slowly sink into the mud if you don't keep up. And the best way to keep
up is building more projects.
|If I'm interviewing someone (I only do the engineering specific part of
the interview, not the psychological part), I don't typically ask about
how long it took them to do a project, I want to know what the projects
were that they've done. Experience really comes from finishing
something and working out all the details necessary to call it done -
it's not just a collection of specific abilities. To that end, I'd
suggest that in addition to some evidence of experience on a resume'
what you need to have under your belt is several working projects
(preferably ones that have gone into some kind of production) that you
could talk about (favorite interviewer question is what was your biggest
problem and how did you solve it?) or organize into a portfolio. Even
better is to have someone in the industry recommend you based on a
project that you did (your positive opinion of yourself is good - a
disinterested third parties' positive opinion of you is golden).
Personally, I think the blood pressure monitor project is something you
should highlight because it shows a genuine desire to work - not just to
get occupy a cubicle and collect a paycheck. You've got to love this
stuff to struggle through the tough parts and do it right - convey that,
and you'll get offers.
Jason Hsu wrote:
In addition to what Tony said, I'd recommend a bit of diversity in
targets. Not just PICs but Atmel, ARM and possibly some DSP type
Also a range of hardware applications - digital, analogue and radio or
But having a portfolio of existing, working projects would be top of the list.
On 25 February 2010 17:11, Tony Vandiver <traceelectronics.com> wrote: tony
Wouter van Ooijen
> What other embedded engineering skills do I need to learn?
IMO embedded engineering is often about measuring and controlling the
outside world (outside the chip, often outside the electronics). So
things that are a plus are such things that your company deals with,
which for instance can be:
- general electronics, HF/wireless, switching, power electronics, sensors
- mathematics, statistics, logic, control theory
- physics, kinematics, robotics
- basic chemistry
- all other kinds of phyiscal/real-world things, from music to economy
When I did job interviews (technical aspects only) I generally tried to
get the guy (no gals seen) to talk about what he had done. I tried to
ask not just in which projects he had worked but also what his specific
When lost for a subject I asked things like
- what achievement are you most proud of?
- what have you learned compared to your first year as a professional?
- we have this-and-this problem, your comments please?
- read this piece of code (2 minutes), then some questions (the code was
very short but quite complicated due to callback/reentrancy problems)
Wouter van Ooijen
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
On Thu, Feb 25, 2010 at 12:09 PM, Jason Hsu <gmail.com> wrote: jhsu802701
> I am currently seeking a position as an embedded engineer.
More information will help. And the following may be very blunt
but it is just my personal opinion. So hopefully you will not get
Why? What is your background? Did you have an engineering
related diploma or better degree? Have you worked as an electronics
The age may play a big part as well. If you are still young, then
you will get better chances since people may give you time to
> So far, I have picked up on embedded engineering on my own,
> with the aid of excellent microcontroller communities like this one.
I think this may make it difficult for you to be employed as
an embedded (firmware) engineer. I think you may have some
good background in analog electronics, so maybe an electronics
design engineer job (mainly hardware, maybe some simple firmware)
might be more suitable.
I have done a few PIC firmware designs, using C and ASM, with several
hundred thousands of product running in the field (industrial automation).
I am familiar with Microchip PICs and tools related to PIC. But I think I am
not qualified as an embedded engineer...
On Wed, Feb 24, 2010 at 11:09 PM, Jason Hsu <gmail.com> wrote: jhsu802701
> I'd like to hear your suggestions on what else I need to learn in
> embedded engineering in order to be a truly outstanding embedded
One thing I haven't seen in resumes and "help wanted" ads, but is
very important in doing embedded software, is the ability to read,
understand, and improve on old, existing code.
Unfortunately, doing new code "from scratch" is not very common. Instead,
you will be doing maintenance on old code, and converting old code to
new platforms (chips going obsolete and such, so the hardware is redesigned).
New projects will often start with code for an existing project and add a bunch
Except for the very smallest projects, I've found that companies prefer to
use C for software instead of assembly. It's easier to find a C programmer
than an assembly programmer.
Also, I've moved several significant pieces of software (~60,000 lines of
C code per project) from one microcontroller and support hardware to a
different microcontroller and support hardware (for example, 68HC11 and
"homebrew" dual slope ADC converter to ATMega2561 and real ADC
converter chip, or 8051 variant to ATMega 644 -- our EE likes the Atmel
chips). That's not going to happen when the code is written in assembly.
Psst... Hey, you... Buddy... Want a kitten? straycatblues.petfinder.org
Jason Hsu wrote:
> What else should I learn?
You've had some great comments, but I think fundamentally the answer to your
question is another question: where does your heart lie? In other words,
what do *you* like to do? What is it about embedded engineering that appeals
most to you?
People learn best by doing. Have you tried getting an internship at a
company whose projects you want to be a part of? Look at their job
descriptions, find one that sounds the best to you, and focus on the areas
of expertise that the job calls for. Tailor your resume to fit the job
description for the best chance to get hired.
Money is important, but job satisfaction is at least as important. Doing
what you enjoy is often worth a pay cut.
PS While many say the economy is improving, I see things that lead me to
believe that we have not seen the worst yet and the recovery we are seeing,
is artificial. Typically during a recession you are better off on your own,
i.e. not working as an employee, but either running your own company or
working as a consultant. Most companies follow the policy "last one hired,
first one to go."
More... (looser matching)
- Last day of these posts
- In 2010
, 2011 only
- New search...