To be honest, how many people are seriously using Olin's
programming environment? I try to learn from the codes but 
I will probably not use it as a whole. The same questions to
JAL. I hear that it is quite inefficient regarding banking
and page selecting but I could be wrong since I have
not really use it other than looking at the Wisp628 
firmware code.

I think assembly (standard MPASM/GPASM) are still the 
most commonly used for the 12/14bit architecture. And
beginners need to understand the datasheet and the 
assembly anyway. But the OP is talking about 16-bit
PIC18Fs. C18 is not too bad and the student version
is free and quite usable. HiTech PICC18 is also quite
good if one wants to pay for it. The beginners can use 
C18 and Assembly at the same time for PIC18F.

The comments about C and PIC18F is not fair IMHO.
Even for PIC12F/16F, HiTech PICC is quite good. I 
started my learning of PIC with PICC 7.85 after
reading the datasheets and a bit of assembly.

And the recommendation of EMBEDINC programming environment 
to the beginners are simply not correct IMHO. I think
Olin is also not recommending that. I am not so sure about 
JAL though. Maybe it is okay.

Regards,
Xiaofan

-----Original Message-----
From: piclist-bounces@mit.edu 
Sent: Thursday, October 27, 2005 9:36 AM
To: piclist@mit.edu
Subject: RE: [PIC] Any advantage of using assembler?


Michael Rigby-Jones wrote:

> I agree to an extent, but the chances of introducing a bug
> in a pure assembly program is far higher than with C IME,
> and often a lot harder to find, especialy in the case of
> a micro with banked/paged memory like the PIC.

For an actual, honest, compiler defect, this statement is probably true. 
But the PIC, especially the 14 and 16 bit core (and I believe the OP was
referring to the 16 bit core) is an environment dramatically different
than that envisoned by the framers of the C language.  While a real
compiler bug my be fairly rare, misbehavior that the programmer would be
unable to differentiate from a bug can be pretty common.

Many common C idioms are simply not possible on the PIC,  (yes, I know
about Turing and all that) and others require the compiler to jump through
an amazing number of hoops.  If you are unfamiliar with the PIC, and
unfamiliar with how the compiler translates C structures into MCU
instructions, you will find it difficult to write and especially debug all
but the most trivial code.

Guys like Olin and Wouter have "languages" that understand the PIC and
it's environment.  Those languages are also well suited to the types of
applications that tend to be written for the PIC.

It is interesting, because either of those guys could probably understand
the vagaries of any compiler in pretty short order, and use a language
like C as a significant productivity boost.

But for someone who doesn't have a deep understanding of the PIC and the
compiler, C, or any modern, nested-scope language for that matter, will be
a real minefield.  For the beginner with the PIC, especially if he already
has a good understanding of C, it would be far better to start with
assembler.

I think that a beginner could be more productive in JAL or Olin's macros,
but I haven't actually used either environment in anger, so I can't say
for sure.

But C, Pascal, and other languages in that family are such a poor fit for
the PIC that the beginner is far better off starting in assembler.  Unless
you have a good understanding of the PIC, the behavior of those compilers
can be quite startling.

--McD

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist