Wagner,

I agree with you - it's essential to know both.  I used to agree with you about
using asm instead of C for "flexibility and control," but a few projects in
mixed modes made me see the value of C.  I now have equal flexibility and
control in either one.

I've been working with these (and other) processors for quite a few years, and
find myself using C to produce quick bug-free code in a shorter time than in
assembly, quite consistently.  Doesn't matter which processor.  WRT PICs, if I
have a library routine in asm, I frequenty drop it into C (this is VERY easy to
do with the HiTech tools).  If I have to write it anew, I use C and frequently
debug the algorithm on my PC using PC tools, then use the same code (sometimes
with minor revisions, often with none) in a PIC.

The C compiler is a tool, just like the assembler.  You ahve to use the right
tool for the job.

Granted, there are some things that are difficult if not impossible to do in C.
One recent example is to perform a add/mult/div sequence on 16-bit values, while
measuring the pulse on a pin at 6uS intervals, using a 4 MHz resonator.
Impossible with straight C, but easy in asm.

The algorithm for the add/mult/div portion was coded in C.  I then interleaved
my pulse measurement into the assembly source code (-S option for HiTech).
Then I had to transfer the code from the HiTech assembler to work on CVASM (to
maintain compatibility with the customer).

Took a little time, but it worked first shot.  It was faster than going it from
assembly the whole way.

It was a matter of using the right tool at the right time in the application.

So, yes, knowing both is essential, but ruling out one or the other is foolish.

Andy










Wagner Lipnharski <wagner@USTR.NET> on 04/13/2000 11:23:13 AM

Please respond to pic microcontroller discussion list <PICLIST@MITVMA.MIT.EDU>








 To:      PICLIST@MITVMA.MIT.EDU

 cc:      (bcc: Andrew Kunz/TDI_NOTES)



 Subject: Re: Question: C vs Asm








Dale Botkin wrote:
>
> On Thu, 13 Apr 2000, Wagner Lipnharski wrote:
>
> > Your PIC C Compiler program source file is written in C language also,
> > correct?  What if, this compiler of the compiler has bugs and generates
> > some holes in the PIC C Compiler?  According to some piclisters here, it
> > is a fact that *every* C compiler has bugs, alive and identified, or
> > hidden and avid to use its fangs over your PIC, so, how can you live in
> > such tension of being possibly assaulted by a terrible ghost of despair
> > at 2am needing to have the code working for a 9am product presentation?
>
> Probably because I know if I do it in assembly, the presentation will be
> at 9 AM -- three months from now.

Exactly. This is the most common point for all "C" people. It will took
light years to produce the same code in assembler... Of course, probably
will take longer or even never be done, "if you don't know how to do
it"...  I know both and as I already said before, assembler takes
probably 10 to 15% more time than C, but I feel much more flexibility
and control.  I feel firmly positioned because I know them both.

[snip]

> > So, what can we learn about it?  If you have a problem with your program
> > written in "C", just don't despair, first *don't look at your code for
> > problems*, but go to the nearest tech support of your compiler and ask
> > if, by any chance, there is any possible *known* bug that can generate
> > such misbehavior at your software... if not, and don't forget it can be
> > a new bug at the compiler, then scan your source code for possible
> > errors, if you are good in assembler, then scan the generated code for
> > possible understanding of what is happening, at least, there is always
> > the black magic and voodoo in south america that are now updated to also
> > fix compilers and I2C routines...
>
> Naah.  First look at your own code, because it's more likely to be at
> fault. If YOUR code looks good, then look at the output of the compiler
> for problems.  If you don't see anything, then ask the compiler folk if
> there are known bugs.

But then again, I don't understand, if you don't know assembler, or
would take forever to write a code in ASM, how can you feel conformable
to debug the C compiler ASM output?

The closer I can imagine, is trying (for me) to debug a program looking
only at the .HEX file binary display...

Wagner