@Bone-Saw said in GPIO issues: I ran omega2-ctrl set spi_cs1 gpio ... I hope you ran omega2-ctrl gpiomux set spi_cs1 gpio instead of the above command.

@Tisham-Dhar assuming you're using the hardware SPI and not bit-banging, I think it would be more straight-forward to use the designated SPI CS1 as the chip select, and then use a mux, with other GPIOs as control signals, to route the CS signal. It's very likely possible to use the hardware controller with a GPIO CS signal, but it would likely involve quite a bit more work than the alternative. Let me know how it goes!

@Pedro-Moura glad to hear it! make sure to post your project when it's done!

@Rogier-Lodewijks no, u don't need patch spidev, only spi-mt7621.c source file and it's in kernel yea. After this u can add cs-gpios in device tree, and spi device in node. Spi device can be spidev if u developing spi driver and u need its API. Thank you)

@Paul-Chabot: From the datasheet you linked, these UCS1903 chips are close relatives to the WS281x family of LED chain chips. To generate the required signal with SPI, you'd need to have a SPI interface available exclusively for the purpose (which you don't on Omega2), and you need to have tight control of the SPI to send a long uninterrupted stream of data (which usually works on Arduino&Co, but is difficult on a Linux system). But luckily, there's hardware better suited for the task than the SPI in Omega2's MT7688 chip: the PWM unit. It's still a bit tricky to meet all timing constraints, but definitely possible. I know because I wrote a kernel driver named p44-ledchain exactly for the purpose I needed it for Omega2 based projects like this (with 200 WS2813 LEDs). Now, the UCS1903 has slightly different timings specs than the chips already supported in p44-ledchain (WS2811, WS2812, WS2813, P9823, SK6812). Still, I think it should work with the P9823 setting. If not, just let me know and I can add another option for the UCS1903 chip to the driver. If you want to give it a try: Install the driver (needs --force-depends because there's no 100% kernel version match): cd /tmp wget http://plan44.ch/downloads/experimental/kmod-p44 ledchain_4.4.61%2B0.9-2_mipsel_24kc.ipk opkg install --force-depends kmod-p44-ledchain* Then load the driver and configure it for a chain of 100 P9823 (see here for detailed description of the module parameters): insmod /lib/modules/4.4.61/p44-ledchain.ko ledchain0=0,100,3 Now you need to configure one of the GPIO pins to provide PWM0 output (GPIO 18 or 46 have that option): omega2-ctrl gpiomux set pwm0 pwm; # for GPIO 18 omega2-ctrl gpiomux set uart1 pwm01; # for GPIO 46 Finally you need to connect your DIN of the first UCS1903 in the chain to the PWM0 output pin of the Omega2 (GPIO 18 or 46). As the Omega2 is 3.3V and the UCS1903 is 5V powered, the high level coming from the Omega2 might not be sufficient for the UCS1903. In my experience with WS281x chips, it can work sometimes, but not reliably. So the right way to do it is adding a level shifter such as a 74AHCT1G125. Now you can just write a string of RGB values into /dev/ledchain0 to control the LEDs, for example: echo -en '\xFF\x00\x00\x00\xFF\x00\x00\x00\xFF' >/dev/ledchain0 to make the first LED red, second green, third blue. There's more info and details in this forum thread

@Douglas-Kryder for what? Pine is just simple dev board, ok, raspberry shows the same error, should I go to raspberry forum? I use flashrom, pine64 is connected by spi, and is used for communication only upd: I resized uboot.bin up to required size and flashed it without errors, tomorrow I will solder it back to omega2 and test it

@Denis-Ilie-Ablachim why don't you give us the part number of the ic you are using? Would bit banging (on some other GPIOs) be a solution?

The address is the register address you are reading. You can usually find this in the part datasheet. There are some issues with Onion SPI still.

@Lindsay-Wright Theoretically you could put variation of the Linkit Smart OpenWrt build on them which should have the patch to switch SPI to half-duplex mode and thus avoid the bit corruption due to a hardware issue with full duplex. But that is obviously a bit of a non-trivial project - ultimately, it just resemphasizes the problem pointed out long ago, that Onion's persistent refusal to release sources which build to a system with working wifi means that the community can't fix little problems for them, and all the work of fixing everything falls on their overstretched team. Another approach you could consider would be to bit-bang SPI, or use a small MCU to bridge to it from I2C or a spare UART.

I am trying to do the same but stuck in the middle. Hoping for a expert reply to resolve this. You're doing a great job @pvadam I think I'm going to play around with your code to understand the point of this problem. Seeking attention of the @administrators Thanks!

@Dana-Myers114 Hi, I have a problem with spi-tool read function it always return 0x00