Accessing general I/O addresses

I apologize in advance if I didn't cross-post properly. I want to
write a .c and .h file controlling a DS1302 real-time clock using a
PIC18F2620 microcontroller. I want to keep my RTC code's pin usage
flexible, so I want to write an initialization routine that reads in
the pins that the whole program wants to use in main.c and have RTC.c
and RTC.h refer to the wanted pins. I am having trouble finding the
address of the pins, let's say RA1, RA2, ..., in the datasheet. I've
posted a similar thread in Microchip forums and got an example shown
in http://www.htsoft.com/forum/all/showflat.php/Cat/0/Number/31232/an/0/page/0#Post31232
. However, due to the typical response time I get on that forum, I'm
trying my luck in other places as well as for second opinion. Thank
you for any comments in advance.

On Wed, 26 Dec 2007 21:35:00 -0800, ssylee wrote:

> I apologize in advance if I didn't cross-post properly. 

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

> I want to write
> a .c and .h file controlling a DS1302 real-time clock using a PIC18F2620
> microcontroller. I want to keep my RTC code's pin usage flexible, so I
> want to write an initialization routine that reads in the pins that the
> whole program wants to use in main.c and have RTC.c and RTC.h refer to
> the wanted pins. I am having trouble finding the address of the pins,
> let's say RA1, RA2, ..., in the datasheet. I've posted a similar thread
> in Microchip forums and got an example shown in
> http://www.htsoft.com/forum/all/showflat.php/Cat/0/Number/31232/an/0/
page/0#Post31232
> . However, due to the typical response time I get on that forum, I'm
> trying my luck in other places as well as for second opinion. Thank you
> for any comments in advance.

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.

-- 
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

On Dec 26, 11:40 pm, Tim Wescott <t...@seemywebsite.com> wrote:
> On Wed, 26 Dec 2007 21:35:00 -0800, ssylee wrote:
> > I apologize in advance if I didn't cross-post properly.
>
> Apparently not -- I only see comp.arch.embedded mentioned in the
> headers.  Google is _not_ a good newsreader!
>
>
>
> > I want to write
> > a .c and .h file controlling a DS1302 real-time clock using a PIC18F2620
> > microcontroller. I want to keep my RTC code's pin usage flexible, so I
> > want to write an initialization routine that reads in the pins that the
> > whole program wants to use in main.c and have RTC.c and RTC.h refer to
> > the wanted pins. I am having trouble finding the address of the pins,
> > let's say RA1, RA2, ..., in the datasheet. I've posted a similar thread
> > in Microchip forums and got an example shown in
> >http://www.htsoft.com/forum/all/showflat.php/Cat/0/Number/31232/an/0/
> page/0#Post31232
> > . However, due to the typical response time I get on that forum, I'm
> > trying my luck in other places as well as for second opinion. Thank you
> > for any comments in advance.
>
> 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.
>
> --
> Tim Wescott
> Control systems and communications consultinghttp://www.wescottdesign.com
>
> Need to learn how to apply control theory in your embedded system?
> "Applied Control Theory for Embedded Systems" by Tim Wescott
> Elsevier/Newnes,http://www.wescottdesign.com/actfes/actfes.html


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?

ssylee wrote:
> On Dec 26, 11:40 pm, Tim Wescott <t...@seemywebsite.com> wrote:

>> 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.
>>
>> --
>> Tim Wescott

Please do not quote tag lines.

> 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?

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).

-- 
Thad

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim Wescott wrote:
> 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.
>

Not if you're using C18. Just use microchip's PORTAbits struct such as:

PORTAbits.RA2 = 1;
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFHdBVZkA9dCbrNdDMRAt5jAKCFHY1GYaEh7VtRHQkhUOIz9zGkxgCfRd8Q
Iph7jWAfanfcoP3yWdBPGYg=
=mHJJ
-----END PGP SIGNATURE-----

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 http://pastebin.com/m36c79878 .

On Dec 28, 2:34=A0am, ssylee <staniga...@gmail.com> wrote:
> 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 inhttp://pastebin.com/m36c79878.

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?

On Dec 28, 9:12=A0am, ssylee <staniga...@gmail.com> wrote:
> 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 http://www.mikroe.com/forum/viewtopic.php?t=12920
. Do you have any examples on how I can accomplish hardware.c to
assign the pins for other modules? Thanks.