@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 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).
@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()@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.
@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.
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.
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?
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.
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.
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:
Perhaps I am missing some simple fix here? Perhaps I should let the LED strip receive signal from MOSI only when CS1 is high?