Chen Xiao Fan wrote:

> It is said that user can do some modifications to extend the chip support
> by an old version of PICC. Has anyone done it? 

I have done this on occasion. But you have to be careful. The only thing
you can (easily) do is to modify the include files, add ports and register
definitions, change EEPROM size, add/change configuration bit definitions.
You can't change the code generator, so you can't really get reliable
support for a series of chips that might need special consideration in the
code generation. (Some series of chips get special treatment according to
errata, for example.) 

So you have to find a base chip that has a code generation that's 100%
compatible with your target chip, and create the include file for your
target chip. Then you create a custom version of the pic.h file, that
contains the generic definitions from the original pic.h file, but includes
your custom include file, and use this in your project instead of the
compiler's pic.h file. And you use the base chip you selected in the
compiler command line options.


> I have problems to convince my boss to get the upgrade version. I only
> have version 7.86pl3 and it does not support a lot of new flash 16F
> PICs. 

IMO it is worth it to maintain a support subscription while you're working
with it. Makes sure you get quick fixes for any problems you may find.


> Actually I have problem to convince him to use C as well since we are
> doing simple programs (generally <2k) and yet have quite critical timing
> requirement. 

I don't know what you mean by "timing": code timing or development timing
:)  IMO C definitely helps with the latter. And usually it isn't a problem
with the former (unless your code structure is based on isochronous loops,
in which case I don't think there's an option to assembly). 

>From the discussions here about this (used to be more frequent, are kind of
rare these days), the result seems to be that for projects of this size
this is mostly a question of personal style. I'm glad that I don't have to
convince a boss... :)  But I guess the one most important argument for a
boss is probably that assembly code tends to be a lot more tied to an
individual than C code. When programming in assembly, you tend to create
your own "language" (maybe better "programming environment"), so to speak
-- look at Olin's stuff, a good example of that. Most won't be as good, and
most won't be as well documented. When programming in C, you use the
language for much of this, which is standardized and known to everybody who
knows the language (and possibly the compiler). So IMO C code tends to be
more "portable" between people than assembly code. Which might be a good
argument to help convince your boss -- after all, something bosses don't
like is creating dependencies on a single employee.

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