Accessing general I/O addresses

Apparently not -- I only see comp.arch.embedded mentioned in the headers. Google is _not_ a good newsreader!

page/0#Post31232

RA0 - RA7 are pins on PORTA, RB0 - RB7 are pins on PORTB, etc. You can find the port addresses in the data sheet quickly enough with some searching.

You cannot address individual pins directly -- you have to read or write the whole port. If you want a means of 'virtually' writing to single pins you have to cook it up yourself, or find someone's method.

Generally the methods I've seen store a port address and offset to get to the pin, then have some means of guaranteeing reentrancy, at least on a system that supports multiple threads.

I also agree that Google is not a good newsgroup reader. So you're suggesting that I have to go something like: PORTA = PORTA or action;, where action is whatever action that I do only to the pin desired?

Please do not quote tag lines.

You can do that. You can also use a pointer to the appropriate type (see the header file declaration for PORTA) if you want to use that instead of a fixed port. Also, for outputs, the latch ports are better, when available (should be on PIC18F2620).

Thanks for all the responses. I found out that the port pointer as well as the bit numbers are unsigned short type from some mikroC sample code. Based on that and some brainstorming on the logic, I've written some sample code, although I haven't really tested it yet. They are in

Generally when using the PIC I find it better to put all of the hardware interfacing in a hardware.c file with hardware.h exposing functions. With the PIC it is incredibly inefficient to use pointers to pins so in your case one could write the DS1302 code so the it calls functions for: void DS1302_ClkHi(); void DS1302_ClkLo(); void DS1302_DatHi(); char DS1302_DatLo(); char DS1302_GetDat(); //or bit or bool etc

In your hardware.c these would be something like: void DS1302_DatHi() { LATA0 =3D 1; }

Equally (an possibly more efficiently) one could use a macro if all that is needed is a simple pin set / clear.

By having the macros / functions in the hardware.h or .c the code in your RTC module will be much more portable, even across processor types. Rocky

Thanks for the tip. For each of the setting and clearing function on the RTC pin, do I use the pin names directly instead of using pointers?

Yes. The PIC does NOT support pointers to bits as a native construct, so it is always very inefficient to de-reference a pointer to a bit. There have been some discussions on the HiTech site about using the port address and a bitmask, but this is fairly poor when setting up the call and typically takes about 20 machine cycles to execute under optimum conditions.

Note that the PIN NAMES will not appear in your RTC.C file or its header, but you will need the prototypes for the function in either the C file or the header. Putting them in the header makes more sense, because you can include RTC.h in HARDWARE.C and MAIN.C, this will ensure that the compiler will moan about inconsistencies in declarations. The goal (to make the RTC.C portable) is to ensure that it does not need to include any project files. Rocky

I'm using mikroC to program the code. When I used the pointer method, I've noticed that there is some funny things going on as described in the second thread of

Sorry about my last message. Appears that Rocky did it on his first email to this thread on the newsgroup already.