On Wed, 02 Mar 2005 00:49:30 +0800, Dan
<d...@dontspammecauseidontlikit.com> wrote:

>On Tue, 01 Mar 2005 11:24:40 GMT, Jonathan Kirwan
><j...@easystreet.com> wrote:
>
>
>>Since the OP specifically mentioned trying to gain knowledge to help secure a
>>job in embedded programming and admitted little assembly experience, I'd
>>recommend working especially on the assembly skills. 
>
>I have to disagree.  I have an embedded application on a Hitachi
>processor with close to 16,000 lines of C++ code.  The total assembly
>code is less than 20 lines.  To spend a lot of time learning assembly
>is counter-productive.  Code written in C and C++ is significantly
>easier to write, debug and maintain.  Knowledge of assembly can at
>times be helpful, but keep it in the 20 to 16,000 perspective.
>

Often those 20 lines of assembly either makes the other 16000 lines
work correctly or not. i.g. if the startup code is not correct, then
one can either not even reach main, or one can have very strange and 
difficult bugs to debug. On a normal OS, those issues are sorted out.
On many embedded systems, that is the most difficult part to sort out.
Unless one has got fairly expensive equipment, the startup portion has
to be debugged blind.

Regards
   Anton Erasmus

On Wed, 02 Mar 2005 00:49:30 +0800, Dan <d...@dontspammecauseidontlikit.com>
wrote:

>On Tue, 01 Mar 2005 11:24:40 GMT, Jonathan Kirwan
><j...@easystreet.com> wrote:
>
>>Since the OP specifically mentioned trying to gain knowledge to help secure a
>>job in embedded programming and admitted little assembly experience, I'd
>>recommend working especially on the assembly skills. 
>
>I have to disagree.  I have an embedded application on a Hitachi
>processor with close to 16,000 lines of C++ code.  The total assembly
>code is less than 20 lines.  To spend a lot of time learning assembly
>is counter-productive.  Code written in C and C++ is significantly
>easier to write, debug and maintain.  Knowledge of assembly can at
>times be helpful, but keep it in the 20 to 16,000 perspective.

I expected the disagreement, Dan.  No problem.

I'll just say that packing 16k lines of C++ into a project, with only 20 lines
of assembly, this means to me that you are probably programming on a relatively
general purpose computing platform and perhaps even with some unstated library
or operating system support that you forgot to mention, as well.

I tend to define embedded programming as a matter of degree that an environment
is UNLIKE a general purpose computing platform.  The more it is different from
this type of programming, the more "embedded" it is.  This is, in fact, why
embedded programmers require other skills.  It is this requirement for special
skills, in fact, that helps to define embedded programming for me.

Those special skills may include:
 * analog and digital design skills
 * schematic reading skills
 * hardware tools familiarity (o'scope, signal gen., etc.)
 * understanding locating linker semantics
 * being familiar with assembly on a variety of CPUs
 * soldering skills
 * mechanical/construction skills
 * familiarity with common hardware functions (like USARTs, timers, etc.)
 * willingness to learn things *before* they are needed...

These are the kinds of things that separate embedded from general purpose and
gives different meaning to the terms.  Highly embedded is at one end of the
spectrum, general purpose computing at the other end.

Jon

On Tue, 01 Mar 2005 22:55:13 +0200, Anton Erasmus <n...@spam.prevent.net>
wrote:

>On Wed, 02 Mar 2005 00:49:30 +0800, Dan
><d...@dontspammecauseidontlikit.com> wrote:
>
>>On Tue, 01 Mar 2005 11:24:40 GMT, Jonathan Kirwan
>><j...@easystreet.com> wrote:
>>
>>
>>>Since the OP specifically mentioned trying to gain knowledge to help secure a
>>>job in embedded programming and admitted little assembly experience, I'd
>>>recommend working especially on the assembly skills. 
>>
>>I have to disagree.  I have an embedded application on a Hitachi
>>processor with close to 16,000 lines of C++ code.  The total assembly
>>code is less than 20 lines.  To spend a lot of time learning assembly
>>is counter-productive.  Code written in C and C++ is significantly
>>easier to write, debug and maintain.  Knowledge of assembly can at
>>times be helpful, but keep it in the 20 to 16,000 perspective.
>
>Often those 20 lines of assembly either makes the other 16000 lines
>work correctly or not. i.g. if the startup code is not correct, then
>one can either not even reach main, or one can have very strange and 
>difficult bugs to debug. On a normal OS, those issues are sorted out.
>On many embedded systems, that is the most difficult part to sort out.
>Unless one has got fairly expensive equipment, the startup portion has
>to be debugged blind.

I should have added the point that the very fact that there IS any assembly at
all in Dan's project points up the need to be familiar with assembly.  If you
need it, you need it.  And chances are, what you need cannot be fabricated well
if you are a neophyte in assembly.  They will be *choice* assembly lines, formed
well only through a thorough and burnished knowledge from good experience.

Jon

On Tue, 01 Mar 2005 18:54:21 GMT, Nicholas O. Lindan wrote:

> Yes.  OTOH, one should do one reasonably sized project in assembler
> as part of a good education.
> 
> An engineer needs to know how to evaluate tools, including compilers.  
> Without a somewhat in depth understanding of assembler coding and 
> assembler techniques one can not do a competent job of evaluation.
> 
> Ditto the determining the applicability of a processor architecture 
> to the job at hand.

Probably the biggest benefit to learning assemler is that it forces you to
gain an understanding of how a microprocessor works. C/C++ allows you to
code away without any real knowledge of the architecture, register sets,
addressing modes, interrupt structure etc. Once a person has learned a
micro inside and out by developing a significant amount of code in assembly
or machine language, learning a new device is just a matter of perusing the
databook. The core knowledge is pretty much transferrable from one chip to
the next.


Bob

Bob Stephens wrote:

> Probably the biggest benefit to learning assemler is that it forces
> you to gain an understanding of how a microprocessor works. C/C++
> allows you to code away without any real knowledge of the
> architecture, register sets, addressing modes, interrupt structure
> etc. Once a person has learned a micro inside and out by developing a
> significant amount of code in assembly or machine language,

You dont have to develop a lot of code.
I started by writing compilers, and this works as well.
Only did two significant projects in assembler in my life.

My favorite was 22kB of assembler code (libraries not included)
developed in less than 24 working hours...
That is almost 1 kB of tested assembly code per hour...

One project I did which never would have  worked in C
was a multitasking program running on a 2-3 MIPS machine
doing 250,000 task switches per second...
Hairy, but got the job done...

Was thinking along the line:
  What happens if I jump to the status register...
When an input port change, this is reflected in the status register
so you could conceivable set the flags to "jump to self"
if the bit is clear, and jump elsewhere when the bit changes.
Almost worked...

Not possible in C

> learning
> a new device is just a matter of perusing the databook. The core
> knowledge is pretty much transferrable from one chip to the next.
>
>
> Bob

-- 
Best Regards,
Ulf Samuelsson
u...@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

"Rob Miller" <r...@coe.neu.edu> wrote in message
news:1...@z14g2000cwz.googlegroups.com...
> I am a recent graduate with a BS in Computer engineering.  I am
> interested in working with embedded systems, but I have no experience
> with them.  I've done basic C/C++ programming and very little ASM.
>
> What steps should I take to learn?
>


Rob,

How about a free online tutorial for Pic chips. It should get you started in
asm.

http://www.mikroelektronika.co.yu/english/product/books/PICbook/picbook.htm

HTH

Mike.

Dan <d...@dontspammecauseidontlikit.com> writes:

> GNU gcc is free, exellent, and C++.  You're definately not limited to
> C.  There are binaries available for the Hitachi processors and for
> many others as well.

Speaking of Hitachi, the Lego Mindstorms might be a possibility for
learning embedded systems.  It uses the Hitachi H8/300.  The
disadvantages are that the ROM documentation is lacking, but there are
lots of web sites out there that could help.  There's no debugger
interface either.  There are definately better systems to learn on.
However, it's relatively inexpensive and can be a lot of fun.

-- 
Darin Johnson
    Support your right to own gnus.

Rene Tschaggelar <n...@none.net> writes:

> Not all projects allow for a Linux system with C++.

Even Linux uses assembler.  And even the C++ has some
inline assembler as well.  It depends upon where the
focus is.  The boot up code almost always has some sort
of assembler in it, as well as core OS routines.
Pre-canned operating systems take away much of the need
for assembler though.

Even if one doesn't have to write assembler well, one should
definately know how to read it!  Also it's very useful to be
able to understand the assembly output from the compiler, to
know where it does a good job and where it is inefficient,
and how things are layed out on the stack.

-- 
Darin Johnson
    "Look here.  There's a crop circle in my ficus!"  -- The Tick

"Ulf Samuelsson" <u...@a-t-m-e-l.com> writes:

> It is OK to know something about assembler, but
> it is probably OK to know just so much that
> you can figure out if you need to improve your C code or not.

If I were looking at job candidates, I would feel much more
confident that candidates that knew assembler had a better
feel for low level machine concepts than candidates that only
knew C.  It isn't a matter of whether they'd actually have to
_use_ assembler or not, but if they know that the board is not
just a black box to put applications on top of.

Ie, a C-only programmer is more likely to think that "count++" is
an atomic operation than a C programmer who's had exposure to
assembler.

Even if it is a 20 lines versus 16,000 lines issue, those 16,000
lines probably weren't written by someone with C-only experience.

-- 
Darin Johnson
    Where am I?  In the village...  What do you want?  Information...

On Tue, 01 Mar 2005 20:58:02 GMT, Jonathan Kirwan
<j...@easystreet.com> wrote:


>I expected the disagreement, Dan.  No problem.

I had a feeling I might cause a bit of controversy with my original
statement.  :-)  Thanks for you thoughts.

>I'll just say that packing 16k lines of C++ into a project, with only 20 lines
>of assembly, this means to me that you are probably programming on a relatively
>general purpose computing platform and perhaps even with some unstated library
>or operating system support that you forgot to mention, as well.

I'm using a 16 bit processor with a bit of memory and some serial
ports and i/o pins.  If that's not embedded I don't know what is.  The
only os type support that I have, queues and timers and such, is what
I've written myself.  The compiler has some standard C library
routines, all the more reason to use C.

>Those special skills may include:
> * analog and digital design skills
> * schematic reading skills
<snipped>

I agree with you here, these are all useful skills.  But knowledge of
assembly would be at the bottom of my list.  I'll pick up an
oscilloscope lead 100 times before I'll look at the assembly output of
the compiler.

Even 8 bit processors and little PICs have C compilers.  People keep
telling me how you need assembly to optimise for either speed or size,
but I've never found a need for it.  Maybe that was the case 20 years
ago when memory  size and processor speed and was more of an issue.

It's much more difficult to write structured code in assembly
language.  It takes way longer to write and it's harder to debug.
It's also a lot harder for someone else to come in afterwards and look
at the code.  I can't imagine anyone writing anything in assembly
unless they absolutely had to, and I can't see very many places where
there's really a need.

Dan