PIC's ports individual bits manipulation - how to?

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

[Dave]

flotulopex,The statement: "If I want to make the display brighter, I slow down the loop with the "Scan" pause making the digit to be powered longer." makes no sense if the drive circuitry is designed correctly and the software is truly multiplexing the digit drivers at 100%/number of displays. The only thing that lowering the display frequency will do is at the lower end of about 50 to 40 hz the viewer will start to see the telltale multiplexing action. If at 60 hz. or more the display brightness should not change as far as your eye is concerned. If your display gets brighter as you increase the frequency then your circuitry is not shutting off the digits fast enough. If it gets dimmer as you increase the frequency then your circuitry is not turning on fast enough. This is assuming you have the dutycycle set at 100%/number of displays with no delays. I have designed an automotive gage set using a 16f88 that runs a 4 digit + decimal point multiplexed display that has a 16 step dimming function thru an A/D channel tied to the dashboard dimmer. I chose 63 hz as the lowest frequency to eliminate the STROBING effect during driving.

Dave Purola,
N8NTA

[flotulopex]

Paul,

The four higher bits of PORTA are Inputs and when I checked out the levels on my PIC with my logic probe (set to TTL), using ~DCD would make the ports change status. BUT I have to try with another my PIC since one of my digits doesn't light-up normally making me think about a "little" problem... Should get a new one tomorrow.

About dimming, modifying the scan (refresh) rate of the digits is effectively not a good solution. It's working but, as said in another post, the strobe effect is also accentuated. I have modified my circuit and added transistors in each Common Anode connection. Those four transistors are then levelled by one additional transistor witch is LDR driven. At least, it works fine.

Dave,

My approach is maybe not a good one and any example/critic/suggestion is welcome. It's my first project involving a LED display, I didn't even know what multiplexing was before, so got still to learn more... My english is poor, what is a "gage set"?