@luz Thank you, I finally solved this! Ordered bunch of 74HC125D chips, there are four gates per chip. I pass through the gate only the CLK line, assuming that any MOSI traffic will be ignored by the strip when there is no CLK. So far so good, it seems that both flash memory (device 0), and LED strip are working just fine.

Pavils Jurjans
@Pavils Jurjans
Posts made by Pavils Jurjans
-
RE: Driving APA102 (SPI) RGB LED from Omega2+
-
RE: SPI using Pyton3
@Pavils-Jurjans Ok, finally, got this working! The missing data problem was solved by changing the frequency to 200KHz. Apparently, the hardware SPI gets unreliable with low frequencies. Now I wonder what is the maximum frequency, as I tried 3.2MHz and it still works (For my 300 pixel APA102 RGB LED strip, I measure about 200 updates per second).
-
RE: SPI using Pyton3
@Lazar-Demin Thanks, I ordered bunch of 74HC125D chips, and it seems to do the trick.
I set up only the CLK line to go through the buffer, though. But as long as the APA102 LED strip works, and the communication with flash memory (SPI device 0) is not disturbed, there's no need to make the similar setup for MOSI, too.
There's another problem surfacing now, though. The
spi.xfer(byte_array)
command sends only 28 bytes correctly, and then the rest is just a bunch of zeros or 0xff. It is as though there's some internal buffer with size of 28 bytes.import spidev spi = spidev.SpiDev() spi.open(32766, 1) spi.max_speed_hz=100000 # 100 KHz size = 50; spi_data = [0x00] * size for offset in range(size): spi_data[offset] = offset print spi_data spi.xfer(spi_data) spi.close()
-
RE: Trying to get the I2S audio working
@Andrew-Naumenko wow, you're totally right! I wonder, is this a bug or intentional removal of feature? Perhaps @Lazar-Demin knows to comment? b195 version is still the old console, and it even pleads to upgrade to the latest firmware at the setup. Kind of awkward.
root@Omega-ABCD:~# aplay -Ll null Discard all samples (playback) or generate zero samples (capture) default:CARD=AudioI2S Audio-I2S, Default Audio Device sysdefault:CARD=AudioI2S Audio-I2S, Default Audio Device **** List of PLAYBACK Hardware Devices **** card 0: AudioI2S [Audio-I2S], device 0: ralink-i2s-HiFi HiFi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0
Another strange thing I have noticed is that the wav file playback by
$ aplay Test.wav
did not succeed: no sound, and Omega just shuts down after few seconds, no error message whatsoever. Not that I cannot survive with only mp3 file support, but something fishy is going on there. -
RE: Trying to get the I2S audio working
@Andrew-Naumenko Well I have b199, shouldn't it work for me, too? What's your output from
aplay -Ll
? It would be interesting to see what are the configuration differences between your system and mine. -
RE: Trying to get the I2S audio working
Apparently not:
root@Omega-ABCD:~# ls /usr/bin | grep alsa alsamixer root@Omega-ABCD:~# alsamixer cannot open mixer: No such file or directory
I think it's because there are zero sound cards to show configuration for:
root@Omega-E1F5:/usr/bin# alsamixer -c 0 invalid card index: 0 try `alsamixer --help' for more information
Somehow I must tell the system that there is one soundcard that should output to I2S.
-
Trying to get the I2S audio working
I've found this tutorial https://onion.io/2bt-omega-i2s-audio/ by @Pavel-Metrokhin. It touts that "the very latest release of the Omega OS has support for I2S audio devices!", and goes on to point that in order to get the I2S support, b177 firmware version must be installed. I have the 0.2.1 (b199) firmware version, that should be containing the I2S support, unless it was removed in later versions.
So I set out to purchase the MAX98367A I2S mono amp breakout board. Today it finally arrived and I proceeded with the setup commands described in that link. However, when trying to play an mp3 file, I get this error:
root@Omega-ABCD:~# mpg123 Test.mp3 ALSA lib confmisc.c:768:(parse_card) cannot find card '0' ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib conf.c:4292:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib conf.c:4771:(snd_config_expand) Evaluate error: No such file or directory ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default [alsa.c:170] error: cannot open device default [audio.c:645] error: failed to open audio device [audio.c:180] error: Unable to find a working output module in this list: alsa [audio.c:545] error: Failed to open audio output module [mpg123.c:913] error: Failed to initialize output, goodbye.
There's an identical error when trying to play a wav file with
$ aplay Test.wav
It appears the problem is connected to alsa not seeing any soundcard:
root@Omega-ABCD:~# aplay -Ll null Discard all samples (playback) or generate zero samples (capture) aplay: device_list:268: no soundcards found...
I am not sure what to do with this. How can I add a soundcard? The author of that tutorial made it look so simple and straightforward. Maybe I am missing some configuration command?
-
RE: Driving APA102 (SPI) RGB LED from Omega2+
I wonder how that works that the APA102 steals the signal from CS0. Why one SPI device consuming MOSI data should mean that another device on that bus does not receive it?
Anyway, I think I will keep looking for a way how to ground the CLK signal that goes to APA102, when CS1 pin is active (low, or high, depending on what will the circuit look like). For example, I am thinking if letting CLS and CS1 (active-high) go in the AND gate, perhaps then the output CLK would be a good for driving the APA102.
-
RE: SPI using Pyton3
Pardon my ignorance, but could you, please, point me to an example of such circuit? I am not sure I can come up with the best solution. Being a programmer rather than electronics engineer, all I can think of is throwing in an AND gate where CLK and (active-high mode) CS are inputs and the output goes to the LED strip.
-
RE: SPI using Pyton3
Dammit, you're right! I should've checked the time scale on the crippled diagram.
But now I stumble on the next problem. I connected my APA-102 RGB LED strip to the GPIO pins 7 (CLK) and 8 (MOSI), and it appears that this connection causes some bad interference with Omega:
- At boot, about 20 of LEDs are lighting up and twinkling, showing that there is some data being sent out of SPI. Since I am not using the CS1 pin, my interpretation is that the data that is meant for SPI device 0, now is captured by the LED strip (it says here, that "..device 0 (CS0) is connected to the flash memory used by the Omega").
- Omega is working with random glitches, perhaps the communication with device 0 is being messed up.
Perhaps I am missing some simple fix here? Perhaps I should let the LED strip receive signal from MOSI only when CS1 is high?