H3-based devices support

[martin-mat]

Hey,

has anybody tried/succeeded with running the lib on H3-based devices, like Oragne Pi, BPi M2+ etc? If so, can you describe steps, especially regarding used gpio driver?

[zador-blood-stained]

Tried just now on Orange Pi One. GPIO works via sysfs without any tweaks.
For reference: OS - Armbian, kernel 3.4.112 (legacy), kernel configuration: orangepione.fex
Wiring:

nRF24L01 | Orange Pi
_________|________________
VCC      | VCC3V3-EXT
GND      | GND
CSN      | SPI0_CS0 (SPI-CE0)
CE       | PA7 (IO-7)
MOSI     | SPI0_MOSI (SPI-MOSI)
SCK      | SPI0_CLK (SPI-CLK)
MISO     | SPI0_MISO (SPI-MISO)

Changes in gettingstarted.cpp:

diff --git a/examples_linux/gettingstarted.cpp b/examples_linux/gettingstarted.cpp
index d25155e..278c3fe 100644
--- a/examples_linux/gettingstarted.cpp
+++ b/examples_linux/gettingstarted.cpp
@@ -46,7 +46,7 @@ using namespace std;
 //RF24 radio(RPI_V2_GPIO_P1_15, RPI_V2_GPIO_P1_24, BCM2835_SPI_SPEED_8MHZ);

 // RPi generic:
-RF24 radio(22,0);
+//RF24 radio(22,0);

 /*** RPi Alternate ***/
 //Note: Specify SPI BUS 0 or 1 instead of CS pin number.
@@ -66,7 +66,7 @@ RF24 radio(22,0);
 // See https://www.kernel.org/doc/Documentation/spi/spidev for more information on SPIDEV

 // Setup for ARM(Linux) devices like BBB using spidev (default is "/dev/spidev1.0" )
-//RF24 radio(115,0);
+RF24 radio(7,0);

 //BBB Alternate, with mraa
 // CE pin = (Header P9, Pin 13) = 59 = 13 + 46 

Edit: Just so it's clear - this configuration works for me, tested with Raspberry Pi B with RF24 and Python wrapper on the other end.

[martin-mat]

@zador-blood-stained thanks for hinting armbian, it looks great. Before I tried an adaptation of raspbian which had /sys/class/gpio_sw instead of standard /sys/class/gpio and even behaved differently. But armbian works perfectly with my orange pc.

[azmathmoosa]

I tried using NanoPi Neo that uses the same H3 and the status bits were all garbage. So i hooked up a logic analyzer and saw the clock signal going high before transmission despite SPI Mode = 0.

Has anyone tried it and got it working in nanopi? Is it an SPIDEV issue on the kernel? I've checked the utilities/SPIDEV/spi.cpp and the mode is correctly being set to 0.

[mirko]

I'm having the same issue with an Orange-Pi-One (AW H3 based).
The RaspberryPi2b for instance does not do that.

Wiring re screenshot:

1. SCK RaspberryPi
2. MOSI RaspberryPi
3. SCK OrangePiOne
4. MOSI OrangePiOne
   So, although it's different kernel versions, I doubt it's a spidev issue but rather sth. in HW.

[mirko]

After some research and pointers from people having also noticed that with older HW (sun4i), the raise to HIGH results from being SUN6I_GBL_CTL_BUS_ENABLE set too early.
Moving that to right before the SPI transfer begins eliminates that peak:

index 8533f4edd00a..6a14589cce32 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -304,6 +304,9 @@ static int sun6i_spi_transfer_one(struct spi_master *master,
 
        sun6i_spi_write(sspi, SUN6I_CLK_CTL_REG, reg);
 
+       /* Finally enable the bus - doing so before might raise SCK to HIGH */
+       sun6i_spi_write(sspi, SUN6I_GBL_CTL_REG, sun6i_spi_read(sspi, SUN6I_GBL_CTL_REG) | SUN6I_GBL_CTL_BUS_ENABLE);
+
        /* Setup the transfer now... */
        if (sspi->tx_buf)
                tx_len = tfr->len;
@@ -411,7 +414,7 @@ static int sun6i_spi_runtime_resume(struct device *dev)
        }
 
        sun6i_spi_write(sspi, SUN6I_GBL_CTL_REG,
-                       SUN6I_GBL_CTL_BUS_ENABLE | SUN6I_GBL_CTL_MASTER | SUN6I_GBL_CTL_TP);
+                       SUN6I_GBL_CTL_MASTER | SUN6I_GBL_CTL_TP);
 
        return 0;