Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Bit Conversion Optimisation?

Status
Not open for further replies.

Mike - K8LH

Well-Known Member
Hi guys,

I've got code to load seven 8-bit shift registers in parallel in about 4.8-usecs and that's workin' fine but I could use help speeding up the algorithm I use later in my ISR to convert the 'column' organized display data to the parallel data required to load the shift registers.

Some background. I use a 9-pin bus of sorts using all of Port B and a PWM pin to drive up to 56 multiplexed 7-segment displays. I use the PWM signal as an inverse Brightness control and a 1% minimum PWM duty cycle to provide a 10-usec 'window' at the beginning of the ISR where I can borrow the Port B column driver lines to load the seven shift registers. The <DAT> pin on each SR is connected to one unique Port B pin (RB1 through RB7) and the <CLK> pin on each SR is connected to RB0.

Loading the SR's at the beginning of the ISR is no problem. Converting the 'column' organized display data to parallel SR data for the next interrupt cycle currently takes about 153 cycles or approximately 30.6-usecs and this is the code I'd like to speed up.

TIA for any suggestions. Regards, Mike
Code:
;
;  build scan data array for next display interrupt cycle.
;  all the b7 bits in one byte, b6 bits in the next byte,
;  and so on.  Bit 0 <CLK> is preset to '0' in each byte.
;
;  153 cycles, 30.6-usecs
;
        lfsr    0,SBuff         ; scan buffer address
V1      rlcf    WBuff+0,f       ;
        rlcf    INDF0,f         ;
        rlcf    WBuff+1,f       ;
        rlcf    INDF0,f         ;
        rlcf    WBuff+2,f       ;
        rlcf    INDF0,f         ;
        rlcf    WBuff+3,f       ;
        rlcf    INDF0,f         ;
        rlcf    WBuff+4,f       ;
        rlcf    INDF0,f         ;
        rlcf    WBuff+5,f       ;
        rlcf    INDF0,f         ;
        rlcf    WBuff+6,f       ;
        rlcf    INDF0,f         ;
        bcf     STATUS,C        ;
        rlcf    POSTINC0,f      ; set b0 <CLK> bit to '0'
        btfss   FSR0L,3         ; all 8 SBuff bytes setup?
        bra     V1              ; no, branch
 

Attachments

  • SR schematic.PNG
    SR schematic.PNG
    35.9 KB · Views: 144
  • SR conv graphic.PNG
    SR conv graphic.PNG
    31.3 KB · Views: 144
You could save 7 cycles by clearing INDF0 before the loop and deleting the bcf STATUS,C - not much use really.

Alternatively, you could swap the hardware so that each SR was driving one segment. So, SR1 would drive the A segments SR2 the B etc. therefore eliminating the row/column shift completely. I do however think the circuit board would end up horrendous.

Mike.
 
Pommie said:
You could save 7 cycles by clearing INDF0 before the loop and deleting the bcf STATUS,C - not much use really.
I'm not sure I understand Mike but you are forcing me to look at the way I'm shifting data. Perhaps I can change that to eliminate that pesky "CLRC" instruction and final shift operation. Thanks.
Alternatively, you could swap the hardware so that each SR was driving one segment. So, SR1 would drive the A segments SR2 the B etc. therefore eliminating the row/column shift completely. I do however think the circuit board would end up horrendous.
I'm pretty happy with the hardware design, thanks (grin).

I was hoping some Guru like yourself would have some magic bit manipulation technique I've never thought of.

Hey, thanks for taking time to look and for the help.

Regards, Mike
 
When problems like this seem insurmountable, a different algorithm can sometimes provide an answer.

One possible solution could be that you could keep a pre shifted "bitmap" of the segments. This would make your multiplexing ISR very fast and simple but whenever you update a digit you would have to write 7 bits to your bitmap. As (normally) digits are updated infrequently this should end up usable. You would of course eat up 56 bytes of ram but as you are using a 18 series PIC this shouldn't be too much of a problem.

Mike.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top