Digistump Forums
The Oak by Digistump => Oak Support => Topic started by: cpetito on February 04, 2016, 09:30:32 am
-
I've been playing with my new OAK with neopixels and found an interesting issue with pin names using this library: https://github.com/Makuna/NeoPixelBus. I believe that the Adafruit library will behave the same: https://github.com/adafruit/Adafruit_NeoPixel
The neopixel data line is connected to my OAK on pin 5.
The issue is that the NeoPixelBus library uses pinMode() and digitalWrite() to configure the OAK pin 5 port for output properly, but then requires the ESP8266 GPIO pin 4 to transmit the data on this pin.
My fix was to remove the library port setup and do it in the sketch setup() using the OAK pin name (5) and using the GPIO pin name (4) in the NeoPixelBus constructor.
Comments and/or a better solution will be appreciated.
-
Is the issue related to this statement in the library files...
"Arduino NeoPixel library
ESP8266 CUSTOMERS PLEASE READ: While this branch does work with the esp8266, due to the latest SDK releases it will not function reliably when WiFi is being used. Therefore I suggest you use the DmaDriven or UartDriven branches, which both include solutions that will work with WiFi on. Further they contains enhancements that just can't be supported on AVR platform. Including HslColor object and an enhanced animator manager."
If so, have you tried the other branches?
I have used the Adafruit NeoPixel lib on other other non-wireless platforms. The only wireless one that I've used prior to Oak is the DigiX. If the ESP8266 requires a work around, I would love to see what you have done to make it work as I'm sure other would too.
-
I'm not sure if the FastLed library will help there, but they support ESP8266 and neopixels so it might be worth giving it a try : https://github.com/FastLED/FastLED
-
I am no expert here. I'm a "jack of all trades and master of none", so weigh the following accordingly.
I found that the neopixel libraries referenced previously set up the control pin with the standard Arduino pinMode() and digitalWrite() functions and using the OAK port numbers work as expected, but that the ESP8266 implementation of the transmit data uses the GPIO port names.
Looking at pins_arduino.h in the OakCore/variants/oak/ repository I found the following mapping comment:
///0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
//uint8_t esp8266_pinToGpio[12] = {2, 5, 0, 3, 1, 4, 15, 13, 12, 14, 16, 17};
Using this mapping it told me that if I wanted to connect the neopixels to OAK pin 5, the corresponding ESP8266 GPIO designation was 4.
With this information I believe that the following will work without any modification to the libraries, For example, using the Adafruit library.
Assuming that you are using OAK pin 5 to control the neopixels, call the constructor with the corresponding GPIO port number, 4 (see mapping above):
Adafruit_NeoPixel strip = Adafruit_NeoPixel(1, 4, NEO_RGB + NEO_KHZ800);
Then in setup() make OAK pin 5 an output and restore OAK pin 4 back to an input if desired:
pinMode ( 5, OUTPUT );
digitalWrite ( 5, 0 );
strip.begin();
pinMode ( 4, INPUT ); //the constructor and begin will set this up as an output, change it back to an input if desired
strip.show(); // Initialize all pixels to 'off'
The above changes worked with Adafruit's strandtest example.
And if you are interested in controlling neopixels via WIFI, check out: http://pance.mk/index.php/wifi-light-with-esp8266-and-arduino-code/
Again, comments, corrections and/or a better solution will be appreciated!
-
cpetito,
Thanks for the info. I was poking around trying to understand the issue after your initial post and did see the pin to gpio mapping for ESP8266.
Thanks for the detail. As soon as I get my Oak running, this will be on my list to try.
-
Hi guys,
I was reading this with interest as I had tried to compile the example code that is given in the DigiLED tutorial and upload to one of my Oaks - it would compile, but the DigiiLED wouldn't change - with the additional info that @cppetito had found, I finally got the code working - the DigiLED has the option of working with Oak pin 1 (default) or Oak pin 5 - both options are covered in my updated code here (will update the tutorial shortly): https://github.com/ajpowell/OakSamples (https://github.com/ajpowell/OakSamples)
I may refine the code a little - could easily perform the map in an array, so you specify the Oak pin, but it works out the GPIO port in code.
-
Great to see some discussions on Digital Pixel LED strips being controlled by OAK via various libraries.
I'm still waiting for my OAKs to arrive, but keen to start reading up on my options ready.
Does anyone know which of these libraries already support RGBW strips? (32bit per pixel instead of 24bit). I figure if my preferred library doesn't already support it, I could hopefully cannibalise it to work alright, but better to start with existing proper supported code if possible by choosing my library carefully at the start! (how do I pick?)
Is anyone here using any of these libraries with the Oak Level shifter shield?
Anyone planning to use any of these libraries with Blynk to get wifi control over the colours, patterns and speeds?
Finding out which libraries are most popular here with OAK users, and will work for my needs (RBGW strip, Blynk & Level Shifter), and being used by others here for similar needs, might help me pick between the libraries, and mean more of us can help each other.
Can't wait to get my Oaks!
Mike
-
Has anyone successfully run the Adafruit NeoPixel strand test on their Oak? Tried but failed. BTW, I was using the Level Shifter 3 pin screw terminal that brings out Pin 5 for DIN, PWR and GND for the strip. Powered the Oak and Level Shifter (at 5v) through the 2 pin screw terminal. In this configuration I was able to run a simple LED flash sketch but not the NeoPixel strand test. I'm using an RGB-123 8 LED RGB strip on a PCB. I've run this successfully on an UNO in the past.
-
NeoPixel strandtest running successfully (and using the Level Shifter shield)...
Config:
Oak BETA 3 firmware, 0.9.3 package.
Adafruit NeoPixel 1.0.4 lib. Turns out I was running an older version of the lib when I thought it was the latest. Was only made aware of this because the Arduino IDE informs which lib it's using when multiple are found.
Level Shifter and Oak powered through Level Shifter 2 pin screw terminal PWR and GND via a 5V 750mA wall wart.
Connection to RGB LED strip through Level Shifter 3 pin screw terminal 5V - P5 (to DIN) - GND.
An finally the part I don't get, using the workaround posted by cpetito http://digistump.com/board/index.php/topic,1984.msg8888.html#msg8888
I don't get that part, I thought that pins_arduino.h for the Oak variant was suppose to make this transparent.
In any case no brick.
-
Oh well... Update: I think it's bricked after running for 15 minutes straight. What post had Erik's dump instructions? I would like to verify that it is indeed bricked, dump memory and provide the dump and sketch to digistump.
-
FALSE ALARM... Cycled power and it started again. Going to look into why it may have stopped. loop() is forever right? ???
-
In theory yes. Curiously I have an Oak set up to allow controlling two servo motors. To invoke the change I use curl. The output I get back includes json that has an item called "connected" which is always either true or false. Curiously I have noticed that after an hour (or some indeterminate time so far) it starts returning "false" for this item. The strange thing is that the servos correctly move to the new position I sent so it is obviously connected. Not sure what this field exactly represents. Another question I have had is whether you can place the code you have inside loop() { ... } inside a while (1) { ... } clause. Sometimes this can shave off a few cycles inside the loop by not wasting a constant exit of loop() and consequent wrapping call back into it. I haven't been brave enough yet to try this yet on an Oak to see ;)
-
That's interesting. If you going to use while() inside loop(), why not just put a while() in setup and never leave setup() or enter loop(). Don't know the background but perhaps setup() and loop() in the Arduino world are just there to provide a simple construct for initialization and running code forever.
-
Totally agree. On the semantic level that we all understand setup() and loop() what you suggest works great (and does on original uno's although you need to supply the (declared but undefined) loop() definition even if it's empty). But am I am curious as things start to become "Arduino compatible" with serious amounts of non-Arduino activity possibly going on in between, whether this will become a frailty in the future due to unknown but required processing that goes on in-between the calls to loop().
-
NeoPixel strantest ran overnight. On to trying the DS18S20 Temperature probe and Particle.variable to for logging on particle.io.
-
similar to the Particle devices and other ESP8266 devices - if you have a while() loop you need to periodically call delay() or Particle.process() to keep the cloud/wifi working during that.
-
Great to see some discussions on Digital Pixel LED strips being controlled by OAK via various libraries.
I'm still waiting for my OAKs to arrive, but keen to start reading up on my options ready.
Does anyone know which of these libraries already support RGBW strips? (32bit per pixel instead of 24bit). I figure if my preferred library doesn't already support it, I could hopefully cannibalise it to work alright, but better to start with existing proper supported code if possible by choosing my library carefully at the start! (how do I pick?)
Is anyone here using any of these libraries with the Oak Level shifter shield?
Well looks like FastLED doesn't yet support RGBW strip, but it is on the radar for future development:
https://github.com/FastLED/FastLED/issues/106
NeoPixel and NeoMatrix support RGBW strips, so they look like the obvious starting point for now...
-
This worked for me -- note the use of: esp8266_pinToGpio[NEOPIXEL_PIN]
#include <Adafruit_NeoPixel.h>
#define NEOPIXEL_PIN 6
// How many NeoPixels are attached to the Arduino?
#define NUMPIXELS 8
Adafruit_NeoPixel pixels = Adafruit_NeoPixel(NUMPIXELS, esp8266_pinToGpio[NEOPIXEL_PIN], NEO_GRB + NEO_KHZ800);
void setup() {
pinMode(NEOPIXEL_PIN, OUTPUT);
digitalWrite(NEOPIXEL_PIN, LOW);
//set up neopixel
pixels.begin();
}
void loop() {
delay(1000);
// For a set of NeoPixels the first NeoPixel is 0, second is 1, all the way up to the count of pixels minus one.
for(int i=0;i<NUMPIXELS;i++){
// pixels.Color takes RGB values, from 0,0,0 up to 255,255,255
pixels.setPixelColor(i, 0, 255, 0); // Moderately bright green color.
pixels.setBrightness(50);
}
pixels.show(); // This sends the updated pixel color to the hardware.
}
-
Just to Update this topic a bit. Using Oak with 1.0 Firmware. Loaded Arduino 1.6.8 on Windows 10 64 Bit machine. Fought w DigiLED a bit till I discovered the pin remapping noted by cppetito. I am using AJPowell's implementation of the workaround (see below) posted by cpetito http://digistump.com/board/index.php/topic,1984.msg8888.html#msg8888 (http://digistump.com/board/index.php/topic,1984.msg8888.html#msg8888)
I have the level shifter shield and it worked but was not necessary. It has a nice 3 wire servo pin set for Oak Pin 7. This maps to GPIO pin 13 on the Acorn module. You only need 5V, Ground and a digital pin output for the DigiLED and, by extension, for the strings of LEDs the Adafruit NeoPixel library will drive. I got this working first on Pin 5 from the level shifter, since that seemed the most direct application of ajpowell's code from his GitHub collection (Thanks, AJ). While the shifter might be a wise choice for a multi light system, the Oak provides 5 V pins as VCC if driven by 5V via USB and the application worked fine without the level shifter. Wired VCC, Ground and Oak pin 7 directly to the 5V, Ground and Pin 1 pin of my DigiLED shield with jumper wires. The 3.3 V max digital signal out to the DigiLED was more than enough to provide a binary stream to program that device. Don't try this non level shifter approach with input pins or if you are trying to drive a load, but as a digital signal or logic bit, don't always need to shift the level up in logic applications. I didn't bother to change the GPIO pin number back to input after the NeoPixel library did its thing but should to keep pins low and have fewer positive voltage pins/headers unused. Now hopefully I will remember this possible numbering conflict for other possible apps.
So my (hopefully) useful additions: Besides Pin Oak Pins 1 and 5, Pin 7 works fine (by sending PIN 5, 4 and 13 to the NeoPixel Library). By extention, most any of the Acorn digital pins can be used. There is a nice table of these mappings at the bottom of the pin out diagram that DigiStump published (and I ignored too long)
Oak Pin to ESP8266 GPIO Mapping
Oak Pin P0 P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11
GPIO 2 5 0 3 1 4 15 13 12 14 16 17
From <=pinout]http://digistump.com/wiki/oak/tutorials/pinout?s[]=pinout (http://digistump.com/wiki/oak/tutorials/pinout?s[)>
- Level Shifter worked w DigiLED but was not necessary. The colors were muted without shifter but logic worked. Same 5V source in w and w/o shift
- Arduino IDE 1.6.8 has been working fine for me on Win 10.
- Adafruit NeoPixel Library 1.0.4 needs the GPIO pin number sent to it and then use the corresponding Oak Pin number set to output
Now I have to try AJPowell's other examples and get the Particle cloud working for more than uploading...
Hi guys,
I was reading this with interest as I had tried to compile the example code that is given in the DigiLED tutorial and upload to one of my Oaks - it would compile, but the DigiiLED wouldn't change - with the additional info that @cppetito had found, I finally got the code working - the DigiLED has the option of working with Oak pin 1 (default) or Oak pin 5 - both options are covered in my updated code here (will update the tutorial shortly): https://github.com/ajpowell/OakSamples (https://github.com/ajpowell/OakSamples)
I may refine the code a little - could easily perform the map in an array, so you specify the Oak pin, but it works out the GPIO port in code.
-
I keep seeing cool Connectivity methods in various threads. Starting one thread to track them might work but could get polluted quickly - it could become a WIKI section. It occurred to me putting a unique string once per Thread where stuff works could at least allow a forum Search to work.
NeoPixel::OAK_CONNECT
-
I got the Sparkfun 5v addressable strips (https://www.sparkfun.com/products/12025) working with FastLEDs on the Oak. A few notes:
- I had to use FastLED master branch, not the official 3.1 release.
- I am driving the LED strip with pin 3. That's the only pin where the pin number and GPIO match up exactly, according to this: http://digistump.com/wiki/oak/tutorials/pinout
- I am running the FastLED "cylon" example on a 1m strip . Looks pretty sweet.
- I am powering both the Oak and the strip in parallel with an external 5V regulated power supply. I've got the power supply hooked (via barrel jack) to a protoboard power/ground bus that then connects to the Vin and GND pins in the middle of the Oak. The LED strip is also connected (in parallel) to that power/ground bus. The plan is to allow the LED strip to draw as much current as it needs without pulling it through the Oak.
Finally, and I doubt this is Oak related, but when I wired in the resistor recommended here ( https://learn.sparkfun.com/tutorials/ws2812-breakout-hookup-guide/hardware-hookup ), it gave me a lot of problems. It seems like it was interfering with the data signal. The LEDs would come on, but were not following the correct color pattern. I tried 220Ohm like suggested and eventually moved down to something like 47Ohm. I'm very new to this and maybe 47Ohm is worthless for the intended purpose, but anything higher than that caused issues.
-
I'm presuming that because the data signal from the Oak is at 3.3v and the LEDs are expecting 5v, that too high a value of inline resistor causes the signal to not get through reliably. Someone else will be able to better explain if that is indeed the correct reason, and if so the maths behind it.
I haven't got round to trying mine Oaks with my neo-pixels yet, but glad to hear it is working without a level shifter attached. (I bought 2 of the level shifter shields from Digistump in case they were needed for controlling neo-pixels, so I can save them for a different project now).
Mike
-
Best bidirectional level shifter ever