Using special function registers, not the built in functions

[localboy]

For personal reasons I would like to call the special function registers directly. Rather than use the built in functions.

There is a program called Chipedit, where "registers" can be selected then "Make include file" this looks to produce the right information, but it conflicts with something else and I cannot get the project to compile.

Does somebody has a process to generate a H file that can be included, where the special function registers can be called by name? Currently I am using a 16F628.

Thank you.

[Heath]

Could you just use the "#byte" directive?

example:

[Ttelmah]

There is a complete list in topic 14755 (for the 18 chips). There was one in the forum for the 16 chips somewhere, but I can't seem to find it at the moment. The normal approach, is just to type #bit, or #byte definitions for the few registers normally needed.

Best Wishes

[PCM programmer]

The 16F87x header file done by Mark is in the Code Library:
http://www.ccsinfo.com/forum/viewtopic.php?t=20186

Here's the header file that Ttelmah mentioned, for the 18F series PICs.
http://www.ccsinfo.com/forum/viewtopic.php?t=14755&start=3

[Guest]

Thank you for your responses. It was quite a shock coming from 5 years of programming PICs in C which I was very happy with, to start a new job with this new compiler, it's like a new language.

Would you suggest following the built-in procedure programming method, or defining the SFRs, or does it not really matter? I want to set out from the start on the best method without hitting a pitfall.

I use PICs to an advanced level (time critical, sometimes in-line assembler, multi master i2c etc...)

[PCM programmer]

There are two types of programmers with CCS. One type doesn't trust
the CCS functions because they don't know what's in them, so they
write all their own functions. The other type is into rapid development
and uses the CCS functions. Testing will show if there is a bug, and then
a look at the .LST file will tell what it is. I'm in the 2nd group.

[RLScott]

Just to let you know, not everyone who talks to SFRs directly is in the Flat Earth Society. I also access SFR's directly and avoid most CCS library functions that deal with them. I do use bit_set() and bit_clear() because I know that they compile into single machine instructions. I find the Microchip documentation of their SFRs to be quite good, so I don't need some additional layer of interface to protect me from the "awful details" of the SFRs. In most cases, even if you use the CCS library interface, you need to understand those details anyway.

However, I think if I ever develop a USB application, I will go with the CCS interface. The complexity of USB is much greater than, say, a UART or a CCP module.

Robert Scott
Real-Time Specialties

[PCM programmer]

I didn't mean Flat Earth. I understand the other side.

[RLScott]

I know. Just kidding.

Robert Scott

[Ken Johnson]

I thought everybody fell off the other side (of the flat earth).

Hmmm . . .

Ken

[mkent]

It would appear that all the PCD folk did??? LOL

[ckielstra]

Just my two cents:

The CCS wrapper functions make it easy to change to another processor type if needs arise. Often the only thing you have to change is the processor include file. With the direct register approach you would have to make a lot of changes migrating for example from a PIC16 to PIC18.

On the other hand the direct register approach is easier to port to another compiler.

I think the CCS functions make for easier code reading than the direct register approach. To me this is the most important issue and that's why I use the CCS functions (but I keep an eye at the generated assembly to check efficiency).