Dumb N00b Question on the best methods to record and replay SPI Signals

[simonboydfoley]

Hi All,
       I am having issues controlling a APA102 LED with inbuilt 2 wire SPI interface. I am programming the LED via GPIO on a Raspberry Pi 3 and a RockPRO64. I have a cheap USB Logic Analyser (Saleae), Oscilloscope (DSO5102P) and Waveform Generator (FeelTech Y6600).

 I can control the LED from the Pi but not the RockPro64.

The SPI signal is identical between the Boards using the logic analyser & oscilloscope to check the waveforms.

The only difference is the frequency of the clocks the different boards GPIO interfaces are able to run at in software.

RPi CLK = 714KHz     (using Python wrapper of GPIO.h using hardware device driver)
RP64 = 7KHz             (using c code to the /sys/class/gpio file interface)

The data sheet of the APA102 indicates min 800 KHz Frequency so I want to be able to replay a SPI2 Wire signal 10 x 32 Bytes at increasing clock frequencies to determine the true lower threshold of the APA102.

I am going to be writing a C library to be wrapped by the Python GPIO Library for the RockPro64  (RockChip RK3399) which is how the RPi managed to get the higher frequencies.

I had hoped that the software waveform generator that came with the FeelTech would enable me to do this ,... but it is horrendous.

Before I crack out an Arduino and do all this in HW ... am I missing a Trick ?   

is there any open source software & SPI Signal encoding standard file format I could be leveraging to do all this in the FeelTech signal generator.

Are there reasonably priced SPI \ I2C \ UART Board \ Devices out there that can be used to generate, save and replay arbitrary bus signals like SPI at differing frequencies ?

Thanks for any advice in advance

... looking to avoid going down a rabbit hole because I am taking a wrong turn somewhere!

[simonboydfoley]

Update:   I have found a few logic analysers that have the capability to replay signals like SPI.

Problem is I can not find suppliers in the EU!

analogarts LP665
http://www.analogarts.com/products/usb-logic-analyzer-pattern-generator/lp665-200-mhz-sample-logic-analyzer-100-mhz-output-range-pattern-generator

I will keep looking. I would be surprised if the USB Port could deliver enough power to also act as a signal generator.

I will keep looking.

[TK]

The min 800KHz requirement is for the oscillator and the datasheet does not say anything about the minimum CLK frequency.  Maybe your CLK + Data signals from the RockPRO64 are not in sync? 

From Hackaday: "The advantage of APA102 LEDs is that they don’t have the strict timing requirements of the WS2812. These LEDs are controlled with a SPI bus that can be clocked at any arbitrary rate, making them easy to use with pretty much any microcontroller or embedded system."

Can you post the logic analyzer capture screen for both the signals generated by Pi and RockPRO64?

[simonboydfoley]

See Attached
I have included the initial sequence of 2 runs on both boards doing the same thing

Initialisation 32 Bits 00000000,00000000,00000000,00000000
LED1              32BIts 11100111,00000000,00000000,10000000
etc etc
LED8              32BIts 11100111,00000000,00000000,10000000
End                32 Bits 00000000,00000000,00000000,00000000

The difference with the rock pro I was pushing the full duty cycle 256 on the LED signal 11111111 instead of 10000000

     writeByteToGpioFlag = writeByteToGpio(36,149,"00000000000000000000000000000000",0);
        //LED 1 Frame
        writeByteToGpioFlag = writeByteToGpio(36,149,"11101111000000000000000011111111",0);
        //LED 2 Frame
        writeByteToGpioFlag = writeByteToGpio(36,149,"11101111000000001111111100000000",0);
        //LED 3 Frame
        writeByteToGpioFlag = writeByteToGpio(36,149,"11101111111111110000000000000000",0);
        //LED 4 Frame
        writeByteToGpioFlag = writeByteToGpio(36,149,"11101111000000001111111100000000",0);
        //LED 5 Frame
        writeByteToGpioFlag = writeByteToGpio(36,149,"11101111000000000000000011111111",0);
        //LED 6 Frame
        writeByteToGpioFlag = writeByteToGpio(36,149,"11101111000000001111111100000000",0);
        //LED 7 Frame
        writeByteToGpioFlag = writeByteToGpio(36,149,"11101111111111110000000000000000",0);
        //LED 8 Frame
        writeByteToGpioFlag = writeByteToGpio(36,149,"11101111000000001111111100000000",0);
        //end frame
        writeByteToGpioFlag = writeByteToGpio(36,149,"00000000000000000000000000000000",1);
 

[simonboydfoley]

I have attached another rockpro64 effort this time emulating the output from the Raspberry Pi a bit better (I have been playing around with the signal brightness and colour patterns.

Apologies I did not want to bog you down with analysis ... my aim was to look for tools that would help me troubleshoot myself.

It seems that there were some cheap SPI signal generation units out there with decent enough software to recreate SPI Signals at varying clock rates .... they were even USB ones ... but they are now all obsolete ..most are just pure analysers now, Its probably because of Arduino.
I just wondered what other more experienced people would do out there.


FYI the reason I think this may be frequency related is because I am using a blinkt unit that has 8 of these LED's daisy chained together.
The SPI CLK & DAT Signal is forwarded on from one unit to the next .. but the DAT signal is delayed by 1/2 a CLK Cycle on the output of each LED. This enforces each LED in the chain to fire 1/2 CLK Cycle apart ... I am not sure why ,,,, but the point is to ad a "delay" indicates a buffer storage and clock sampling rate.   Fail to be fast enough for that buffer / sampling rate ,,,, and I suspect the unit can not detect the CLK Cycle and it simply barfs on outputting any signal to the LED's at all... That's my hunch. The chinglish in the data sheet is hard to interpret, but if the sampling clock is has a minimum speed of 800KHz ... it would suggest that in order to detect the 180 deg phase change .... YOu need a minimum clock on the SPI of 400KHz.

The Raspberry Pi achieves this coming in at 714KHz.
But the RockPro64 coming in at just 7KHz ... falls well short ...

This is the hypothesis I want to test ,,, if I can get the signal clock to to > 400-600KHz .... the Blinkit unit should work ?

https://cpldcpu.wordpress.com/2014/11/30/understanding-the-apa102-superled/

Q). What precision tool will allow me to test this theory by storing and replaying an arbitrary SPI Signal buffer at differing CLK frequencies ?

The feeltech I bought has garbage software  to generate the wave form I need :-(


   

[TK]

In my opinion, an Arduino would be the best and cheapest tool.

[simonboydfoley]

I have decided to write a proper GPIO Driver for the board using GRF Registers then publish back to the community :-)