Having trouble starting off with WS2812

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.

Comments

  • 21 Comments sorted by Date Added Votes
  • Mike GreenMike Green Posts: 22,584
    edited September 30 Vote Up0Vote Down
    I've tried again with the Spin demo programs for WS2812B and they work fine. Sometimes the BlocklyProp/C program works fine, mostly I get a quick flash, then nothing. I'll try inserting some delays.

    Delays added to BlocklyProp/C didn't seem to help.
  • WS28xx timing is pretty fussy. Is it possible that the C translation of the WS28xx is running in LMM mode and having timing problems? I grasping at straws because I don't know how C works on the Propeller.
    Jon McPhalen
    Hollywood, CA
    It's Jon or JonnyMac -- please do not call me Jonny.
  • Mike, here's a manual conversion of JonnyMac's WS28xx Spin object to C++: https://github.com/parallaxinc/PropWare/blob/develop/PropWare/hmi/output/ws2812.h
    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.
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    Tag me with "@DavidZemon" if you have a question for me. I will be checking these forums far less for the forseeable future.
  • There is some ws2812 code in this project I did a while back to use a strip of ws2812 LEDs to simulate flames.

    https://github.com/dbetz/flames.git
  • Can you post a link to your BlocklyProp code too?
  • Ken, How do I get a link to the BlocklyProp code?
  • Mike Green wrote: »
    Ken, How do I get a link to the BlocklyProp code?

    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, here's the link.

    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.
  • I don't have all the right parts at home to fully test this, but I can tomorrow afternoon at the office.

    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
  • Mike Green wrote: »
    Ken, here's the link.

    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.

    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).

    Jon McPhalen
    Hollywood, CA
    It's Jon or JonnyMac -- please do not call me Jonny.
  • 5V version

    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
  • I moved the OLED setup to the start of the program and added 100ms pauses before each Update. With those two changes the program worked as expected. 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.
  • One more odd behavior ... I'm using MacOS High Sierra (10.13.1). BlocklyPropClient is running in the background. Safari is running BlocklyProp which is connected to the client and I'm downloading compiled programs and I get a window "Do you want the application “proploader” to accept incoming network connections?

    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.
  • Mike, we also suggest Chrome as the browser for BlocklyProp. It has proven far more reliable at handling the core Google blockly engine.

    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
  • Chrome doesn't seem any better for BlockyProp than Safari. The problem with proploader seems the same and I haven't been able to download the program to my ActivityBoard this round of testing.

    If I can get to test it, I'm going to try first to eliminate the 100ms delays before Update
  • Mike, need a bit more information.

    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 haven't tried to download via WiFi. The Activity Board is attached via a USB cable (USB-C adapter to cable to Board). This has worked many times before with PropellerIDE and SimpleIDE although fails to download successfully with PropellerIDE on large programs (32K-ish, Tachyon Forth for example).

    I'm using a MacBook Pro (late 2016, 13") with MacOS 10.13.1 (High Sierra beta)
  • Mike Green wrote: »
    One more odd behavior ... I'm using MacOS High Sierra (10.13.1). BlocklyPropClient is running in the background. Safari is running BlocklyProp which is connected to the client and I'm downloading compiled programs and I get a window "Do you want the application “proploader” to accept incoming network connections?

    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.

    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.



    Jeff Martin
    Parallax Inc.
    (916) 624-8333 x3002
    jmartin@parallax.com
    http://www.parallax.com
  • Mike GreenMike Green Posts: 22,584
    edited October 2 Vote Up0Vote Down
    I wouldn't be surprised if this were a bug in this beta version of MacOS, but it is triggered by something that proploader is doing. In the IP address box in BlocklyPropClient, there's "0.0.0.0". I don't know what that means.

    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
  • Interesting ... If I run proploader from the command line (Terminal), it seems to work fine. Can PropellerIDE be changed to use proploader?
Sign In or Register to comment.