Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow Puck.js to drive Neopixel/WS281x/APA10x RGB pixels #1023

Closed
gfwilliams opened this issue Jan 13, 2017 · 14 comments
Closed

Allow Puck.js to drive Neopixel/WS281x/APA10x RGB pixels #1023

gfwilliams opened this issue Jan 13, 2017 · 14 comments

Comments

@gfwilliams
Copy link
Member

This might be solved with the addition of: #695

But we need to test.

@MaBecker
Copy link
Contributor

Hi Gordon,

tried this simple code to control some neopixels with a Puck, expected to have eight white leds, but did not work. I guess there is something wrong with the code I am using.

var LEDs = 8*3;
var SPI1 = new SPI();
SPI1.setup({baud:3200000, mosi:D1});
var rgb = new Uint8ClampedArray(LEDs).fill(25);
SPI1.send({data:rgb,count:LEDs});

@MaBecker
Copy link
Contributor

Oh completely forgot about that NPs need special timing like used with

SPI2.send4bit([255,0,0], 0b0001, 0b0011); 

Can the ESP8266.neopixelWrite() be implemented as NRF.neopixelWrite() to handle this ?

@MaBecker
Copy link
Contributor

Have a workaround for now: Puck - USART - ESP8266 - Neopixel

Also started to port ESP8266.neopixelWrite() to NRF.neopixelWrite().

  • stuck with the asm stuff

  • what are the equivalent calls for:

    GPIO_REG_WRITE(GPIO_OUT_W1TS_ADDRESS, pinMask);
    ets_intr_lock()
    ets_intr_unlock()

could need some help ....

jswrap_puck.h.txt
jswrap_puck.c.txt

@gfwilliams
Copy link
Member Author

It's probably better to do as suggested in this bug, and to just enable the full-speed SPI write - in which case the code from your 2nd post should work.

Disabling interrupts on nRF52 can be a bit iffy, as the radio gets upset (I think there's a watchdog timer).

DMA SPI would be perfect, but there's a big in the nRF52's hardware which means that single-byte SPI writes fail via DMA, so to get it working I'll have to make a special SPI function that falls back to non-DMA for single byte transfers :(

@MaBecker
Copy link
Contributor

Ok, I understand - Dropped the idea of implementing NRF.neopixelWrite()

@gfwilliams
Copy link
Member Author

Just FYI - I have this done now - just waiting to check on licensing of the code I'm using before I commit it.

I'll be adding E.neopixelWrite which'll work the same on all platforms.

@MaBecker
Copy link
Contributor

Wow - this is so cool - Thanks !

@MaBecker
Copy link
Contributor

@gfwilliams Is there something you want me to change for ESPs ?

@gfwilliams
Copy link
Member Author

Nope, it should be fine - I moved the code around so E.neopixelWrite is added for it too, and ESP8266.neopixelWrite just forwards to E.neopixelWrite for compatibility.

When I commit it'd be great if you could test though, just to make sure I didn't break anything :)

@MaBecker
Copy link
Contributor

sure, I can test

@MaBecker
Copy link
Contributor

ran some test - works perfect - thanks !

@gfwilliams
Copy link
Member Author

Great - thanks!

@MaBecker
Copy link
Contributor

MaBecker commented Mar 1, 2017

One more point to add, this will cause confusion:

Write to NeoPixel/WS281x/APA10x-style LEDs attached to the given pin

this function can not handle APA10X, because they need two data lines.

APA's need SPI :)

@gfwilliams
Copy link
Member Author

It's unfortunate - I guess I'll have to spell out the part numbers individually, APA104 are fine: https://groups.google.com/forum/#!topic/atxhs-discuss/r_bGlXBZC-E - as are some other APAs as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants