Accessing ports ( Melanie )

[anj]

As part of figuring out logarithms, i came across some code i didnt understand, and chasing it back, found it came from basic stamp usage. This allowed me to address a bit "relative" to another bit, using an integer offset index
ie

test var word
fred var test.bit0

then fred(3) is equivalent to test.bit3

hence i could directly address bits within a for--next loop

I tried experimenting with this using ports instead and it works
ie 16F876
-------------
xport var porta.0 'define base point
k VAR byte 'loop var

ADCON1 = 7
trisa = %00000000
trisb = %00000000
trisc = %00000000
portA = 0
portB = 0
portC = 0
loop:
portA = 0
pause 1000
for k = 0 to 7 'this accesses port a
xport(k) = 1 ' set pin high
pause 1000
next k

portB = 0
pause 1000
for k = 8 to 15 'this accesses port b
xport(k) = 1
pause 1000
next k

portC = 0
pause 1000
for k = 16 to 23
xport(k) = 1
pause 1000
next k

goto loop
end
-------------------------
you will note you appear to be able to access ALL ports, not just those defined by the PINS directive.
Using this allows me to access ports within a subroutine using a preset integer to define the port i want.
It compiles and seems to run OK, but has no syntax description anywhere ( except half a page in the basic stamp instructions booklet ).
Based on the fact it works, but is undocumented for Pics, is there a reason it shouldnt be used???

Andrew

[Melanie]

You must have missed PBP Manual section 4.11...

...and I also refer you to Dennis Saputelli's treatise on 07 June 2002 thread "PICBASIC-L How to address any port pin was - Tricky assembler question". Search for it here...

http://list.picbasic.com/cgi-bin/board-search.cgi

Melanie

[anj]

Gday Melanie
I have read section 4.11 forwards and backwards, many times, and it doesnt cover what i posted. ( My booklet has a print date of 8/02 )

According to sect 4.11, i can only use pins of 0-15 to address ports. For a 28 pin device these cover ports C and D
In my example, i started by addressing port A.
Also, in my case, the corresponding numbers used are not fixed to 0-15, but depend on what offset you start with. In my example i was up to 23 and still going ( starting from PortA.0 )

Also there is no discussion in the book on the syntax used ie
XPort(3) where the (3) is the relative offset ie

If i go
XPort = PortB.0 then XPort(4) equates to PortB.4

if i then redefine the start point ie
XPort = PortB.2 now XPort(2) equates to PortB.4

In both cases i access PortB.4 but use a different index.
I can find no discussion of this behaviour in the manual supplied with my PBP Pro 2.43, only in the basic stanmp manual. ( And not real clear there either )
I will still read yr referenced link, but was just enquiring into whether or not this method of addressing ports was ok with a std PIC.
Andrew

[Melanie]

There is no problem with that usage.

If you find the thread I indicated, you will find it details pretty much what you're doing.

I agree the manual is somewhat spartan on many things and isn't updated as often as it could be. Always check and download the latest revision from the MeLabs website....

www.melabs.com

[anj]

Gday Melanie
Thks for the link, lots more nice info to digest there.
One further question though.
In all discussions on that list, i noted they were addressing the accessing of pins within a single port.
With what i have done, i found you can access portC using portA as your start point, ( which makes it suitable for my subroutine usage ).
I understand arrays and referential addressing so can figure out what is happening, however what i would like to know is what implicit arrays are available and/or how are they determined.
Ie there seems to be a ports array that has ( at least ) portA for 8 then portB for 8 then port C for 8 etc.
Is it based on sequential internal memory addresses or some other internal PicBasic definitions?

Re the manual, i tried the online version first, but it appears to be older than the paper copy i got with my software?
( Based on the print date on page 1 ), or do they update individual pages as they go. I couldnt detect any page renumbering so assume no.
Andrew