Having trouble starting off with WS2812
Mike Green
Posts: 23,101
I'm new with BlocklyProp and SimpleIDE and thought I'd start with a strip of WS2812Bs and an OLED on an Activity Board. I've done the basic "Hello World" with just SimpleIDE, then with BlocklyProp and all worked well. I then tried to light up a single WS2812B and it didn't work ... lit some colors ... not what I wanted ... sometimes didn't light up at all. I tried a string of 8 with 7 of them dark. It didn't work any better. The OLED worked fine. I've checked connections. The string of 8 had been used before with Spin. Attached is the C code.
c
2K
Comments
Delays added to BlocklyProp/C didn't seem to help.
Shouldn't be too hard to move it from a C++ class to a C struct with related functions, but as always, let me know if you need help with that.
https://github.com/dbetz/flames.git
Click on the "hamburger" menu on the far right and go to "my projects". Find the project and click on it.
Then, scroll down and choose "shared". Save it and copy the URL here.
- Ken
- Ken
I had gone through the 3 tutorials on the WS2812.
I added a 100ms delay after initializing the WS2812B driver. The C code attached in the first post doesn't have this.
I'm using an Activity Board WX with the WiFi Module plugged in and configured for AP+STA, but otherwise not used. Power comes from one of your Li-ion Power Packs.
A couple of thoughts here:
- 5V or 12V version? They're very dependent on an exact power supply
- The OLED setup line should be on the top of your code
- Reduce this back to something very basic, controlling one LED first -does it work with a single LED?
- Try a small pause before the Update block
And I'll check back to see if any of these ideas helped.
Also, there's something that really messed me up with the WS2812s. It's the color of their wiring. At the moment I forgot what it was - but I think green was the signal line and white was ground, or something like this. Check carefully because this caught me more than once.
Ken Gracey
With a direct 3.3V output, you need to keep the connections to the strip pretty short. I have a lot of custom PCBs that are designed to drive servos and/or WS28xx LEDs in which I deploy the TC4427 MOSFET driver to create a stiffer 5v signal to the device. I have found, on occasion, that the capacitance of the solderless breadboard can create problems, too. Best to go from the pin through a 470 ohm resistor to the strip (signal input).
I'll try moving the OLED setup line later today
I've tried it with a single LED ... same behavior
I'll try the additional pause too and let you know
The LED(s) are soldered to a substrate without wires attached. The single LED has male headers attached for breadboard use. The 8 LED strip has half of one of your servo/sensor 3-wire jumpers attached. In both cases the wiring has been checked multiple times and works fine with the Spin test program.
Thanks
Thanks JonnyMac for the suggestion. There's only about 4-5" between the LED and the Propeller pin. I'll keep that in mind for the future.
Clicking Deny may limit the application’s behavior. This setting can be changed in the Firewall pane of Security & Privacy preferences.
(Deny) (Allow)". No matter which response I use, this window will disappear then reappear a few seconds later. Downloading still works.
As you build your program back into what you want it to be, check it at every step and find out where it breaks. That part will be useful information to us, as it could expose an issue with this particular series of blocks.
I'm wondering if that OLED Init block was causing a problem with it's placement outside of the top.
Ken Gracey
If I can get to test it, I'm going to try first to eliminate the 100ms delays before Update
Are you using BlocklyProp to download via WiFi and have this problem with the PropLoader prompt?
What about wired with a USB cable? Any problems there?
I'm going to have Jeff get a look at this.
Ken Gracey
I'm using a MacBook Pro (late 2016, 13") with MacOS 10.13.1 (High Sierra beta)
I haven't seen that specific message, but it sounds like it's macOS's firewall getting in the way. The strangest part is "incoming network connections." BlocklyPropClient receives network communication from the local browser (running BlockyProp), and also transmits information back to the local browser that way - if it were blocked by a firewall, it shouldn't work, but this is saying "proploader" and not BlocklyPropClient. PropLoader is part of the BlocklyPropClient, and certainly requests network access (for Wi-Fi module use), but it shouldn't be accepting unsolicited network traffic, but certainly directed network traffic. When BlocklyProp checks what ports are available, it does so through BlocklyPropClient, which checks with PropLoader... so it makes sense at that point for a firewall message to be displayed the first time PropLoader is run, but I'd expect it to accept your (Allow) response and stick with it, never bothering you again. The behavior you're experiencing with that dialog sure sounds like a bug in macOS to me.
I'm glad to see that downloading still works. I'd expect wired connections to continue to work, but Wi-Fi may or may not work depending on what's going on with the macOS firewall. You may have to go to the Firewall pane of Security & Privacy preferences to see what it says about PropLoader and adjust it to allow network communication always.
Just so you're aware, PropLoader communicates with networked Wi-Fi modules by broadcasting a "discovery" packet on your local subnet and looking for responses from networks Wi-Fi modules. If you've selected a "Wi-Fi" module port in BlockyProp (or SimpleIDE), it will talk directly to that Wi-Fi module via it's known IP address (not broadcast, and must be on local subnet). The PropLoader never tries to communication outside of your local subnet (ie: it doesn't try Internet addresses, just local network addresses) and it shouldn't listen to incoming network traffic except that which is directed at it's own IP address (your Mac's IP address on your local network) and to it's network port (which is port 32420... conveniently the stock code of the Wi-Fi module itself, unless you've configured it to use a different network port).
From your message, it sounds like it's downloading just fine, no problems except an annoying prompt from macOS. Please let us know if that's not the case.
I do wish PropellerIDE's loader (Mac version) would get fixed. It seems to work ok for small programs, but consistently fails with near 32K programs (probably timing). Tachyon Forth is one that I rarely can download. I have to fall back to an HP Netbook running Linux to download non-trivial Spin stuff. I should try proploader maybe on the binary files