Re: suggestions for computer science background in embedded field

John Larkin wrote in
news:rdm9s29aa1hj14nvo51cv1j4kbhcl6sdrq@xxxxxxx
:
"[..]

In order to program things, the prime requirement is that you
understand things. [..]"


Aye.



Vladimir Vassilevsky wrote in
news:v26xh.41256$Gr2.3960@xxxxxxxxxxxxxxxxxxxxxxxxxx
:
"John Larkin wrote:


In order to program things, the prime requirement is that you
understand things. The programming part is just routine.

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$1@xxxxxxxxxxxxxxxxxxx
:
"[..]

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
WWW.SIGDA.org/Archives/NewsGroupArchives/comp.lang.vhdl/2006/Feb/comp.lang.vhdl.55830.txt
someone who used to be responsible for producing the breadboard for
software I was writing (though he was a student of something maybe
like telecoms engineering (retard)), and our design had several third
party peripheral devices multiplexed to a single port on a bus in a
mutually exclusive fashion. Unfortunately his (not our) design would
select one of the devices to be supposedly active (and so the others
would be supposedly in high impedance (disconnected)) by setting the
selected device to low (zero) and all the others to high (one) even
though the manufacturers for about half of the devices chose to make
them active high instead of active low. [..] he refused to check the
manufacturers'
datasheets because as I was a "software" person I would think that
devices are active high. More than a week later he still had not
bothered to check so I had to confront him in person with a printout
of one datasheet for one of the devices showing that it is active high
and a printout of a datasheet for one of the other devices showing
that it is active low and hold them up in front of him side by
side. At least he immediately conceded that what I was saying was
right and he thanked me.

[..]"

John Larkin wrote in
news:rdm9s29aa1hj14nvo51cv1j4kbhcl6sdrq@xxxxxxx
:
"[..]

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
WWW.Britannica.com/eb/article-60620/principles-of-physical-science
for reminding me of names)).


John Larkin wrote in
news:rdm9s29aa1hj14nvo51cv1j4kbhcl6sdrq@xxxxxxx
:
" 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:rdm9s29aa1hj14nvo51cv1j4kbhcl6sdrq@xxxxxxx
:
" 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:rdm9s29aa1hj14nvo51cv1j4kbhcl6sdrq@xxxxxxx
:
" 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$Gr2.3960@xxxxxxxxxxxxxxxxxxxxxxxxxx
:
" 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:uqr9s2dfmdph2ua1ga0pslcinj1i2kde90@xxxxxxx
:
"[..]

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$Gr2.39658@xxxxxxxxxxxxxxxxxxxxxxxxxx
:
"[..]

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$HV6.47272@xxxxxxxxxxxxxxxxxxxx
:
"[..]

[..] 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$Gr2.3960@xxxxxxxxxxxxxxxxxxxxxxxxxx
:
"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:uqr9s2dfmdph2ua1ga0pslcinj1i2kde90@xxxxxxx
:
"[..]

It's my opinion that modern CS education teaches a lot of very bad
habits."


True.


Vladimir Vassilevsky wrote in
news:LJ6xh.41265$Gr2.39658@xxxxxxxxxxxxxxxxxxxxxxxxxx
:
"[..]

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$HV6.47272@xxxxxxxxxxxxxxxxxxxx
:
"[..]

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
.

Relevant Pages

  • Re: snow!
    ... This is an electronic design group, ... be happy that I'm not designing electronics at the moment? ... Because I'm not willing to think the same way as John Larkin does - ... A couple of my ideas have ended up in patents, ...
    (sci.electronics.design)
  • Re: BJT Can be Considered a CCCS in some situations
    ... John Larkin wrote: ... I don't design transistors, I design electronics, so I ... > I don't recall anybody discussing intrinsic device physics here. ... when I stated "the bipolar transistor is a voltage controlled device". ...
    (sci.electronics.design)
  • Re: Where are all the ESR meters?
    ... John Larkin wrote: ... voltages when probing in-circuit storage capacitors. ... Interesting that for a proposed "group design", ...
    (sci.electronics.design)
  • Re: Debouncing....at About 1Mhz
    ... John Larkin wrote: ... Clearly it needs some delay. ... So design and post something and quit whining. ... grow a mustache for the first time in your life... ...
    (sci.electronics.design)
  • Re: Newer Model Instrumentation Amp
    ... On Jun 21, 9:57 am, John Larkin ... Would have guessed the fault current ... Supertex's datasheet says "not recommended for new design." ...
    (sci.electronics.design)