I've been asked to write a tutorial to introduce people who have had a
bit of programming experience to embedded hardware and software.  I
can think of plenty of material for such a tutorial, but I don't want
to miss something important, or treat my particular background as
universal, so I'm hoping that some of you will offer your top N things
to teach an embedded newbie (with N being a function of your free time
and/or enthusiasm).  Thanks,

Mike

On Apr 21, 7:26=A0pm, Mike Silva <snarflem...@yahoo.com> wrote:
> I've been asked to write a tutorial to introduce people who have had a
> bit of programming experience to embedded hardware and software. =A0I

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?"

On Apr 21, 7:34=A0pm, zwsdot...@gmail.com wrote:
> On Apr 21, 7:26=A0pm, Mike Silva <snarflem...@yahoo.com> wrote:
>
> > I've been asked to write a tutorial to introduce people who have had a
> > bit of programming experience to embedded hardware and software. =A0I
>
> 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

Mike Silva wrote:
> 
> I've been asked to write a tutorial to introduce people who have
> had a bit of programming experience to embedded hardware and
> software.  I can think of plenty of material for such a tutorial,
> but I don't want to miss something important, or treat my
> particular background as universal, so I'm hoping that some of you
> will offer your top N things to teach an embedded newbie (with N
> being a function of your free time and/or enthusiasm).  Thanks,

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]: <http://cbfalconer.home.att.net>
            Try the download section.

Mike Silva wrote:
> I've been asked to write a tutorial to introduce people who have had a
> bit of programming experience to embedded hardware and software.  I
> can think of plenty of material for such a tutorial, but I don't want
> to miss something important, or treat my particular background as
> universal, so I'm hoping that some of you will offer your top N things
> to teach an embedded newbie (with N being a function of your free time
> and/or enthusiasm).  Thanks,
> 

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 <gasp> 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.

On Apr 21, 7:38=A0pm, Mike Silva <snarflem...@yahoo.com> wrote:

> Well, my bias would be 8 bits and no OS. =A0But 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.

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.

zwsdotcom@gmail.com wrote:
> On Apr 21, 7:38 pm, Mike Silva <snarflem...@yahoo.com> wrote:
> 
>> 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.
> 
> 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.

In article <50fab360-3ec8-47eb-a97b-
fcd64cf3e0da@k2g2000yql.googlegroups.com>, snarflemike@yahoo.com says...
> On Apr 21, 7:34=A0pm, zwsdot...@gmail.com wrote:
> > On Apr 21, 7:26=A0pm, Mike Silva <snarflem...@yahoo.com> wrote:
> >
> > > I've been asked to write a tutorial to introduce people who have had =
a
> > > bit of programming experience to embedded hardware and software. =A0I
> >
> > 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?"
>=20
> 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.
>=20
> Mike

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          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

Mike Silva wrote:
> I've been asked to write a tutorial to introduce people who have had a
> bit of programming experience to embedded hardware and software.  I
> can think of plenty of material for such a tutorial, but I don't want
> to miss something important, or treat my particular background as
> universal, so I'm hoping that some of you will offer your top N things
> to teach an embedded newbie (with N being a function of your free time
> and/or enthusiasm).  Thanks,

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
http://www.abvolt.com

Mike Silva wrote:
> I've been asked to write a tutorial to introduce people who have had a
> bit of programming experience to embedded hardware and software.  I
> can think of plenty of material for such a tutorial, but I don't want
> to miss something important, or treat my particular background as
> universal, so I'm hoping that some of you will offer your top N things
> to teach an embedded newbie (with N being a function of your free time
> and/or enthusiasm).

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:
http://www.broadcom.com/collateral/pb/3548-PB01-R.pdf

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.

On Apr 21, 9:41=A0pm, Jan Brittenson <bson@at_rockgarden.net> wrote:
> Mike Silva wrote:
> > I've been asked to write a tutorial to introduce people who have had a
> > bit of programming experience to embedded hardware and software. =A0I
> > can think of plenty of material for such a tutorial, but I don't want
> > to miss something important, or treat my particular background as
> > universal, so I'm hoping that some of you will offer your top N things
> > to teach an embedded newbie (with N being a function of your free time
> > and/or enthusiasm).
>
> It's too broad to define. =A0I'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. =A0It has a compositing
> graphics core with OpenGL support. =A0Plus the usual ethernet
> etc. =A0Our system runs an embedded Linux SMP kernel. =A0Here's the
> public brief; it's pretty amazing what they've crammed into a
> single chip:http://www.broadcom.com/collateral/pb/3548-PB01-R.pdf
>
> 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?

>>>Mike Silva wrote:
>>>>I've been asked to write a tutorial to introduce people who have had a
>>>>bit of programming experience to embedded hardware and software.
>>>>
Paul Carpenter wrote:
>The Lament of Embedded computing
>
>  Embedded computing is like the insect species
>[...]
To pick a nit:
I was going to refute this by using Yellowjacket as an example
--but it appears that too is too broad:
http://google.com/search?q=cache:3s_Pr_LmnS4J:en.wikipedia.org/wiki/Yellowjacket+genus+family+order+class

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

In article <QcuHl.15256$pr6.9045@flpi149.ffdc.sbc.com>, Vladimir 
Vassilevsky says...
> 
> 
> Mike Silva wrote:
> > I've been asked to write a tutorial to introduce people who have had a
> > bit of programming experience to embedded hardware and software.  I
> > can think of plenty of material for such a tutorial, but I don't want
> > to miss something important, or treat my particular background as
> > universal, so I'm hoping that some of you will offer your top N things
> > to teach an embedded newbie (with N being a function of your free time
> > and/or enthusiasm).  Thanks,
> 
> 1. Start with reading the original datasheets and manuals, not the 
> retellings, interpretations or other fiction.

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

Mike Silva wrote:

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

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

JeffM wrote:
>>>> Mike Silva wrote:
>>>>> I've been asked to write a tutorial to introduce people who have had a
>>>>> bit of programming experience to embedded hardware and software.
>>>>>
> Paul Carpenter wrote:
>> The Lament of Embedded computing
>>
>>  Embedded computing is like the insect species
>> [...]
> To pick a nit:
> I was going to refute this by using Yellowjacket as an example
> --but it appears that too is too broad:
> http://google.com/search?q=cache:3s_Pr_LmnS4J:en.wikipedia.org/wiki/Yellowjacket+genus+family+order+class
> 

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

http://en.wikipedia.org/wiki/File:TwoYearNest.jpg

[...]

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

Mike Silva wrote:
> I've been asked to write a tutorial to introduce people who have had a
> bit of programming experience to embedded hardware and software.  I
> can think of plenty of material for such a tutorial, but I don't want
> to miss something important, or treat my particular background as
> universal, so I'm hoping that some of you will offer your top N things
> to teach an embedded newbie (with N being a function of your free time
> and/or enthusiasm).  Thanks,
> 

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.

>>Paul Carpenter wrote:
>>>[...]
>>> Embedded computing is like the insect species
>>>[...]
>JeffM 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:
>>http://google.com/search?q=cache:3s_Pr_LmnS4J:en.wikipedia.org/wiki/Yellowjacket+genus+family+order+class
>>
Joerg wrote:
>Yellowjackets _are_ everywhere, at least right now.
>
With the wave of warm weather, I did check the eves.

>Then, when too many years of unfettered "growth" happens
>you see a bloat not unlike MS-Windows:
>http://en.wikipedia.org/wiki/File:TwoYearNest.jpg

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.

JeffM wrote:
>>> Paul Carpenter wrote:
>>>> [...]
>>>> Embedded computing is like the insect species
>>>> [...]
>> JeffM 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:
>>> http://google.com/search?q=cache:3s_Pr_LmnS4J:en.wikipedia.org/wiki/Yellowjacket+genus+family+order+class
>>>
> Joerg wrote:
>> Yellowjackets _are_ everywhere, at least right now.
>>
> With the wave of warm weather, I did check the eves.
> 
>> Then, when too many years of unfettered "growth" happens
>> you see a bloat not unlike MS-Windows:
>> http://en.wikipedia.org/wiki/File:TwoYearNest.jpg
> 
> 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.

On Apr 22, 11:38=A0am, Mike Silva <snarflem...@yahoo.com> wrote:
> On Apr 21, 7:34=A0pm, zwsdot...@gmail.com wrote:
>
> > On Apr 21, 7:26=A0pm, Mike Silva <snarflem...@yahoo.com> wrote:
>
> > > I've been asked to write a tutorial to introduce people who have had =
a
> > > bit of programming experience to embedded hardware and software. =A0I
>
> > 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. =A0But 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

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

In article <a4202556-3511-410e-b98c-
b53bc8238bf5@i28g2000prd.googlegroups.com>, jeffm_@email.com says...
> >>>Mike Silva wrote:
> >>>>I've been asked to write a tutorial to introduce people who have had a
> >>>>bit of programming experience to embedded hardware and software.
> >>>>
> Paul Carpenter wrote:
> >The Lament of Embedded computing
> >
> >  Embedded computing is like the insect species
> >[...]
> To pick a nit:
> I was going to refute this by using Yellowjacket as an example
> --but it appears that too is too broad:
> http://google.com/search?q=cache:3s_Pr_LmnS4J:en.wikipedia.org/wiki/Yellowjacket+genus+family+order+class

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

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

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

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

On Tue, 21 Apr 2009 19:52:01 -0700, Joerg
<notthisjoergsch@removethispacbell.net> wrote:

>Mike Silva wrote:
>> I've been asked to write a tutorial to introduce people who have had a
>> bit of programming experience to embedded hardware and software.  I
>> can think of plenty of material for such a tutorial, but I don't want
>> to miss something important, or treat my particular background as
>> universal, so I'm hoping that some of you will offer your top N things
>> to teach an embedded newbie (with N being a function of your free time
>> and/or enthusiasm).  Thanks,
>> 
>
>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".

No argument. However (there's always a "however" ;-) a tool like doxygen
http://www.stack.nl/~dimitri/doxygen/index.html comes in handy when it
comes time to document the nuts and bolts.

-- 
Rich Webb     Norfolk, VA

On Apr 22, 8:54=A0am, Rich Webb <bbew...@mapson.nozirev.ten> wrote:

> No argument. However (there's always a "however" ;-) a tool like doxygenh=
ttp://www.stack.nl/~dimitri/doxygen/index.htmlcomes in handy when

Good comments are necessary, but not sufficient. Doxygen is a nice way
of presenting comments without the accompanying code. But the hard
part of a good project is the design, which precedes most or all of
the implementation.

Mike Silva wrote:

> I've been asked to write a tutorial to introduce people who have had a
> bit of programming experience to embedded hardware and software.  I
> can think of plenty of material for such a tutorial, but I don't want
> to miss something important, or treat my particular background as
> universal, so I'm hoping that some of you will offer your top N things
> to teach an embedded newbie (with N being a function of your free time
> and/or enthusiasm).  Thanks,
>
> Mike

Details, details, details

Embedded is a special kind of programming done by special people
who can't wait for morning to continue their profession.

It is the rush that you get looking at the final product and saying
there is a little bit of me in there.

It just never goes away.

Several others have dealt with the technical details. I add my vote
for design planning should be done before the code is written.

Regards,

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com

Rich Webb wrote:
> On Tue, 21 Apr 2009 19:52:01 -0700, Joerg
> <notthisjoergsch@removethispacbell.net> wrote:
> 
>> Mike Silva wrote:
>>> I've been asked to write a tutorial to introduce people who have had a
>>> bit of programming experience to embedded hardware and software.  I
>>> can think of plenty of material for such a tutorial, but I don't want
>>> to miss something important, or treat my particular background as
>>> universal, so I'm hoping that some of you will offer your top N things
>>> to teach an embedded newbie (with N being a function of your free time
>>> and/or enthusiasm).  Thanks,
>>>
>> 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".
> 
> No argument. However (there's always a "however" ;-) a tool like doxygen
> http://www.stack.nl/~dimitri/doxygen/index.html comes in handy when it
> comes time to document the nuts and bolts.
> 

Extractor-style "documentation" never impressed me much, and that 
includes Doxygen. IMHO there needs to be a lot more prose around and not 
just glossary-type listings. In our case the rules are pretty simple, an 
inspector from the FDA who is not an embedded system specialist must be 
able to understand the stuff. If he doesn't then the FDA ain't gonna be 
happy. And if the FDA ain't happy, nobody's gonna be happy :-)

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

On Apr 22, 11:26=A0am, Joerg <notthisjoerg...@removethispacbell.net>
wrote:

> Extractor-style "documentation" never impressed me much, and that
> includes Doxygen. IMHO there needs to be a lot more prose around and

It's extremely useful when you have an ISO requirement "code must
include documentation" and are too lazy to actually do things like
sitting down before you open the compiler, and deciding on paper what
the product shall actually do (in detail).

It's also handy as a browseable reference of enums, data structures,
etc. and for tracking TODOs.

Joerg wrote:

> Extractor-style "documentation" never impressed me much, and that
> includes Doxygen. IMHO there needs to be a lot more prose around and not
> just glossary-type listings. In our case the rules are pretty simple, an
> inspector from the FDA who is not an embedded system specialist must be
> able to understand the stuff. If he doesn't then the FDA ain't gonna be
> happy. And if the FDA ain't happy, nobody's gonna be happy :-)

I agree.

There needs to be three documents first a design document that spells
out objectives approach and system functionality with subsections
on implementation approaches and design.

A user document that describes what the user sees, expects and does..

Finally the implementation hardware design and source code.

Regards,

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com

On Wed, 22 Apr 2009 08:26:28 -0700, Joerg
<notthisjoergsch@removethispacbell.net> wrote:

>Rich Webb wrote:
>> On Tue, 21 Apr 2009 19:52:01 -0700, Joerg
>> <notthisjoergsch@removethispacbell.net> wrote:
>> 
>>> Mike Silva wrote:
>>>> I've been asked to write a tutorial to introduce people who have had a
>>>> bit of programming experience to embedded hardware and software.  I
>>>> can think of plenty of material for such a tutorial, but I don't want
>>>> to miss something important, or treat my particular background as
>>>> universal, so I'm hoping that some of you will offer your top N things
>>>> to teach an embedded newbie (with N being a function of your free time
>>>> and/or enthusiasm).  Thanks,
>>>>
>>> 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".
>> 
>> No argument. However (there's always a "however" ;-) a tool like doxygen
>> http://www.stack.nl/~dimitri/doxygen/index.html comes in handy when it
>> comes time to document the nuts and bolts.
>> 
>
>Extractor-style "documentation" never impressed me much, and that 
>includes Doxygen. IMHO there needs to be a lot more prose around and not 
>just glossary-type listings. In our case the rules are pretty simple, an 
>inspector from the FDA who is not an embedded system specialist must be 
>able to understand the stuff. If he doesn't then the FDA ain't gonna be 
>happy. And if the FDA ain't happy, nobody's gonna be happy :-)

Yep and yep. No disagreement at all. First write down -- using full
sentences and correct grammar -- what it's supposed to do, what it
*does* do, and why, and how.

With some more reflection, doxy is probably too particularized for an
intro course. It is useful a year later, though, when the "The customer
wants us to add this new interface." Sort of like ctags on steroids...

-- 
Rich Webb     Norfolk, VA

Rich Webb wrote:
> On Wed, 22 Apr 2009 08:26:28 -0700, Joerg
> <notthisjoergsch@removethispacbell.net> wrote:
> 
>> Rich Webb wrote:
>>> On Tue, 21 Apr 2009 19:52:01 -0700, Joerg
>>> <notthisjoergsch@removethispacbell.net> wrote:
>>>
>>>> Mike Silva wrote:
>>>>> I've been asked to write a tutorial to introduce people who have had a
>>>>> bit of programming experience to embedded hardware and software.  I
>>>>> can think of plenty of material for such a tutorial, but I don't want
>>>>> to miss something important, or treat my particular background as
>>>>> universal, so I'm hoping that some of you will offer your top N things
>>>>> to teach an embedded newbie (with N being a function of your free time
>>>>> and/or enthusiasm).  Thanks,
>>>>>
>>>> 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".
>>> No argument. However (there's always a "however" ;-) a tool like doxygen
>>> http://www.stack.nl/~dimitri/doxygen/index.html comes in handy when it
>>> comes time to document the nuts and bolts.
>>>
>> Extractor-style "documentation" never impressed me much, and that 
>> includes Doxygen. IMHO there needs to be a lot more prose around and not 
>> just glossary-type listings. In our case the rules are pretty simple, an 
>> inspector from the FDA who is not an embedded system specialist must be 
>> able to understand the stuff. If he doesn't then the FDA ain't gonna be 
>> happy. And if the FDA ain't happy, nobody's gonna be happy :-)
> 
> Yep and yep. No disagreement at all. First write down -- using full
> sentences and correct grammar -- what it's supposed to do, what it
> *does* do, and why, and how.
> 
> With some more reflection, doxy is probably too particularized for an
> intro course. It is useful a year later, though, when the "The customer
> wants us to add this new interface." Sort of like ctags on steroids...
> 

Doxygen is good for source-code documentation - it lets you write more 
elaborate and structured documentation than plain comments, and it's 
tied tightly to the code in question.

But that's only for source code documentation - it is not appropriate 
for other documentation.

A project needs a good specification at the start - say what the program 
is supposed to do.  Getting that right is half the work - once you have 
a good specification, the rest is just implementation coding (and a bit 
of testing...).  If your specification is not good, then your code will 
be wrong even if it's perfect.

Of course, there's the old saying about specifications - programming 
from specification is like walking on water - it's easy when its frozen.

zwsdotcom@gmail.com wrote:
> On Apr 22, 11:26 am, Joerg <notthisjoerg...@removethispacbell.net>
> wrote:
> 
>> Extractor-style "documentation" never impressed me much, and that
>> includes Doxygen. IMHO there needs to be a lot more prose around and
> 
> It's extremely useful when you have an ISO requirement "code must
> include documentation" and are too lazy to actually do things like
> sitting down before you open the compiler, and deciding on paper what
> the product shall actually do (in detail).
> 

Agencies such as FDA or FAA won't likely give a hoot about whether it's 
ISO compliant enough. They want the docs to be per their standards and 
expectations or the result of an audit will be a closed door pep talk in 
the CEO's office ;-)


> It's also handy as a browseable reference of enums, data structures,
> etc. and for tracking TODOs.


Yes, for that it's probably quite useful. But not as ECO-ready 
documentation. At least I would not sign off on it.

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

Walter Banks wrote:
> 
> Joerg wrote:
> 
>> Extractor-style "documentation" never impressed me much, and that
>> includes Doxygen. IMHO there needs to be a lot more prose around and not
>> just glossary-type listings. In our case the rules are pretty simple, an
>> inspector from the FDA who is not an embedded system specialist must be
>> able to understand the stuff. If he doesn't then the FDA ain't gonna be
>> happy. And if the FDA ain't happy, nobody's gonna be happy :-)
> 
> I agree.
> 
> There needs to be three documents first a design document that spells
> out objectives approach and system functionality with subsections
> on implementation approaches and design.
> 
> A user document that describes what the user sees, expects and does..
> 
> Finally the implementation hardware design and source code.
> 

Ideally the documentation relating to implementation should be written 
concurrently. That's what I do when designing anything, always. There 
will be all the CAD windows and in parallel a fat and growing MS-Word 
file set, either on the same PC or a laptop next to it.

I've seen it too often where the final docs are done in hindsight, at 
the point when people are already stressed because of late-in-the-game 
issues that came up, or just because they'd rather move on to the next 
interesting project. So the stuff gets slapped together as fast as 
possible, to be "done with it". This leads to poor final documentation. 
The other reason why I do it concurrently is that I could be hit by a 
truck tomorrow and my clients still need to be able to get on with the 
project, without having to reverse engineer my designs.

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

Joerg wrote:

> Ideally the documentation relating to implementation should be written
> concurrently. That's what I do when designing anything, always. There
> will be all the CAD windows and in parallel a fat and growing MS-Word
> file set, either on the same PC or a laptop next to it.
>
> I've seen it too often where the final docs are done in hindsight, at
> the point when people are already stressed because of late-in-the-game
> issues that came up, or just because they'd rather move on to the next
> interesting project. So the stuff gets slapped together as fast as
> possible, to be "done with it". This leads to poor final documentation.
> The other reason why I do it concurrently is that I could be hit by a
> truck tomorrow and my clients still need to be able to get on with the
> project, without having to reverse engineer my designs.

We all have the same scars different truck. The amazing thing is
doing it "right" results in a better product sooner. Being beat up
because no code is being typed will extent the project.

Three or four years ago I wrote a code generator for a particularly
nasty processor. I spent 3 1/2 months on the design document and
a full day writing the code. The total changes to the code since "1"
satisfaction doing it right "priceless"

Regards,

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com

Walter Banks wrote:
> 
> Joerg wrote:
> 
>> Ideally the documentation relating to implementation should be written
>> concurrently. That's what I do when designing anything, always. There
>> will be all the CAD windows and in parallel a fat and growing MS-Word
>> file set, either on the same PC or a laptop next to it.
>>
>> I've seen it too often where the final docs are done in hindsight, at
>> the point when people are already stressed because of late-in-the-game
>> issues that came up, or just because they'd rather move on to the next
>> interesting project. So the stuff gets slapped together as fast as
>> possible, to be "done with it". This leads to poor final documentation.
>> The other reason why I do it concurrently is that I could be hit by a
>> truck tomorrow and my clients still need to be able to get on with the
>> project, without having to reverse engineer my designs.
> 
> We all have the same scars different truck. The amazing thing is
> doing it "right" results in a better product sooner. Being beat up
> because no code is being typed will extent the project.
> 
> Three or four years ago I wrote a code generator for a particularly
> nasty processor. I spent 3 1/2 months on the design document and
> a full day writing the code. The total changes to the code since "1"
> satisfaction doing it right "priceless"
> 

Yep, that's how it's supposed to be.

This almost drove the guys crazy at the Institute for Measurement 
Technology and Aachen University (Germany): Me starting my masters 
project, a complete CCD camera from scratch. Some folks said it's way to 
complicated for one guy. Oh, and they also needed a VME data acqusition 
for it so I told them I'd build one if someone brings a crate of beer. 
They did, and said that this other project relies on my stuff being 
ready before the big SPIE conference. "Ok", I said. 3 months down the 
road, no hardware. 4 months, still nothing but almost a book worth of 
documentation. And so on. Then the professor had a concerned chat with 
me. Told him that the plans were just about done and the camera would be 
ready for use in four weeks. "Plan. Hmm  ..." He left, shaking his head. 
Three weeks later it all worked.

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

Joerg wrote:
> 3 months down the 
> road, no hardware. 4 months, still nothing but almost a book worth of 
> documentation. And so on. Then the professor had a concerned chat with 
> me. Told him that the plans were just about done and the camera would be 
> ready for use in four weeks. "Plan. Hmm  ..." He left, shaking his head. 
> Three weeks later it all worked.

If you were an unknown quantity to your professor at the time, then he
acted very appropriately. After all, at that point your behavior was
externally indistinguishable from someone who only knew how to plan
and had no clue about the actual implementation work.

As an aside, I'm not all that convinced about the benefits of a strict
think-plan-do waterfall model of development. It is fine if you are
doing a run-of-the-mill application with tools you are familiar with.
But in the face of ambiguity or uncertainty, a more iterative model
might be more appropriate.
-- 
Pertti

It's very refreshing to hear lessons "from the trenches" about our
field. Great topic!

Vladimir Vassilevsky escribi�:

[...]

> Application engineers are not engineers.

Wow. Just like sea lions are not lions?

On Apr 21, 9:52=A0pm, Joerg <notthisjoerg...@removethispacbell.net>
wrote:
> Mike Silva wrote:
> > I've been asked to write a tutorial to introduce people who have had a
> > bit of programming experience to embedded hardware and software. =A0I
> > can think of plenty of material for such a tutorial, but I don't want
> > to miss something important, or treat my particular background as
> > universal, so I'm hoping that some of you will offer your top N things
> > to teach an embedded newbie (with N being a function of your free time
> > and/or enthusiasm). =A0Thanks,
>
> 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.

One of my favorite phrases:
Self documenting code isn't.

  Ed

In message <49EF2FEF.F155AC55@bytecraft.com>, Walter Banks
<walter@bytecraft.com> writes
>
>
>Mike Silva wrote:
>
>> I've been asked to write a tutorial to introduce people who have had a
>> bit of programming experience to embedded hardware and software.  I
>> can think of plenty of material for such a tutorial, but I don't want
>> to miss something important, or treat my particular background as
>> universal, so I'm hoping that some of you will offer your top N things
>> to teach an embedded newbie (with N being a function of your free time
>> and/or enthusiasm).  Thanks,
>>
>> Mike
>
>Details, details, details
>
>Embedded is a special kind of programming done by special people
>who can't wait for morning to continue their profession.
>
>It is the rush that you get looking at the final product and saying
>there is a little bit of me in there.
>
>It just never goes away.
>
>Several others have dealt with the technical details. I add my vote
>for design planning should be done before the code is written.


In a presentation I do called:  Debugging is difficult. So why do it?
There are two slides of relevance here.

1 a pie chart of project failures in  61508  projects.  Over 60% of the
failures are due to [incorrect] specification.

2 A combined project time line of all the successful projects at a major
comms company.  IT turned out for all the successful projects the first
50-50% of the elapsed time was spend on specifications and design. Only
15% on code and (code) test. There were additional integration and
systems test phases.

In both cases they had good systems.

So
1 work out what you want to build  (requirements)
2 how it should be built                (Specification )
3 Detailed design                        (design)
4 build to design.
5 Test according to design specification.
6 Test system according to system spec
7 Test with customer against requirements.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Pertti Kellomaki wrote:
> Joerg wrote:
>> 3 months down the road, no hardware. 4 months, still nothing but 
>> almost a book worth of documentation. And so on. Then the professor 
>> had a concerned chat with me. Told him that the plans were just about 
>> done and the camera would be ready for use in four weeks. "Plan. Hmm  
>> ..." He left, shaking his head. Three weeks later it all worked.
> 
> If you were an unknown quantity to your professor at the time, then he
> acted very appropriately. After all, at that point your behavior was
> externally indistinguishable from someone who only knew how to plan
> and had no clue about the actual implementation work.
> 

Well, there was quite an extensive schematic at that time, along with 
explanations about how stuff worked and why certain architectural 
choices were made.


> As an aside, I'm not all that convinced about the benefits of a strict
> think-plan-do waterfall model of development. It is fine if you are
> doing a run-of-the-mill application with tools you are familiar with.
> But in the face of ambiguity or uncertainty, a more iterative model
> might be more appropriate.


This was most certainly no run-of-the-mill project. It beat the CCD 
cameras of those days hands down. The array manufacturer (they also made 
their own cameras with it) came visit and the CCD division executive 
offered me a job on the spot. I could have started there the millisecond 
the university handed me my degree but it was a large company and I 
wasn't cut out for work in a large corporation. Went to a smaller 
business instead.

I use this approach all the time and I work at the cutting edge of 
medical and other markets. In fact, agencies almost mandate this 
approach. Upon audits one of the first things they request is the design 
history and if he asks you better be able to place that in front of the 
officer within minutes.

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

On Tue, 21 Apr 2009 22:36:45 -0400, Robert Adsett
<sub2@aeolusdevelopment.com> wrote:

>In article <QcuHl.15256$pr6.9045@flpi149.ffdc.sbc.com>, Vladimir 
>Vassilevsky says...
>> 
>> 
>> Mike Silva wrote:
>> > I've been asked to write a tutorial to introduce people who have had a
>> > bit of programming experience to embedded hardware and software.  I
>> > can think of plenty of material for such a tutorial, but I don't want
>> > to miss something important, or treat my particular background as
>> > universal, so I'm hoping that some of you will offer your top N things
>> > to teach an embedded newbie (with N being a function of your free time
>> > and/or enthusiasm).  Thanks,
>> 
>> 1. Start with reading the original datasheets and manuals, not the 
>> retellings, interpretations or other fiction.
>
>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.

   Further down in the "regular" specs, there are usually minumum,
typical and maximum columns for things like current consumption (and
that one for microcontrollers often has half a dozen or more figures,
depending on run/wait/stop modes and what on-chip clocks and
peripherals are powered up). Ignore the typical column, and use only
the worst case number from the other two columns.

>
>Robert

On Tue, 21 Apr 2009 16:26:41 -0700 (PDT), Mike Silva
<snarflemike@yahoo.com> wrote:

>I've been asked to write a tutorial to introduce people who have had a
>bit of programming experience to embedded hardware and software.  I
>can think of plenty of material for such a tutorial, but I don't want
>to miss something important, or treat my particular background as
>universal, so I'm hoping that some of you will offer your top N things
>to teach an embedded newbie (with N being a function of your free time
>and/or enthusiasm).  Thanks,

   One of the first things that comes to mind is "magic memory
locations" in memory-mapped I/O or even with separate I/O addressing
(where there may STILL be memory mapped I/O) that unlike RAM, what you
read from a hardware location may have no connection (it may do an
entirely different function from) what you write to that location.
I've heard of people getting confused over this, and having a hard
time not thinking something like "Oh, that must be a bad memory
location in RAM."
   Going into more detail here, this is even true of bits in a word,
some may be read/write, but others may be read-only status bits (that
get cleared by hardware just after the read!) and writes to those bits
may be don't-care, or specified as "always write zero here."
   There's hardware addresses on desktop systems that work like that
(or even ram locations such as the keyboard key buffer, filled in by a
keyboard interrupt routine and read out by a function called from the
application), but desktop developers often never see such low-level
details.
   I recall the serial chip in the original Macintosh, I forget the
part number, but you had to write TWO consecutive words to it to write
to a register, and to read a register you had to write a word, then
read the register. That was fun, I hadn't used a chip like that one
before, but since then there was a Dallas chip with a one-wire
interface.

   More stuff hinges on the size of the target systems. I suspect
there's a lot of mixed knowledge and assumptions among embedded
developers depending on the targets they're used to. 32 bit processors
running some Unix thing will likely have all the bells and whistles of
the average desktop machine available, and the assumptions of such
developers will be similar to "mainstream" desktop developers.
   Smaller systems running on 8-bit or 16-bit processors may not have
things "desktop developers" take for granted, such as scanf, printf,
dynamic memory allocation and floating point operations, virtually
unlimited program and data memory, and where things such as floating
point they ARE available, they may end up taking half or more of the
program and RAM space, and run at 1/100th the speed of integer (or
fixed-point, something else you may need to explain) operations.

   Of course, now you can get a 32 bit processor powered off a
rechargable cell and running a conference badge, like this one:

http://canyourbadgedothis.com

so things aren't dividable between 8/16/32 bit systems as being
necessarily  different. I suppose you could implement a printf for
putting up a message on the LED matrix display, but I'm sure a usable
enough function comes with the board.

   A better dividing line might be "has OS" vs. "no OS" but I've also
seen discussions here of "What constitutes an OS?"

   "Embedded" cover a huge and growing number of products. Years ago I
saw someone working on an ATM in a supermarket, it was all opened up
with a display showing system stuff. I felt a tightness in my chest
when I recognized it as some version of Microsoft Windows.

>Mike

On Apr 23, 1:50=A0pm, Chris H <ch...@phaedsys.org> wrote:
> In message <49EF2FEF.F155A...@bytecraft.com>, Walter Banks
> <wal...@bytecraft.com> writes
>
>
>
>
>
>
>
> >Mike Silva wrote:
>
> >> I've been asked to write a tutorial to introduce people who have had a
> >> bit of programming experience to embedded hardware and software. =A0I
> >> can think of plenty of material for such a tutorial, but I don't want
> >> to miss something important, or treat my particular background as
> >> universal, so I'm hoping that some of you will offer your top N things
> >> to teach an embedded newbie (with N being a function of your free time
> >> and/or enthusiasm). =A0Thanks,
>
> >> Mike
>
> >Details, details, details
>
> >Embedded is a special kind of programming done by special people
> >who can't wait for morning to continue their profession.
>
> >It is the rush that you get looking at the final product and saying
> >there is a little bit of me in there.
>
> >It just never goes away.
>
> >Several others have dealt with the technical details. I add my vote
> >for design planning should be done before the code is written.
>
> In a presentation I do called: =A0Debugging is difficult. So why do it?
> There are two slides of relevance here.
>
> 1 a pie chart of project failures in =A061508 =A0projects. =A0Over 60% of=
 the
> failures are due to [incorrect] specification.
>
> 2 A combined project time line of all the successful projects at a major
> comms company. =A0IT turned out for all the successful projects the first
> 50-50% of the elapsed time was spend on specifications and design. Only
> 15% on code and (code) test. There were additional integration and
> systems test phases.
>
> In both cases they had good systems.

What was the first 50 in 50-50% supposed to be?

Fred Brooks ("The Mythical Man Month") offered 1/3 planning, 1/6
coding, 1/4 component and partial system test, 1/4 system test.

Chris H wrote:
> In message <49EF2FEF.F155AC55@bytecraft.com>, Walter Banks
> <walter@bytecraft.com> writes
>>
>> Mike Silva wrote:
>>
>>> I've been asked to write a tutorial to introduce people who have had a
>>> bit of programming experience to embedded hardware and software.  I
>>> can think of plenty of material for such a tutorial, but I don't want
>>> to miss something important, or treat my particular background as
>>> universal, so I'm hoping that some of you will offer your top N things
>>> to teach an embedded newbie (with N being a function of your free time
>>> and/or enthusiasm).  Thanks,
>>>
>>> Mike
>> Details, details, details
>>
>> Embedded is a special kind of programming done by special people
>> who can't wait for morning to continue their profession.
>>
>> It is the rush that you get looking at the final product and saying
>> there is a little bit of me in there.
>>
>> It just never goes away.
>>
>> Several others have dealt with the technical details. I add my vote
>> for design planning should be done before the code is written.
> 
> 
> In a presentation I do called:  Debugging is difficult. So why do it?
> There are two slides of relevance here.
> 
> 1 a pie chart of project failures in  61508  projects.  Over 60% of the
> failures are due to [incorrect] specification.
> 

No surprise there.


> 2 A combined project time line of all the successful projects at a major
> comms company.  IT turned out for all the successful projects the first
> 50-50% of the elapsed time was spend on specifications and design. Only
> 15% on code and (code) test. There were additional integration and
> systems test phases.
> 
> In both cases they had good systems.
> 
> So
> 1 work out what you want to build  (requirements)
> 2 how it should be built                (Specification )
> 3 Detailed design                        (design)


At this point a serious design review should be held where all 
stakeholders are present. Yes, including the sales and marketing guys.

I have seen the results where design reviews were either not performed 
or done in a "let's quickly get it over with" fashion. "Now wait, we 
always assumed its bus could be connected to the xyz gizmo!" ... "Uhm, 
nobody told us that".


> 4 build to design.
> 5 Test according to design specification.
> 6 Test system according to system spec
> 7 Test with customer against requirements.
> 


-- 
Regards, Joerg

http://www.analogconsultants.com/

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

On Apr 21, 6:09=A0pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
wrote:
> 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.

That's useful to point out.  Active low is usually an unfamiliar
concept to new embedded programmers.

Similarly, a brief introduction to reading a digital schematic
will be very helpful.  No matter how much the boss thinks
that software people never have to look at schematics, these
are often the best specifications.  Ie, how to tell active low
from active high, whether a line is pulled high or low, etc.

> 8. When planning on memory/speed utilization, don't go over 60%. You
> will need this reserve later.

But don't let the software people know there is a reserve, or
they'll assume they can use it freely.

> 9. Don't use the example code that comes with the compiler or evaluation
> board.

Oh yeah, big agreement here.  What is sad is that many beginners
use sample code as exemplar code, and get bad habits early on.
I'm of the theory that most of these companies give the job of
writing examples to new hires fresh out of school, or even
unpaid interns still in school, since I've seen some truly horrid
code splashed proudly with the name of the Big Company.

Ed Prochak wrote:

> On Apr 21, 9:52 pm, Joerg <notthisjoerg...@removethispacbell.net>
> wrote:
> >>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".
>>
> One of my favorite phrases:
> Self documenting code isn't.


However one shouldn't forget that the developer documentation is just 
one of many processes that are important for the achievement of the 
goals of the project. Documentation is not a goal in itself; neither it 
is a dogma. The infatuation for bureaucracy is very counter productive. 
The development of the sensible documentation requires talent and 
consumes a lot of effort; the dull documentation is worse then no 
documentation as it creates a mess and confusion.

I think it is very important to make the design suitable for debug, 
production testing and repair. Provide enough of test points, test 
signals and test modes in the software; so every I/O signal could be 
verified. Before developing a feature, think how you are going to test 
it and what hardware would be required to do that. Often those things 
are overlooked or added at the very last moment. The result is a lot of 
suffering at the design verification and later in production.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On 2009-04-23, Darin Johnson <darin@usa.net> wrote:
> On Apr 21, 6:09�pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
> wrote:
>> 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.
>
> That's useful to point out.  Active low is usually an unfamiliar
> concept to new embedded programmers.

And especially with open drain outputs.  Yesterday was a mad day
- I was working a small quick-and-dirty project and wanted it done
in one day.  You know what that entails - stripboard, DIP packages,
PICs (for local availability) and mountains of wiring.  All went
swimmingly until I tried bringing up a test version of the software
of the programmign baord - A Velleman K8048.  One of the LEDs just
wouldn't work.  The software was obviously goign through the correct
region of code but that LED still didn't light.  I kind of assumed
Velleman were competent at designing this kind of thing, but no,
they attempted to drive an LED anode high from an open drain
output...

-- 
Andrew Smallshaw
andrews@sdf.lonestar.org

On Apr 23, 7:12=A0pm, Pertti Kellomaki <pertti.kellom...@tut.fi> wrote:
> As an aside, I'm not all that convinced about the benefits of a strict
> think-plan-do waterfall model of development. It is fine if you are
> doing a run-of-the-mill application with tools you are familiar with.
> But in the face of ambiguity or uncertainty, a more iterative model
> might be more appropriate.

A combination of both is a good idea.
Here, we like to physically 'Measure the foundations' before 'The
Plan' gets too large, and that means a usually small looping piece of
code, that pushes the
system.
Twice recently, we found 'undocumented issues' that meant a major
change in
design plan in one case, and a slight recode in another.

Raised one with the IC vendor :
"Oh yes, that's how we designed it"
"Yes, you are right, that behavior detail is not reflected in the data
sheet formula"
"Really?, others don't have this issue ?"

-jg

Darin Johnson wrote:
> On Apr 21, 6:09 pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
> wrote:
>> 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.
> 
> That's useful to point out.  Active low is usually an unfamiliar
> concept to new embedded programmers.
> 

Although, not much anymore these days. Most drivers are CMOS and the 
difference between Rdson of the upper and lower devices is quite small.

Active low has a major downside: If you have a row of LEDs at the front 
they or their series resistors must be connected to a supply plane. 
Someone slips with a tool ... bzzzt ... flash ... *PHHHOOMP*

Seen it happen more than once, and those supply planes can pack a punch.

[...]

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

On Thu, 23 Apr 2009 10:12:16 +0300, Pertti Kellomaki wrote:

>> road, no hardware. 4 months, still nothing but almost a book worth of 
>> documentation. And so on. Then the professor had a concerned chat with 
>> me. Told him that the plans were just about done and the camera would be 
>> ready for use in four weeks. "Plan. Hmm  ..." He left, shaking his head. 
>> Three weeks later it all worked.
> 
> If you were an unknown quantity to your professor at the time, then he
> acted very appropriately. After all, at that point your behavior was
> externally indistinguishable from someone who only knew how to plan
> and had no clue about the actual implementation work.

An extreme example of this philosophy can be found in the computer games
industry. Publishers always want to see stuff working ASAP. This
forces you to start with a hacked-together demo which eventually grows
into the final product.

As a programmer, this is infuriating. But any publisher who made a
habit of accepting developers' promises at face value would have long
since collapsed.

Mike Silva wrote:
> Chris H <ch...@phaedsys.org> wrote:
>
.... snip ...
>
>> 2 A combined project time line of all the successful projects
>> at a major comms company.  IT turned out for all the successful
>> projects the first 50-50% of the elapsed time was spend on
>> specifications and design. Only 15% on code and (code) test.
>> There were additional integration and systems test phases.
>>
>> In both cases they had good systems.
> 
> What was the first 50 in 50-50% supposed to be?

Somehow I suspect the obvious answer (0%) to be wrong.  ;-)  The
message was a useful piece of advice to a beginner.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

On Apr 21, 7:26=A0pm, Mike Silva <snarflem...@yahoo.com> wrote:
> I've been asked to write a tutorial to introduce people who have had a
> bit of programming experience to embedded hardware and software. =A0I
> can think of plenty of material for such a tutorial, but I don't want
> to miss something important, or treat my particular background as
> universal, so I'm hoping that some of you will offer your top N things
> to teach an embedded newbie (with N being a function of your free time
> and/or enthusiasm). =A0Thanks,
>
> Mike

All interesting ideas to Mike's question !
But, in my experience, the answer is ...NOTHING !
Most of the beginners I've worked with
already knew it all   ;-)

See ya, Dave

On Apr 22, 2:42=A0pm, Joerg <notthisjoerg...@removethispacbell.net>
wrote:

> > It's extremely useful when you have an ISO requirement "code must
> > include documentation" and are too lazy to actually do things like
> > sitting down before you open the compiler, and deciding on paper what
>
> Agencies such as FDA or FAA won't likely give a hoot about whether it's

I was actually being sarcastic there. My department has a new mandate
to achieve CMMI level 3 compliance and there is an exponential growth
in paperwork, most of which is being algorithmically generated by
cheat scripts and doxygen, and then later algorithmically checked by
macros. Sometimes I think the only actual coding that is happening is
the arms race between automatic document generation and automatic
traceability matrix checking.

Nobody wrote:

> On Thu, 23 Apr 2009 10:12:16 +0300, Pertti Kellomaki wrote:
> 
> 
>>>road, no hardware. 4 months, still nothing but almost a book worth of 
>>>documentation. And so on. Then the professor had a concerned chat with 
>>>me. Told him that the plans were just about done and the camera would be 
>>>ready for use in four weeks. "Plan. Hmm  ..." He left, shaking his head. 
>>>Three weeks later it all worked.
>>
>>If you were an unknown quantity to your professor at the time, then he
>>acted very appropriately. After all, at that point your behavior was
>>externally indistinguishable from someone who only knew how to plan
>>and had no clue about the actual implementation work.
> 
> 
> An extreme example of this philosophy can be found in the computer games
> industry. Publishers always want to see stuff working ASAP. This
> forces you to start with a hacked-together demo which eventually grows
> into the final product.

Computer games is the essence of modern programming. A big bunch of low 
paid and interchangeable duffers working long hours on enthusiasm and 
for the promise of the wonderful future. Extreme labor fluidity. A 
project is just a huge pile of routine; nothing new or exquisite.


> As a programmer, this is infuriating. But any publisher who made a
> habit of accepting developers' promises at face value would have long
> since collapsed.

VLV

In message <76e16d0a-d963-435b-9375-c43ad4144be3@b1g2000vbc.googlegroups
..com>, Mike Silva <snarflemike@yahoo.com> writes
>On Apr 23, 1:50�pm, Chris H <ch...@phaedsys.org> wrote:
>> In message <49EF2FEF.F155A...@bytecraft.com>, Walter Banks
>> <wal...@bytecraft.com> writes
>>
>>
>>
>>
>>
>>
>>
>> >Mike Silva wrote:
>>
>> >> I've been asked to write a tutorial to introduce people who have had a
>> >> bit of programming experience to embedded hardware and software. �I
>> >> can think of plenty of material for such a tutorial, but I don't want
>> >> to miss something important, or treat my particular background as
>> >> universal, so I'm hoping that some of you will offer your top N things
>> >> to teach an embedded newbie (with N being a function of your free time
>> >> and/or enthusiasm). �Thanks,
>>
>> >> Mike
>>
>> >Details, details, details
>>
>> >Embedded is a special kind of programming done by special people
>> >who can't wait for morning to continue their profession.
>>
>> >It is the rush that you get looking at the final product and saying
>> >there is a little bit of me in there.
>>
>> >It just never goes away.
>>
>> >Several others have dealt with the technical details. I add my vote
>> >for design planning should be done before the code is written.
>>
>> In a presentation I do called: �Debugging is difficult. So why do it?
>> There are two slides of relevance here.
>>
>> 1 a pie chart of project failures in �61508 �projects. �Over 60% of the
>> failures are due to [incorrect] specification.
>>
>> 2 A combined project time line of all the successful projects at a major
>> comms company. �IT turned out for all the successful projects the first
>> 50-50% of the elapsed time was spend on specifications and design. Only
>> 15% on code and (code) test. There were additional integration and
>> systems test phases.
>>
>> In both cases they had good systems.
>
>What was the first 50 in 50-50% supposed to be?

50-60%

>Fred Brooks ("The Mythical Man Month") offered 1/3 planning, 1/6
>coding, 1/4 component and partial system test, 1/4 system test.

The figures from the working projects I had indicated planning 50%  and
testing 30%  but then the testing was preceded with static analysis in
the coding phase and the testing was automated.

However which ever way you look at it for successful projects you are
looking at 30-50% planning, 30-50% testing and about 15% coding.

It might come as a surprise to programmers (if not Software Engineers)
that coding is the smallest phase on *successful* projects.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In message <9292a234-d61c-446d-89d7-68109f718a4d@v15g2000yqn.googlegroup
s.com>, Dave Nadler <drn@nadler.com> writes
>On Apr 21, 7:26�pm, Mike Silva <snarflem...@yahoo.com> wrote:
>> I've been asked to write a tutorial to introduce people who have had a
>> bit of programming experience to embedded hardware and software. �I
>> can think of plenty of material for such a tutorial, but I don't want
>> to miss something important, or treat my particular background as
>> universal, so I'm hoping that some of you will offer your top N things
>> to teach an embedded newbie (with N being a function of your free time
>> and/or enthusiasm). �Thanks,
>>
>> Mike
>
>All interesting ideas to Mike's question !
>But, in my experience, the answer is ...NOTHING !
>Most of the beginners I've worked with
>already knew it all   ;-)

Ouch :-))))

However you do make a VERY good point...


A while ago in this (or comp.lang.c)  was a person who declared it was
VERY easy to write fully portable C at all times and started pointing
out mistakes "novices" made....   He knew what he was talking about and
the rest of us were all wrong...    It turned out he had written a few
PC programs as a hobby and was doing PIC MCU's in his first year at
collage. He had not worked on any other MCU but he "knew it all"



-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Joerg wrote:
> Pertti Kellomaki wrote:
> 
>> As an aside, I'm not all that convinced about the benefits of a strict
>> think-plan-do waterfall model of development. It is fine if you are
>> doing a run-of-the-mill application with tools you are familiar with.
>> But in the face of ambiguity or uncertainty, a more iterative model
>> might be more appropriate.
> 
> I use this approach all the time and I work at the cutting edge of 
> medical and other markets. In fact, agencies almost mandate this 
> approach. Upon audits one of the first things they request is the design 
> history and if he asks you better be able to place that in front of the 
> officer within minutes.
> 

The best development method depends entirely on the project type and the 
customer - as with all things embedded, the answer is "it depends".

For your medical products, you have a clear specification, you can plan 
your design to that specification, and implement the product to that 
specification.  That's essential for that sort of project, and if there 
is no clear specification, there will be no project and no product.

But not all embedded systems need the levels of documentation, security, 
auditability (is there such a word?) and quality control as something 
like medical equipment - and not all projects have the time and money 
for such a rigorous process.

The embedded world is huge, and there are vast numbers of customers who 
have only a vague idea of what they want the system to do - there is no 
way they can give you a concrete specification.  You have to expect to 
go through a number of iterations, with first "prototypes" on paper, 
then using general-purpose cards, then prototype versions of a dedicated 
card, then final versions of the cards.  At each stage, you are in 
dialogue with the customer and are writing and changing as you go along. 
  Clearly you have to have a time and payment model to match - and yes, 
the customer will sometimes be paying you to do it over, rather than 
paying you do it right in the first place, because they didn't know what 
"right" was until first doing it "wrong".

You can, of course, call this whole prototyping and development stage 
"design and planning" and the final hardware and software the 
"implementation", if you want to shoe-horn it into an idealised 
development model.  But you have a better chance of success (both for 
the developer and the customer) if you realise from the start that 
sometimes development is circular, not linear.

Both models, and everything in between, work for appropriate projects, 
customers and developers.

Pertti Kellomaki wrote:

> As an aside, I'm not all that convinced about the benefits of a strict
> think-plan-do waterfall model of development. It is fine if you are
> doing a run-of-the-mill application with tools you are familiar with.
> But in the face of ambiguity or uncertainty, a more iterative model
> might be more appropriate.

Part of the design document process is finding out how the tools
and silicon work.

I worked on a project in the mid 80's that had a black board
set aside for one liner words of wisdom. One that I remember
on that board said,

"If you had time enough to do it over, how come you didn't have
time enough to do it right?"

Regards,

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com

On Apr 24, 3:03=A0am, Chris H <ch...@phaedsys.org> wrote:
> In message <76e16d0a-d963-435b-9375-c43ad4144...@b1g2000vbc.googlegroups
> .com>, Mike Silva <snarflem...@yahoo.com> writes
>
>
>
>
>
> >On Apr 23, 1:50=A0pm, Chris H <ch...@phaedsys.org> wrote:
> >> In message <49EF2FEF.F155A...@bytecraft.com>, Walter Banks
> >> <wal...@bytecraft.com> writes
>
> >> >Mike Silva wrote:
>
> >> >> I've been asked to write a tutorial to introduce people who have ha=
d a
> >> >> bit of programming experience to embedded hardware and software. =
=A0I
> >> >> can think of plenty of material for such a tutorial, but I don't wa=
nt
> >> >> to miss something important, or treat my particular background as
> >> >> universal, so I'm hoping that some of you will offer your top N thi=
ngs
> >> >> to teach an embedded newbie (with N being a function of your free t=
ime
> >> >> and/or enthusiasm). =A0Thanks,
>
> >> >> Mike
>
> >> >Details, details, details
>
> >> >Embedded is a special kind of programming done by special people
> >> >who can't wait for morning to continue their profession.
>
> >> >It is the rush that you get looking at the final product and saying
> >> >there is a little bit of me in there.
>
> >> >It just never goes away.
>
> >> >Several others have dealt with the technical details. I add my vote
> >> >for design planning should be done before the code is written.
>
> >> In a presentation I do called: =A0Debugging is difficult. So why do it=
?
> >> There are two slides of relevance here.
>
> >> 1 a pie chart of project failures in =A061508 =A0projects. =A0Over 60%=
 of the
> >> failures are due to [incorrect] specification.
>
> >> 2 A combined project time line of all the successful projects at a maj=
or
> >> comms company. =A0IT turned out for all the successful projects the fi=
rst
> >> 50-50% of the elapsed time was spend on specifications and design. Onl=
y
> >> 15% on code and (code) test. There were additional integration and
> >> systems test phases.
>
> >> In both cases they had good systems.
>
> >What was the first 50 in 50-50% supposed to be?
>
> 50-60%
>
> >Fred Brooks ("The Mythical Man Month") offered 1/3 planning, 1/6
> >coding, 1/4 component and partial system test, 1/4 system test.
>
> The figures from the working projects I had indicated planning 50% =A0and
> testing 30% =A0but then the testing was preceded with static analysis in
> the coding phase and the testing was automated.
>
> However which ever way you look at it for successful projects you are
> looking at 30-50% planning, 30-50% testing and about 15% coding.
>
> It might come as a surprise to programmers (if not Software Engineers)
> that coding is the smallest phase on *successful* projects.

Right, that's why I posted his numbers, to support your point.

Mike

On Thu, 23 Apr 2009 16:22:38 -0700, the renowned Joerg
<notthisjoergsch@removethispacbell.net> wrote:

>Darin Johnson wrote:
>> On Apr 21, 6:09 pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
>> wrote:
>>> 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.
>> 
>> That's useful to point out.  Active low is usually an unfamiliar
>> concept to new embedded programmers.
>> 
>
>Although, not much anymore these days. Most drivers are CMOS and the 
>difference between Rdson of the upper and lower devices is quite small.

I guess, if you consider >2:1 "quite small".  It's down to SS
physics-- the carrier mobility- a 2 or 3:1 difference between
n-channel and p-channel devices.  

Take for example, a PIC12F508 operating at 3.0V

Voh at 125�C is 1.5V at 4.5mA or so (3 sigma minimum)  

Vol at 125�C is < 0.7V at 10mA (again, 3 sigma maximum) 

The differences are not as great in HC devices (about 40% in the
guaranteed values), probably because they use larger devices for the
output p-channel, since it affects the rise time with a large fanout.

Anyway, most designers will automatically connect an LED+resistor load
between Vdd and a CMOS output, and if external discrete drivers are
required (eg. for muxing an array, the first ones to go discrete are
the source drivers). 

Though you can get some very nice p-channel discrete MOSFETs these
days if you don't mind very low breakdown voltage. 

>Active low has a major downside: If you have a row of LEDs at the front 
>they or their series resistors must be connected to a supply plane. 
>Someone slips with a tool ... bzzzt ... flash ... *PHHHOOMP*
>
>Seen it happen more than once, and those supply planes can pack a punch.
>
>[...]

No current limiting? 8-( Bad place to scrimp if it's a product that
requires maintenance. 



Best regards, 
Spehro Pefhany
-- 
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

On Apr 24, 3:32=A0am, Chris H <ch...@phaedsys.org> wrote:
> In message <9292a234-d61c-446d-89d7-68109f718...@v15g2000yqn.googlegroup
> s.com>, Dave Nadler <d...@nadler.com> writes
>
> >On Apr 21, 7:26=A0pm, Mike Silva <snarflem...@yahoo.com> wrote:
> >> I've been asked to write a tutorial to introduce people who have had a
> >> bit of programming experience to embedded hardware and software. =A0I
> >> can think of plenty of material for such a tutorial, but I don't want
> >> to miss something important, or treat my particular background as
> >> universal, so I'm hoping that some of you will offer your top N things
> >> to teach an embedded newbie (with N being a function of your free time
> >> and/or enthusiasm). =A0Thanks,
>
> >> Mike
>
> >All interesting ideas to Mike's question !
> >But, in my experience, the answer is ...NOTHING !
> >Most of the beginners I've worked with
> >already knew it all =A0 ;-)
>
> Ouch :-))))
>
> However you do make a VERY good point...
>
> A while ago in this (or comp.lang.c) =A0was a person who declared it was
> VERY easy to write fully portable C at all times and started pointing
> out mistakes "novices" made.... =A0 He knew what he was talking about and
> the rest of us were all wrong... =A0 =A0It turned out he had written a fe=
w
> PC programs as a hobby and was doing PIC MCU's in his first year at
> collage. He had not worked on any other MCU but he "knew it all"
>
> --
> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> \/\/\/\/\ Chris Hills =A0Staffs =A0England =A0 =A0 /\/\/\/\/
> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

The serious point here is really that the best training leads to
- understanding of exactly how much one does NOT know, and
- learning how to go about getting things done regardless

Hope that is useful Mike !
Best Regards, Dave

In message <3aa331e5-ec44-4437-bd71-26700139e4f9@q16g2000yqg.googlegroup
s.com>, Dave Nadler <drn@nadler.com> writes
>On Apr 24, 3:32�am, Chris H <ch...@phaedsys.org> wrote:
>> In message <9292a234-d61c-446d-89d7-68109f718...@v15g2000yqn.googlegroup
>> s.com>, Dave Nadler <d...@nadler.com> writes
>>
>> >On Apr 21, 7:26�pm, Mike Silva <snarflem...@yahoo.com> wrote:
>> >> I've been asked to write a tutorial to introduce people who have had a
>> >> bit of programming experience to embedded hardware and software. �I
>> >> can think of plenty of material for such a tutorial, but I don't want
>> >> to miss something important, or treat my particular background as
>> >> universal, so I'm hoping that some of you will offer your top N things
>> >> to teach an embedded newbie (with N being a function of your free time
>> >> and/or enthusiasm). �Thanks,
>>
>> >> Mike
>>
>> >All interesting ideas to Mike's question !
>> >But, in my experience, the answer is ...NOTHING !
>> >Most of the beginners I've worked with
>> >already knew it all � ;-)
>>
>> Ouch :-))))
>>
>> However you do make a VERY good point...
>>
>> A while ago in this (or comp.lang.c) �was a person who declared it was
>> VERY easy to write fully portable C at all times and started pointing
>> out mistakes "novices" made.... � He knew what he was talking about and
>> the rest of us were all wrong... � �It turned out he had written a few
>> PC programs as a hobby and was doing PIC MCU's in his first year at
>> collage. He had not worked on any other MCU but he "knew it all"
>
>The serious point here is really that the best training leads to
>- understanding of exactly how much one does NOT know, and
>- learning how to go about getting things done regardless
>
>Hope that is useful Mike !
>Best Regards, Dave

Agreed. A little knowledge is only a dangerous thing IF you do not know
it is a little knowledge.

Blind enthusiasm gets people killed. though how one teaches students
caution id a difficult question.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Spehro Pefhany wrote:
> On Thu, 23 Apr 2009 16:22:38 -0700, the renowned Joerg
> <notthisjoergsch@removethispacbell.net> wrote:
> 
>> Darin Johnson wrote:
>>> On Apr 21, 6:09 pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
>>> wrote:
>>>> 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.
>>> That's useful to point out.  Active low is usually an unfamiliar
>>> concept to new embedded programmers.
>>>
>> Although, not much anymore these days. Most drivers are CMOS and the 
>> difference between Rdson of the upper and lower devices is quite small.
> 
> I guess, if you consider >2:1 "quite small".  It's down to SS
> physics-- the carrier mobility- a 2 or 3:1 difference between
> n-channel and p-channel devices.  
> 
> Take for example, a PIC12F508 operating at 3.0V
> 
> Voh at 125�C is 1.5V at 4.5mA or so (3 sigma minimum)  
> 
> Vol at 125�C is < 0.7V at 10mA (again, 3 sigma maximum) 
> 
> The differences are not as great in HC devices (about 40% in the
> guaranteed values), probably because they use larger devices for the
> output p-channel, since it affects the rise time with a large fanout.
> 
> Anyway, most designers will automatically connect an LED+resistor load
> between Vdd and a CMOS output, and if external discrete drivers are
> required (eg. for muxing an array, the first ones to go discrete are
> the source drivers). 
> 
> Though you can get some very nice p-channel discrete MOSFETs these
> days if you don't mind very low breakdown voltage. 
> 

Last device I checked in this respect was the MSP430 and that had 
relatively equal Rdson values for N and P.


>> Active low has a major downside: If you have a row of LEDs at the front 
>> they or their series resistors must be connected to a supply plane. 
>> Someone slips with a tool ... bzzzt ... flash ... *PHHHOOMP*
>>
>> Seen it happen more than once, and those supply planes can pack a punch.
>>
>> [...]
> 
> No current limiting? 8-( Bad place to scrimp if it's a product that
> requires maintenance. 
> 

Sure there is a current limit. But if the board needs several amps on 
that node for other purposes you can't limit lower than that. Providing 
a "sub-plane" with its own personal limiter kind of gets old ;-)

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

zwsdotcom@gmail.com wrote:
> On Apr 22, 2:42 pm, Joerg <notthisjoerg...@removethispacbell.net>
> wrote:
> 
>>> It's extremely useful when you have an ISO requirement "code must
>>> include documentation" and are too lazy to actually do things like
>>> sitting down before you open the compiler, and deciding on paper what
>> Agencies such as FDA or FAA won't likely give a hoot about whether it's
> 
> I was actually being sarcastic there. My department has a new mandate
> to achieve CMMI level 3 compliance and there is an exponential growth
> in paperwork, most of which is being algorithmically generated by
> cheat scripts and doxygen, ...


Just don't build medical or aircraft stuff that way or that'll haunt you 
some day :-)


>                         ... and then later algorithmically checked by
> macros. Sometimes I think the only actual coding that is happening is
> the arms race between automatic document generation and automatic
> traceability matrix checking.


-- 
Regards, Joerg

http://www.analogconsultants.com/

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

In article <49F180A1.D3BEDA81@bytecraft.com>, walter@bytecraft.com 
says...
> 
> 
> Pertti Kellomaki wrote:
> 
> > As an aside, I'm not all that convinced about the benefits of a strict
> > think-plan-do waterfall model of development. It is fine if you are
> > doing a run-of-the-mill application with tools you are familiar with.
> > But in the face of ambiguity or uncertainty, a more iterative model
> > might be more appropriate.
> 
> Part of the design document process is finding out how the tools
> and silicon work.
> 
> I worked on a project in the mid 80's that had a black board
> set aside for one liner words of wisdom. One that I remember
> on that board said,
> 
> "If you had time enough to do it over, how come you didn't have
> time enough to do it right?"
> 
>
As others have pointed out, the common answer is:  "The specifications
were incomplete at the beginning."

Mark Borgerson

On Fri, 24 Apr 2009 09:03:18 -0700, Joerg
<notthisjoergsch@removethispacbell.net> wrote:

>Spehro Pefhany wrote:
>> On Thu, 23 Apr 2009 16:22:38 -0700, the renowned Joerg
>> <notthisjoergsch@removethispacbell.net> wrote:
>> 
>>> Darin Johnson wrote:
>>>> On Apr 21, 6:09 pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
>>>> wrote:
>>>>> 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.
>>>> That's useful to point out.  Active low is usually an unfamiliar
>>>> concept to new embedded programmers.
>>>>
>>> Although, not much anymore these days. Most drivers are CMOS and the 
>>> difference between Rdson of the upper and lower devices is quite small.
>> 
>> I guess, if you consider >2:1 "quite small".  It's down to SS
>> physics-- the carrier mobility- a 2 or 3:1 difference between
>> n-channel and p-channel devices.  
>> 
>> Take for example, a PIC12F508 operating at 3.0V
>> 
>> Voh at 125�C is 1.5V at 4.5mA or so (3 sigma minimum)  
>> 
>> Vol at 125�C is < 0.7V at 10mA (again, 3 sigma maximum) 
>> 
>> The differences are not as great in HC devices (about 40% in the
>> guaranteed values), probably because they use larger devices for the
>> output p-channel, since it affects the rise time with a large fanout.
>> 
>> Anyway, most designers will automatically connect an LED+resistor load
>> between Vdd and a CMOS output, and if external discrete drivers are
>> required (eg. for muxing an array, the first ones to go discrete are
>> the source drivers). 
>> 
>> Though you can get some very nice p-channel discrete MOSFETs these
>> days if you don't mind very low breakdown voltage. 
>
>Last device I checked in this respect was the MSP430 and that had 
>relatively equal Rdson values for N and P.
><snip>

I just went back to some old notes.  Running on a 3V supply, the low
side output driver goes to 0.5V at 10mA and 1.5V at 25mA measured, so
50 ohms going towards 60 ohms over that 10mA to 25mA compliance.  On
the high side it was 0.5V at 8mA, so about 62.5 ohms.  I don't have
notes for trying to pull more than that from the high side.

But this is "relatively equal," I'd guess.  Perhaps because this was
by design and the LxW values are intentionally different?

Jon

Jon Kirwan wrote:
> 
.... snip ...
> 
> I just went back to some old notes.  Running on a 3V supply, the
> low side output driver goes to 0.5V at 10mA and 1.5V at 25mA
> measured, so 50 ohms going towards 60 ohms over that 10mA to 25mA
> compliance.  On the high side it was 0.5V at 8mA, so about 62.5
> ohms.  I don't have notes for trying to pull more than that from
> the high side.

Now consider what is going on inside that chip.  At 10 ma, the
drive component is passing 10 ma through 0.5 V, for 5 milliwatts
internal dissipation.  At 25 ma, it is passing 25 ma through 1.5 V,
for 37.5 milliwatts internal dissipation.  Which is most likely to
destroy the output transistor?

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

Jon Kirwan wrote:
> On Fri, 24 Apr 2009 09:03:18 -0700, Joerg
> <notthisjoergsch@removethispacbell.net> wrote:
> 
>> Spehro Pefhany wrote:
>>> On Thu, 23 Apr 2009 16:22:38 -0700, the renowned Joerg
>>> <notthisjoergsch@removethispacbell.net> wrote:
>>>
>>>> Darin Johnson wrote:
>>>>> On Apr 21, 6:09 pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
>>>>> wrote:
>>>>>> 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.
>>>>> That's useful to point out.  Active low is usually an unfamiliar
>>>>> concept to new embedded programmers.
>>>>>
>>>> Although, not much anymore these days. Most drivers are CMOS and the 
>>>> difference between Rdson of the upper and lower devices is quite small.
>>> I guess, if you consider >2:1 "quite small".  It's down to SS
>>> physics-- the carrier mobility- a 2 or 3:1 difference between
>>> n-channel and p-channel devices.  
>>>
>>> Take for example, a PIC12F508 operating at 3.0V
>>>
>>> Voh at 125�C is 1.5V at 4.5mA or so (3 sigma minimum)  
>>>
>>> Vol at 125�C is < 0.7V at 10mA (again, 3 sigma maximum) 
>>>
>>> The differences are not as great in HC devices (about 40% in the
>>> guaranteed values), probably because they use larger devices for the
>>> output p-channel, since it affects the rise time with a large fanout.
>>>
>>> Anyway, most designers will automatically connect an LED+resistor load
>>> between Vdd and a CMOS output, and if external discrete drivers are
>>> required (eg. for muxing an array, the first ones to go discrete are
>>> the source drivers). 
>>>
>>> Though you can get some very nice p-channel discrete MOSFETs these
>>> days if you don't mind very low breakdown voltage. 
>> Last device I checked in this respect was the MSP430 and that had 
>> relatively equal Rdson values for N and P.
>> <snip>
> 
> I just went back to some old notes.  Running on a 3V supply, the low
> side output driver goes to 0.5V at 10mA and 1.5V at 25mA measured, so
> 50 ohms going towards 60 ohms over that 10mA to 25mA compliance.  On
> the high side it was 0.5V at 8mA, so about 62.5 ohms.  I don't have
> notes for trying to pull more than that from the high side.
> 
> But this is "relatively equal," I'd guess.  Perhaps because this was
> by design and the LxW values are intentionally different?
> 

Careful, as Chuck hinted, that's pushing your luck. Tzzzt ... phut ... 
*POOF*

A newer device I checked ended up near 35ohms both H and L. It is best 
if digital stuff is designed that way because it eases fast multi-phase 
PWM controls, dead time control and so on. The H to L difference is 
mostly a remnant from the TTL days. That stuff really could not source 
worth a dime.

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

On Fri, 24 Apr 2009 17:16:35 -0400, CBFalconer <cbfalconer@yahoo.com>
wrote:

>Jon Kirwan wrote:
>> 
>... snip ...
>> 
>> I just went back to some old notes.  Running on a 3V supply, the
>> low side output driver goes to 0.5V at 10mA and 1.5V at 25mA
>> measured, so 50 ohms going towards 60 ohms over that 10mA to 25mA
>> compliance.  On the high side it was 0.5V at 8mA, so about 62.5
>> ohms.  I don't have notes for trying to pull more than that from
>> the high side.
>
>Now consider what is going on inside that chip.  At 10 ma, the
>drive component is passing 10 ma through 0.5 V, for 5 milliwatts
>internal dissipation.  At 25 ma, it is passing 25 ma through 1.5 V,
>for 37.5 milliwatts internal dissipation.  Which is most likely to
>destroy the output transistor?

Well, I wasn't suggesting this as practice.  At the time, I was just
playing with a new part to monitor about where it hit mid-point and
where it hit 0.5V.  Reporting my notes isn't a suggestion and I didn't
intend it as one.

I was mainly supporting Joerg's comment, by looking back at early
notes I took.  In particular, note that at 10mA/0.5V for the low side
drive mosfet and 8mA/0.5V for the high side drive mosfet.

It might have helped if I hadn't reported the 1.5V figure for the low
side.  But it was there in the notes, so I wrote it out.  Oh, well. No
good dead... and all that.

Jon

On Fri, 24 Apr 2009 16:04:32 -0700, Joerg
<notthisjoergsch@removethispacbell.net> wrote:

>Jon Kirwan wrote:
>> On Fri, 24 Apr 2009 09:03:18 -0700, Joerg
>> <notthisjoergsch@removethispacbell.net> wrote:
>> 
>>> Spehro Pefhany wrote:
>>>> On Thu, 23 Apr 2009 16:22:38 -0700, the renowned Joerg
>>>> <notthisjoergsch@removethispacbell.net> wrote:
>>>>
>>>>> Darin Johnson wrote:
>>>>>> On Apr 21, 6:09 pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
>>>>>> wrote:
>>>>>>> 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.
>>>>>> That's useful to point out.  Active low is usually an unfamiliar
>>>>>> concept to new embedded programmers.
>>>>>>
>>>>> Although, not much anymore these days. Most drivers are CMOS and the 
>>>>> difference between Rdson of the upper and lower devices is quite small.
>>>> I guess, if you consider >2:1 "quite small".  It's down to SS
>>>> physics-- the carrier mobility- a 2 or 3:1 difference between
>>>> n-channel and p-channel devices.  
>>>>
>>>> Take for example, a PIC12F508 operating at 3.0V
>>>>
>>>> Voh at 125�C is 1.5V at 4.5mA or so (3 sigma minimum)  
>>>>
>>>> Vol at 125�C is < 0.7V at 10mA (again, 3 sigma maximum) 
>>>>
>>>> The differences are not as great in HC devices (about 40% in the
>>>> guaranteed values), probably because they use larger devices for the
>>>> output p-channel, since it affects the rise time with a large fanout.
>>>>
>>>> Anyway, most designers will automatically connect an LED+resistor load
>>>> between Vdd and a CMOS output, and if external discrete drivers are
>>>> required (eg. for muxing an array, the first ones to go discrete are
>>>> the source drivers). 
>>>>
>>>> Though you can get some very nice p-channel discrete MOSFETs these
>>>> days if you don't mind very low breakdown voltage. 
>>> Last device I checked in this respect was the MSP430 and that had 
>>> relatively equal Rdson values for N and P.
>>> <snip>
>> 
>> I just went back to some old notes.  Running on a 3V supply, the low
>> side output driver goes to 0.5V at 10mA and 1.5V at 25mA measured, so
>> 50 ohms going towards 60 ohms over that 10mA to 25mA compliance.  On
>> the high side it was 0.5V at 8mA, so about 62.5 ohms.  I don't have
>> notes for trying to pull more than that from the high side.
>> 
>> But this is "relatively equal," I'd guess.  Perhaps because this was
>> by design and the LxW values are intentionally different?
>
>Careful, as Chuck hinted, that's pushing your luck. Tzzzt ... phut ... 
>*POOF*
>
>A newer device I checked ended up near 35ohms both H and L. It is best 
>if digital stuff is designed that way because it eases fast multi-phase 
>PWM controls, dead time control and so on.

Because of what I already know about P and N channel mosfets, when I
see balanced outputs like this I tend to imagine they are designed to
be that way.  And PWM DAC is what comes early to mind.

>The H to L difference is 
>mostly a remnant from the TTL days. That stuff really could not source 
>worth a dime.

Don't I know it.  I will never forget Ioh=400uA.

Jon

Jon Kirwan wrote:
> On Fri, 24 Apr 2009 16:04:32 -0700, Joerg
> <notthisjoergsch@removethispacbell.net> wrote:
> 

[...]

>> The H to L difference is 
>> mostly a remnant from the TTL days. That stuff really could not source 
>> worth a dime.
> 
> Don't I know it.  I will never forget Ioh=400uA.
> 

I'll never forget the time when I pushed one real hard driving a diode 
sampler, touched it and ... tssssst ... had seven blisters on my index 
finger, 1/100" spacing.

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

Chris H wrote:

> Blind enthusiasm gets people killed. though how one teaches students
> caution id a difficult question.

Not necessarily.  "Once burnt, twice shy" is ancient wisdom that fully 
applies here.  Countless generations of parents have consistently found 
that there's only one way to teach caution: first-hand experience of 
actual pain caused by lack of it.

Egos, like toes, have to be stubbed a couple times to convey the value 
of caution.  Once the necessary number of painful experiences have taken 
place, the lesson can be completed and renewed by scary movies or war 
stories ---- but the initial stage will invariably be accompanied by an 
"ouch!".

So yes, beginners will be a little full of themselves.  Sooner or later 
that will lead to a bloody nose.  Since you know it will happen 
regardless what you try, and it's actually in everybody's interest that 
it does, the best you can do is keep some control over when and how it 
does, so nobody gets hurt too bad.  Book the costs under the heading 
"educational expenses".

Hans-Bernhard Br�ker wrote:
> Chris H wrote:
> 
>> Blind enthusiasm gets people killed. though how one teaches students
>> caution id a difficult question.
> 
> Not necessarily.  "Once burnt, twice shy" is ancient wisdom that fully
> applies here.  Countless generations of parents have consistently found
> that there's only one way to teach caution: first-hand experience of
> actual pain caused by lack of it.
> 
> Egos, like toes, have to be stubbed a couple times to convey the value
> of caution.  Once the necessary number of painful experiences have taken
> place, the lesson can be completed and renewed by scary movies or war
> stories ---- but the initial stage will invariably be accompanied by an
> "ouch!".
> 
> So yes, beginners will be a little full of themselves.  Sooner or later
> that will lead to a bloody nose.  Since you know it will happen
> regardless what you try, and it's actually in everybody's interest that
> it does, the best you can do is keep some control over when and how it
> does, so nobody gets hurt too bad.  Book the costs under the heading
> "educational expenses".

Yes.  I distinctly remember one incident, back when we were still
losing the war and the US hadn't gotten involved yet.  I had a 100
watt iron on something on top of my dresser, and I knocked it off. 
I caught it, protecting the floor etc. from being burnt, but I
rapidly learned the smell of scorched flesh.  After restoring it to
the holder I could yell and get parents involved.  I haven't caught
another iron since.  My palm eventually healed.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

On Apr 25, 11:04=A0am, Joerg <notthisjoerg...@removethispacbell.net>
wrote:
> A newer device I checked ended up near 35ohms both H and L. It is best
> if digital stuff is designed that way because it eases fast multi-phase
> PWM controls, dead time control and so on. The H to L difference is
> mostly a remnant from the TTL days. That stuff really could not source
> worth a dime.

It depends, most price-sensitive devices use what I'd all area-
matching on their
P-N drivers, so a typical uC has 10mA spec, for 220mV Vol and 500mV
Voh drops.
To get better matching , you need to skew the area, which costs money

Even LVC logic, which has a nominal 24mA symmetric spec, gives 550mV
NF
and 800mV PF at 24mA,

Then, you can find the Die impedance, and bonding impedances, favour
the
N Side even more. (Which digital designer things about the Vcc
impedance ?)

I recall checking an early AVR, and the 'rubbish' (!) that came
out of the ports driven HI, was indicative of quite high Power
impedances inside the chip.

-jg