Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
RPi: to use spidev1.0 or other GPIOs
#1
Hi, I want to use the pins 38, 40 in the RPi GPIO(BOARD) for SPI MOSI and SCLK respectively. (http://pi.gadgetoid.com/pinout/pin40_gpio21)
I m using the /dev/spidev0.0 for other devices
Or is it possible to use may be two of the GPIO to use the LPD8806 based strip?
#2
So... you are on the right track since 38 and 40 are for the secondary SPI port.
What do you get when you run this?

Code:
ls -al /dev/spidev*

Normally, you would have spidev0.0 and spidev0.1 and if the latest Raspbian comes with the secondary SPI drivers now (it didn't before) I would imagine you would see something like spidev1.0

So, part of the problem is that LPD8806 is "SPI-like", not true SPI... meaning it doesn't support chip select. So, ANYTHING you send over SPI, the LEDs will react too.

Not really sure what other SPI devices you are using but I would recommend either using a library that can bit-bang SPI on arbitrary GPIO pins for those other devices and use the real SPI for the LEDs... there is no bit-bang support in BiblioPixel because it would be way to slow and wouldn't work.

My understanding is that the pigpio library does support the secondary SPI device (ID 2) but I know you may have already written code with other libraries.

In the way that BiblioPixel and DriverLPD8806 works, if the new SPI device shows up then you could just set dev="/dev/spidev1.0" in the DriverLDP8806 init.

I just loaded up a new Pi 2 with the latest firmware recently and will check tonight at home to see if the device shows up and let you know. But if you have one and can try, like above, let me know here. BiblioPixel will only work with it if you can use a file-based device path.
#3
So... nope. Raspbian doesn't expose SPI1 as a device file, so that's a no go. I'll keep looking into it and see if I can find a way to enable it... but I would still suggest trying to do what you need to with pigpio (or similar) for your other devices and use SPI0 for the LEDs. I'll also look into if there's a way to bit-bang the LEDs... but speed would be... bad.
#4
(08-04-2015, 09:23 PM)Adam Wrote: So... nope. Raspbian doesn't expose SPI1 as a device file, so that's a no go. I'll keep looking into it and see if I can find a way to enable it... but I would still suggest trying to do what you need to with pigpio (or similar) for your other devices and use SPI0 for the LEDs. I'll also look into if there's a way to bit-bang the LEDs... but speed would be... bad.

Today i tried to using PIGPIO and was successful with the a sample program like the following. Unfortunately i wasn't able to control the LEDs.

Code:
#!/usr/bin/env python
import pigpio
import time
# mosi=20 miso=19 sclk=21 ce0=18 ce1=17 ce2=16      aux SPI gpios (B+ only)
# used SPI flags
AUX_SPI=(1<<8)
pi = pigpio.pi() # Connect to local Pi.
# Get handle to aux SPI channel 1.
leds = pi.spi_open(1, 50000, AUX_SPI)
pi.spi_write(leds, '0')    
time.sleep(5)
pi.spi_close(leds)
pi.stop()

The whole system of an wireless access point is built out already with RPi.GPIO library and "spidev0.0". I will look into testing it just by a drop in replacement for RPi.GPIO
I will be testing if i can still run my existing program on RPi.GPIO and just run PIGPIO for the LEDs with no conflicts.
Is there a way to amend the Bibliopixel to use PIGPIO? Being slow doesn't matter as the led strip is only used for notification purposes and a couple of seconds would also be fine. it would be cool to use your existing animations to make the notification effects.
#5
All you are writing to the LEDs there is a 0... the character 0 actually, so decimal 48.
Did you try writing something else to it?
To vastly oversimplify, the LDP8806 protocol works like this.
3 bytes per pixel (not usually in RGB order... depends on the manufacturer) where only the first 7 bits are used, so 21-bit color total.
The 8th bit (or bit 7 in 0 indexing) is the "latch" bit. This bit MUST be 0 when sending color data. Then, when you are done, send a byte with bit 7 set to 1. I always just send 0xFF since any byte with bit 7 set is ONLY used as a latch, meaning it then tells all the ICs to set the LED color to the new data.

So, I would try sending this array of bytes to your strip via pigpio:

[0x7F, 0x7F, 0x7F, 0xFF]

That should light the first pixel white.

And yes, you could absolutely utilize pigpio with a new driver or appending to the original.

First, take a look at this: https://github.com/ManiacalLabs/BiblioPixel/blob/master/bibliopixel/drivers/spi_driver_base.py

That is the base SPI driver. Ideally, we could modify that to optionally use pigpio.

But also check out this: https://github.com/ManiacalLabs/BiblioPixel/blob/master/bibliopixel/drivers/LPD8806.py
For the LPD8806 specifics.

I honestly think the easiest would be to modify spi_driver_base and add a new parameter to the init called use_pigpio and another pigpio_interface which would be the SPI ID (0 & 1 are the original and 2 is the aux SPI port you are trying to use). Then, if use_pigpio is set to True, use the pigpio sub-system instead.

I'm certainly happy to help out making these changes. I have all I need to test it, but always good to have more than just me testing things. And I'm releasing a new version soon anyways Smile

Definitely try just sending those 4 bytes to a strip before making BiblioPixel modifications... no point in trying if pigpio doesn't work in the first place.
#6
yes, I did try others and it was working with PIGPIO. The drawback is that it utilises all the SPI pins which are connected to the other daughter boards for the actual application.
I worked it up with bit banging and i dont have to use more than the two pins that i require. Ideal for my operation. It is now hard to figure out the data structure to send to the strip. I have a 16 LED strip and i hope it will not be that hard to figure that out for programatic implementation from your previous reply.

Code:
    def writeByte(dataOut): # should be initialised earlier with RPi.GPIO

        # Push data
        for i in range(8):
            GPIO.output(dataPin, (dataOut & (0x80 >> i)) <> 0)
            GPIO.output(clockPin, GPIO.HIGH)
            GPIO.output(clockPin, GPIO.LOW)

clockPin and dataPin can be any random pin from RPi GPIOs.
Thank you very much for support.
#7
Nice... I'll see about adding a bit-banged option to DriverLPD8806 I'm sure that would be useful Smile


Forum Jump:


Users browsing this thread: 1 Guest(s)