Dan wrote:

> On 28 Feb 2005 13:45:29 -0800, "Rob Miller" <r...@coe.neu.edu>
> wrote:
> 
>>I've done basic C/C++ programming and very little ASM.
> 
> There's very little need for using assembly in embedded programming.

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

On Tue, 01 Mar 2005 15:18:47 +0800, Dan <d...@dontspammecauseidontlikit.com>
wrote:

>On 28 Feb 2005 13:45:29 -0800, "Rob Miller" <r...@coe.neu.edu>
>wrote:
>
>> I've done basic C/C++ programming and very little ASM.
>
>There's very little need for using assembly in embedded programming.

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

You will find several articles about Embedded Software Development
at:

http://www.eventhelix.com/RealtimeMantra/

Deepa
--
EventStudio 2.5 - http://www.EventHelix.com/EventStudio
Real-time and Embedded System Modeling with Sequence Diagrams

Thanks for all the information.  Now I have to decide which direction
to go in.  I would like to start out small.  I used to co-op for Hasbro
and another company in Providence and did electronic toys there, so I
am somewhat familiar with 8-bit micros and I have also done some work
with PIC.  I know there is somewhat of a grey area between
microcontrollers and embedded systems (or so I've heard, but I think
this should help me.

I just wanted to thank everyone again for being so helpful, and
hopefully when I learn enough, I can help others.  Keep an eye out for
more newbie questions from me.

Rob Miller wrote:
> Thanks for all the information.  Now I have to decide which direction
> to go in.  I would like to start out small.  I used to co-op for Hasbro
> and another company in Providence and did electronic toys there, so I
> am somewhat familiar with 8-bit micros and I have also done some work
> with PIC.  I know there is somewhat of a grey area between
> microcontrollers and embedded systems (or so I've heard, but I think
> this should help me.

Yes, the grey area between a microcontroller and an embedded
system is called electronics. An embedded system starts at
a PIC plus something on a board. This something being :
-a communication unit such as serial, feldbus CAN, USB,
  ethernet and such.
-some measurement units such as filter & ADC
-some control units driving linepower, 24V, controlsignals, ..
-perhaps some storage
-perhaps some display units, LCD, LED, meters, ...
-perhaps a powersupply

> 
> I just wanted to thank everyone again for being so helpful, and
> hopefully when I learn enough, I can help others.  Keep an eye out for
> more newbie questions from me.
> 

Good luck.

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

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.

Dan

On Tue, 01 Mar 2005 09:19:06 +0100, Rene Tschaggelar <n...@none.net>
wrote:

>> There's very little need for using assembly in embedded programming.
>
>That is not necessarily true.
>Not all projects allow for a Linux system with C++.

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

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

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.

l...@larwe.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
>
> 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.

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

"Dan" <d...@dontspammecauseidontlikit.com> wrote

> To spend a lot of time learning assembly
> is counter-productive.

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.
To reply, remove spaces: n o lindan at ix  . netcom . com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/