Looking for recommendations: schematic reading turotial

Paul Keinanen wrote:
> "Adrian" <adrianbica@yahoo.com> wrote:
>> "Ignacio G.T." <igtorque.rem...@evomer.yahoo.es> wrote:
>>>
>>> By concentrating his/her efforts in the application part and
>>> leaving the "low level details" to real men/women of the same
>>> team?
>>
>> Then he/she is not "experienced"!
> 
> Embedded systems are quite often tested using a row of switches
> to simulate binary inputs, potentiometers to simulate analog
> transducer signals and LEDs for monitoring digital outputs. In
> order to test an embedded software using these tools, very little
> knowledge of electronics is needed, but still you may have to
> write device drivers etc.
> 
> The software designer in a team does not usually have to worry
> about galvanic isolation, input protection and EMC filtering,
> which are done specialised HW people.
> 
> Still it helps if the software designer is able to look at the
> circuit diagram, e.g. to determine if the buffer stage between
> the processor pin and the external (say 20 mA) circuit is
> inverting or not, in order to write the correct polarity into
> the output register.

To illustrate the importance of knowing something, some years ago I
arrived on a job to create PIC software.  Most things had already
been laid out, and prototype boards made.  I found a circuit
inputting push buttons from a panel where there was a pull-up
resistor and a capacitor to ground on the input pin.

I made some fuss about this, and got a series resistor added from
the actual switch.  The problem would not have shown up until some
time in the field, when the inrush current from the capacitor
discharge would have welded the switch contacts, leading to a poor
quality reputation.

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>



-- 
Posted via a free Usenet account from http://www.teranews.com

On 20 Mar 2007 10:50:29 -0700, "Adrian" <adrianbica@yahoo.com> wrote
in comp.arch.embedded:

> On Mar 18, 9:21 pm, Jack Klein <jackkl...@spamcop.net> wrote:
> > I have a colleague who is an experienced embedded programmer, but she
> > never had any formal electronics training and she has asked me to try
> 
> This sounds really weird. How can someone be an "experienced embedded
> programmer" without being able to read schematics?

Believe it or not, it is quite possible for someone to be an
"experienced embedded programmer" without being an expert at reading
schematics.  A very large part of embedded programming involves
reading the data sheets for the controller and on-chip and off-chip
peripherals, which she can do quite well.

You can even control analog circuitry quite well by just knowing what
value you need to see when reading the ADC, without understanding the
transfer function of the signal through the amplifiers that the board
designer put in place.

My colleague is from Germany, and the educational system there at the
time meant she was allowed to attend a limited technical training
school, rather like our junior colleges, I gather.  A male with a
similar interest in embedded system development would have been
welcome at the real university.

There are times when she is bringing up new boards or circuit designs
when she feels that more expertise in reading schematics, especially
since ours use some different symbols from the European ones she used
to deal with, would help.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

Jack Klein wrote:
> On 20 Mar 2007 10:50:29 -0700, "Adrian" <adrianbica@yahoo.com> wrote
> in comp.arch.embedded:
> 
> 
>>On Mar 18, 9:21 pm, Jack Klein <jackkl...@spamcop.net> wrote:
>>
>>>I have a colleague who is an experienced embedded programmer, but she
>>>never had any formal electronics training and she has asked me to try
>>
>>This sounds really weird. How can someone be an "experienced embedded
>>programmer" without being able to read schematics?
> 
> 
> Believe it or not, it is quite possible for someone to be an
> "experienced embedded programmer" without being an expert at reading
> schematics.  A very large part of embedded programming involves
> reading the data sheets for the controller and on-chip and off-chip
> peripherals, which she can do quite well.
> 
> You can even control analog circuitry quite well by just knowing what
> value you need to see when reading the ADC, without understanding the
> transfer function of the signal through the amplifiers that the board
> designer put in place.
> 
> My colleague is from Germany, and the educational system there at the
> time meant she was allowed to attend a limited technical training
> school, rather like our junior colleges, I gather.  A male with a
> similar interest in embedded system development would have been
> welcome at the real university.
> 
> There are times when she is bringing up new boards or circuit designs
> when she feels that more expertise in reading schematics, especially
> since ours use some different symbols from the European ones she used
> to deal with, would help.

What CAD packages do you run there ? - often they have Eval versions, 
that can read-only any design file, and she could load/peruse the 
drawings, and use the query features, on any symbol she was unsure of.
(eg I think NOR/NAND/XOR differ & maybe Pwr/Gnd conventions) - most
'box' symbols are fairly generic. C's and R's should be very portable.

It helps to learn on something that is at least partly familiar so give
her some SCHs from boards she has worked on.

-jg

> My colleague is from Germany, and the educational system there at the
> time meant she was allowed to attend a limited technical training
> school, rather like our junior colleges, I gather.  A male with a
> similar interest in embedded system development would have been
> welcome at the real university.
Why do you think there is a difference between female and male in the
educational system of Germany? There are different forms of
institutions where one is able to learn the skills. But there is no
difference between male and female.

On Mar 21, 3:57 pm, Jonathan Kirwan <jkir...@easystreet.com> wrote:
> On 21 Mar 2007 11:15:51 -0700, "Ed Prochak" <edproc...@gmail.com>
> wrote:
>
> >On Mar 21, 11:50 am, "Adrian" <adrianb...@yahoo.com> wrote:
> >> On Mar 21, 9:47 am, "Ignacio G.T." <igtorque.rem...@evomer.yahoo.es>
> >> wrote:
>
> >> > By concentrating his/her efforts in the application part and leaving the
> >> > "low level details" to real men/women of the same team?
>
> >> Then he/she is not "experienced"!
>
> >Depends on the type of embedded system.  Not all embedded applications
> >are memory constrained, hardware controller, no OS programs.  Running
> >ontop of a realtime OS the higher application might only have to worry
> >about their realtime deadlines, not hardware registers.
>
> Yes, but then what is the difference from that and any general
> programmer writing applications on general purpose computing
> platforms?
>
> To me, what makes you more (or less) an embedded programmer is the
> degree to which you require skills outside of those required by
> programmers working on general purpose computing systems.  Do you need
> to understand linker details and influence the linking process?  Do
> you need to write assembly?  Do you directly control hardware or
> interact with electronic components you need to understand?  Do you
> need to concern yourself with Harvard achitecture variances from the C
> system model?  Do you need to delve into the generated code sometimes?
> Are you cycle-counting because you need to have alternate paths of
> code branches take exactly the same number of CPU cycles?  Are you
> wriing what amounts to a BIOS or O/S?  Do you need to understand
> numerical methods well and analyze error propagation and control it?
> Do you find many of your projects requiring you to understand signal
> processing basics?  Do you need to read schematics and influence their
> design?  Do you need to understand sensor and transducer physics?  Do
> you find many of your projects requiring you to be fluent in linear
> algebra, ordinary differential equations, group theory, kalman or
> other optimal filtering theories, fourier and laplace, compiler
> parsing theory, dynamical catastrophe theory, etc?
>
> If you find more of your work merrily assuming a general operating
> system and BIOS you can rely upon for detailed control of hardware, if
> you find more of your work allowing you to just write C or C++ code
> and never really needing to expand your vistas beyond that space, if
> you find your programming life and programming concerns and problems
> little different from those who actually _do_ program on general
> purpose computing platforms then to that degree you are not an
> embedded programmer.  It's the differences from general programming,
> those general programming skills usually taught in basic undergrad
> courses, that make one more experienced as an embedded programmer.
>
> Jon

I tried replying twice, but both seem to have been lost. Here's one
last try.
some of my earlier thoughts are lost now,
 and I give up on addressing you point by point.

Jon,

You seem to be mixing lowlevel realtime requirements with embedded
systems.

here's my simpe view of an embedded system:
if it looks like a computer to the end user, then it's not embedded
if it looks like a specialized device to the end user, then it is an
embedded system.
the simplest way to say it might be:
if your team/devision/company is building a "thing"
 then you are doing embedded programming.

Examples:
personally I tend to think of PDAs as small computers, but not all
users would agree with me. There are some devices that sit on the edge
like this.

Most users would agree the following are not computers,
    IOW they agree these are embedded systems:
printers
radar
ATMs
microwave ovens
diagnostic medical devices (from glucode meters up to CAT scanners and
in between)
typesetting systems
cellphones (though newer models are starting to look more computer-
like)
cable tuners
some HVAC controllers (got a digital thermostat in your home?)
aircraft controls (especially on "fly by wire" models have lots of
embedded software)
ABS (anti-lock Braking systems)
basically any product using digital hardware and software, where the
end user looks at it as a widget and not a computer is an embedded
system.

I'll give an example from personal experience. On one assignment, I
developed a QC package for a diagnostic medical device. This product
tested blood and urine samples for things like glucose and albumin
(many different tests). the QC package involved basically two parts.
the first part would fit your criteria for embedded software. It
provided graphics primitives by writting directly to the display frame
buffer. This was the low level software that needed intimate knowledge
of the hardware. The other part would fail your criteria. It took the
QC data and provided various analysis reports, including plots of the
data using the new graphics routines from the other part.

In my view both parts of that QC package were embedded programming,
because the end user saw them as part of teh device. They did not view
the device as a computer, but as a diagnostics machine. The
higherlevel part of the QC package could have run just as well on a
PC, but there the users would see it as just another program on a
computer. The key differrence between you and I is exactly that.

It is not how close to the metal you program, but what the end user
sees IMHO.
   ed

On Mar 23, 1:31 pm, "Ed Prochak" <edproc...@gmail.com> wrote:
> In my view both parts of that QC package were embedded programming,
> because the end user saw them as part of teh device. They did not view
> the device as a computer, but as a diagnostics machine. The
> higherlevel part of the QC package could have run just as well on a
> PC, but there the users would see it as just another program on a
> computer. The key differrence between you and I is exactly that.
>
> It is not how close to the metal you program, but what the end user
> sees IMHO.
>    ed

Ed,

I think we all agree that there are pieces of code on embedded systems
which are not necessary involving some hardware. We call this
"Application layer". But this was not the question here.
The question here was if you can call a software programmer who worked
only on this kind of stuff, an "experienced embedded programmer".
Beside that, how can you spend your life close to hardware engineers
or at least close to hardware systems  and not learn on the fly how to
read several trivial schematics symbols?

Adrian

On 23 Mar 2007 11:31:39 -0700, "Ed Prochak" <edprochak@gmail.com>
wrote:

><snip>
>It is not how close to the metal you program, but what the end user
>sees IMHO.

Thanks for going to so much trouble.  I'm sorry it worked out that way
and you have my sympathies -- been there, myself.

I just cannot agree with you, though.  What 'defines' embedded to me
has NOTHING to do whatever with what the end user sees.  That's
because this work is my life and my joy and much as a gunsmith has so
much more to being a gunsmith than what a user of a gun can possibly
know about, so it is with my work, as well.  I grant you can try and
define things the way you choose to, but then that definition wouldn't
be of much value to me, personally, and I'd need to find another
phrase for it.  And frankly, I don't think it really makes much sense
to let end-use define what my work and practice mean to me.  It's
about what I see in the work, not what others see in their use of
products and applications.

To me, the term carries real meaning to practitioners.  (I was careful
in my earlier comment to point out that this is how I see it and folks
can choose their own way, of course.)  There is quite a range of
difference in mindset, skills, interests, talents and so on that work
to make _embedded_ work different.  There is and has for quite some
time been a difference between programming work performed upon general
purpose programming systems and work which is performed where this
supporting infrastructure is to some degree or even nearly completely
absent and where also the needs require other tools and skills not
normally required on general operating systems.

The example I gave about having to deal with linkers can be expanded
to make this point.  On general purpose computing systems, one does
not need to even understand well the programming model that a compiler
conforms to and that an operating system assumes and doesn't need to
know about memory segments (and here I'm using the term NOT in the
narrow sense of an Intel x86 processor's hardware, but in the far more
general meaning that a linker writer uses the term) and the ability to
duplicate them intact to other memory regions without pointer
adjustment or to deal with memory aliasing sometimes found in systems
that ignore some addressing lines, but where this is meaningful in an
embedded application and quite useful.

It is the fluency of the differing tools and knowledge applied that
makes the difference, from my long experience in the field.  It's that
reason why I personally use the term 'embedded.'  You are free, of
course, to use your meaning.  It just isn't helpful to me to see
things that way.  I understand where you are coming from, I just must
disagree with it.

Think of this like you might think about the difference between a
common homebuilder using modern tools and someone trained to build a
home without nails or screws or electrical power tools, but using
wooden pegs and mortise and tenon and using tools, such as chisels,
that can be built from much more prosaic and less technological tools.
There would be a difference in practical skills and tools used worth
nothing here and this difference would have little to do with what a
home-buyer sees in the finished product (though there will be
differences there, as well.)

Jon

On Fri, 23 Mar 2007 19:30:46 GMT, Jonathan Kirwan
<jkirwan@easystreet.com> wrote:

> worth nothing here

Sorry, I meant "worth _noting_ here"

Jon

On Mar 23, 3:30 pm, Jonathan Kirwan <jkir...@easystreet.com> wrote:
> On 23 Mar 2007 11:31:39 -0700, "Ed Prochak" <edproc...@gmail.com>
> wrote:
>
> ><snip>
> >It is not how close to the metal you program, but what the end user
> >sees IMHO.
>
> Thanks for going to so much trouble.  I'm sorry it worked out that way
> and you have my sympathies -- been there, myself.
>
> I just cannot agree with you, though.  What 'defines' embedded to me
> has NOTHING to do whatever with what the end user sees.  That's
> because this work is my life and my joy and much as a gunsmith has so
> much more to being a gunsmith than what a user of a gun can possibly
> know about, so it is with my work, as well.  I grant you can try and
> define things the way you choose to, but then that definition wouldn't
> be of much value to me, personally, and I'd need to find another
> phrase for it.  And frankly, I don't think it really makes much sense
> to let end-use define what my work and practice mean to me.  It's
> about what I see in the work, not what others see in their use of
> products and applications.

I also have enjoyed nearly all of my embedded programming
assignments.

The enduser provides the context.
to use your analogy.
 Whether you hand craft the gun or mass produce it, you are a gun
maker.
 Whether you program the software for a device using assembler or a
high level language, you are an embedded programmer.
>
> To me, the term carries real meaning to practitioners.  (I was careful
> in my earlier comment to point out that this is how I see it and folks
> can choose their own way, of course.)  There is quite a range of
> difference in mindset, skills, interests, talents and so on that work
> to make _embedded_ work different.  

YES, it is the mindset.
Knowing that the end product should be perceived as something in it's
own right and not as a computer that does something makes the programs
in that system embedded.


>  .... There is and has for quite some
> time been a difference between programming work performed upon general
> purpose programming systems and work which is performed where this
> supporting infrastructure is to some degree or even nearly completely
> absent and where also the needs require other tools and skills not
> normally required on general operating systems.

The first part about missing supporting infastructure is true in many
cases but not all.
I want to be able to include those systems that have an OS, are
programmed in a high level language, that are field upgradable by
installing new software, that have remote diagnostic
interfaces(including internet connections) as embedded systems.

Yes ther are skills not normally needed. A common example is error
recovery. You cannot simple throw an error up on the screen (there
might not be one), and ask the user to fix the problem. Programming in
that environment takes different skills and a different mindset. We
agree a lot here.

>
> The example I gave about having to deal with linkers can be expanded
> to make this point.  On general purpose computing systems, one does
> not need to even understand well the programming model that a compiler
> conforms to and that an operating system assumes and doesn't need to
> know about memory segments (and here I'm using the term NOT in the
> narrow sense of an Intel x86 processor's hardware, but in the far more
> general meaning that a linker writer uses the term) and the ability to
> duplicate them intact to other memory regions without pointer
> adjustment or to deal with memory aliasing sometimes found in systems
> that ignore some addressing lines, but where this is meaningful in an
> embedded application and quite useful.

So then in your definition, a compiler writer is an embedded
programmer because he has to think about these things.  Any programmer
having to interface between different languages may have to be aware
of these things.
And by this you specifically exclude those writing application code on
the higher level. What happened to picking the right tool for the job?
Note in this context that application code might be meaningless
outside of the device, IOW it is not general progamming.

>
> It is the fluency of the differing tools and knowledge applied that
> makes the difference, from my long experience in the field.  It's that
> reason why I personally use the term 'embedded.'  You are free, of
> course, to use your meaning.  It just isn't helpful to me to see
> things that way.  I understand where you are coming from, I just must
> disagree with it.

I see your point, but I suggest it is rather limiting. Some of the
things you mentioned in an earlier post could easily fall under the
category of scientific programming. You would, I think, agree that not
all scientific programming is embedded.

Also your definition limits you in the search for possible solutions
to developing a new embedded system.  It reminds me of an earlier
experience I had. I do not think you would react this way, but someone
following your definition might be tempted to do this:
On a new embedded project, a contract engineer said he did not want
the overhead of the company's embedded kernal. He claimed to be able
to program a statemachine that coule deal with everything. I pointed
out two things, first that his statemachine would have to also handle
programming all teh included devices, like interrupt controllers and
that this was thus new and untested code, lenghtening the project
schedule. Then secondly I demonstrated for him the low overhead of our
kernal. He realized his statemachine would not be able to perform as
well, or be as flexible. His statemachine required applications to be
aware of one another saving state in the application code, not quite
as flexible as a priority driven OS where context switches were all
handled in the OS. In the end he accepted programming under the OS and
the product was produced. All of this was due to his mindset that
embedded sytems were written on the bare metal, with little or no
infrastructure provided. That may be the case for very small
controller devices, but not for all embedded systems.



>
> Think of this like you might think about the difference between a
> common homebuilder using modern tools and someone trained to build a
> home without nails or screws or electrical power tools, but using
> wooden pegs and mortise and tenon and using tools, such as chisels,
> that can be built from much more prosaic and less technological tools.
> There would be a difference in practical skills and tools used worth
> nothing here and this difference would have little to do with what a
> home-buyer sees in the finished product (though there will be
> differences there, as well.)
>
> Jon

SO, do I understand this analogy of your correctly? the programmer
that does it by programming in assembler, without an OS or BIOS, and
develops his own library routines (including those for common features
like printf() calls) is an embedded programer. Another programmer that
installs a BIOS, ports an OS, and programs in high level languages is
by this analogy not an embedded programmer.
Do I have that right. If not I really don't see this analogy at all in
the context of this discussion.

Bottom line. BTW  is that a agree that you need more awareness of the
hardware when programming embedded, than when doing general
progamming. It seems you think that should be the primary focus of the
embedded programmer. And I think the focus is on the final product,
the hardware is considered only within that context.

We are not that far apart really, just s shift of focus. And I'm sure
we would have a great time discussing this and other things over a
beer sometime.

Ed Prochak

On Mar 23, 3:34 pm, Jonathan Kirwan <jkir...@easystreet.com> wrote:
> On Fri, 23 Mar 2007 19:30:46 GMT, Jonathan Kirwan
>
> <jkir...@easystreet.com> wrote:
> > worth nothing here
>
> Sorry, I meant "worth _noting_ here"
>
> Jon

understood.