![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
Ttelmah
Joined: 11 Mar 2010 Posts: 19384
|
|
Posted: Tue Dec 20, 2011 2:44 am |
|
|
aaronik19 wrote: | Ttelmah, thanks for your reply. But acccording to my knowledge, since you are OR gate the val an Opval, the output will be always 11111111 most of the time. I do not know why you used that working. Can you please explain more if you can?
Thanks |
Be careful of asmboy's suggestion. What happens here is that the port is changed to be an _input_, the value on it is read, then the low two bits of this are combined with the bits you want to send, and the port then changed to an output, and the whole result sent.
Unfortunately also, if the output loads are high a port pin that has had a '1' written to it, may not always read as a '1' back, and in which case the bit gets lost.
It _may_ work, but depends on the loads on the pins, capacitances, etc. etc., but may also cause problems....
On my code, OR does not work the way you think. You may be confusing the effect of a logical OR '||' from a bitwise OR '|'.
Imagine you have:
0b01010101 sent out on the port using 'output_latched', and therefore stored in 'opval'. Then you send 0b10101010 using 'outputb_masked'.
The incoming 10101010 gets changed to 10101000 by the '&'.
Then the opval value gets changed to 0b00000001 by it's '&'.
10101000
00000001
or them together
10101001
OR gives a '1' wherever there is a '1' in either source byte, and nowhere else. So the top six bits of your value get output, combined with the low two bits of what has previously been sent.
On the PIC 18, the value previously sent, is available in the 'LATB' register, so asmboy's suggestion, can be made to work perfectly (without any glitches), using:
Code: |
#byte LATB=getenv("SFR:LATB")
// per your example -to preserve the low order 2 bits :
// NEW bits is expected to contain the hi order 6 bits you want
// and we mask out the low order bits in case they were not 0
void changebits ( byte newbits ){
output_b( (LATB&3) | (newbits&0b11111100) );
}
// any easier to understand ??
|
This uses the hardware latch so that the byte is output without having to change the port direction for a few cycles, and gets rid of the potential glitch, and any potential problems if the port loading is high. However doesn't work on the PIC16 chips.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Tue Dec 20, 2011 6:42 am |
|
|
Quote: |
port is changed to be an _input_, the value on
|
I think that is NOT for sure true, you see -
IF you use fast_IO() and declare portb tris as all 0
as i ALWAYS DO for output - i simply don't want the compiler involved in
port I/O direction - as i don't trust compiler generated TRIS in a program i am going to sell - i am willing and even eager to be in charge of I/o direction ;-))
Anyway - with fast_io(b) - you get this on an 18F part :
Code: |
.................... void changebits ( byte newbits ){
.................... output_b( (input_b()&3) | (newbits&0b11111100) );
0004: MOVF F81,W
0006: ANDLW 03
0008: MOVWF 0E
000A: MOVF 0C,W
000C: ANDLW FC
000E: IORWF 0E,W
0010: MOVWF F8A
.................... }
|
but if you are STILL anxious - you can always ( memory permitting)
maintain a phantom portb var byte --
and operate on IT - then output the phantom variable. |
|
![](templates/subSilver/images/spacer.gif) |
aaronik19
Joined: 25 Apr 2011 Posts: 297
|
|
Posted: Wed Dec 21, 2011 7:28 am |
|
|
thanks to all. Both methods worked fine great help thanks guy and best wishes |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|