Open jimbotel opened 5 years ago
Hi @jimbotel, I'd love to help, but I currently have neither a working setup of a LED-strip nor do I have a raspberry pi 4 around. I am happy to accept a pull-request though. Are you already using the new version (npm install rpi-ws281x-native@next
, see here: https://github.com/beyondscreen/node-rpi-ws281x-native/tree/v1.x)?
There are some candidates for things that depend on the actual hardware, and as I didn't update this library for some time (the rpi4 wasn't released back then) it might be that something needs to get a well-deserved update :D
rpi-version
-dependency, which might interfere (As that seems to be abandoned, we might need a better way to handle that here: https://github.com/beyondscreen/node-rpi-ws281x-native/blob/v1.x/lib/get-native-bindings.js#L33Would you be comfortable checking out this repo and hacking around to see if you can fix it? I'm happy to assist if you like...
Hi @usefulthink , Thanks for your reply. I reviewed the code and my understanding is that all the required changes had to be implemented in the library rpi_ws281x, so I went for it. Last weekend I reviewed what was done in pigpio to make it work with the pi4 and introduced some changes in rpi_ws281x code, and it is working now. I'm preparing a pull request to https://github.com/jgarff/rpi_ws281x There's something that I don't like, though. RPi 4B is supposed to get rid of the audio jack interference issues, see: https://www.raspberrypi.org/forums/viewtopic.php?t=245209 However, I'm still seeing this issue (I added my comments to that forum thread), so right now I don't know if this is because of a wrong implementation in rpi_ws281x (due to the changes I introduced, or to something previous), or just that this problem is not completely solved. As a summary: I have a working version of node-rpi-ws281x-native, I tested and its working fine, but I stil have to disable the internal audio and use a usb audio adapter to get the audio properly. Note: I disabled it by adding a blacklist file in /etc/modprobe.d/ with the following lines: blacklist snd_bcm2835 blacklist snd_pcm blacklist snd_timer blacklist snd_pcsp blacklist snd
Oh that sounds very promising. Please let me know when you have the PR ready, I will then update the upstream-dependency and publish it to npm.
Hi @usefulthink , I forked your repository https://github.com/beyondscreen/rpi_ws281x.git and added the changes to support the pi4, I just issued the pull request. Initially I thought I had forked from the original https://github.com/jgarff/rpi_ws281x , so I created the pull request against that one, but I got many conflicts and then I realized of my error. I explain this because I've seen that jgarff repository is being updated, in fact I've seen changes added today to support the rpi4, so I think it would be a good idea to use that repository as base for node-rpi-ws281x-native if possible, instead of your fork that is now outdated. May be some of the interfere problems I'm facing with the audio jack have been fixed in fgarff's. What do you think? Would that be possible, or will it break your code?
Thanks, Jaime.
Hi @usefulthink , FYI, I compiled/ran the test program in jgarff repo, https://github.com/jgarff/rpi_ws281x in my Pi4, and it still interferes with the audio jack, but the behavior is better (I don't get a continuous noise when reproducing audio, just don't get anything :-). In any case, I think it would be good that you point to jgarff's repo for the underlying rpi_ws281x library to be up to date. Regards, Jaime-
@jimbotel do you know when your PR will be in?
In the mean time could you upload your compiled node-rpi-ws281x-native
? I've got a pi4 LED hat that I'm trying to knock out some testing with.
Thanks!
Hi Jeff, I did the PR a few days ago, it's pending to be "approved". Can you please double check if you can see it?
@jimbotel It looks like yours was #371 - which I believe shows as merged into master and closed.
However, I'm not really sure how to pull it down and build it locally - though I can try.
If I can get that working should rpi-ws281x-native@next work as expected? Thanks for the quick response!
Hi @JeffJassky , I think there's some confusion here. node-rpi-ws281x-native includes its own fork of https://github.com/jgarff/rpi_ws281x , i.e. https://github.com/beyondscreen/rpi_ws281x I did a PR to that fork: https://github.com/beyondscreen/rpi_ws281x/pull/3 Previously I also did a PR to jgarff's (my changes based on beyondscreen's base code), but the code had diverge too much so I had to close that. In summary, I see two options here: 1) beyondscreen could merge my PR to his fork of rpi_ws281x. That should give support to rpi4 2) beyondscreen could try using jgarff's rpi_ws281x master code in his node-rpi-ws281x-native. jgarff's rpi_ws281x already provides support to rpi4 and, as far as I can see, it continues quite active. (2 makes more sense to me)
Finally, as I pointed before, both versions of rpi_ws281x still interfere with the audio jack in the rpi4, so you still have to blacklist the corresponding modules. I'm going to open an issue in jgarff's hoping they can have that fixed.
Note: if you want to try my changes, you can do an "npm install node-rpi-ws281x-native" to get all the code, then replace the files from: https://github.com/jimbotel/rpi_ws281x/tree/raspi4support into your node_modules/node-rpi-ws281x-native/src/rpi_ws281x and do an "npm build node-rpi-ws281x-native" to have it recompiled. Let me know if that works.
Regards, Jaime-
@jimbotel Thanks for the detailed clarification. I got everything to build - though still getting this error.
Could not verify raspberry-pi version. If this is wrong and you are running this on a raspberry-pi, please file a bug-report at https://github.com/beyondscreen/node-rpi-ws281x-native/issues
I ran these steps which are slightly modified from the steps you outlined, but I believe are still correct:
npm install rpi-ws281x-native@latest
git clone --single-branch --branch raspi4support https://github.com/jimbotel/rpi_ws281x.git
cp -r rpi_ws281x/* node_modules/rpi-ws281x-native/src/rpi_ws281x
npm build node_modules/rpi-ws281x-native
Source copies over. Confirmed that your edits made it in there. build runs clean.
I also created a /etc/modprobe.d/blacklist.conf
file containing
blacklist snd_bcm2835
blacklist snd_pcm
blacklist snd_timer
blacklist snd_pcsp
blacklist snd
I also tried using rpi-ws281x-native@next
which resolves to @1.0.0-alpha1
. That build failed miserably. Assuming that's not the one I should be using.
Lastly, I notice that you're using a node-
prefix on your package name. I'm assuming that's a mistake since there doesn't seem to be any packages named node-rpi-ws281x-native
in the registry.
Suggestions or corrections are appreciated. Thanks!
Hi @JeffJassky ,
I'm using rpi-ws281x-native indirectly. There's another module that invokes this one and probably is not using all the functions. I touched the underlying rpi_ws281x module, but If I understand correctly, what you found is something that has to be updated in the "parent" pi-ws281x-native. To be more precise, I see in lib/ws281x-native.js
:
41 if(!socFamily) { return 0; }
42
43 switch(socFamily[1].toLowerCase()) {
44 case 'bcm2708': return 1;
45 case 'bcm2835': return 1;
46 case 'bcm2709': return 2;
47 default: return 0;
48 }
49 } ());
Raspberry Pi 4 has a bcm2711, so I guess a line like:
case 'bcm2711': return 3;
has to be added after line 46 above. Not sure if that's all or more changes will be required.
Regards, Jaime-
@jimbotel
I was able to hack through the rpi-ws281x-native/lib/ws281x-native.js
and rpi_ws281x/board_info.c
files to get the lights working.
However, using BalenaOS like I am /proc/cpuinfo
has no records for hardware
, model name
or revision
in mine which are required by rpi_ws281x
.
I imagine this is an oversight on the part of Balena, considering the clear documentation here: https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md.
I posted the issue on the Balena forums: https://forums.balena.io/t/rpi4-proc-cpuinfo-missing-hardware-and-model-name/29080
BalenaOS Raspberry Pi 4 /proc/cpuinfo
processor : 0
BogoMIPS : 108.00
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3
processor : 1
BogoMIPS : 108.00
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3
processor : 2
BogoMIPS : 108.00
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3
processor : 3
BogoMIPS : 108.00
Features : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3
Hi @JeffJassky ,
It's great that you managed to get it working, congratulations! In my case I have the "official" raspbian distro from raspberry.org and /proc/cpuinfo shows at the end:
Hardware : BCM2835
Revision : b03111
Serial : 10000000bb3b2055
So, as the doc you pointed out mentions:
Note: As of the 4.9 kernel, all Pis report BCM2835, even those with BCM2836, BCM2837 and BCM2711 processors. You should not use this string to detect the processor. Decode the revision code using the information below, or cat /sys/firmware/devicetree/base/model
Even if rpi 4 has a BCM2711, the "Hardware" section says BCM2835
, and that's probably the reason why I didn't get the Could not verify raspberry-pi version
.
In any case, the right thing to do (as the doc mentions) is to use the Revision
, that's what's implemented in rpi_ws281x/board_info.c
. This doesn't work in your case either, cause you're missing the last 3 lines in /proc/cpuinfo
Regards, Jaime-
It looks like this method of determining cpu/hardware is not supported by ARM64 architecture. We may need to update these packages to officially support the ARM64 standards note: https://github.com/raspberrypi/linux/issues/2110
It seems we should be using something like these instead:
/sys/firmware/devicetree/base/serial-number
/sys/firmware/devicetree/base/model
/proc/device-tree/model
/proc/device-tree/serial-number
Hi there, sorry for the delay, I didn't find the time to have a look and write a response.
A few things to note here:
I didn't actually intend to continue supporting the current version for much longer, but I didn't get around to do more testing of the prerelease-version of the 1.0.0. However, if the current version is what you are using and that works for you, I am absolutely fine with merging any PRs and publishing new npm-versions for you.
I think we should completely remove the hardware-detection code from the javascript-side, as the master-version of jgarff/rpi_281x already does a good job providing the necessary safeguards
Also I wanted to move away from using my own fork of the rpi_ws281x-library, but there were so many upstream-changes by now that using that instead would have been too much of a change for my taste. So I did that for the 1.0 version (to be found here: https://github.com/beyondscreen/node-rpi-ws281x-native/tree/v1.x or via npm install rpi-ws281x-native@next
).
This new version also has new apis and binding-code that is significantly simplified, which - hopefully - will make upstream updates in the future easier to handle. Now, as @JeffJassky notes
I also tried using rpi-ws281x-native@next which resolves to @1.0.0-alpha1. That build failed miserably. Assuming that's not the one I should be using.
That's something I did not see happening, and I was hoping that indeed the new version should actually do a better job. Can you provide some more information what is going wrong there? Maybe we can figure that out together (as I've written before, I don't own a rpi4, so I never had the ability to test it myself..)
regarding the audio-interference issues, I never really took the time to look into it in more detail, I think I roughly understand what is happening, but I have no Idea if it is at all fixable, only ever found comments about that just being as it is 🤷♀.
Hi @usefulthink Thanks for your comments. Personally I do prefer a less fancy but more stable version of the code, I don't want to push you to a non-fully tested version. For the same reason I understand your decision to fork rpi_ws281x library. I did not test rpi-ws281x-native@next , nor the combination of rpi-ws281x-native + current jgarff rpi_ws281x-library, so I would suggest to move forward slowly. I can help with the testing -when I'm not traveling- Thanks a lot for your help.
I just tried to run some code using my pi4(8Gb) (the same code ran fine yesterday on a pi2B+) and got the following error
[rpi-ws281x-native] Could not verify raspberry-pi version. If this is wrong and you are running this on a raspberry-pi, please file a bug-report at https://github.com/beyondscreen/node-rpi-ws281x-native/issues A non-functional stub of this modules interface will be returned.'
after a bit of a poke around it looks like what is listed in the hardware field in the cpuInfo file on my pi (BCM2711), is not in the list in the switch in node-rpi-ws281x-native/blob/master/lib/ws281x-native.js
Hi @MrBim ,
Can you please try with this one and let me know if it works fine on your pi4(8GB) ?
git clone --single-branch --branch raspi4support https://github.com/jimbotel/rpi_ws281x.git
If it does, I'll do a PR to beyondscreen main branch with the changes.
Thanks!
Thank you for such a quick response, I pulled the repo, but I am using js to do everything in my current project.
I am super rusty with my python so it may take me a couple of days to get this tested.
In the meantime, I have managed to resurrect my work by adding the board as an extra case to https://github.com/beyondscreen/node-rpi-ws281x-native/blob/master/lib/ws281x-native.js (line 46/47)
Hi @MrBim , You can test basic functionality by compiling the code from rpi_ws281x directory (scons) and -assuming it is successful- then execute: sudo ./test
Hello, I'm trying to use a NeoPixel Diffused 8mm Through-Hole LED: https://www.adafruit.com/product/1734 on a raspberry 4. I tested some basic functionality ( brightness.js https://github.com/beyondscreen/node-rp ... r/examples ) and it gets stuck upon init() step, providing no clue of what's going on. However, using the same SD card from the RPI4 in a RPI3B+, everything works fine, so the problem seems to be related to the change in HW, but I cannot determine where it is. Can you please give me a hand with that?
Thanks, Jaime-