Post by thread:[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 interviews. 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 its repository.) 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? -- Jason Hsu http://www.jasonhsu.com/swrwatt.html http://www.jasonhsu.com/swrwatt-c.txt http://www.jasonhsu.com/swrwatt-asm.txt

On 2/24/2010 8:09 PM, Jason Hsu wrote: > I am currently seeking a position as an embedded engineer. Excellent! > 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 > interviews. Now you are ahead of 50% of your competition; you acknowledge that you are a beginner but are striving to learn. Two thumbs up! {Quote hidden}> 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 > its repository.) > > 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? > 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 employers. 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. Good luck!

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. Good Luck, Tony Jason Hsu wrote: {Quote hidden}> 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 > interviews. > > 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 > its repository.) > > 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? > >

Jason, 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 chips. Also a range of hardware applications - digital, analogue and radio or other comms. But having a portfolio of existing, working projects would be top of the list. RP On 25 February 2010 17:11, Tony Vandiver <spam_OUTtonyTakeThisOuTtraceelectronics.com> wrote: {Quote hidden}> 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. > > Good Luck, > > Tony > > > Jason Hsu wrote: >> 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 >> interviews. >> >> 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 >> its repository.) >> >> 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? >> >> >

> 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 contribution was. 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 <.....jhsu802701KILLspam@spam@gmail.com> wrote: > 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 upset. Why? What is your background? Did you have an engineering related diploma or better degree? Have you worked as an electronics engineer before? 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 learn. > So far, I have picked up on embedded engineering on my own, > with the aid of excellent microcontroller communities like this one. > http://www.jasonhsu.com/swrwatt.html 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... -- Xiaofan http://mcuee.blogspot.com

On Wed, Feb 24, 2010 at 11:09 PM, Jason Hsu <jhsu802701KILLspamgmail.com> wrote: > 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. 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 of modifications. 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. Good Luck! Bill -- 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. Vitaliy 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."