ola
ola copied to clipboard
OpenLightingProject
Implementing WS2812b signal transmission in SPI plugin.
We ought to get #1358 in first, which makes a few changes to the way personalities work, but fairly minimal code changes your end.
Okay @Ph0N37Ic5 the other PR is in, so do you want to resolve conflicts and update; you should see the equivalent changes to make to your PR.
Thanks @Ph0N37Ic5 . We're still seeing your PR offset with the recent master changes. How did you get them in? git pull upstream master if you've added https://github.com/OpenLightingProject/ola.git as a remote should do the trick. Alternatively you can use the resolve conflicts button at the bottom of the pull request.
Confusingly, there don't seem to be actual conflicts, it just doesn't have your changes present as it's expecting.
Sorry for being such a noob, but how do I add something as a remote? I seem to be having issues with pulling the upstream master.
It looks like you've managed the remote thing, but otherwise see https://help.github.com/articles/adding-a-remote/ and the other excellent articles on GitHub.
There are also a few lint issues you'll need to fix please, see towards the bottom of the lint job log here: https://travis-ci.org/OpenLightingProject/ola/jobs/345721735
I'm working on the tests in SPIOutputTest.cpp, but it might take a little while.
It's currently failing due to differing lengths: https://travis-ci.org/OpenLightingProject/ola/jobs/345771055#L5288
You forgot to modify SPIOutput::InternalWriteDMX so your functions are never being called yet.
Now it fails in new and wonderful ways, the question is, who's calculations are wrong, its or mine?
You mean who's testing the tester. :stuck_out_tongue:
Am I right in thinking this should also support WS2811, did I read that somewhere?
Can you also post on the PR when you've done some hardware tests, and which flavour of LEDs it was, some other rough detail etc.
It's currently compiling on my RPi. The tests will be with the WS2812b. From what I can see from the data sheets the WS2811 uses the same protocol, but I have none I can test with. In any case testing would probably have to wait until tomorrow evening. I occasionally have to sleep, and I have some engagements in the morning.
Tomorrow or later is fine, people have been waiting a lot longer for this already! It's great you've started a PR :smile:
Is there any other place there needs to be made changes in order to load the plugin from the config? It doesn't seem to want to accept any number outside 1 through 8.
I'm not really sure what to suggest. Do you want to try via the RDM tab in the web UI? Are your new personalities listed there?
Otherwise does olad -l 4 show anything about not loading them when it first starts up?
I can at least select the APA102 flavours, and I've even pushed the info up to our website: http://rdm.openlighting.org/model/display?manufacturer=31344&model=3
Olad only reads the log at startup, so you need to start olad, then stop it, then edit the file (which will have been created at first run), then start it again to make it read your edits.
Nope, not getting more than 2 APA102 interfaces, and no WS2812b in the list.
Try a make, or make clean then a make; if you're not getting the APA pixel brightness, you're not building against master...
I've ... ... "make uninstall"ed it on my pi. ... merged master back into my fork ... re-cloned it to my pi and am compiling it anew. This might take a while.
Interesting output from ./configure
checking random usability... no checking random presence... yes configure: WARNING: random: present but cannot be compiled configure: WARNING: random: check for missing prerequisite headers? configure: WARNING: random: see the Autoconf documentation configure: WARNING: random: section "Present But Cannot Be Compiled" configure: WARNING: random: proceeding with the compiler's result configure: WARNING: ## --------------------------------------------- ## configure: WARNING: ## Report this to [email protected] ## configure: WARNING: ## --------------------------------------------- ## checking for random... no
checking SaleaeDeviceApi.h usability... no checking SaleaeDeviceApi.h presence... no checking for SaleaeDeviceApi.h... no configure: WARNING: SaleaeDevice library is not usable.
So it compiled all right, but I seem to have gotten a different problem, just before I reset everything the webserver started complaining about not finding it's files, now after a complete rebuild, it still has the same problem. Seems that the web files got installed to /usr/local/share/olad/www but olad is looking for them in /usr/share/olad/www.
Go figure, anyway, a complete reinstall does not show the last four items in the list. This might be related, as it seems most everything goes into /usr/local/... rather than /usr/... But it must be finding it, otherwise it would not show up at all, right? And there is no other instances of the libraries on the system.
This is all that is mentioned about SPI in syslog:
Feb 26 07:38:44 raspberrypi olad: olad/PluginManager.cpp:195: Trying to start SPI Feb 26 07:38:44 raspberrypi olad: plugins/spi/SPIWriter.cpp:59: Created SPI Writer /dev/spidev0.1 with speed 1000000, CE is 0 Feb 26 07:38:44 raspberrypi olad: plugins/spi/SPIDevice.cpp:97: spidev0.1, Software backend, 1 ports Feb 26 07:38:44 raspberrypi olad: common/io/EPoller.cpp:306: ss process time was 0.000024 Feb 26 07:38:44 raspberrypi olad: common/thread/Thread.cpp:194: Thread , policy SCHED_OTHER, priority 0 Feb 26 07:38:44 raspberrypi olad: olad/plugin_api/DeviceManager.cpp:105: Installed device: SPI Device:15-spidev0.1 Feb 26 07:38:44 raspberrypi olad: olad/plugin_api/PortManager.cpp:119: Patched 15-spidev0.1-O-0 to universe 3 Feb 26 07:38:44 raspberrypi olad: plugins/spi/SPIWriter.cpp:59: Created SPI Writer /dev/spidev0.0 with speed 1000000, CE is 0 Feb 26 07:38:44 raspberrypi olad: plugins/spi/SPIDevice.cpp:97: spidev0.0, Software backend, 1 ports Feb 26 07:38:44 raspberrypi olad: common/io/SelectPoller.cpp:233: ss process time was 0.013927 Feb 26 07:38:44 raspberrypi olad: common/thread/Thread.cpp:194: Thread , policy SCHED_OTHER, priority 0 Feb 26 07:38:44 raspberrypi olad: olad/plugin_api/DeviceManager.cpp:105: Installed device: SPI Device:15-spidev0.0 Feb 26 07:38:44 raspberrypi olad: olad/PluginManager.cpp:200: Started SPI
Ok, so sometimes it helps digging through the whole filesystem to find old versions. I was wondering why things didn't seem to update at all. For some reason there was a version installed in /usr/lib/arm-linux-gnueabihf/, I got things to show up now. 8/
Has this effort been abandoned, or is the core functionality merged and funcional (WS2812B support via SPI plugin)?
Sorry, I missed this before @Ph0N37Ic5
Interesting output from ./configure
checking random usability... no checking random presence... yes configure: WARNING: random: present but cannot be compiled configure: WARNING: random: check for missing prerequisite headers? configure: WARNING: random: see the Autoconf documentation configure: WARNING: random: section "Present But Cannot Be Compiled" configure: WARNING: random: proceeding with the compiler's result configure: WARNING: ## --------------------------------------------- ## configure: WARNING: ## Report this to [email protected] ## configure: WARNING: ## --------------------------------------------- ## checking for random... no
I think this has been fixed in a later master. Otherwise can you confirm OS version and compiler version please (or ideal share all of config.log)
checking SaleaeDeviceApi.h usability... no checking SaleaeDeviceApi.h presence... no checking for SaleaeDeviceApi.h... no configure: WARNING: SaleaeDevice library is not usable.
That's fine, it just means you can't use the Logic sniffer to decode RDM, I don't think they do an ARM version of their libs anyway...
Has this effort been abandoned, or is the core functionality merged and funcional (WS2812B support via SPI plugin)?
Hi @petiepooo ,
That would be a question for @Ph0N37Ic5 . I'm not sure if they'd managed to test the code in this PR with any hardware after their initial tests. Do you have hardware? Are you interested in helping out? The code doesn't look too far away from being merge-able if it works.
Also see some other options mentioned in #578 (e.g. Fadecandy support, with a few limitations) has been in for a while.
Is there any update? How could I get Ws2812b leds running via OLA on my Pi 4? I have already a working C-program, with which I can control at least 1000 WS2812 leds (for help: https://github.com/jbentham/rpi). Now I wish I could build a system that takes Artnet Signal as Input and turn it into WS signal (eventually combined with my working code). As a newbie I would like to know if OLA can help me for this target. Otherwise what else could you recommend to me? Thanks for any feedback.
Is there any update?
No real change from the project side since last time this was asked:
That would be a question for @Ph0N37Ic5 . I'm not sure if they'd managed to test the code in this PR with any hardware after their initial tests. Do you have hardware? Are you interested in helping out? The code doesn't look too far away from being merge-able if it works.
I'm happy to help if someone wants to look at the code further, if you have some hardware on hand you could try compiling @Ph0N37Ic5 's code and see if it works, and give us some feedback if not and we can probably give some pointers as to what might be wrong.
How could I get Ws2812b leds running via OLA on my Pi 4?
Again, to avoid mixing and fragmenting discussion, see the more general thread here where I've responded to your other library suggestion ( https://github.com/OpenLightingProject/ola/issues/578#issuecomment-871790445 ):
Also see some other options mentioned in #578 (e.g. Fadecandy support, with a few limitations) has been in for a while.
@peternewman I did try #1382 and although the software side of things went well, when it outputted to the WS2811, it would flicker and the first LED in the strand would not have the correct color. I assume it works well with WS2812b just fine but haven't tested it as it isn't my use case. I also don't have the know-how to debug it on that low of a level and I don't have a scope.
Originally posted by @ryanriccio1 in https://github.com/OpenLightingProject/ola/issues/1740#issuecomment-929330363
I have the hardware to test this ( scope and lots of different led tape ), but not the expertise to get this to build. Happy to test is someone can help with the software side.
