What does an embedded beginner need to know?

Too generic, narrow down "embedded hardware and software" to at least a bit width of processor and a yes/no to the question "is there an OS already?"

Well, my bias would be 8 bits and no OS. But maybe there are good arguments otherwise, so I don't want to narrow down at this point. I'm trying to hear views outside my natural inclinations.

Mike

1. Elementary digital electonics. Enough to be able to build a simple computer.
2. Elementary analog electronics. Enough to use transistors and op-amps.
3. Assembly language for at least one machine.
4. Higher level language. C is suitable. Pascal is better, but rarer. Also consider Ada.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

Ok, here goes, from years of work with embedded guys (I am an analog dude myself):

a. Do not trust the POR/BOR on a uC. b. If marketing says the POR/BOR is really good, don't believe it. c. Learn how to roll your own POR/BOR.

Seriously, this is not a joke. By far the most grief I unearthed in embedded designs was related to that.

d. Learn a little bit about simple HC logic.

I found that embedded guys would often try to do everything within the confines of a processor. Cases where they selected a larger uC at over a buck in added cost where a couple of 15c shift registers would have sufficed to give them the additional port pins. The topper was when I put a big fat DSP out of a job. All that was left for it was handling two RS232 links.

e. Get a copy of "The Art of Electronics"

Some embedded guys know next to nothing about the transistors and whatnot that the hardware guys connect to a uc. Or maybe even an inductor. It's ok not to be too familiar with discretes but the book will help them understand if they have to.

f. Use the WDT and resist the temptation to kidnap its timer. g. Make a hazard analysis and stick to it.

f and g is the 2nd on my "bug unearthing list". It's so easy to get lost in the code, to the point where one fails to think about what happens when event 23A does not result in valve 3 to be actuated because the driver FET has blown out.

h. Take a peek at the layout.

This is 3rd on the list. They should get familiar with how a good layout looks like. Then when they see there's only one lone bypass cap somewhere in the boonies and numerous splits in the ground plane they should become suspicious and get a 2nd opinion.

i. Learn when to hold'em and when to fold'em.

This would be 4th. Often folks try to do it all on their own. Until the day of reckoning cometh at the EMC lab or somewhere. A second pair of eyes could have told them that they'd better not let the address lines chat around when not needed and so on.

j. Learn about ESD.

Often LCD lines, keyboard lines, D-sub-something connections and such are left completely unprotected, running smack dab into a port pin. All it takes is a dry winter day and a pair of Nikes ... tsssk ... phut ... nothing goes anymore.

k. Consider 2nd sourcing.

Not easy with uC, other than the trusty old 8051 44-pinners. But: Often the board can be designed to accept two or more uC of different brands that aren't 100% identical. At least it's worth a consideration.

Hope this helps.

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

If you are most experienced with 8 bits/no OS then teach that. The fact of the matter is that the things a programmer on a 1GHz uC with

512MB RAM running Linux needs to know are not the same things a programmer writing code for a 1K PIC needs to know, and trying to make one program teach everything is a recipe for failure. Take the topic you know best and engage your students with this information.

Yes. I'll second that. However, tell them that crossing from 8bit turf onto 16bit turf such as the MSP430 is really not rocket science. At least to me it wasn't.

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

a

The Lament of Embedded computing

Embedded computing is like the insect species Embedded is everywhere, insects are everywhere Embedded comes in many sizes, shapes and forms Insects come in many sizes, shapes and forms Some insect species can live almost anywhere Some insect species can only live in specific places Some insect species can only live with certain animals Some embedded computing aspects can be used anywhere Some embedded computing aspects can only be used in specific places Some embedded computing aspects can only be used with certain ndustries

Embedded computing is like the insect species Embedded is everywhere, insects are everywhere

(Copyright 2009 Paul Carpenter)

--=20 Paul Carpenter | snipped-for-privacy@pcserviceselectronics.co.uk PC Services Timing Diagram Font GNU H8 - compiler & Renesas H8/H8S/H8 Tiny For those web sites you hate

1. Start with reading the original datasheets and manuals, not the retellings, interpretations or other fiction.
2. After you read the datasheet, read the errata sheet and check with the version of the chip that you have.
3. Don't make any assumptions like if this works for microcontroller X, that should work in the same way for microcontroller Y.
4. Make sure the PWM width is never set to 0 or equal or higher then the period. This is a very common mistake.
5. Provide some means for debugging, production testing and repair. Like LEDs, RS-232 or JTAG, test points on the PCB.
6. Before developing a feature, think how you are going to test it. Not tested === no feature.
7. Professionals don't power the LEDs from logic '1' at the outputs. A logic output is a sink, it is sourcing only to an extent.
8. When planning on memory/speed utilization, don't go over 60%. You will need this reserve later.
9. Don't use the example code that comes with the compiler or evaluation board. Application engineers are not engineers.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

It's too broad to define. I'm right now working with a Broadcom

3548, a Connected Device DTV SoC - it has, in addition to the ATSC/HDMI/component receivers and FHD/surround audio codecs on chip also not one but two 400MHz MIPS32 cores. It has a compositing graphics core with OpenGL support. Plus the usual ethernet etc. Our system runs an embedded Linux SMP kernel. Here's the public brief; it's pretty amazing what they've crammed into a single chip:

Working with a system like this is *completely* different from a logic-substitute 16-pin PIC bit banger.

You might want to start your lecture series with a characterization of embedded systems, and then let the participants know which area you're going to focus on.

I'm curious, does the typical first university course in embedded programming focus on such high-end hardware and software?

Paul Carpenter wrote:

To pick a nit: I was going to refute this by using Yellowjacket as an example

--but it appears that too is too broad:

Yeah, it also bugs me when people say "the human race".

Teach how to read a data sheet. Absolute maxiumum ratings are not operating regions. What the front descriptive paragraphs promise, the expanded details take away.

Robert

I have no idea. Isn't this your domain expertise?

Yellowjackets _are_ everywhere, at least right now. Then, when too many years of unfettered "growth" happens you see a bloat not unlike MS-Windows:

[...]

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

I missed an important one:

l. Document, document, document, start _before_ writing code.

Commented source code is not documentation. Good planning before writing code is very valuable. As one of my bosses put it: "If you didn't document it, it didn't happen".

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Joerg wrote:

With the wave of warm weather, I did check the eves.

Holy cow! Whatever he's growing there, they sure do like the ecosystem.

I like your list in this thread--especially the addendum. When I read the Subject line, I was expecting to see several like what Vladimir wrote.

I like his point about the PWM. The situation I witnessed was the opposite, someone had left the PWM at 100% ... a high amperage smell wafted through the room, then ... *BANG*

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

a

If they have some programming experience, then tackle this from a physical-numbers angle.

Pin Count is a good one. Silicon area is another. PCB layers is another.

- show them some 6 pin uC - in the sub 50c region. (eg Freescale RS08, Atmel ATiny10, MicroChip PIC12? et al) - and show them code for a Toothbrush timer. That's a peg in the ground.

Then, chose something they are likely to already know, but may not really know the content, such as MP3 players / cell phones. Do a Pincount / Silicon area / PCB layer comparison, and you have another peg in the ground.

-jg

That is why I said 'species' meant as in plural of all insect species..

Well I would always come last, in that race...

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate