Tom Lucas <news@remove_auto_this_flame_to_reply.clara.co.uk> wrote:
> 
> We were certainly hoping to not have to relocate someone. Are you sure 
> people are on more than 40K? I reckoned that that was about the going 
> rate for someone with 10 or so years experience, in fact a little over 
> even for London. Has there been a big jump in the average recently? 
> 

I'm sure I'm on more than that, put it that way, and I know how much
some of the people who used to work for and with me were paid and
they're in the same ballpark. 

In my last workplace in North Yorkshire, 'software engineers' made
up to about low 30s basic, seniors and team leads were up to low
40s basic (there was also a bonus scheme that could reasonably be
expected to add around 15% to these numbers) depending on skills
and experience.  Salaries there were felt to be "market rate" - i.e.
enough to keep most people from deserting, at least until various morale
crises caused by our parent company ;P

I've since moved on to somewhere with considerably better basic
(though quite probably less bonus) and comparable bens.

I think the level of skills and experience you're after would
comfortably be seen as "senior" in my former workplace, so draw your own
conclusions! 

pete
-- 
p...@fenelon.com "he just stuck to buying beer and pointing at other stuff"

In article <45543b5a$0$8085$8...@news.wineasy.se>, 
d...@westcontrol.removethisbit.com says...
> Tom Lucas wrote:
> > "Eric" <e...@hotmail.com> wrote in message 
> > news:1...@m73g2000cwd.googlegroups.com...
> >> The company I work for is in the process of interviewing several
> >> embedded software candidates.
> >>
> >> What types of questions could we ask to make sure the interviewee is 
> >> an
> >> embedded software candidate and not just a high level CS major?
> >>
> >>
> >> We've asked questions about whether they would feel more comfortable
> >> doing low level drivers or application level stuff? The usual answer 
> >> we
> >> get is "I can do all of that"..... No, most people are better suited
> >> for one or the other... many can do both, but that person usually has
> >> strengths in one or the other.
> >>
> >> Another sample questions is "What steps would you have to go through 
> >> to
> >> set up an interrupt on a mirco?"
> >>
> >> Any other ideas for interview questions?
> > 
> > Ask them to explain where you would use a volatile variable. That's 
> > always a good test to see if they've been paying attention. 
> > 
> 
> Atomic access and mixing interrupt and main routine data is another 
> goodie - some people mistakenly think adding "volatile" is enough. 
> There are plenty of mistakes in the following code:
> 
> 
> uint16 msecsCounter;
> 
> void timerFunc(void) {		// Called by timer interrupt
> 	msecsCounter++
> }
> 
> void delay10(void) {
> 	uint16 startTime = msecsCounter;
> 
> 	while (1) {
> 		if (msecsCounter > (startTime + 10)) return;
> 	}
> }
> 
That's a good example.  Some of the errors will be flagged by
the compiler, some will not.

Mark Borgerson

 

In article <45549534$0$8083$8...@news.wineasy.se>, 
d...@westcontrol.removethisbit.com says...
> Arlet wrote:
> > David Brown wrote:
> > 
> >> Atomic access and mixing interrupt and main routine data is another
> >> goodie - some people mistakenly think adding "volatile" is enough.
> >> There are plenty of mistakes in the following code:
> >>
> >>
> >> uint16 msecsCounter;
> >>
> >> void timerFunc(void) {		// Called by timer interrupt
> >> 	msecsCounter++
> >> }
> >>
> >> void delay10(void) {
> >> 	uint16 startTime = msecsCounter;
> >>
> >> 	while (1) {
> >> 		if (msecsCounter > (startTime + 10)) return;
> >> 	}
> >> }
> > 
> > Of course, atomic access is typically only a problem for this code on 8
> > bit systems.
> > 
> > The code above also has an issue when the timer wraps around.
> > 
> > I agree it would be interesting to see a candidate find and fix these
> > problems, as well as the obvious "volatile" that's missing.
> > 
> 
> You spotted all the problems that apply on small embedded systems. 
> There may be other issues on big cpus ("volatile" doesn't necessarily 
> work as you would like when you have caches, out-of-order execution, 
> parallel processing, etc.) - but then you really do want to use an OS 
> and make the issues into SEPs.  For small micros, it is a common mistake 
> to think that "volatile" gives you atomic access, when obviously it does 
> not.

Does your compiler allow you to omit the semicolon after
    msecsCounter++??   Codewarrior won't let me get away with that.
> 
> > A recommendation to add an OS to solve this problem wouldn't score any
> > bonus points for me. There are many cases where a full-fledged OS is
> > overkill, and embedded programmers need to be able to fix this, and
> > similar, code themselves.
> > 
> 

An even more interesting case might occur if you needed a delay less 
than 10 milliseconds  and tried to use an OS where the delay routines
do not have sub-millisecond resolution.  I run into this problem almost 
every time I try to do high-resolution timing with an OS.   You often
have to switch to a different  set of system calls when you change
timing delays by an order of magnitude or more.


Mark Borgerson

On 10 Nov, in article
     <1...@e3g2000cwe.googlegroups.com>
     usenet+5...@ladybug.xs4all.nl "Arlet" wrote:

>David Brown wrote:
>
>> Atomic access and mixing interrupt and main routine data is another
>> goodie - some people mistakenly think adding "volatile" is enough.
>> There are plenty of mistakes in the following code:
>>
>>
>> uint16 msecsCounter;
>>
>> void timerFunc(void) {                // Called by timer interrupt
>>       msecsCounter++
>> }
>>
>> void delay10(void) {
>>       uint16 startTime = msecsCounter;
>>
>>       while (1) {
>>               if (msecsCounter > (startTime + 10)) return;
>>       }
>> }
>
>Of course, atomic access is typically only a problem for this code on 8
>bit systems.

Or those with 8 bit memory access that is NOT atomic.

>The code above also has an issue when the timer wraps around.
>
>I agree it would be interesting to see a candidate find and fix these
>problems, as well as the obvious "volatile" that's missing.

Also to what accuracy you want to wait as using a delay routine like
that, has a wait period that is *greater* than 9 units to just over 10 units
on a not heavily loaded system. Amongst other issues.

>A recommendation to add an OS to solve this problem wouldn't score any
>bonus points for me. There are many cases where a full-fledged OS is
>overkill, and embedded programmers need to be able to fix this, and
>similar, code themselves.

Depending on what accuracy of delay you need and what the delay is
synchronised to has a lot of impact on choices of methods. Along with
how the cpu operates, or other OS and/or task interactions/lockings etc..

As usual the answer is really "depends".

-- 
Paul Carpenter          | p...@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>;    PC Services
<http://www.gnuh8.org.uk/>;              GNU H8 & mailing list info
<http://www.badweb.org.uk/>;             For those web sites you hate

I left the UK because nobody in Scotland was interested in an over 50
engineer. I had to resort to contracting on the continent where I had no
troubles at all finding work.

Wim

"Wim Ton" <w...@bluewin.ch> wrote in message 
news:4554bfe5$1...@news.bluewin.ch...
>I left the UK because nobody in Scotland was interested in an over 50
> engineer. I had to resort to contracting on the continent where I had 
> no
> troubles at all finding work.
>
> Wim

Engineering does seem to be much more valued on the continent than it is 
in the UK. It probably doesn't help that everyone from Washing machine 
installers to tyre fitters are calling themselves engineers here.

Shame about the age discrimination but I think it is factor in most jobs 
these days. Seems ridiculous really when you know that when you emply a 
21year old kid, you're only going to get two years before they move on. 

Wim Ton a écrit :
> I left the UK because nobody in Scotland was interested in an over 50
> engineer. I had to resort to contracting on the continent where I had no
> troubles at all finding work.
> 
Could you tell us where on the continent?

In article <455439f3$0$8096$8...@news.wineasy.se>,
 David Brown <d...@westcontrol.removethisbit.com> wrote:

> David Kelly wrote:
> > 
> > The compiler doesn't have to be broken at all. If there is any kind of 
> > optimization taking place there is no rule that the compiler has to 
> > evaluate expressions in the order give.

s/give/given/

[...]

> People in this thread keep suggesting things like compiling without 
> optimisation, and seem to believe that this will force the compiler to 
> translate each code line into literally equivalent assembly.

I agree some are making that assumption but I chose my words carefully. 
"If there is any kind of optimization taking place ..." isn't the same 
thing as deliberate selection of optimizer options.

Good C compilers are not simply elaborate collections of macros driving 
an assembler altho the historical Pascal faction would have one believe 
such.

CBFalconer wrote:
> Me too.  All I can think of is that the debugger is flawed, and
> actually setting the breakpoint before the completion of the
> statement.

One of my guesses would be that the stack was getting clobbered.
Doesn't even have to be broken interrupt handlers.  Just put a
buffer on the stack, save a pointer to it somewhere, then leave
the function.  Next time something tries to write to that buffer
it will corrupt the currently running stack.  If done in a
different context it will be very mysterious.

A habit a lot of programmers have is in assuming the rest of the
system is working.  In embedded systems you can't necessarily
trust that the hardware and OS are working correctly (and
sometimes not even the compiler as I've discovered).  A
candidate that says "that can't happen, z must equal 3" is
inadvertently limiting the scope of the problem solving.

Granted, in an interview one usually expects that such questions
can be solved without going outside the box, especially if the
question is asked as if it were a puzzle.  I think candidates
might open up more if the question were asked as "I once had
something like this fail for me, can you give me ideas on what
may have caused this impossible result?"

--
Darin Johnson

Paul Black wrote:
> visweswara wrote:
> > Eric wrote:
> >> The company I work for is in the process of interviewing several
> >>> Any other ideas for interview questions?
> >
> > Please visit this URL . It contains simple questions to make sure the
> > candidate is good at embedded systems.
> >
> > h t t p://www.embedded.com/2000/0005/0005feat2.htm
>
> Kind of casts doubt on the rest of the questions and answers when the
> answer to the first one is so far out.
>
>
> --
> Paul

yeh, the define won't work it won't even compile

why does know what #error does make someone a nerd?

wheter the "?" operator will make more optimal code that if/else it
depends on the compiler

who cares about how you do an infinite loop, its just an infinite loop

but knowing when and why you need volatile and why an interrupt cannot
return values or be passed parameters is a good start...

-Lasse