Graduating soon! Embedded career?

[aurmer]

I will be graduating at the end of the fall. My degree program is not common; it focused on telecommunications protocols, control systems, and embedded design.

I love embedded C, and I would like to pursue a career in embedded design. I have mostly worked with PICs with limited experience in ARM and even FPGA-style. All of my peers in technical fields have given me advice, but I now turn to the EEVblog community.

- What books should I read before interviewing for an entry level design position?
- What architectures/controller brands should I tinker with in my spare time?
- What specialties exist in this field? Are there any specialties on the rise (growing market demand)?

EDIT:
- What questions should I be asking that I don't know to ask? =)

[JPortici]

I'm *finally* working on this field and the only advice i can give you is bring some of your projects to the interview. In my experience an employer is interested in what you can already do and that you can actually do shit. there is a world of difference in "i have no previous working experience/this will be my forst job" than "i'm just out of school but i have done this this and that."

At my last interview i brought one of my pcbs and we stayed a couple of hours chatting, discussing what i was doing what they were doing and so on. Didn't even take a look at the CV. Needless to say it was my last interview because i'm working there

[aurmer]

Thanks, this advice seems universal. I need to demonstrate value to a prospective employer. Do you have any thoughts on what "common/frequently seen skills" I should be able to competently discuss?

[rstofer]

Embedded...  Well, you certainly need to be up to speed on C.  Were I an employer, I wouldn't even discuss Python, Java or C++ if I was looking for an embedded programmer.  It's done in C.  Maybe a touch of ASM.  Review the startup code for some of the ARM processors.  There's usually a hundred lines or so of ASM.

ARM!  Everything is headed toward ARM processors.  You should understand the various incantations of ARM devices from the single core jelly-bean chips up to the top of the line.

Got real talent?  Bring up Linux on a prototype board.  Sure, it will already be done for that board but get one of the "Bring Up Linux On Raw Iron" books and work it through.  Leave the device drivers to someone else.  Just get it up to a console level device.  You will probably need to understand U-Boot.

Want a more interesting project?  Get the source listings for Unix V6 and bring it up on an ARM with a memory management unit.  It should be pretty easy and the book is readily available:

http://v6.cuzuco.com/v6.pdf

I would hope you could find a way to OCR the listings.

I think the Linux port is better understood and probably more relevant.

Bring your board and all your code listings.  Make sure you bring a tablet with a terminal emulator so you can demonstrate the thing.

Good luck!

[dannyf]

"What questions should I be asking that I don't know to ask? =)"

The answer obviously depends on what's important to you. If coding to a pic or a mcu is important to you, by all means do it.

I would argue that most of the money that embedded programmers are making are being made by thee cell phone app people. It is far easier to get people to see value thus pay bug money for something they can see and use.

With that said, I would suggest that you start to learn about the arm processors, especially the higher end ones. Thee opportunities in the 8 bit market will continue to shrink and drift towards lower and lower end, making opportunities in the Western countries harder and harder to find and pays lower and lower.

In you want a book, I would suggest internal training manuals from large corporations - you can find them on the net - or industry guidance like misra. They will help you understand the difference between writing a product, and hacking some code together.

Hope it helps.

[uncle_bob]

"What questions should I be asking that I don't know to ask? =)"

The answer obviously depends on what's important to you. If coding to a pic or a mcu is important to you, by all means do it.

I would argue that most of the money that embedded programmers are making are being made by thee cell phone app people. It is far easier to get people to see value thus pay bug money for something they can see and use.

With that said, I would suggest that you start to learn about the arm processors, especially the higher end ones. Thee opportunities in the 8 bit market will continue to shrink and drift towards lower and lower end, making opportunities in the Western countries harder and harder to find and pays lower and lower.

In you want a book, I would suggest internal training manuals from large corporations - you can find them on the net - or industry guidance like misra. They will help you understand the difference between writing a product, and hacking some code together.

Hope it helps.

Hi

Spend some time thinking about where you want to work, what industry you want to work in, and what sort of products you will be working on. These sort of things pretty quickly lead to interesting tidbits like "how much do you make" and "how much does it cost to live there". Making a mid range salary in a high cost area can be tiresome. Making the same salary in a low cost area can be a lot of fun. Working for the only company within 500 miles that does "your stuff" is not quite the same as working for one of ten companies doing the same thing in the same town. Living in the middle of the desert is not so great if you really need to go fishing at least two or three times a week.

Yes, some of that is a bit over done. I don't know enough about you to make it more specific. Sorry about that. Once you have an industry to focus on, learn what they make. Learn what it does. Learn what they do in the market that makes them unique. Work all that out *before* the interview.

Bob

[Sal Ammoniac]

Definitely concentrate on C. The majority of work in the embedded field is done in C. The rest is done in assembly, C++, ADA, and a few other more obscure languages not worth bothering with.

The industry is moving to the ARM architectures. I suggest studying the Cortex-M, Cortex-R, and Cortex-A architectures. You can download the architecture manuals from the ARM website.

I'd also recommend these books:

http://www.amazon.com/Definitive-Guide-Cortex%C2%AE-M3-Cortex%C2%AE-M4-Processors/dp/0124080820?ie=UTF8&keywords=arm%20cortex%20m4&qid=1465434399&ref_=sr_1_2&s=books&sr=1-2

http://www.amazon.com/Better-Embedded-System-Software/dp/0984449000?ie=UTF8&keywords=better%20embedded%20software&qid=1465434481&ref_=sr_1_1&sr=8-1

[uncle_bob]

Hi

For < $20 most of the players in the ARM business will sell you a demo board with all the "stuff" to make it work. For $40 or so you can get a pretty fancy gizmo. Pick on e and do a project on it. I would *hope* you have done this already in school. If not, then most definitely get one of these boards and get it up and running. Even if all you do is work through their demo code, that's going to teach you a lot of the answers to "practical" questions. You *might* get luck and pick a board from their favorite vendor. Even if you don't the principles are all pretty similar between brands.

Bob

[Sal Ammoniac]

Another tip: when you get an interview with a company for an embedded position, try to find out what microcontroller they use in their products. Sometimes you can find this on their web site. Sometimes you can search Google for a teardown of their products and find out that way. Then download the datasheet and user's manual from the MCU vendor and study it prior to the interview.

[uncle_bob]

Another tip: when you get an interview with a company for an embedded position, try to find out what microcontroller they use in their products. Sometimes you can find this on their web site. Sometimes you can search Google for a teardown of their products and find out that way. Then download the datasheet and user's manual from the MCU vendor and study it prior to the interview.

Hi

If you did that with our products (and could *see* anything in our crap pictures), you would latch on to one of at least three MCU families.  None of them were the hot topic for the most recent firmware guy we hired

Sometimes you can over plan / over think this stuff. It's still a very good thing to do. Just don't count on your research always being right. Be ready to switch gears quickly.

Bob

[tggzzz]

Some observations:

• today's specific processors will be obsolete in 5 years => demonstrate you know how to learn, and you'll be employable in 5 years
• if an employer requires experience in Frobniz 3 + Splurdle 2.6, then they are specifying they want a technician that can press buttons => guess what happens in 5 years time
• choose a doable project, then do it, then tell them what you would do better next time => demonstrated initiative, judgement, skill, perseverence, learning => "he'll do that for me too"
• demonstrate you know the fundamental theory and its practical consequences => useful and necessary for engineering design for the next 50 years

Examples of fundamental theory include semaphores, Leslie Lamport's distributed work (see wackypedia), and similar

[coppice]

Embedded...  Well, you certainly need to be up to speed on C.  Were I an employer, I wouldn't even discuss Python, Java or C++ if I was looking for an embedded programmer.  It's done in C.  Maybe a touch of ASM.  Review the startup code for some of the ARM processors.  There's usually a hundred lines or so of ASM.

Embedded covers a wide range, from 1k flash MCUs to substantial Linux or Windows systems. What you said is very much true of small MCUs. Its less true of larger embedded systems.

ARM!  Everything is headed toward ARM processors.  You should understand the various incantations of ARM devices from the single core jelly-bean chips up to the top of the line.

A huge number of employers are now so ARM focussed they won't be looking for experience of any other processor on your CV. Its getting silly, as its not the core which differentiates most MCUs. Its the peripherals. If you program in C, and don't use a really crude core like an 8051, C code ports with trivial changes.... until you get to the peripheral control. Then porting gets as hard going from ARM to ARM as from ARM to/from anything else.

That said, look around at a few ranges of devices, ARM or otherwise. You can't say much about why you would choose A over B, if you know nothing about solutions other than A.
[/quote]

[AndyC_772]

If you already have some FPGA experience, I'd say build on that if you can.

Absolutely anyone in this business can pick up a small microcontroller and make it do stuff. It's a commodity skill, and anyone else applying for the same job as you will be able to do it too.

If you're confident programming FPGAs, though, then that will mark you out as having a special, worthwhile skill. Have a read around the forum; there are precious few FPGA threads, and those there are tend to be from people just starting out, learning the languages, and struggling to figure out how to make them tick. There's little (if any) more advanced discussion, and few people who are able to confidently answer questions about them.

For about the last 15 years or so, I've been designing products that combine a general purpose processor of some kind, with a programmable device. The CPU runs the application code, and the FPGA or CPLD does the thing that's interesting, unique, and really hard to do any other way. Whether it's implementing an unusual serial protocol, supporting a great many channels of <insert interface type here>, or driving external circuits in a complex but time critical way, the FPGA is the part which makes it possible.

Be the person who brings FPGA know-how into a company, and you'll be a valuable asset.

[coppice]

If you already have some FPGA experience, I'd say build on that if you can.

Absolutely anyone in this business can pick up a small microcontroller and make it do stuff. It's a commodity skill, and anyone else applying for the same job as you will be able to do it too.

Being able to write a program for an MCU, or develop for an FPGA, is in a similar category to being able to read and write. Its not usually why someone employs you, but its a necessary skill to have. People mostly employ engineers who have some understanding of their application. If you work on large projects you can get so lost in the implementation that churning out code - whether that code defines software or hardware - can be the only skill you really need. Most projects aren't that big. Its relevant applications knowledge that will differentiate you, or consign your CV to the waste bin.

The number of people who can write C or VHDL/Verilog from a detailed requirement spec is in the millions. Most of them are probably in a country with lower pay than yours.

The number of people who can break down a problem from first base, and arrive at a detailed requirement spec, for the relevant application, is not usually that big. They often need to be where the problem lies, and not just in the cheapest possible location. Most of these people can turn that spec into usable code, if its not too big and there's nobody cheaper available to do it. These are valuable people.

[Sal Ammoniac]

Absolutely anyone in this business can pick up a small microcontroller and make it do stuff. It's a commodity skill, and anyone else applying for the same job as you will be able to do it too.

You would think so, wouldn't you? I've interviewed several people recently who couldn't. One of these guys didn't even know what a pull-up resistor was and when/why it's used.

[CM800]

Absolutely anyone in this business can pick up a small microcontroller and make it do stuff. It's a commodity skill, and anyone else applying for the same job as you will be able to do it too.

You would think so, wouldn't you? I've interviewed several people recently who couldn't. One of these guys didn't even know what a pull-up resistor was and when/why it's used.

shoot me? 

[jnz]

Frobniz 3 + Splurdle 2.6[/

Best part of this thread!

Really though; there is some good stuff here. I agree STM32 to Nordic to NXP can all be ARM and be just as compicated in worst case as PIC to ARM best case - however - do learn ARM because the tools, the core peripheral's like the NVIC and power management, all pretty common.

As to the FPGA... Some of you guys are wildly smart and get FPGA with no issue - but for me being self-taught and no time to devote to it, if we ever need an FPGA we'll be hiring someone for that. I have to agree that C people are a dime a dozen, but verilog is a specific advantage.

I'll be hiring someone in the nearish future for embedded... I would give someone with FPGA experience a few points, even though it's unlikely my industry/applications would make use programmable gates.

If FPGA isn't your thing.... Understanding the IoT techs like IPv6 and BLE would get you a job with me right away. If I was looking for a job right now, I'd have Nordic nRf52 and Ti2650 dev kits in front of me.

[AndyC_772]

The number of people who can write C or VHDL/Verilog from a detailed requirement spec is in the millions. Most of them are probably in a country with lower pay than yours.

That's something I might have been inclined to believe, were it not for the fact that writing code for MCUs and FPGAs is a major part of how I make a living.

I've found low cost, overseas development to be either completely irrelevant, or a good source of income for me when I get to redo it properly. 'Buy cheap, buy twice' applies to R&D as much as it does to domestic appliances.

It helps if you're working on products that are in some way unique or specialised, because that's where the best margins are. Besides, who really wants to work on the next 'me too' product that's IoT / wearable / 'smart', or which ticks some other fashionable must-have box of the week? Not me, that's for sure. Take your GPS enabled, data logging, cloud connected nostril hair trimmer and shove it.

Most of these people can turn that spec into usable code, if its not too big and there's nobody cheaper available to do it. These are valuable people.

Agreed - but I think being capable of doing the implementation is a pre-requisite for writing a good spec, though. Start by learning the technical skills, enjoy using them, then write specs for others to follow... safe in the knowledge that what you're requiring people to do is actually technically sound.

Absolutely anyone in this business can pick up a small microcontroller and make it do stuff. It's a commodity skill, and anyone else applying for the same job as you will be able to do it too.

You would think so, wouldn't you? I've interviewed several people recently who couldn't. One of these guys didn't even know what a pull-up resistor was and when/why it's used.

I wish I were more surprised than I am, but I've had much the same experience myself.

Let me rephrase my statement; absolutely anyone who might actually get the job you're applying for can pick up a small microcontroller and make it do stuff.

[Jeroen3]

- What books should I read before interviewing for an entry level design position?

- What architectures/controller brands should I tinker with in my spare time?

Definitely get around to know ARM Cortex. But you will be asked to service update an existing product based on a 8051.
Maybe even automotive architectures if you're into that.

- What specialties exist in this field? Are there any specialties on the rise (growing market demand)?

"IoT" or scada security specialist will be requested in a few years I guess. The current open-source embedded tcp/ip stacks are (to keep it short) not very well made.

- What questions should I be asking that I don't know to ask? =)

Ask how their toolchain is set up, and what version control is used.
Do they use Windows or Linux. Gcc or proprietary compilers. This is a shows how much value management sees in software development. And how professional they are. If they don't use version control, try some more companies.

[tggzzz]

- What questions should I be asking that I don't know to ask? =)

Who will I be working with and for? Make sure you meet them in their working environment.
How does a typical project go? Initial lead, specification/requirements, delivery/acceptance, repeat business. Project management techniques.
How is new equipment purchased? Who specifies, and budget breakpoints.
Is travel possible/mandated?
When can you take holidays?
What happens if you work extra hours to meet a deadline?
What different things might I be able to do in 2 and 5 years time.

Above all, get several interviews. You will not do yourself justice in the first 3 or 4 interviews, and you will see different corporate styles.

[uncle_bob]

Hi

Consider the size of the company you are looking at / looking for:

A big company (thousands of engineers) will likely have all the T's crossed and all the i's dotted. They will be quite good at interviewing and likely will be easy to find. The company likely has tens of thousands of employees.

A very small company (a dozen engineers) will likely have some gaps here and there. They likely are not interview pro's. They may be a bit hard to track down. The company may have less than 100 employees. Everybody knows everybody else.

Once upon a time, big companies gave job stability and a clear path to the future. Small companies came and went. At least in my life, small companies have given me a *lot* more exposure to whole process of making a product work. They also have been much better at taking care of those who can fill the gaps they inevitably have. Larger companies have tended to be a bit more rigid in what they let you do / encourage you to learn. They also seem to come and go almost as fast as small companies (we've merged with XXX/ split from YYY/ exited the market for ZZZ / reorganized ( = moved to another country) / outsourced ....).

Bob

[rstofer]

That interview video was an hour worth spending.  I am slightly older than either of them but traveled much of the same ground.  I was in grad school when the 8080 was selling for $300+ and the Altair 8800 computer cost just about the same (I still have mine).  It's been an interesting ride over the last 40 years or so.

[aurmer]

Absolutely anyone in this business can pick up a small microcontroller and make it do stuff. It's a commodity skill, and anyone else applying for the same job as you will be able to do it too.

You would think so, wouldn't you? I've interviewed several people recently who couldn't. One of these guys didn't even know what a pull-up resistor was and when/why it's used.

That is funny! Would you be willing to share some good interview questions from your personal bank? (Maybe go a little more advanced than pull-up resistors, haha)

[uncle_bob]

Absolutely anyone in this business can pick up a small microcontroller and make it do stuff. It's a commodity skill, and anyone else applying for the same job as you will be able to do it too.

You would think so, wouldn't you? I've interviewed several people recently who couldn't. One of these guys didn't even know what a pull-up resistor was and when/why it's used.

That is funny! Would you be willing to share some good interview questions from your personal bank? (Maybe go a little more advanced than pull-up resistors, haha)

Hi

Ok, you have a three element circuit. All elements are in series.

1) A voltage source of 10V
2) A source resistor of X ohms
3) A load resistor of 10 ohms.

The question:

What is the value of the unknown resistor that gives maximum power transfer into the load? (possibly dressed up a bit)

The most common answer is (of course) 10 ohms. You have seen a very similar circuit in text books before and know the answer for that circuit.

The correct answer is zero ohms.

If you are designing anything that relates to power, it's a pretty important thing to remember. It's rarely taught at the lower levels.

Bob