portA problem

[keymuu]

Hi!

I do not know what is going on!

PortB works just fine,
but
a) code does NOT toggle the test (test1, test2) pins
b) code does toggle the test pins

test1 = portA.1 and test2 = portA.2

'a)
loop:
pause 5
toggle test1
toggle test2

if portB = 0 then
portB = $ff
'// toggle test1
else
portB = 0
'// toggle test2
endif
goto loop:

'b)
loop:
pause 5
'// toggle test1
'// toggle test2

if portB = 0 then
portB = $ff
toggle test1
else
portB = 0
toggle test2
endif
goto loop:


Could somebody please try to explain how this is possible?
I'm puzzled, how is this possible?
Using picbasicpro 2.50

regards
key

[skimask]

I do not know what is going on!

http://www.picbasic.co.uk/forum/showthread.php?t=561
And it would REALLY help to know which PIC you are using...

[keymuu]

http://www.picbasic.co.uk/forum/showthread.php?t=561
And it would REALLY help to know which PIC you are using...

Thanks for the reply...

The prosessor is 18F4550

and before the the code there is:
trisA = 0
trisB = 0

So, actually i do not know if it is a portA problem or a TOGGLE failure?

Regards
Key

[skimask]

Re-read that linked post above...read it good, read it carefully...then re-read the 3rd paragraph...then re-read it again...

And if you're not sure if it's a TOGGLE failure or not, then don't use TOGGLE...
Surely you can come up with a different method of changing the state of a bit from one to the other and back again...

[keymuu]

Re-read that linked post above...read it good, read it carefully...then re-read the 3rd paragraph...then re-read it again...

And if you're not sure if it's a TOGGLE failure or not, then don't use TOGGLE...
Surely you can come up with a different method of changing the state of a bit from one to the other and back again...

...when I add ADCON1 = 7 to the code after trisA and trisB it does not change the outcome. Here is the code:

DEFINE OSC 48
'
test1 var PORTA.1
test2 var PORTA.2

trisA = 0
trisB = 0
ADCON1 = 7

ProgramStart:

pause 5
toggle test1 '// comment -- THIS DOES NOT WORK!
toggle test2 '// these two lines AND

if portB = 0 then
portB = $ff
'//toggle test1 '// uncomment -- THIS WORKS
else
portB = 0
'//toggle test2 '// uncomment
endif

goto ProgramStart

Depending where toggle is it either work or does not work. If you have the possibility to test this, please let me know if works on your pic.

Thank you in advance

Regards
Key

[skimask]

...when I add ADCON1 = 7 to the code after trisA and trisB

1/2 way there...keep reading and re-reading...
And again...read the PBP manual about TOGGLE. Not that TOGGLE is a bad command, but there are other ways to flip a bit...

Anybody got the link to the R-M-W 'writeup' thread here?
The PIC is running 48Mhz here (apparently). I see possible R-M-W issues...

Besides that...look at your code...There are logical flow flaws (is that the correct way to put that?) in it...
How do you know TOGGLE isn't actually working the way it should?
Can you see that fast? I can't...

[Pic_User]

Anybody got the link to the R-M-W 'writeup' thread here?
The PIC is running 48Mhz here (apparently). I see possible R-M-W issues...

http://www.picbasic.co.uk/forum/showthread.php?p=34331

[skimask]

http://www.picbasic.co.uk/forum/showthread.php?p=34331

That's one of them, but somewhere out there is a much longer, more involved explanation of the R-M-W issue. Someday I'll come across it again...

[Pic_User]

That's one of them, but somewhere out there is a much longer, more involved explanation of the R-M-W issue. Someday I'll come across it again...

http://www.picbasic.co.uk/forum/showthread.php?p=8886

[skimask]

http://www.picbasic.co.uk/forum/showthread.php?p=8886

Man, you're finding more than I'm finding.
Obviously that's a good one too, but the one I'm thinking of is a single-thread in-and-of itself, all about R-M-W...
Then again, I might be wrong. Maybe that thread was on Microchip's forums. Things like that tend to run together after awhile ya know...

[keymuu]

1/2 way there...keep reading and re-reading...
And again...read the PBP manual about TOGGLE. Not that TOGGLE is a bad command, but there are other ways to flip a bit...

Anybody got the link to the R-M-W 'writeup' thread here?
The PIC is running 48Mhz here (apparently). I see possible R-M-W issues...

Besides that...look at your code...There are logical flow flaws (is that the correct way to put that?) in it...
How do you know TOGGLE isn't actually working the way it should?
Can you see that fast? I can't...

Thank you Skimask, you are right, I'm 1/2 way there and in fact even slightly further... I did read a little bit further also...

Found in the pic18F4550 data sheet that LATA is about the same as PORTA, so I changed PORTA.1 to LATA.1 and that solved the issue. However I do not understand why PORTA does not work and LATA works in this "example". Could somebody try to explain that shortly, I am sure it will help ohter people also. Knowing that LATx is included in the 18F pics, but still does not grasp how it (change toggle place) works like it does?
How could this be an r-m-w matter?

Regards
Key

[skimask]

Read-Modify-Write, it's briefly explained in the PBP manual somewhere...and it's also explained in those links above a bit...

[Pic_User]

Read-Modify-Write, it's briefly explained in the PBP manual somewhere...and it's also explained in those links above a bit...

This one is pretty good explaining what it is.
Outside the forum:http://www.piclist.com/techref/readmodwrite.htm

[Bruce]

However I do not understand why PORTA does not work and LATA works in this "example". Could somebody try to explain that shortly

Setting or clearing port bits directly reads the whole port, alters the bit in question,
the writes the whole 8-bit value back to the port.

Example (for 18F parts);

HIGH PORTB.0
HIGH PORTB.1
HIGH PORTB.2, etc

And PBP will generate assembler code something like;

bsf PORTB,0 ; reads the whole port, sets RB0, writes the 8-bit value back to the port
bcf TRISB,0 ; make RB0 an output (now RB0 begins to go high)
bsf PORTB,1 ; reads whole port again (note that RB0 may not be high yet because this happens fast)
bcf TRISB,1
bsf PORTB,2
bcf TRISB,2, etc.

What happens is when RB0 goes high, then it's made an output, it may take a while
before the actual voltage output on RB0 goes high - due to external capacitance.

If the voltage output on RB0 is below the PIC logic 1 input threhold, when the port was
read on the 2nd bsf instruction, it gets read back in as zero, and a logic 0 gets output
back on RB0. It read the port, modified only RB1, and wrote the new value back to the
port. I.E. That's R-M-W.

When you use the LAT registers it doesn't cause the whole port to be read back, modified,
then written again.

The faster the core is running, and the more external capicitance there is, the more you will
have problems with read-modify-write.

Microchip added the LAT registers on 18F series primarily to eliminate this problem.

[BrianT]

You are setting ADCON1 = 7. This sets PortA to analog.

I would be setting ADCON1 = %00001111 in order to make PortA all digital.

This has changed froom the PIC16F877 series.

HTH
Brian

[keymuu]

....... The faster the core is running, and the more external capacitance there is, the more you will have problems with read-modify-write. ....

Thank you Skimask, Bruce, Pic_user and all other for your support.

The more one comes familiar with PIC, there are more and more that is not advertised by Microchip in the first place, mais c'est la vie....

Before this problem, I was not aware of such a thing as r-m-w. Now I think I understand what the phenomena is. In a matter of fact, I was kind of lucky when I run into this TOGGLE problem.

Thank you once again for your kind help....

Regards
Key

[skimask]

Before this problem, I was not aware of such a thing as r-m-w. Now I think I understand what the phenomena is. In a matter of fact, I was kind of lucky when I run into this TOGGLE problem.

Besides heat and actual power transmission issues, that r-m-w issue is one of the big reasons why we don't have 100GHz Intel Core2 processors running with a 25GHz Front-Side-Bus...