Just a simple question

[sambyte]

I finally decided to use CCS C. This is mainly because of this comparison.
http://www.ccsinfo.com/content.php?page=newcompilercomp

I don't know if this is a fair comparison since it is coming from CCS itself.

I got myself a copy and have a go on it. I got a question...

example...
#byte PORTB = 6 //Just an example, check the <--- WHY?
#define ALL_OUT 0 //DATA sheet for the correct
#define ALL_IN 0xff //address for your chip
main() {
int i;
set_tris_b(ALL_OUT);
...

Q. Why PORTA (or PORTB etc) is not predefined in the device header .h file? Why do we have to refer to the device datasheet for the correct address every time, when it can be set as standard?

Thanks
Sam

[andyfraser]

Is it just me, but when I buy a new compiler, the first thing I do is read the manual to find out what functions are available in the libraries.

If you read the manual, especially the Discrete I/O section you will see numerous functions for dealing with ports without having to know their addresses.

Andy

[FvM]

The CCS concept may be unexpected at first sight, cause other compilers typically are accessing SFRs to perform basic I/O. In the example, no PORTB SFR definition is needed when all IO is done by CCS built-in functions. They form a kind of hardware-abstraction layer. Direct SFR access is an additional option, that may be meaningful in special cases.

[sambyte]

The code fragment was actually taken from the CCS C manual on page 307 (actual page, 319)
...
#byte PORTB = 6 //Just an example, check the
#define ALL_OUT 0 //DATA sheet for the correct
#define ALL_IN 0xff //address for your chip
main() {
int i;
set_tris_b(ALL_OUT);
PORTB = 0;// Set all pins low
for(i=0;i<=127;++i) // Quickly count from 0 to 127
PORTB = i; // on the I/O port pin
set_tris_b(ALL_IN);
i = PORTB; // i now contains the portb value.
}
...

As a newbie to CCS C, example is the first part I'd look first for a quick start. To me, CCS should have only used built-in functions to avoid confusion in their examples. The code above should have read like this...

main() {
int i;
set_tris_b(ALL_OUT);
output_b(0);// Set all pins low
for(i=0;i<=127;++i) // Quickly count from 0 to 127
output_b(i); // on the I/O port pin
set_tris_b(ALL_IN);
i = input_b(); // i now contains the portb value.
}

[FvM]

A special point with built-in functions is the automatic control of TRISx registers in default mode. It's generally convenient but may be unwanted in some cases. Direct access to SFR is one means to handle these cases.

[SherpaDoug]

The header files for all the chips I use have the I/O pins defined. I very rarely use a whole port for any one function so I hardly ever have to define a port.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[ckielstra]

[RLScott]

[sambyte]

Hi Robert,
I agree with you. That's exactly what I'm going to do. For now, I just use #asm to access them directly. Like you've said, nothing so complicated about the PIC I/O...

I am just so used with MChip assembly SFR names...HiTECH C has no problem with them.

[FvM]

If you use C statements for direct SFR accesses instead of assembler, the generated code is exactly the same, with writing less text. You need to define the SFRs once, of course.

[sambyte]

BTW Robert, this is just an idea. Do you mind sharing with me those header files? It'll save a lot of times. I was thinking of adding portion of HTC device header files to existing CCS device header files, with a bit of modification, of course.

Thanks
Sam

[Ttelmah]

How about using the forum search?.
There are two 'standard' includes posted here. One for 16 chips, and one for 18 chips. Use "register name defines", and set to search for 'all terms'. You will find PCM programmer has done links to the normally used defines.
Now, in general:
I'd avoid asm. In the early CCS days, it was necessary, but now, there is little you can do with assembler, that you can't do just as well with the compiler.
For 90% of applications, the CCS default approach works well. Look for example at the recent posting by PCM, on how to access half a port for read, and half for write. works just as well as an assembler solution.
Using the standard defines then allows those 'other' operations, stepping beyond those easy to do with the CCS functions. The latter compilers, have an ability to generate such a define file for you, but it would have been simpler, and tidier, for CCS just to include default files, with the compiler. A case of an 'overcomplex' solution really....

Best Wishes

[FvM]

BTW, did you notice the PCW IDE's Device Editor tool and it's option, to generate SFR include files?

[sambyte]

Thanks guys..I'll try that...

[sambyte]

Thanks FvM. I've just found out about how to create the file. I'm beginning to like the CCS C more...

Thanks again...