Embedded software interview question collection

Any caching system worth its salt ought to have a mechanism to designate cacheable and non-cacheable regions. Just make sure the i/o ports are non-cacheable.

Separate i/o vs memory space -- lots of cpu's only have memory space (like ppc). Not always an option.

-Dave

--
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture
Reply to
David Ashley
Loading thread data ...

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.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
Reply to
Tim Wescott

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

Reply to
Dingo

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

Reply to
Julian Gardner

Then axe them how to pronouce "nuclear"

Reply to
Jim Stewart

Or spell the word "ask" ;).

Sorry, couldn't resist...

Steve

formatting link

Reply to
Steve at fivetrees

Now you're being culturally insensitive (:

Reply to
Jim Stewart

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

Reply to
steve_schefter

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

Reply to
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

Reply to
Julian Gardner

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

Reply to
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 ;)

[1] There is enough debate about this amongst those of us who have been doing it for decades. I can't expect someone new to *know* what it is as we can't agree on what it is. Indeed, if someone claimed to *know* what it is, as a definable object, I would be very sceptical indeed; there's a difference between confidence and arrogance (although it's not arrogance if you're right ;)

Cheers

PeteS

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

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Reply to
Paul E. Bennett

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"

Reply to
Jim Stewart

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

--
WBR, Yuriy.
"Resistance is futile"
Reply to
Yuriy K.

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

--
WBR, Yuriy.
"Resistance is futile"
Reply to
Yuriy K.

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

--
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
Reply to
Michael N. Moran

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.

--
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
Reply to
Michael N. Moran

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

Reply to
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

Reply to
Kelly Hall

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.