Embedded software interview question collection

dreamguy007@hotmail.com wrote:

> I'm trying to collect some good interview questions for embedded
> software engineer positions

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

Paul E. Bennett wrote:
> 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'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

Julian Gardner wrote:
> 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

Pretty please don't top-post.

Interesting compiler treatment of volatile by the compiler.

> 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.

IOW, your seeing the cached value of the memory location (which isn't
memory).

> 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

What are the other variables on the cache line? More registers?
RAM? If registers, then you need to disable the cache for that
region of memory. It would be highly unlikely that the locations
surrounding a status register would be RAM used for "normal"
program variables.


-- 
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

Darin Johnson wrote:
> Yuriy K. wrote:
> > Start with the definition of "volatile".
>
> 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.

Actually I use it fairly frequently for readonly status registers.
It's good code hygiene.

Robert

Yuriy K. wrote:
> Clifford Heath wrote:
> > Describe a situation where you had to diagnose a bug caused by priority
> > inversion.
>
> And do not hire a good person who just have not worked with such
> problems. Unless you are looking for very specific RTOS experience.

I can't recall any situations where I had such problems.  But I
certainly know what problems can occur, and ways to remedy them.
The project I'm working on now had the problem before I joined the
company.  I've probably worked on other systems systems that had
priority inversion going on somewhere, but which didn't cause bugs
that were noticed or important enough to fix right away.  (usually
only a portion of real-time code actually has timing requirements)

A much more commonly encountered bug though would be deadlock.
I've run across several candidates that don't do well even describing
what this is in the general case and draw a complicated diagram on
the whiteboard trying to explain them.  (worse is when I find
this bug in a commercial RTOS component and their developer
working on the fix doesn't seem to understand deadlocks)

--
Darin Johnson

"Yuriy K." <yktech@mail.ru> wrote in message 
news:eea76t$bk5$3@news.netins.net...
> Tom Lucas wrote:
>
>>> I'm trying to collect some good interview questions for embedded
>>> software engineer positions
>>
>> I would ask what they have done outside of work that is relevent. If 
>> someone is passionate about something then they will do it for fun as 
>> well as when they have to.
>
> As long as they are young. Then come wife, kids, house (not necessary 
> in this particular sequence :)).

I suppose the sequence may depend on the attractiveness and 
responsibility of the candidate. Can't get a girl until he has a house 
and then, once he has one whoops here come kids - better make her a wife 
;-)

I think the need for extra-curricular activity decreases as you get 
older but if I was recruiting fresh graduates then I would be very keen 
to find out what they have done over and above their schooling. 

"Eric" <englere_geo@yahoo.com> wrote in message 
news:1158196018.991941.188730@p79g2000cwp.googlegroups.com...
> dreamguy007@hotmail.com wrote:
>
>> I'm trying to collect some good interview questions for embedded
>> software engineer positions
>
> 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.

And then tell him which processor he has to use because the manufacturer 
gave the procurement department a particularly fine lunch and became the 
preferred supplier
:-p 

Darin Johnson wrote:
> Yuriy K. wrote:
>> Clifford Heath wrote:
>>> Describe a situation where you had to diagnose a bug caused by priority
>>> inversion.
>> And do not hire a good person who just have not worked with such
>> problems. Unless you are looking for very specific RTOS experience.
> I can't recall any situations where I had such problems.

I agree. I'd ask the question mainly to see whether I got a baffled
expression or some kind of cogent response, whether or not they'd
actually had the face the problem. It's just always better to say
"tell me about a case where you had to ..." than to say "tell me
in what situation this might happen and how you would handle it".
IOW, ask for actual experiences, not taught techniques.

Stef wrote:
> In comp.arch.embedded,
> Peter <meltyb@hotmail.com> wrote:
>> "Michael N. Moran" <mike@mnmoran.org> wrote in message 
>> news:2CRNg.59500$e9.5509@bignews4.bellsouth.net...
>>> Julian Gardner wrote:
>>>> Well ive been arguing with a company because they cant get to grips what 
>>>> volatile really does and because of this the new piece of hardware they 
>>>> have released witb an embedded processor does not work if the cache is 
>>>> switched on!!!!
>>>>
>>>> I have tried for 2 years to get them to understand but they still screw 
>>>> the design up.
>>>>
>>>> I now need to got through all my code and try to move every variable into 
>>>> a seperate block of memory so there will be no memory corruption.
>>> Off topic, but ... maybe it's because my brain hasn't clicked on yet,
>>> but what has the use of volatile got to do with cache?
>>>
>> volatile on a variable stops a compiler from doing optimisations like 
>> caching. This is useful if there is more than one thread using the variable 
>> because the actual variable and a cached copy would not match.
>>
> And how would the compiler do this? Will it insert a complete cache
> flushing sequence after the variable update?
> 
> On the other hand, if you only worry about different threads, you do not 
> need to worry about the cache. All threads run on the same CPU (multi
> core excluded here ;-) and will therefore use the same cached value, no
> problem.
> 
> You only need to worry about the cache if there is some kind of DMA at
> work. You might also run into problems with self modifying code using
> separate data and instruction caches.
> 
> Use volatile for variables that get updated outside the normal execution
> flow (from an interupt or from another thread). This prevents the compiler
> from re-using a value read into a register, but this has nothing to do
> with caches.
> 
> 

In embedded programming, the biggest use of non-cache access (and of 
volatile access) is for accessing memory mapped peripherals.

Sometimes it is possible for the processor to choose to avoid the cache 
- the Nios soft processor from Altera uses the highest address bit to 
indicate a non-cache access, and thus "volatile" avoids the cache. 
However, that's an unusual case.  The most common volatile/cache problem 
is the misunderstanding that some people have when they believe that 
"volatile" accesses avoid the cache.

In comp.arch.embedded,
David Brown <david@westcontrol.removethisbit.com> wrote:
> Stef wrote:
>> In comp.arch.embedded,
>> Peter <meltyb@hotmail.com> wrote:
>>> "Michael N. Moran" <mike@mnmoran.org> wrote in message 
>>> news:2CRNg.59500$e9.5509@bignews4.bellsouth.net...
>>>> Julian Gardner wrote:
>>>>> Well ive been arguing with a company because they cant get to grips what 
>>>>> volatile really does and because of this the new piece of hardware they 
>>>>> have released witb an embedded processor does not work if the cache is 
>>>>> switched on!!!!
>>>>>
>>>>> I have tried for 2 years to get them to understand but they still screw 
>>>>> the design up.
>>>>>
>>>>> I now need to got through all my code and try to move every variable into 
>>>>> a seperate block of memory so there will be no memory corruption.
>>>> Off topic, but ... maybe it's because my brain hasn't clicked on yet,
>>>> but what has the use of volatile got to do with cache?
>>>>
>>> volatile on a variable stops a compiler from doing optimisations like 
>>> caching. This is useful if there is more than one thread using the variable 
>>> because the actual variable and a cached copy would not match.
>>>
>> And how would the compiler do this? Will it insert a complete cache
>> flushing sequence after the variable update?
>> 
>> On the other hand, if you only worry about different threads, you do not 
>> need to worry about the cache. All threads run on the same CPU (multi
>> core excluded here ;-) and will therefore use the same cached value, no
>> problem.
>> 
>> You only need to worry about the cache if there is some kind of DMA at
>> work. You might also run into problems with self modifying code using
>> separate data and instruction caches.
>> 
>> Use volatile for variables that get updated outside the normal execution
>> flow (from an interupt or from another thread). This prevents the compiler
>> from re-using a value read into a register, but this has nothing to do
>> with caches.
>> 
>> 
>
> In embedded programming, the biggest use of non-cache access (and of 
> volatile access) is for accessing memory mapped peripherals.
>
True, and this could be catagorized as DMA. The peripheral directly
modifies the memory mapped registers.

> Sometimes it is possible for the processor to choose to avoid the cache 
> - the Nios soft processor from Altera uses the highest address bit to 
> indicate a non-cache access, and thus "volatile" avoids the cache. 
> However, that's an unusual case.  The most common volatile/cache problem 
> is the misunderstanding that some people have when they believe that 
> "volatile" accesses avoid the cache.

I was not aware of such a processor. My only hands-on experience with
caches is on the AT91RM9200 (ARM 920T). On this one you can tell the 
MMU which areas to cache and which not. As I understand it, this is far
more common the your Nios example. Volatile has no effect on the cache,
but is needed in addition to turning the cache off for the I/O areas.

Also got bitten by the cache when using a serial driver that uses the
PDC (sort of DMA on AT91 devices). I had to use an uncached area of
memory for the PDC buffers to get it working.


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)