IEE or IEEE

Hi Ian,

That is true, to some extent. But I found that working together with an engineer who is interested in the hardware and myself being interested in software we can build a nice product of high quality. Some of these have now surpassed their 10th anniversary in production.

The minute you need to enter low power modes (like that ol' PCON command) a mutual understanding of what each other's designs do is essential.

Regards, Joerg

It is certainly project specific I agree. The vast majority of projects I have been involved in (and recruited for) have for high volume cost sensitive products where it is essential to squeeze every last ounce of performance out of the software and hardware together.

Indeed, in many of the designs I have been involved in, a very high degree of innovation is necessary to achieve the cost/performance targets for which a high level of knowledge outside your own specific discipline is required (and can include disciplines other than just electronics and software)..

Ian

--
Ian Bell

They also have absolutely no clue about resource usage. They have no idea how much rom/ram/cpu will be required for code they write. And because they have no understanding of hardware, it's extremely difficult to _teach_ them about resource usage.

And if they ever need to use an Oscilloscope or Logic Analyzer to determine if the problem with a prototype is hardware or software, you may as well send them to the movies.

I remember working with one CS grad who tried to call some assembly language routines from his Pascal source code. The assembly language routines expected parameters in registers, and the Pascal compiler passed them on the stack. Needless to say, it didn't work.

I told him he needed to write assembly-language wrappers that popped the parameters from the stack into the registers. His response was:

"What stack?"

"What are registers?"

It wasn't that he didn't know that particular CPU or assembly language, he didn't even understand the underlying concepts. I tried to explain it to him, but it was pretty much hopeless. He eventually found another EE to write the assembly language for him, and he went back to writing his Pascal program.

--
Grant Edwards                   grante             Yow!  That's a decision
                                  at               that can only be made
                               visi.com            between you & SY SPERLING!!

We recently took on another chap as a prototype wireman to assist with the workload of geting a new experimental rig up and running in pretty sdhort order. On Monday he said "you didn't ask about doing mechanics, cryogenics and operating this stuff in the interview". True enough, but we had already figured out that he was quite versatile fromk his CV and the interview.

For my part, as a Systems Engineer, I have certainly learned a lot about High Energy Plasma Physics, Cryogenics, Low Temperature Measurements techniques, behaviour of gases and liquid gases, and High vacuum pumping systems to add to what I already knew of Motion Control Systems, Load and Torque Measurements, Power Control, PLC programming, Forth Programming and basic electronics.

Whoever expects engineering to be shoehorned into narrow confines had better reconsider. The trick to being a good engineer is to be open to learning new stuff continuously.

So, the people you look for need to exhibit this openess to continued day-by-day learning, whatever way they come to you.

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

Hi Ian,

That's why I used to present candidates with an actual or recent problem. How would they go about it? Can they think holistic? Are they willing to? In the case of SW folks I did sometimes ask them to come to the lab with me and try to trigger a Tek scope on a signal from a circuit or pulse generator. To be fair, HW engineers would be asked about what an interrupt latency is.

Regards, Joerg

The same sort of people who see no problem in passing an array by value.

Ian

--
Ian Bell

And also, >That is true, to some extent. But I found that working together with an

...

Interesting points to read. I prefer having as much overlap in skills for those on a team as is possible. I'll elaborate:

I started out as a mathematics and physics major and learned computer science out of my need for calculating physical systems, but eventually made CS my own profession because it paid the bills. Electronics has been a hobby for quite some time and I have acquired some understanding, though I certainly don't try and offer my meager hobbyist electronics skills professionally.

But projects I work on involve optics, detector physics, electronics, fairly sophisticated signal processing, numerical methods, as well as a variety of software skills. I am *not* usually responsible for designing the optics, but I have had years of experience in both designing and building (by hand-grinding) and testing optical system, so I can and do comment on the designs I see and participate in them. I am *not* usually responsible for selecting the detector, but my understanding of physics does allow me to understand and participate in that process, too. I am somewhat fluent at reading the schematics, so I often do make recommendations which do impact on resulting product design in helpful ways. My skills in mathematics mean that I can both develop and accept mathematical ideas and use numerical methods to understand sources of error that accrue from specific algorithm implementations or the use of floating point notation, etc.

In short, it helps to understand the overall system and electronics and software tradeoffs and to help think through various alternatives and also to catch the mistakes others may make in an early and timely way.

What makes this work better is that while I don't have the final responsibility in the other areas, I do understand them and I do impact their design and I have enough overlap of skills to not let things slip through the cracks, so to speak. When a physicist writes a closed equation, I can use my knowledge of numerical methods to generate a sequential algorithm that delivers what is intended -- often, the physicist has almost no idea about the vagaries and limitations of programming issues and simply imagines that the calculations are always exact, for example, and that constants are exact, as well (just by way of example) and doesn't really understand how software can actually create errors and that these errors can accumulate if they aren't understood and managed well. Having an overlap of skills is what helps keep these problems from arising in the first place, when in highly partitioned skill sets these things can often "slip through" and wind up in the final product. Similar arguments may also apply to why a software person needs to understand the hardware to some degree, as well.

I taught undergrad CS courses for a few years at the 2nd and 3rd year level at a local university here. Not a long experience, but there it is. Class size was around 55-65, or so. Subjects included assembly languages, computer architecture, operating systems, and concurrent programming. In such classes, I'd often have 5 or 6 students from the EE department -- about 10%. In every case, my experience is that these EE students would have almost zero problem understanding my lectures and doing the work assigned. By comparison, out of the remaining 50-60 CS-only students, I'd have perhaps a slightly smaller number (about 3 or 4) who were as fluent. The rest required a fair amount of my office time to help them think things through.

I don't mean to say that the lesson here is that EE folks are necessarily brighter, but that being personally and eagerly interested in various technical areas is a good thing. My "sense" is that what Joerg said is about right -- though perhaps I'd broaden it a little -- having an abiding interest in all things surrounding a project is key. Someone who is narrowly focused on remaining isolated and partitioned off as a "software person," in embedded work where there are myriad important interactions, is a recipe for problems and quite possibly failure. You need many eyes watching out for problems and who can bring their own unique viewpoints to bear and help make the resulting product one born of an overall more comprehensive viewpoint. Having people who keep themselves into their own little functional boxes is often a bad thing in embedded work.

But I'd be looking for this kind of interest in many areas together with the ability to actually translate that interest into, at least, a skilled and serious amateur understanding of these other areas. Not simply excluding CS and reaching for EE. You can find these kinds of people from both areas, though perhaps it may be argued that an EE is more likely to have broader technical interests. (On that last point, I wouldn't know.)

Jon

Yup. Nicely said.

Jon

How true. There was some discussion of this some time ago on sci.electronics.design IIRC and it is still surprising how few engineers can analyze a simple circuit or design one. This is one of my pet gripes with all the universities. They will teach people how to analyze a circuit to the death but they teach virtually nothing about how to go about designing one.

Ian

--
Ian Bell

snip

Exactly.

Ian

--
Ian Bell

That and not being able to solder. How you can get a 4 year ee degree and never touch a soldering iron baffles me.

those

science

own

quite

try

fairly

of

but I

hand-grinding)

and

detector,

participate in

often

helpful

error that

point

software

the

responsibility

I have

speak.

numerical

intended --

of

exact,

example) and

these

an

first

apply to

well.

level at a

size was

classes,

every

problem

of

number

office

technical

right --

all

work

and

who

people who

thing in

the

CS and

though

technical

Very well said. My dad, who's an engineer and actually more into hardware than software, knows by practice that understanding not only the hardware (or not only the software) exclusively is real important because that makes both design and implementation better, not to say that locating and fixing problems is way easier when you're not limited to just one half of the product. I, myself, as a former physics student (though I've shifted from physics to CS), know about this importance from practice. And it is quite the right kind of thing to be interested in may things, I mean, when you have broader knowledge (often from several areas of science/engineering) you can do more and better, you can invent unexpectedly (or just come to) good solutions. And yes, it's better for CS guys to know how the transistors work (and not only them) which make up their CPUs, how to make custom ASIC to solve the task that the CPU isn't able, etc etc. Beyond CS there's always math and physics. Math is a must, physics is very much desired. Btw, good business in IT requires knowledge of both the business itself and the matter, the engineering stuff that's behind.

Alex

Grant Edwards wrote in news:416c16b2$0$405$ snipped-for-privacy@newsreader.visi.com:

I'm a CS major, been doing embedded systems for over 20 years now, started before I got my degree in fact. You should never pigeonhole someone based on just one thing like that.

Learned how to use an oscilloscope on the job, from watching the EEs do it. Learned how to use a logic analyzer by playing with one for a while.

Ah, if you are looking for someone fresh out of college, with no experience, sure, I'd go with someone else.

Those concepts were taught in the CS program I took. I guess YMMV depending on what school is in question.

--
Richard

snip

Is that true> Good Lord, it's worse than I thought. I thought all EEs started soldering before they reached their teens. I was selling crystal sets at primary school and built my first valve amplifier at 12. I have a strong suspicion that TV has a lot to answer for in preventing today's kids finding an absorbing hobby which teaches them concentration, depth and breadth of study, and for then creating unrealistic expectations of their working life before they even reach it,

Ian Ian Bell

snip

And not only that, it is a lot more *fun*.

Ian

--
Ian Bell

I am sure there are exceptions but when recruiting you just do not have the time to find them. Good engineering practice - go for the solution you know is going to work in the quickest time at the lowest cost.

When our business was growing fast we always included CS qualified candidates in our recruitment searches for embedded staff. I interviewed many and not one of them had any real knowledge of hardware. I only hope things are changing.

Ian

--
Ian Bell

It's that bad in the US. I can't speak for other countries. And don't get me started on CS grads that have never programmed in assembly or used vi to modify a unix config file...

Not always true, most is determined by committees often full of retired or near retiremnet people, that companies put on the committees to show they are involved. Many Standards become more about politics (ISO especially), whether it be national (see HDTV 'standards'), or competitive (do some research on various companies leanings on various standards.

Often the people involved are far removed from actual engineers (of any grade), and the engineering input is lost amongst the other bits once the bureaucrats get hold of it.

The main basis of one EMC/EMI standard transpired to start from

"must not interfere with a TV set from X metres"

No engineering or scientific basis came into it. Let alone how different TV sets are to be susceptible to interference in different ways in different bands.

-- Paul Carpenter | snipped-for-privacy@pcserviceselectronics.co.uk PC Services GNU H8 & mailing list info For those web sites you hate

The horror I had a few years back of trying to sort out why one calibration function for a card was not working, involved a couple of us having to backtrack through a mess of code dealing with FOUR calibration values, that we traced back through the code and gave up at ten levels after -

1/ Several instances of creating another local copy of the structure (of 4 ints) 2/ Passing of the 4 parts of the structure or local copy by value, at least twice. (So we could guarantee any real updates of four values getting back up the chain). 3/ Passing of FOUR addresses to each member of the structure or a local copy of it at least twice.. 4/ Only ONE instance of passing a pointer to a local copy of the structure.

At this stage NO processing had happened on any part of the data! This was on a commercial shipped add-on card for a PC

We gave up and said we could not ship this product when we were not happy with reliability of the code to perform its specified task.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate