Learning embedded systems - Page 4

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Learning embedded systems

Quoted text here. Click to load it

There's very little need for using assembly in embedded programming.

Dan



Re: Learning embedded systems

Quoted text here. Click to load it

That is not necessarily true.
Not all projects allow for a Linux system with C++.

Rene
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

Re: Learning embedded systems

Quoted text here. Click to load it

You certainly don't need Linux to program with C++.   I don't know of
any processor that don't have at least a C compiler.  C++ is not
uncommon in embedded systems.

Dan


Re: Learning embedded systems

Quoted text here. Click to load it

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

Re: Learning embedded systems

Quoted text here. Click to load it

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.  Don't ignore the C
knowledge, of course, but if the OP is weak on assembly and knows it, then this
is the area on which to concentrate effort.  Luckily, that is also exactly what
most manufacturers give away in their development systems, too.  So this is
entirely consistent with the OP's other comment about "a cheap development
system I can use at home."

I'd recommend focusing on developing assembly-only projects, as well as mixed
assembly and C; learning about linker control files (those files often used by
various embedded linkers that specify the memory arrangements in the target);
and facility with simulation and jtag debuggers, where possible.

It is exactly the ability to mix assembly with C or to program entire projects
in assembly and to be able to get in and adjust architecture/linker files to
meet project needs that will help differentiate an embedded programmer.

I hire embedded programmers.  And a lack of assembly experience, a lack of
knowledge in mixing assembly and C, a lack of knowledge about writing
significant applications in assembly, and a lack of knowledge in working with
linker control files are precisely the kinds of things that cause me to continue
looking elsewhere.  C-only experience is about a dime-a-dozen.

(Of course, if the desired embedded work is to be done on relatively large, and
relatively general purpose computing platforms, then the focus might be more on
specific experiences with application-specific features and functions.)

In other words, I don't agree much with the aim of your statement.  It is
exactly good experience with assembly that will better improve the OP's chances
at securing such a job.

Jon

Re: Learning embedded systems
On Tue, 01 Mar 2005 11:24:40 GMT, Jonathan Kirwan


Quoted text here. Click to load it

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.

Dan


Re: Learning embedded systems
Quoted text here. Click to load it
secure a
I'd

This is highly non-representative of embedded systems in general (in
terms of shipped units).

Not being able to understand your compiler's assembly output represents
a loss of control of the hardware and a step down the road to voodoo
programming.


Re: Learning embedded systems
Quoted text here. Click to load it

You definitely need to understand how to program in C
to generate efficient assembly code.

Number of shipped units is however not as good an indicator.
What is interesting is what jobs he can find with assembler skills and
which he can find with C skills.
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.

I can program in assembler , and in one project for the tiny15 without
any SRAM, it was neccessary, but when the tiny13 arrived
it was easy to rewrite in C without a big impact.
The allocation of global variables into register is quite useful.

--
Best Regards,
Ulf Samuelsson
We've slightly trimmed the long signature. Click to see the full one.
Re: Learning embedded systems

Quoted text here. Click to load it

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

Re: Learning embedded systems

Quoted text here. Click to load it

This is a bit dangerous example, since if the programmer is first
exposed to a processor with atomic memory location increments, this
assumption may be permanent, unless he/she studies to code for any
future processor as thoroughly as the first processor :-)

Paul


Re: Learning embedded systems

Quoted text here. Click to load it

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.

At the post-mortem to a disaster, pointing a finger at the local
expert and whining "He told me to use it" cuts no mustard.

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
We've slightly trimmed the long signature. Click to see the full one.
Re: Learning embedded systems

Quoted text here. Click to load it

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

Re: Learning embedded systems

Quoted text here. Click to load it

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

Quoted text here. Click to load it

--
Best Regards,
Ulf Samuelsson
We've slightly trimmed the long signature. Click to see the full one.
Re: Learning embedded systems
On Wed, 02 Mar 2005 00:49:30 +0800, Dan

Quoted text here. Click to load it

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




Re: Learning embedded systems

Quoted text here. Click to load it

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

Re: Learning embedded systems

Quoted text here. Click to load it

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

Re: Learning embedded systems
On Tue, 01 Mar 2005 20:58:02 GMT, Jonathan Kirwan


Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it
<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


Re: Learning embedded systems

Quoted text here. Click to load it

No problem, as I said.

Quoted text here. Click to load it

Sounds embedded.


That's not what I brought up, though.

Quoted text here. Click to load it

I've written, many times here in this group in the past, specific and useful
semantics that simply are not available via a C or C++ compiler.  Look it up via
google.  That you are NOT aware of them makes my point clearly.

Quoted text here. Click to load it

Which, true or otherwise, doesn't bear at all on why I said what I said.

Quoted text here. Click to load it

Sometimes.  But that statement is most certainly true if you refuse to become
competent at it.  When you aren't skilled at it, it's a given that you'd be
right.

Quoted text here. Click to load it

... and if you are hiring, it may be easier to find programmers who are familiar
with C.  I won't argue.

Quoted text here. Click to load it

My point is that good familiarity with assembly, whether or not it is required
for a specific project I have in mind, is valuable in my mind.  Having more
thinking tools, not less, is better.

I'd suggest to you that you think about the fact you don't even recognize some
of the unique values concerned.  I fully understand your points about C/C++ and
I agree with the value of using such languages in embedded work.  Yet you do NOT
understand my points.  Perhaps this is because of your lack, not mine.  Just a
thought for you to ponder.

Jon

Re: Learning embedded systems


Quoted text here. Click to load it

I just finished a project (MSP430) that's about 98 % C and 2 % assembly, but
I think that an understanding of assembly is essential. I may code the
application in C, but I think in assembly.

-Hershel Roberson

Re: Learning embedded systems

Quoted text here. Click to load it

Yes. That's it exactly.


Bob

Site Timeline