Looking for recommendations: schematic reading turotial

This may be obsolete, but how about the ARRL handbook?

--
 
 
 
 "A man who is right every time is not likely to do very much."
                           -- Francis Crick, co-discover of DNA
 "There is nothing more amazing than stupidity in action."
                                             -- Thomas Matthews

Symbols:

I guess this is as good a page as you will find: (Uses Cadsoft EAGLE for artwork, so symbols are Yurpeen) http://66.102.9.104/search?q=cache:6rL03uKDGK8J:

The original link for Google's spider:

Other starter pages:

http://66.102.9.104/search?q=cache:_OCkLUlbiGUJ:doctord.dyndns.org:8000/courses/Topics/Electronics/Mark_Sokos/How_to_read_schematics.htm

More pages here (of lesser quality) if you want them.

Excellent suggestion; I also suggest collecting at least one Handbook per decade from 1960 onwards.

Regards,

Michael

This sounds really weird. How can someone be an "experienced embedded programmer" without being able to read schematics?

By concentrating his/her efforts in the application part and leaving the "low level details" to real men/women of the same team?

-- A real man.

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.

Ed

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

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.

Paul

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.

On 20 Mar 2007 10:50:29 -0700, "Adrian" wrote in comp.arch.embedded:

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

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

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.

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

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

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

Sorry, I meant "worth _noting_ here"

Jon

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.

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.

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.

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.

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.

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

understood.