"badal_akr" <badal_akr@yahoo.com> writes:
> >"Steve at fivetrees" <steve@NOSPAMTAfivetrees.com> wrote in message
> >news:yeWdnRhvg58HJJrYnZ2dnUVZ8tadnZ2d@pipex.net...
> >> "Tim Wescott" <tim@seemywebsite.com> wrote in message
> >> news:bemdnaBBKJ-zA5rYnZ2dnUVZ_vKdnZ2d@web-ster.com...
> >> > dreamguy007@hotmail.com wrote:
> >> >> Hi all,
> >> >>
> >> >> Lately I've been assigned to interview many candidates.  Sometimes
> it's
> >> >> hard to ask questions that actually can reveal candidate's true
> >> >> potential, skills, etc.
> >> >>
> >> >> I'm trying to collect some good interview questions for embedded
> >> >> software engineer positions
> >> >> Can anyone contribute? Thanks!
> >> >>
> >> > We would:
> >> >
> >> > * Ask them to calculate the number of pixels on the screen that
> >> > corresponded to some real-world distance.
> >> >
> >> > * Ask them to write said calculation in C (it was just one line --
> >> > at least if we were going to hire them).
> >> >
> >> > * Ask them to rewrite said calculation without using floating point.

> >> Huh? Why would calculating the number of pixels on a screen involve
> >> floating point?

> >I took it that Tim was asking about distance on-screen, which I took
> could
> >be diagonal. In that case, assuming the screen was flat, the natural
> >solution would require a square root. Performing the calculation without
> >floating point would demonstrate some skills useful in low-end embedded
> >systems - how to get good enough answers. Of couse it might just be a
> >trick question as in max(abs(x1-x2),abs(y1-y2))...
> >
> >Well, that was my interpretation anyway.

> I think, this guy himself is preparing for the interviews questions to
> face. 

Perhaps this is a test to see if the interviewee is alert
enough to realize that the questions as presented are
impossible to answer without further information.  If
that is the intent, it represents a common real-world
situation...

I think, this guy himself is preparing for the interviews questions to
face. 


>"Steve at fivetrees" <steve@NOSPAMTAfivetrees.com> wrote in message
>news:yeWdnRhvg58HJJrYnZ2dnUVZ8tadnZ2d@pipex.net...
>> "Tim Wescott" <tim@seemywebsite.com> wrote in message
>> news:bemdnaBBKJ-zA5rYnZ2dnUVZ_vKdnZ2d@web-ster.com...
>> > dreamguy007@hotmail.com wrote:
>> >> Hi all,
>> >>
>> >> Lately I've been assigned to interview many candidates.  Sometimes
it's
>> >> hard to ask questions that actually can reveal candidate's true
>> >> potential, skills, etc.
>> >>
>> >> I'm trying to collect some good interview questions for embedded
>> >> software engineer positions
>> >> Can anyone contribute? Thanks!
>> >>
>> > We would:
>> >
>> > * Ask them to calculate the number of pixels on the screen that
>> > corresponded to some real-world distance.
>> >
>> > * Ask them to write said calculation in C (it was just one line --
at
>> > least if we were going to hire them).
>> >
>> > * Ask them to rewrite said calculation without using floating point.
>>
>> Huh? Why would calculating the number of pixels on a screen involve
>floating
>> point?
>
>I took it that Tim was asking about distance on-screen, which I took
could
>be diagonal. In that case, assuming the screen was flat, the natural
>solution would require a square root. Performing the calculation without
>floating point would demonstrate some skills useful in low-end embedded
>systems - how to get good enough answers. Of couse it might just be a
trick
>question as in max(abs(x1-x2),abs(y1-y2))...
>
>Well, that was my interpretation anyway.
>
>Peter
>
>
>

Rufus V. Smith wrote:
> "Paul E. Bennett" <peb@amleth.demon.co.uk> wrote in message 
> news:ee9vb6$im0$1$8300dec7@news.demon.co.uk...
> 
>>Kelly Hall wrote:
>>
>>
>>>dreamguy007@hotmail.com wrote:
>>>
>>>>I'm trying to collect some good interview questions for embedded
>>>>software engineer positions
>>>>Can anyone contribute? Thanks!
>>>
>>>Ask them about their favorite programming language, CPU, or EDA
>>>software, bench scope, etc.  Ask them what features in it they hate the
>>>most.
>>>
>>>A person who can't list the faults or shortcomings in their tools
>>>haven't used them enough.
>>>
>>>Kelly
>>
>>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.
>>
> 
> 
> A proud personal achievement of my own was when I turned a $10K+ logic
> analyzer into a $25 voltmeter.
> 
> I just twiddled with the switching thresholds of several inputs, then
> hooked them on the same line...
> 
> Not so instant A/D converter.
> 
> Although this is very useful when a signal is expected to stay within
> a range.
> 
> Rufus
> 
> 

Reminds me of a time I showed an acquaintance the limits of a logic 
analyzer - it doesn't tell you what voltages or ringing occured. All it 
does is show a threshold was crossed.
I did some work with the menus in a HP (now Agilent) analyzer to trigger 
a LeCroy scope to nail down a problem.

Cheers

PeteS

"Paul E. Bennett" <peb@amleth.demon.co.uk> wrote in message 
news:ee9vb6$im0$1$8300dec7@news.demon.co.uk...
> Kelly Hall wrote:
>
>> dreamguy007@hotmail.com wrote:
>>> I'm trying to collect some good interview questions for embedded
>>> software engineer positions
>>> Can anyone contribute? Thanks!
>>
>> Ask them about their favorite programming language, CPU, or EDA
>> software, bench scope, etc.  Ask them what features in it they hate the
>> most.
>>
>> A person who can't list the faults or shortcomings in their tools
>> haven't used them enough.
>>
>> Kelly
>
> 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.
>

A proud personal achievement of my own was when I turned a $10K+ logic
analyzer into a $25 voltmeter.

I just twiddled with the switching thresholds of several inputs, then
hooked them on the same line...

Not so instant A/D converter.

Although this is very useful when a signal is expected to stay within
a range.

Rufus

Paul Keinanen wrote:
> I first heard the term "priority inversion" when NASA had some
> problems with their Mars rovers perhaps a decade ago, but I had not
> encountered that problem previously, even after working with various
> real time kernels for more than a decade before that.

It can be very subtle and difficult to detect.    Usually when there
is some priority inversion effect it won't be noticed; the code
isn't stuck and the extra length of time that some operations take
to run aren't immediately noticed.

It's probably most common in larger systems that have lots of tasks
and broad use of RTOS or library services.  Ie, if the memory
allocation
routines use a mutex (which is a very normal thing to do), then any
high priority task that uses these routines could be subject to
priority
inversion.

--
Darin Johnson

In comp.arch.embedded,
David Brown <david@westcontrol.removethisbit.com> wrote:
> Stef wrote:
>> In comp.arch.embedded,
>> David Brown <david@westcontrol.removethisbit.com> wrote:
>>>>
>>> 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.
>
> That strikes me as a strange way to view it, but I suppose it depends on 
> where you are coming from - for my type of programming, caches and DMA 
> are very high-end features, while memory-mapped peripherals are accessed 
> continuously.

Maybe a bit odd to look at it like that, but plausable. But I must admit
I only thought of it to get out of the fact that I had overlooked the most
obvious reason for using volatile. ;-) Sorry about that.

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

On Wed, 13 Sep 2006 19:16:51 -0500, "Yuriy K." <yktech@mail.ru> wrote:

>Clifford Heath wrote:
>
>>> I'm trying to collect some good interview questions for embedded
>>> software engineer positions
>> 
>> 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.

There are quite a lot of people who do not lock multiple resources or
design their data structures in such a way that atomic variable
updates can be used or use the RTOS in a way that each data structure
has a clear owner.

I first heard the term "priority inversion" when NASA had some
problems with their Mars rovers perhaps a decade ago, but I had not
encountered that problem previously, even after working with various
real time kernels for more than a decade before that.

Paul

Stef wrote:
> 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.
> 

That strikes me as a strange way to view it, but I suppose it depends on 
where you are coming from - for my type of programming, caches and DMA 
are very high-end features, while memory-mapped peripherals are accessed 
continuously.

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

That's a much more common arrangement (and you can configure cache areas 
on the Nios too) - I was just using it as an example.

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

Yes, DMA and caches are fun.  Live is a lot easier when your cpu clock 
speeds match your memory speeds and you don't have to bother with caches.

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)

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.