Searching \ for '[PIC] More chip support for old version of Hitech' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=port
Search entire site for: 'More chip support for old version of Hitech'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] More chip support for old version of Hitech '
2005\05\19@023110 by Chen Xiao Fan

face
flavicon
face
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 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.

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 bought the C
compiler in year 2000 when I was under a different group.
I have used it in three projects before and I think it
is a very good tool to have. Debugging a program written
in assembly is really much more difficult than that written
in C.

Xiaofan


2005\05\19@032657 by Jan-Erik Soderholm

face picon face
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 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.
>
> 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 bought the C
> compiler in year 2000 when I was under a different group.
> I have used it in three projects before and I think it
> is a very good tool to have. Debugging a program written
> in assembly is really much more difficult than that written
> in C.

Hi.
With due respect, this is your boss's decissions. If you
don't like it, talk to *him* about it. I don't think one
should rant about once boss in a public forum.

Jan-Erik.



2005\05\19@035056 by Chen Xiao Fan

face
flavicon
face
Sorry again but I think I am not ranting about his decision.
It is only because that I have not demonstrating enough
the advantages of PICC compared to assembly.

Sorry if you feel disturbed by the email.

Xiaofan

-----Original Message-----
From: Jan-Erik Soderholm [spam_OUTjan-erik.soderholmTakeThisOuTspamtelia.com]
Sent: Thursday, May 19, 2005 3:27 PM
To: .....piclistKILLspamspam@spam@mit.edu
Subject: RE: [PIC] More chip support for old version of Hitech PICC

Hi.
With due respect, this is your boss's decissions. If you
don't like it, talk to *him* about it. I don't think one
should rant about once boss in a public forum.

Jan-Erik.


2005\05\19@041702 by Jan-Erik Soderholm

face picon face
Chen Xiao Fan wrote :

> Sorry again but I think I am not ranting about his decision.
> It is only because that I have not demonstrating enough
> the advantages of PICC compared to assembly.
>
> Sorry if you feel disturbed by the email.

Oh, maybe I was a bit unclear...
*I* am not particulary disturbed, I was just afraid that
your boss might be... ;-)

As a side not, about a year ago on another mail list, some
frustrated guy made a statement on a public list about that
the current decissions made by his employer. A couple
of hours later there was a second post were he write a long
message about how sorry he was about the first post.

Still, I *think* he lost his job becuse of that...

Now, your post was *nothing* compared to that one... :-)

Take care,
Jan-Erik



2005\05\19@065600 by Gerhard Fiedler

picon face
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

2005\05\24@230251 by Chen Xiao Fan

face
flavicon
face
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 removed}

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...