The obvious first thought is that this is a consequence of Linux not being a real-time operating system. I would expect that occasionally the kernel fiddles around with it's scheduling, your LED driver process gets stalled a little bit and poof your data transmission is corrupted.The problem I have now is that, "once in a while", the LEDs show an unexpected pattern.
Code: Select all
$ sudo nice -20 myLedProcess
more activity could put a larger load on the 3v3 regulator which might affect the logic high GPIO output voltage, (which is *very* critical at this point) so no the fact that corruption gets worse with CPU activity isn't automatically an indicator that it isn't a logic level problem, the more I read the more it points to logic level problems, as at least the main reason, it behaves exactly as I would expect.Heater wrote: ↑Wed Dec 27, 2017 8:00 amCertainly, looking at the data sheet, meeting the logic high level from a Pi output is problematic. That would be the first to fix.
However or OPs claims that the "corruption" gets worse when certain software activity is going on on the Pi don't totally rule out timing issues as well.
Anyway, first things first.
with a single simple transistor I think you would have also inverted the signal, not just level shifted it, for that you would need two transistors, so perhaps that was the issue.NotRequired wrote: ↑Wed Dec 27, 2017 12:57 pmThe problems I had with SK6812 was due to timing issues, no doubt! I had wired up a transistor (not 100% sure, but I think it was a P2N2222A with a VBE(sat) of 2) to lift 3.3V to 5V and it still would not work right. I tried all the libraries I could find, but still no cigar! Never tried the dedicated core or Nice, though..
Yes, I believe I used this method, but there still was some weird "artifacts" every now and then. I ended up using an arduino nano powered by a USB-port through wich I then could send commands from the Pi to the nano with a python script.
Wow, if my suggestion is working perfectly I think you have just made my day.Heater ... I have done everything you said, and it works just perfectly now:
I'd never heard of isolcpus. I was going to use maxcpus.- add this at kernel boot prompt, to reserve cores 2 and 3 (first core is #0): isolcpus=2,3
Again, I had never heard of taskset. I was about to start writing some C code and set CPU affinity on some thread....- start my bash script on core 2: /usr/bin/taskset -c 2 /root/ws2812-spi/ws2812.sh
exactly my point, bit-banging I/O works under Raspbian.
I think that conclusion does not follow from what doublehp said....exactly my point, bit-banging I/O works under Raspbian.
I can't say if APA102 r totally reliable but so far I haven't had trouble with them.I am perfectly aware it's not the best solution; but, untill now, nobody certified me that APA102 would bork better. You say it's easier to use; you didn't say it would provide 100.000000% reliability.