Embedded software interview question collection

Declaring a variable as 'volatile' wouldn't solve the cacheing problem, at least not in any of the systems I've worked on. The 'volatile' keyword will prevent the _compiler_ from caching a variable on it's own, but it won't prevent the cache from caching it -- you have to do that when you set up the MMU.

For that matter, if you're having true 'volatile' declaration problems turning the cache off shouldn't fix it -- because it's a code generation issue, not a cache handling issue.

I'm sure that question would stump many interviewees.

"I my free time I ... I ... I ...? There must be some mistake. I thought this was an engineering position."

Thats one of the problems, they have no cache area, just all memory and the compiler also uses another instruction to access volatile.

Now when the cache is off then the two different commands work the same but with the cache on a non-volatile write goes to cache (no write through) but a volatile write bypasses the cache altogether, only when you move to a different cache line is it written into memory. so if you have a volatile variable in the middle of a block of data and you write to it then as soon as you read/write outside the cached area the variable gets its old value back.

joolz

Then axe them how to pronouce "nuclear"

Or spell the word "ask" ;).

Sorry, couldn't resist...

Steve

Now you're being culturally insensitive (:

What processor is that? I've not run into ones that have special machine instructions for volatile. Rather, the compiler mostly avoids using registers for the memory in question, so that it accesses the real location each time the variable is used.

Cache is certainly an issue for the keeping things consistent, but in my experience this is not related to "volatile". Rather, the cache problem is avoided by explicitly turning off the cache where necessary. For example, if I map a hardware register to a virtual address, I tell the routine that gives me the virtual address that caching should be turned off here. Not related to the compiler like volatile is.

But if there is a processor with special machine instruction to bypass cache, well, I learn something new every day... Not sure I'd want to take advantage of it though since it sounds rather unportable.

Regards, Steve

I've confused candidates by asking about "const volatile". I don't think it's a useful question though, as it's mostly a trivia question. When I asked this I always wanted to get an impression about how the candidate thought about the problem, but it turned out that so many spent enough time being baffled by the question that they never got to the meatier issues.

Some people feel strongly that candidates should know all of the subtleties of a language, but I don't think necessary in practice. I sort of get the impression that the people who do best on the trivia questions are often the bright people just out of school as opposed to the bright people with lots of experience.

So I tend to ask things that indicate how much actual practical experience they've had. Ie, say "give me an example of how you've used this".

-- Darin Johnson

its the arc core and it has a extension of .di which can be used in both ld and st (ld.di and st.di) which is what the compiler produces for volatile read/writes

if you turn this off then when you read a real volatile like the rs232 registers then the cache comes into play and you dont see the change in the say status register.

So the only way i can see of getting this to work is by placing all volatiles into a seperate region and then selectivly going through my code and using a pragma turn on/off the compiler switch for the .di

joolz

Some many years ago [about 15, as I recall] I had to deal with with 'rate centres' (as they are known to BellCore) and wrote a program to plot the picture on the screen of a VGA screen, using appropriate scaling, of all known rate centres. It was a nice map of the USA showing the major Interstates in lower density regions.

Interesting to do, certainly, and I had to do it in integer mathematics as I had to provide pixel addresses :)

Cheers

PeteS

I once completely stumped a candidate with the simple question [1]:

'What is an embedded system?'

The poor guy floundered, which told me he had problems dealing with 'new' (perhaps unknown) territory, so he was ultimately rejected.

I am always interested in just what the candidate thinks what an embedded system *is*; then we can move on to what *my* embedded systems are :)

I also want to know how a person will react when confronted with completely new things, which is common in embedded systems (those who have been in it more than 20 years will understand this ;)

Cheers

PeteS

Having used quite a variety of different tools (of all sorts) I never found that the shortcomings of any of them were more than a mere minor niggle. I would expect any embedded engineer to be able to work around a few minor shortcomings in the equipment and tools he is using and still turn out a dependable system. Then, I never went in for needing extremely complex equipment or tools in the first place.

I would be impressed if, given a non-working logic board, the candidate could diagnose the probable fault with the simplest available tools.

Are you old enough to remember the time before the term was used. In the 70's and early 80's it was "dedicated computer system" or possibly "OEM computer".

I saw lots of PDP8's embedded in the bellies of instruments, typesetters and cnc machines and none of them were referred to as "embedded"

I think EDN or Electronic Design coined the term "embedded system"

And do not hire a good person who just have not worked with such problems. Unless you are looking for very specific RTOS experience.

As long as they are young. Then come wife, kids, house (not necessary in this particular sequence :)).

In cached systems, the MMU (or similar) is configured to prevent caching to memory mapped I/O regions.

Even if you have memory mapped I/O registers (incorrectly) configured as cached, using volatile will not help you. Volatile only prevents the compiler from eliminating (optimizing away) what it views as redundant loads or stores. Compilers don't even know if the generated code is operating in/on cached or uncached regions of memory.

Even more interesting is that volatile by itself doesn't even ensure that loads and stores are performed in program specified order if the processor employs out-of-order execution. In this case, the programmer must insert memory barrier instructions such as the PPC eieio instruction between the appropriate loads and stores (to volatile locations).

Please don't top-post.

It sounds like you have an I/O region with caching enabled. Don't do that, it hurts ;-) You need to set up your MMU /page tables correctly to avoid this.

Give them a situation where they need to pick an MCU for a given task, and give a reasonable number of facts about the task. Tell them to explain the pros and cons of using various MCU devices and families in this scenerio. Also, tell them that their final chip selection isn't the issue here, but rather they'll be evaluated based on their general knowledge of the tradeoffs and how well they "make the case" for their choice.

Proper chip selection early in the design cycle is essential. Even if your company only works within one chip family, there are almost always a number of individual members that have to be considered. Pin counts and functions, on-chip peripherals, RAM, flash, power dissipation, speed, etc are all important.

You can also ask them which MCUs they've worked with, and once you have the answer, ask a couple questions about them (best and worst features, problems they encountered when working with them, etc). Look for answers that hint about actual "hands on" experience. I even might not count it against him if I disagree with his findings in a particular case, but I'd like to hear words that don't come directly from a data sheet. People need a good mind more than they need a good cheatsheet.

Eric

I'm not saying that every tool has major faults. But every tool I've worked with for any length of time has demonstrated nits or irregularities or something else that increased my frustration level by some amount.

(Actually: one of the few tools I've used that hasn't demonstrated any nits to me was my trusty HP-11C calculator. Maybe it was too simple to have nits. Every PCB or schematic capture tool I've used has tweaked my blood pressure, though.)

The goal of the question is to determine if the candidate has more than passing familiarity with any tool they claim to know well.

Kelly