Trouble with SHIFTOUT and LSBFirst not working...

OLDmarty

Senior Member
Hi All,

I'm currently using Picaxe Editor 6.1.0.0 and playing with a Maxim 7219 LED Driver chip and EVERYTHING is working quite good so far...

However, regarding the SHIFTOUT command, i can't seem to get the "LSBFirst_L" option to work.
Using "MSBFirst_L" works fine and i see the appropriate LED patterns light up as i expect.
When i change to LSBFirst_L, no LEDs come on at all.

Is this a bug in the new editor??????


I'd prefer to send my data LSB first to make my code easier to read in future if i can see the LSB nibble is sent before the MSB nibble when sent to the LEDs.
At the moment, i am sending my code "backwards" to make it appear correctly on the LEDs.

Yes, I have confirmed all my wiring order of the row/column bits are all in correct order. ;-)

NOTE: i'm not using the hardware spi pins etc, just some basic Port.C pins.

Here's my code setup, and this works until i try to use the LSBFirst_L option ;-(

Code:
#PICAXE 40X2
#NO_DATA
#NO_TABLE
;
;
; Assign the Control signals from PICAXE to MAX7219
SYMBOL Clock_pin = C.7
SYMBOL Load_pin = C.6
SYMBOL Data_pin = C.5
;
;
; Setup all the port bits to a clean state...
dirsA        = $FF                ;11111111, set PortA to all OUTPUTS
dirsB        = $FF                ;11111111, set PortB to all OUTPUTS
dirsC        = $FF                ;11111111, set PortC to all OUTPUTS
dirsD        = $FF                ;11111111, set PortD to all OUTPUTS
outpinsA    = $00                ;00000000, clear PortA outputs to all 0's
outpinsB    = $00                ;00000000, clear PortB outputs to all 0's
outpinsC    = $00                ;00000000, clear PortC outputs to all 0's
outpinsD    = $00                ;00000000, clear PortD outputs to all 0's
;
;======================================
; All the 7219 config codes are done here, and all work!
;======================================
;
SHIFTOUT Clock_pin, Data_pin, MSBFirst_L, ($01, $14) : PULSOUT Load_pin, 1 ; <---- Works perfectly!
;
SHIFTOUT Clock_pin, Data_pin, LSBFirst_L, ($01, $14) : PULSOUT Load_pin, 1 ; <---- Does not Work at all!
;
;At the moment i need to send out a "41" instead of "14" to make the correct LED come on, but in future, this backward data makes 
;my whole LED map unclear to determine which led and in what order they will turn on/off
;I'd really prefer to use LSBFirst to do this reversal and keep things clear ;-)
;
 

Aries

New Member
LSBFirst sends out all the bits in reverse order, so $14 (=binary 0001 0100) comes out as binary 0010 1000 (=$28), not $41.
 

OLDmarty

Senior Member
LSBFirst sends out all the bits in reverse order, so $14 (=binary 0001 0100) comes out as binary 0010 1000 (=$28), not $41.
Agreed, i actually need to swap numbers, not reverse all the bits, so i'll opt for another way ;-)
 

westaust55

Moderator
@JimPerry,
The MSBfirst_L, MSBfirst_H, LSBfirst_L and LSBfirst_H are all PICAXE programmer predefined constants.
See: http://www.picaxe.com/BASIC-Commands/Advanced-IO-Interfacing/shiftout/

@OLDmarty,
Have you read the tutorial and tried the associated code from my (2013 vintage) thread here:
https://picaxeforum.co.uk/threads/getting-started-with-the-max7219-eight-digit-7-segment-led-driver.23293/
SHIFTOUT with LSBfirst_L was certainly working then for me.

Quite a while since I used the 7219 but note the following from my tutorial:
; Subroutine to shift the register address and data value out to the MAX7219
; Tests have identified that the MAX7219 incoming data is clocked in through the lsb towards the msb.
; If only one MAX7219 is connected then the first four significant bits of data can be ignored to
; improve the data transfer speed by 25%
As Aries has highlighted, if your control registers set up has been based on exchanging the high and low nybbles of the bytes then the control registers are likely not set up correctly.
 

OLDmarty

Senior Member
Thanks Westy,

I actually learned all my 7219 coding/configs from your link quite a while ago ;-)
So, that's my reference of what i do when driving 7219's these days.

Anyway, I can see that playing with some "test numbers" and having them reversed is sending data to a 7219 'row' beyond the number 8, hence no display during my previous tests. A great oversight on my part lol

However, i will need to achieve a "byte SWAP' by other means, sending LSbyte followed by MSbyte, into the 7219 shiftout string,because reversing the outgoing 8bit data in the existing bytes complicates bit-mapping even further ;-(

At worst case, I may just leave the code as it was and include EXTENSIVE notes all over it to remember that my first byte is the 2nd byte to appear on the LEDs and be done with it ;-)
 

Aries

New Member
If you want to reverse the two halves of a BYTE variable, you can use something like this:
Code:
b0 = b0 * 257 / 16
You can use this for b0 etc, also @ptr and @bptr
 

Aries

New Member
Agreed, i actually need to swap numbers, not reverse all the bits, so i'll opt for another way ;-)
If you want $14 to become $41, you need my version ( b0 = b0 * 257 / 16 );
b0 = b0 Rev 8 reverses all the bits
 

hippy

Technical Support
Staff member
If you want $14 to become $41, you need my version ( b0 = b0 * 257 / 16 );
That 'times 257' is quite a neat optimisation. I thought it was wrong at first, but it provides for a 'times 256 plus 1 times', saves an addition over what would often be used -

b0 = b0 * 256 + b0 / 16

For fastest execution speed on an X2 -

b0 = b0 << 8 | b0 >> 4

I'm not sure how these compare in execution speed -

b1 = b0 : b0 = w0 / 16
b1 = b0 : b0 = w0 >> 4
 

OLDmarty

Senior Member
Thanks everyone for all your input.
Geez, you guys know more than 1 way to skin a cat lol ;-)

I have since proven to myself a few bit-reversed trials to prove that shiftout LSBFIRST does in fact work ;-)

Thanks again.
 
Top