PIC's ports individual bits manipulation - how to?

[SteveB]

I might have misread the original intent, but you did ask:

How is it possible to handle ONLY those four bits wihtout modifying the other (MSB) four bits?

"Under the hood" PBP will either write to the port as a Byte, or set/clear individual bits. This means you have 2 basic approaches:
1) Dave's approach, which deals with the port as a byte. This uses some bit manipulation to preserve the status of the MSBs.
2) And what I was trying to get at, but was not very clear, and that is to set each bit individually.

Just so I've got it straight, as your FOR...NEXT loop counts from 0 to 3 you would like to see a pattern on PORTAs LSB like: 0001, 0010, 0100, 1000. Is this correct?

If this is the case, then this should work:

Digit VAR Byte
DCD_temp VAR Byte

FOR Digit = 0 TO 3
     DCD_temp = DCD Digit 
     PORTA.0 = DCD_temp.0
     PORTA.1 = DCD_temp.1
     PORTA.2 = DCD_temp.2
     PORTA.3 = DCD_temp.3
NEXT Digit

SteveB

[nish]

hi all
i m new to pic16f877a.i need a help regarding timers in pic 16f877a.
in the timer1,T1CON register what is the purpose of using T1OSCEN bit and the T1SYNC bit.if we are using T1SYNC bit,with what signal it will get synchronised and the purpose of synchronization.expecting the reply.

thanx n advance

nish

[flotulopex]

I was already sleeping when I wrote this big mistake.

Thanks SteveB; indexing the ports, like "PORTA.0[Var]", works well. But you're right, it is about to adress the four LSBs.

[paul borgmeier]

If the upper four bytes are guaranteed to always be inputs then you do not need to worry about how “they” are affected by your modifications of the lower four output bytes. Your

PORTA = ~DCD digit

should work fine (all reads are of the actual values of the pins irrespective of any previous written values; all writes are read-modify-write operations).

If the upper four bits could be outputs then you do need to worry and you can use one of the suggested fixes. If speed is an issue as you suggest (but I do not see why it would be, especially with a pause in the main loop), then you could 1) switch to real interrupts (see Darrel's methods) and 2) unroll your for-next loop. A possible version is shown below for the latter.

' PORTA = XXXX1111

value_d = value dig 3    'Select the 3 Digit Value
lookup value_d, [$7E,$0C,$B6,$9E,$CC,$DA,$FA,$0E,$FE,$DE], Segments
PORTA = PORTA - 8 ' PORTA = XXXX0111
PORTB = Segments
pause Scan

MAIN:
value_d = value dig 0    'Select the 0 Digit Value
lookup value_d, [$7E,$0C,$B6,$9E,$CC,$DA,$FA,$0E,$FE,$DE], Segments
PORTA = PORTA +7 ' PORTA = XXXX1110
PORTB = Segments
pause Scan

value_d = value dig 1    'Select the 1 Digit Value
lookup value_d, [$7E,$0C,$B6,$9E,$CC,$DA,$FA,$0E,$FE,$DE], Segments
PORTA = PORTA - 1  ' PORTA = XXXX1101
PORTB = Segments
pause Scan

value_d = value dig 2    'Select the 2 Digit Value
lookup value_d, [$7E,$0C,$B6,$9E,$CC,$DA,$FA,$0E,$FE,$DE], Segments
PORTA = PORTA - 2  ' PORTA = XXXX1011
PORTB = Segments
pause Scan

value_d = value dig 3    'Select the 3 Digit Value
lookup value_d, [$7E,$0C,$B6,$9E,$CC,$DA,$FA,$0E,$FE,$DE], Segments
PORTA = PORTA - 4 ' PORTA = XXXX0111
PORTB = Segments
pause Scan

Goto MAIN

and for clarity – any change to a single pin in PBP actually is writing to the entire port. (i.e, if you do this PORTA.0=1 then the microprocessor does this PORTA = uuuuuuu1 where the u is the value of the port pin at the time of the execution of the command)

[flotulopex]

Thanks a lot, Paul.

First, the "need for speed" is due to the display refresh rate. The higher the speed is, the less time each digit is going to be light on and so, it will dimm naturally.

If I want to make the display brighter, I slow down the loop with the "Scan" pause making the digit to be powered longer.

I could do it another way with a slower clock rate: dimm the LEDs with transistors (this is what I actually did).

Another way would also be to modulate the voltage for each digit's pin at the µc. But I'm not so far yet

PORTA = ~DCD Digit will set 1 bit to a state and all others to the other state; this is an unwanted effect in my case.

I didn't think about your solution; it's always amazing to see how many different ways there are to solve a problem. I will try it anyway since I want to know witch is more memory space effective.

[SteveB]

and for clarity – any change to a single pin in PBP actually is writing to the entire port. (i.e, if you do this PORTA.0=1 then the microprocessor does this PORTA = uuuuuuu1 where the u is the value of the port pin at the time of the execution of the command)

Paul, looking at the ASM, bitwise manipulation of the port is handled by BSF/BCF commands. For example.

PORTA.3 = 1 results in: BSF PORTA, 003h
PORTA.2 = 0 results in: BCF PORTA, 002h
and
PORTA.1 = DCD_temp.1 results in:

     btfsc   _DCD_temp, 001h
     bsf     PORTA,  001h
     btfss   _DCD_temp, 001h
     bcf     PORTA,  001h

Are you saying that even these bitwise commands, when actually implemented by the PIC, will write to the whole port?

Steve

[paul borgmeier]

Are you saying that even these bitwise commands, when actually implemented by the PIC, will write to the whole port?

Yes - the entire port is updated via port R-M-W when using bcf or bsf.

[paul borgmeier]

First, the "need for speed" is due to the display refresh rate. The higher the speed is, the less time each digit is going to be light on and so, it will dimm naturally.

Have you demonstrated this? Your loop has each digit on for about ¼ the time. Frequency should be irrelevant because with higher frequceny, it will be lit less but will be lit more often. Would not you need to turn the digit off before the pause (or between pauses) to affect the dimness? I will have to think about it more.

PORTA = ~DCD Digit will set 1 bit to a state and all others to the other state; this is an unwanted effect in my case.

I thought you wanted
MAIN:
PORTA = XXXX1110
PORTA = XXXX1101
PORTA = XXXX1011
PORTA = XXXX0111
GOTO MAIN

where the upper nibble were inputs? If they are inputs, they will not be affected by your PORTA=~DCD command because, well, they are inputs.

I didn't think about your solution; it's always amazing to see how many different ways there are to solve a problem. I will try it anyway since I want to know witch is more memory space effective.

Earlier you mentioned speed is an issue, now you mention code space – the unrolled version will not be very code efficient but it should by slightly faster than the looped depending on How PBP converts them to ASM. If one were to write it in ASM, I know the unrolled method would be faster (at least I know I could write an ASM version faster than a looped. Also the PORTA add commands could be done in two instructions versus more as with the >>, & and | approach). However, I still do not know if your upper nibble of PORTA will always be inputs?