Academically, people who are work in embedded engineering field have more EE background than CS background. Is that correct? For people who have computer science background, that means they need to work more on hardware electronics side? I heard some people also say embedded field has 2 types of people: software embedded engineers, and hardware embedded engineers.
please advice. thanks..
Yay, another chance to promote my book. My most recent embedded systems book talks about this topic in some detail. Here is a page I wrote describing the book:
The short answer to your question is that people with a strong CS background are more likely to find embedded jobs in systems that have a clearly defined application layer. This means (by c.a.e standards) fairly large systems, typically 32-bit and based on an off-the-shelf operating system such as WinCE, Linux, etc.
However this is not an immutable law of nature. Where you excel will depend largely on where your aptitudes and interests lie. Formal training is useful to help you discover those aptitudes, but frankly you will not use much of your tertiary education in the real world regardless of what you do for a living (unless you become a professional academic. And that IS an immutable law of nature).
If you enjoy/are good at working with code that is highly abstracted from the underlying hardware, you'll spend your life in the app layer. If you're a good procedural programmer with a penchant for timing, low- level details etc. you'll spend your life in the lower layers (and you'll have a wider variety of embedded projects open to you).
Ken wrote:
"Academically, people who are work in embedded engineering field have more EE background than CS background. Is that correct?"
Maybe, and maybe unfortunately. My primary degree is in computer science. I am a Ph.D. candidate in electronic engineering. I consider myself to be a computer scientist with an interest in embedded computing. I happen to be officially classified as an electronic engineer at present (but "Ph." denotes science instead of engineering): do not place too much faith in labels: disciplines are not cohesively categorized into mutually exclusive names. One does not need to do a physics degree to understand enough about electrons to use electronics.
" For people who have computer science background, that means they need to work more on hardware electronics side?"
You need to do whatever you need to do. I am aware of a computer science primary degree in which the hardware description language Verilog is taught. No hardware description language was available for my primary degree, so I studied VHDL in my spare time. Oddly enough as a computer is hardware and as one of the words in "computer science" is "computer", I was lectured in my primary degree on rather inescapable essential aspects of computer science such as computer hardware. I was even lectured on electronics in that degree, but of course electronics is not literally essential for "embedded engineering" nor computer hardware but even someone who had been a major former proponent of optical (photon-based) computers without electronics has surrendered in so far as being willing to practically campaign for hybrid hardware with photons and electrons.
" I heard some people also say embedded field has 2 types of people: software embedded engineers, and hardware embedded engineers."
Some people could say that.
If you are a computer scientist who will work in an embedded field with people who are not computer scientists (computer scientists are excellent people) nor software engineers (retards) nor information system people (retards) then they may be electronic engineers (retards) who will be prejudiced into thinking that you need to learn more about a lower level, e.g. an older researcher who is an electronic engineer looked at this VHDL code of mine:
library ieee; use ieee.std_logic_1164.all; use IEEE.numeric_std.all; package user_defined_types is
--Stuff commented out. subtype amplitude_type is signed(5 downto 0);
--Stuff commented out.
--SimVision would display my original code like --subtype amplitude_type is integer range -32 to 31; --analyzed by Cadence ncvhdl_p with 32 bits. My original code should have been reified to the proper dimensions by a decent tool: the type of coding in my original code is good enough for optimal storage in Ada (of course, with Ada a full word would be used because that is the way a computer is built, but were it not for that it would be as lean as IEEE.numeric_std.(un)signed) and according to what is written in 4.2.41 Arithmetic Operations on Bit-Vectors of
and said that as I am becoming an electronic engineer now I have to understand that amplitude_type takes up eight or three bits (I kid you not, but I unfortunately can not remember with clarity which of eight or three he said). If you can calculate how many bits amplitude_type needs (a hint is that it is greater than three and less than eight) you may know more about embedded engineering than electronic engineers but they are stubborn and do not want to learn from people "from computer science" nor accept that we understand aspects of their work better than they do even if they say that they work in a field which spans across our disciplines which they want to learn from.
Electronic engineers are not the only people who would ignore you because they are defiantly insistent that you could know nothing about hardware: e.g. I mentioned in
Good luck Ken!
Lewin A.R.W. Edwards wrote:
"[..]
If you enjoy/are good at working with code that is highly abstracted from the underlying hardware, you'll spend your life in the app layer. If you're a good procedural programmer with a penchant for timing, low- level details etc. you'll spend your life in the lower layers (and you'll have a wider variety of embedded projects open to you)."
Ada's representation clauses (
Yes, and in the three or four actual products that are written in Ada, this is highly important. While there are exceptions, including the one you mentioned, my advice reflects the broad view of industry employment opportunities.
A much larger exception to my rule is the possibility of developing Jazelle-enhanced devices that use Java as the "native" language; there are certainly more Java-based commercial [!= military] embedded systems than Ada ones. I didn't mention this either, because it's a tiny percentage of the job market.
Ok, here is the view from an EE type who often works in embedded. Usually I do the hardware design (with the code in mind) and a SW guy does the code (with the hardware in mind). I found that in the end it all boils down to communication skills. I need to be able to explain my hardware to the firmware designer in a way that he or she can understand without exactly having to know how a double-balanced mixer or similar "weird stuff" works. He in turn does the same without too much "nerd talk" so we can sit down and hash out the critical stuff.
An example: On one product we had to periodically shut down the uC, totally, no clock. This had noise reasons because there was lots of sensitive signal acquisition going on. To make it a real challenge, the regular wake-ups and the workload of the uC had to be identical from one wake-up to the next. As much as possible. That required the both of us to really try to understand each other's work. To make it really interesting the whole enchilada was controlled from a huge Windows-based system, meaning the firmware guy and I had to also discuss lots of details with hardcore SW engineers who knew C++ inside out but almost nothing about embedded. This design is now entering its 12th year of production.
The type of your degree isn't too important IMHO. Communication skills and flexibility are. Talking about flexibility, one of the SW engineers from that project is now the owner/manager of a successful upscale restaurant :-)
-- Regards, Joerg http://www.analogconsultants.com
In my experience, looking back, yes. But as software becomes more complex, maybe looking back might not necessarily tell what the future will be.
It certainly helps. I have worked though, with software engineers writing software for embedded applications who know very little about electronics, including such things as resistors. But they get along mostly fine, as far as I could tell, as the ones like that I have worked with can work well enough with others who do know something about hardware.
Or both - although I suspect most will have an inclination to one or the other.
Regards,
Paul.
IME the occasional kegger or pool party also helps tremendously when it comes to getting along with each other :-)
-- Regards, Joerg http://www.analogconsultants.com
The rift between the hardware and software camps is often comical. At a certain large company where I used to work, the hardware engineers were forced to create "Hardware/Software Interface Specifications" to specify exactly what the software must do to properly support the hardware.
One of the hardware guys used to refer to these documents as "Hardware for Idiots".
Anyone who can't immediately recognize at minimum voltage dividers of various types and RC filters is viewed with extreme contempt by the hardware designers.
(And IMHO that is as it should be. Any CS types who can't analyze these basic circuits need to get themselves in a couple college courses. And any CS types who can't use a soldering iron need to order a few electronic kits ...)
-- David T. Ashley (dta@e3ft.com) http://www.e3ft.com (Consulting Home Page) http://www.dtashley.com (Personal Home Page) http://gpl.e3ft.com (GPL Publications and Projects)
Been there, and it's sad. As Joerg said, communication is key.
Putting the shoe on the other foot, any hardware designer who can't understand basic code needs to get *themself* a course or two. I am principally in hardware design, particularly in the embedded space, but I do a fair amount of code too.
The most successful jobs (my experience, YMMVG) are where the hardware and software designers both understand what the other and the project is trying to achieve and work toward that together. A little mutual respect rather helps this process along as well.
FWIW, I've worked on both sides of that fence [sometimes on a single project ;) ]
Cheers
PeteS
Modestly excluding my humble self, an EE, the two best embedded programmers I know were educated in chemistry and physics.
In order to program things, the prime requirement is that you understand things. The programming part is just routine.
Student breadboards don't prove much. Nowadays, serious electronics is far too complex to breadboard; a CPU, flash, a few BGA FPGAs, eight or
10 linear and switching power supplies, and a thousand analog parts is common these days. We design and release all the documentation on rev A, have manufacturing build us a couple, and we make them work. Over 90% of the time, we can sell rev A, because we designed it right.It's quite common for a single (retard) EE to do 100% of the design of a product - definition, specs, parts selection, schematic, bom, pc layout, pld's, embedded code, datasheet, manual. How many (excellent) software types can do this?
John
Or working together from the very start of a project, defining the h/s boundary and interfaces together. If the hardware is designed first and tossed over the wall to the programmers, it may not work as well.
John
Exaclty. "There is no and there couldn't be any replacement for the common sense, good taste, intelligence and experience" (Stroustrup).
From my experience, it appears to be much more productive not trying to get absolutely everything right at the rev. level A. For any more or less nontrivial design, it is very difficult to foresee everything. Moreover, it takes more time designing it to the perfection from the first try rather then doing 2-3 iterations. Also, while the project is moving on, the specs tend to change. So, rev. A goes to the trash, rev. B is operational however it may need some fixes, and, finally, rev. C is released.
Just an example: a manual for a modern CPU is ~1000 pages. To do everything right from the first try, you have to read and understand the manual from cover to cover. However all that you really need to know is ~20 pages of the exact description of the features that you are going to use for this project. The 99.9% of the other information is mostly irrelevant and having to go through it just adds to the overhead.
Then how does that happen that the experienced pure software folks are generally paid higher then the EEs?
The formal training in CS is a definite plus for the embedded developer. It sets up the right methodology of the development and prevents from reinventing the wheels.
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
But that takes, maybe, 4 weeks per iteration. The very assumption that rev A will not be deliverable is self-fulfilling. A day or two of careful checking can often skip a full spin. As a day or two of careful code review can often skip a month of chasing bugs.
Speak for yourself.
It's my opinion that modern CS education teaches a lot of very bad habits.
John
That, to me, implies an improper specification of what the unit was supposed to do. There's a difference between an improper spec and a changing spec; an improper spec is impossible to design to because no-one really knows *what* it is supposed to do. A changing spec can cause a lot of problems, though, but not nearly as many as an imporper one. A changing spec is one thing I charge a lot of money for. An improper spec gets charged more ultimately because I insist on a proper specification.
Ditto.
I have a CS degreed coworker who apparently believes it is beneath him to read the *entire* datasheet for a peripheral unit (in this case a very simple part); this has happened a number of times where I have had to explain to him the operation of both the processor he is supposed to be programming for and the peripheral he is supposed to be using. I'm not saying all CS grads are like that, but if not, he's not the best advertisement. If not reading the entire datasheet (i.e. understanding the complete operation of the device) is the CS methodology, no wonder they get a (deserved in that case) bad rap.
Cheers
PeteS
That sounds like too slow. I'd say two weeks, even if you are not willing to pay extra for the fast prototyping. And there are other projects to work on in the mean time.
John, if you say the word "sugar" 100 times, it neither makes your mouth fill sweet no adds extra calories to your diet. :)
The opposite can be true also. Several days of carefull checking can very well be a wasted time. BTW, I used to know a guy who manually verified the boards against the netlist.
Look at the salary reviews publushed in the industry magazines.
Like what, for example?
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
Agreed. I am currently designing a board (in layout now) based on a PXA device and when all the relevant datasheets and app notes are put together it's about 2000 or so pages. I have read every single word of all those and made copious notes so I can bring together the scattered but necessary information.
However all that you really need to know is
I completely disagree here. Given the layout of typical processor datasheets and app notes, the information I need to successfully design a board is spread across all those pages and I have to read *and understand* every word in the whole shooting match before I can commit to a layout. What's so difficult about it for some is it means they have to inhale a huge amount of information, but it goes with the territory. Proper design, whether it be software or hardware or both requires a thorough knowledge of the parts being used.
;)
There are some good points in CS, and some not so good if it means not bothering to understand the platform.
Cheers
PeteS
Oh - you mean the people that provide you with hardware (boards and all that boring crap) that provide you with a something to program for a living?
;)
Cheers
PeteS
Oh - you mean the people that provide you with hardware (boards and all that boring crap) that provide you with a something to program for a living?
;)"
No, they do not provide me with hardware. If you regard hardware to be "boring crap", perhaps you find news:comp.arch.* boring and do not have much job satisfaction ;)
Cheers, C.P.G. the E.E. and C.S.
John Larkin wrote in news: snipped-for-privacy@4ax.com : "[..]
In order to program things, the prime requirement is that you understand things. [..]"
Aye.
Vladimir Vassilevsky wrote in news:v26xh.41256$ snipped-for-privacy@newssvr21.news.prodigy.net : "John Larkin wrote:
Exaclty. "There is no and there couldn't be any replacement for the common sense, good taste, intelligence and experience" (Stroustrup).
[..]"I do not know whether Stroustrup said that. It reminds me of someone I am involved with who sincerely espouses good principles (e.g. do not write a datum in more than one part of the documentation because when it changes it must be changed in more than one place), but who is completely unaware that he is very bad at putting such concepts into practice (he untruthfully and honestly insists that he has such a good memory that he can remember the current configuration of a design so when asked for a number he does not bother to look it up in the documentation and says that it is something which it is not).
Colin Paul Gloster wrote in news:epvr31$g0b$ snipped-for-privacy@newsserver.cilea.it : "[..]
Electronic engineers are not the only people who would ignore you because they are defiantly insistent that you could know nothing about hardware: e.g. I mentioned in
John Larkin wrote in news: snipped-for-privacy@4ax.com : "[..]
Student breadboards don't prove much."
Nothing proves much. Someone who believes in proofs is deluded. You can check for a history of supposed proofs which people do not believe any more and scientific results which people refused for a long time to accept and victimized proponents of them (e.g. that black holes do not emit radiation; Ohm's laws; the existence of irrational numbers; how to square a circle; that some computer science problem is or is not tractable; how to make system with electronic discrete logic which can not become metastable in a given finite temporal bound; and indeed counterarguments fabricated to ridicule a theory but actually support it: such as Siméon-Denis Poisson's argument that were Augustin-Jean Fresnel's wave theory of light true, a bright spot would appear at the very centre of the shadow cast by a circular obstacle (kudos to
John Larkin wrote in news: snipped-for-privacy@4ax.com : " Nowadays, serious electronics is far too complex to breadboard;"
Untrue, but it is true that much of the available embedded employment is not with breadboards, and may be too complicated for breadboards.
John Larkin wrote in news: snipped-for-privacy@4ax.com : " a CPU, flash, a few BGA FPGAs, eight or
10 linear and switching power supplies, and a thousand analog parts is common these days."John Larkin seems to have confused scale with seriousness.
John Larkin wrote in news: snipped-for-privacy@4ax.com : " We design and release all the documentation on rev A, have manufacturing build us a couple, and we make them work. Over
90% of the time, we can sell rev A, because we designed it right.It's quite common for a single (retard) EE to do 100% of the design of a product - definition, specs, parts selection, schematic, bom, pc layout, pld's, embedded code, datasheet, manual. How many (excellent) software types can do this?"
Congratulations, though were I recruiting an electronic engineer, I would rather choose one who would not be a retard as I would hope for better results from someone who is not retarded than results I would expect from someone who is retarded. As John Larkin mentioned that he can "sell" something I suspect that he makes products, which many people in embedded fields do. However, as embedded work is something which is put into something else, not everyone in an embedded field works on a product: e.g. I am involved in a mission in which far less than half of the mass is electronics and as in theory anyone can learn and do anything, in theory a lone single person could (very surrealistically) do what is taking hundreds of people (working on aspects other than just computers and electronics) many years to finish.
Vladimir Vassilevsky wrote in news:v26xh.41256$ snipped-for-privacy@newssvr21.news.prodigy.net : " From my experience, it appears to be much more productive not trying to get absolutely everything right at the rev. level A. For any more or less nontrivial design, it is very difficult to foresee everything. Moreover, it takes more time designing it to the perfection from the first try rather then doing 2-3 iterations. Also, while the project is moving on, the specs tend to change. So, rev. A goes to the trash, rev. B is operational however it may need some fixes, and, finally, rev. C is released.
Just an example: a manual for a modern CPU is ~1000 pages. To do everything right from the first try, you have to read and understand the manual from cover to cover. However all that you really need to know is ~20 pages of the exact description of the features that you are going to use for this project. The 99.9% of the other information is mostly irrelevant and having to go through it just adds to the overhead.
[..]"John Larkin wrote in news: snipped-for-privacy@4ax.com : "[..]
But that takes, maybe, 4 weeks per iteration. The very assumption that rev A will not be deliverable is self-fulfilling. A day or two of careful checking can often skip a full spin. As a day or two of careful code review can often skip a month of chasing bugs.
[..]"Vladimir Vassilevsky wrote in news:LJ6xh.41265$ snipped-for-privacy@newssvr21.news.prodigy.net : "[..]
The opposite can be true also. Several days of carefull checking can very well be a wasted time. [..]"
Both approaches have merits. Finding out that the datasheets contain falsehoods or finding out that we have a broken component or finding out that our system is subject to a physical problem which we had not considered to be significant are examples of things which need an empirical attempt. So sooner is better than later, except of course when it is too soon. So, it depends.
Pete Smith wrote in news:My6xh.86560$ snipped-for-privacy@newsfe1-gui.ntli.net : "[..]
[..] an improper spec is impossible to design to because no-one really knows *what* it is supposed to do. [..] [..]"An improper specification could be something else, e.g. something which contains a fallacy (that is a computer science term for a contradiction or inconsistency) e.g. a requirement that every time a particular function returns, that it must return a multiple of six less than -234 and a requirement that every time this function returns that it is required to return a multiple of ten greater than 753.
Vladimir Vassilevsky wrote in news:v26xh.41256$ snipped-for-privacy@newssvr21.news.prodigy.net : "The formal training in CS is a definite plus for the embedded developer. It sets up the right methodology of the development and prevents from reinventing the wheels."
Yes. However, by being taught computer science, one can be aware of how to make something ("reinventing") instead of getting it from somewhere else, when appropiate, which is also good.
John Larkin wrote in news: snipped-for-privacy@4ax.com : "[..]
It's my opinion that modern CS education teaches a lot of very bad habits."
True.
Vladimir Vassilevsky wrote in news:LJ6xh.41265$ snipped-for-privacy@newssvr21.news.prodigy.net : "[..]
Like what, for example?"
Such as weak types; just use VxWorks because it is what everyone the lecturer asked said they use; pictures instead of designs (also in university in another subject); neither incompetence nor ignorance need to impede one's career (as a lecturer anyway (one unfortunately finds out later that this does not apply only to academics)) (also in university and outside of university in another subject); use the end of a line to end a comment; do not pay for software which is not gratis; do not bother to use a filename which makes it easy to determine what application could open a file; if you have access to a UNIX(R) machine, just keep it in its crappy UNIX(R) defaults and enforce a ten megabyte disk quota which is enough for the temporary files of X Windows's to have your logging in privileges disabled even if you do not install a decent GNU substitute for a lame UNIX(R) program; use only Windows; use only Java; code metrics; not even mentioning version tracking software; be so stupid that you can not understand one line of VDM-SL you just finished writing a few seconds ago but be a former developer of a train (avoiding rail travel in Europe may be safe); cancel a lecture as it would clash with a professional sporting event; never consider temperature; never consider cost; bad designs are successful; do not consider memory; do not mention hardware description languages; encourage interleaving threads on a single processor; increase your salary instead of buying good tools; republish almost the same content of some of your earlier papers without making clear what has changed; giving the answer the examiner mistakenly believes is right in order to pass; not understanding someone else's lecture notes which you are using and punishing students who do not do well enough even though they know the topic at least as well as you (which is not very well at all); ...
Pete Smith wrote in news:My6xh.86560$ snipped-for-privacy@newsfe1-gui.ntli.net : "[..]
I have a CS degreed coworker who apparently believes it is beneath him to read the *entire* datasheet for a peripheral unit (in this case a very simple part); this has happened a number of times where I have had to explain to him the operation of both the processor he is supposed to be programming for and the peripheral he is supposed to be using. I'm not saying all CS grads are like that, but if not, he's not the best advertisement. If not reading the entire datasheet (i.e. understanding the complete operation of the device) is the CS methodology, no wonder they get a (deserved in that case) bad rap."
I understand and disapprove of this attitude of fellow computer scientists. Not understanding something he must read is one thing, refusing to even read it is another. Fire him.
Regards, Colin Paul Gloster
When you realise that you have vagueness in a specification it is sometimes time to consider constructing a prototype of the solution for just the vague part. These "try-it-out" style of prototypes are a side project, not to be considered as part of the final product being developed. but to firm up the technical specifications so that a proper design can be achieved for the main project.
As the prototypes do not figure in the mainstream of development they do not need to be considered as revisions of the main project. They do need, though, some identity so that you can refer to them in meetings and at presentation of the results of tests with the prototypes.
-- ******************************************************************** 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.. ********************************************************************
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.