An Ametuer Who needs Advice

Devyn wrote:

<snip>

>I want know if what i'm doing is right-
>
>1) Write the code in C
>2) View the assembly version
>3) Cut out extra lines and optimize Assembly Code
>4) Generate Hex code and download it into the PIC

I have no experience with the Hitech compiler nor with PICs, but Step 3
is not typical in any of the many development environments I have used.
The compiler should be responsible for its own optimizations.  Even in
unoptimized mode there should be few if any truly "extra" lines.  The
worst part is that doing this seperates ones source code from the object
code it represents.  This makes development and maintenance far more
difficult.

The only time I have done this kind of thing is when I used C as an
algorithmic starting point for a function that I knew would have to be
extremely optimized for speed.  In this case, only the assembly source
was used in the release build and the C source was included only as
comments in the assembly source to document the technique.

<snip>

-- 
========================================================================
          Michael Kesti            |  "And like, one and one don't make
                                   |   two, one and one make one."
          mkesti@gv.net            |          - The Who, Bargain

Hi, this is the problem with C on these small micros (1 of the problems
anyway). Dump it and go back to using the free assembler.

"Albert Lee Mitchell" <albmit@albert.amresearch.com> wrote in message
news:pan.2003.12.24.23.06.50.307995@albert.amresearch.com...
> On Fri, 19 Dec 2003 00:47:16 +0000, Chris Hills wrote:
>
> > In article <pan.2003.12.18.23.34.04.495514@albert.amresearch.com>,
> > Albert Lee Mitchell <albmit@albert.amresearch.com> writes
> >>       Linux won't help a bit with embedded micros, move on to the three
or
> >>four
> >>main languages used,
> >
> > C in 90%
>
> Do you have any data to support this guestimate?
>
> >>Basic,
> > only by amateurs at home

I am under the impression that the basic compilers/interpreters are good
tools for people who have an objective but don't want (or can't) get too
deep into the understanding of controllers, etc. Builders of model robots
and the like do pretty well with the parallax stamp. It is also a good
product for mechanical engineers, scientists, etc., who want to accomplish
tasks that are appropriate to those kinds of products without going
overboard in terms of having to learn to program in C or asm. -- Mike

Michael R. Kesti <mkesti@gv.net> wrote:
> I have no experience with the Hitech compiler nor with PICs, but Step 3
> is not typical in any of the many development environments I have used.
> The compiler should be responsible for its own optimizations.  Even in
> unoptimized mode there should be few if any truly "extra" lines.  The
> worst part is that doing this seperates ones source code from the object
> code it represents.  This makes development and maintenance far more
> difficult.

If you're trying to pass off compiler output as assembly-language
homework, as I suspect the OP might be doing, there probably will be 
"extra lines" ;P

pete
-- 
pete@fenelon.com "There's no room for enigmas in built-up areas."

In article <PzkHb.14738$7D3.3097@fed1read02>, Mike Turco
<miketurco@yahoo-nospam4me.com> writes
>
>"Albert Lee Mitchell" <albmit@albert.amresearch.com> wrote in message
>news:pan.2003.12.24.23.06.50.307995@albert.amresearch.com...
>> On Fri, 19 Dec 2003 00:47:16 +0000, Chris Hills wrote:
>>
>> > In article <pan.2003.12.18.23.34.04.495514@albert.amresearch.com>,
>> > Albert Lee Mitchell <albmit@albert.amresearch.com> writes
>> >>       Linux won't help a bit with embedded micros, move on to the three
>or
>> >>four
>> >>main languages used,
>> >
>> > C in 90%
>>
>> Do you have any data to support this guestimate?

Several sets.

The one below shows C at 80% in 1997... the use of C in embedded work
has not deminished.  BAsIC and PL/M have declined. C++ increased. 

I can dig out other surveys etc but most are in hard copy. this one was
electronic.



http://www.netrino.com/Publications/Bibliography

From: Bill Giovino <editor@microcontroller.com>
Subject: Re: Embedded Systems development languages?
Date: Sat, 04 Sep 1999 
Organization: http://www.Microcontroller.com

Re: Embedded Systems development languages?

That has a one-letter answer:  C.  I would guess 75% of small-to-medium-
scale projects are done largely in C, occasionally with small hand-coded
sections of assembler.  Another 20% in assembler and Forth, and the rest
in obscure languages for certain esoteric applications.  Programmers
often claim to write these programs in C++ but their coding style is
generally just 'straight C'; they just happen to be using a C++
compiler.  A bigger project, running on PC-like hardware, is a different
animal and genuine object-oriented C++ Would probably be the language of
choice.  A very small project (less than about 1K of code) will more
frequently be written in assembler, purely because the processor it's
running on will be so small that hand-optimisation will be necessary.

This information is from 1997:
Programming Languages used in Embedded Development:
C                       80%
Assembly        75%
C++             49%
BASIC           15%
Fortran         8%
ADA             6%
Java            4%
Forth           1%
PL/M            1%
Other           2%

This is from a representative survey of 233 software engineers over
various markets. Note that this does not add up to 100%, as more than
one language may be used on a project...  Embedded C++ was not broken
out from C++.

Many surveys ask engineers what language they would be using 2, 3 years
out. In my opinion, those numbers are worthless - any engineer will tell
you he hopes to be hopes to be using the latest programming language!
80% of you are using fuzzy logic, right?


-Bill Giovino
 http://www.Microcontroller.com




/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

"Chris Hills" <chris@phaedsys.org> wrote in message
news:XoOqFDADbf7$EA8J@phaedsys.demon.co.uk...
> In article <PzkHb.14738$7D3.3097@fed1read02>, Mike Turco
> <miketurco@yahoo-nospam4me.com> writes
> >
> >"Albert Lee Mitchell" <albmit@albert.amresearch.com> wrote in message
> >news:pan.2003.12.24.23.06.50.307995@albert.amresearch.com...
> >> On Fri, 19 Dec 2003 00:47:16 +0000, Chris Hills wrote:
> >>
> >> > In article <pan.2003.12.18.23.34.04.495514@albert.amresearch.com>,
> >> > Albert Lee Mitchell <albmit@albert.amresearch.com> writes
> >> >>       Linux won't help a bit with embedded micros, move on to the
three
> >or
> >> >>four
> >> >>main languages used,
> >> >
> >> > C in 90%
> >>
> >> Do you have any data to support this guestimate?
>
> Several sets.

That wasn't my question and I doubt that you and I would have any
disagreement regarding this matter. I don't doubt what you are saying about
C being the prevalent language. It beats basic, hands down, when it comes to
doing serious work with controllers. However, there are many instances where
C is not required. Basic is a good general purpose tool that bridges the gap
for people who aren't necessarily f/w or h/w folks, but need to accomplish
specific tasks.

On 27 Dec 2003 18:42:09 GMT, CBarn24050 wrote:

> Hi, this is the problem with C on these small micros (1 of the problems
> anyway). Dump it and go back to using the free assembler.

Plus you will learn a *LOT* more about microprocessors writing in Assembler
- of course you can also learn a lot of patience  and humility trying to
sort out compiled code in assembler ;)

You will find articles about real-time and embedded software design
at:

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

Sandeep
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - Go Beyond UML Use Case and Sequence Diagrams

On Fri, 26 Dec 2003 10:36:31 +0000, Chris Hills wrote:

> In article <pan.2003.12.24.23.06.50.307995@albert.amresearch.com>,
> Albert Lee Mitchell <albmit@albert.amresearch.com> writes
---------snip------------
>>>>Basic,
>>> only by amateurs at home
>>
>>       Correct me if I'm wrong but the original post this thread responds to is
>>by a self-professed amateur. 
> 
> So? That is no reason to use it. There are plenty of C tools and support
> available from the free to the very expensive.  The point is that there
> is a LOT of support for C for all levels. There is no need to tie one
> self down to a less appropreate language just because some ametures use
> it.. 

	Yes, it is a reason unless you are pursuing your own agenda.  The
gentleman originating this tread asked specifically for "amateur" help.  C
is not for amateurs and arguably not for low-level embedded applications. 
At least not with optimization turned on.

>>       On most micros however there is no correlation between the number of 
>>developers using Forth 
>>and the number of embedded control projects in use.
> 
> This is true. The amount of forth in use probably dwindles even more if
> you look ate the number of projects or indeed the number of installed
> devices.

	Dogma again.  Forth is a well-hidden trade secret by most of my clients. 
There is no way, again, that you can supply any meaningful statistics so
please discriminate between your opinion and reality.
 
> I have nothing against forth but an ammeter will get fat more help and
> support (and tools) on a far wider variety of micros and application
> types that he could from forth.

	Huh?  No tool is better than it's user.  Again, the number of products
has no correlation to it's quality.  Hmmm, a pattern is emerging here. 
Instead of pushing your agenda why not give cites and evidence and let the
reader and original poster decide?


-- Regards, Albert
----------------------------------------------------------------------
AM Research, Inc.    			  The Embedded Systems Experts
http://www.amresearch.com          			  916.780.7623
----------------------------------------------------------------------

Albert Lee Mitchell wrote:


>  
>> I have nothing against forth but an ammeter will get fat more help and
>> support (and tools) on a far wider variety of micros and application
>> types that he could from forth.
> 
> Huh?  No tool is better than it's user.  Again, the number of products
> has no correlation to it's quality.  Hmmm, a pattern is emerging here.
> Instead of pushing your agenda why not give cites and evidence and let the
> reader and original poster decide?
> 

I think you miss his point.  I suspect he means the number of *users* who
can provide support via forums like this is greater.

Ian