Thanks for the reply. I guess there is no point extend this old
version. Right now we do not need to use PICC since we are
switching to other MCUs (Silabs 8051 and possibly AVR) due 
to the reason of cost and small packaging ( Silabs 8051: for
its small packaging and fast ADC, AVR for its smaller packaging
and lower cost) for some new projects. For the 8051, the 
Keil C is great. When I was using PICC, I actually bought 
the support option.

I guess portability is not that important for small 
program like this. Develop timing is not an issue
for the software as well since the difficult part is 
not in the software. Code timing is critical though
since we are dealing detecting pulse of 1us to 4us
using 1MIPS or 2MIPS MCU. The response time requirement
is  500us or 1ms. In order to achieve the response 
time and better EMC performance, the loop need to 
be quite short. For asynchronous detection, we even
have to count instructions to ensure the timing.

Xiaofan

-----Original Message-----
From: Gerhard Fiedler [mailto:lists@connectionbrazil.com]
Sent: Thursday, May 19, 2005 6:56 PM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] More chip support for old version of Hitech PICC

...

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.

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