Most recent activity
-
Grabbed the latest in git (1v62) and the problem still persists. (Verified I'm running 1v62 by confirming some latest fixes.)
It occurs with an array of values on SPI1 pin A7. Works fine on SPI2 pin B15.
If I discard the first two bytes in the array (and effectively don't use the G and R colors in the first LED), all other LEDs work as expected.
-
-
Thx for taking the time. Most appreciated if you could try accessing the first LED in the string.
The data sheet did state GRB, which was my experience.
http://www.adafruit.com/datasheets/WS2812.pdfBut putting that aside; the real issue was the first two bytes in a data array being ignored. So in short, on pin A7 with SPI1, I can only set the first LED to intensities of blue (being that the G and R bytes were ignored). All other LEDs were fine (LED 2, 3, etc.)
On pin B15 with SPI2, everything was fine. But I need the SD; and the fun part here is accessing the SD generates an inadvertent light show. Lol.
It would be awesome if you could share you findings / code samples when you have a moment (with some WS2812B's in your possession).
Thank you!
-
So I'm using SP1 on pin A7 and here's what I'm observing.
Just using the code from the examples:
SPI1.setup({baud:3200000, mosi:A7}); // All good here
// Per the tutorial, the following should make LED1 red;
// but our WS2812 string is addressed GRB, not RGB, so it should be GREEN.
// Oddly it becomes BLUE.
SPI1.send4bit([255, 0, 0], 0b0001, 0b0011);// As noted above, our LED string is addressed as GRB when on B15 (this works fine).
// Below it gets weird in that this line makes LED2 GREEN (not LED1 RED).
// In other words, I've discovered on SPI1 A7 we cannot set the first two bytes.
// Everything is shifted two bytes over.
SPI1.send4bit([0, 255, 0], 0b0001, 0b0011); // Should be LED1 RED, but it's not!// So the above is really functioning as
SPI1.send4bit([x, x, 0, 255, 0, 0], 0b0001, 0b0011); // Where x are the untouchable bytes. -
-
-
Chip auto-detection would be awesome!
The new chip on our boards has been incredible. With uglify magnification, we're currently at about 12KB of JS and growing. And the Espruino platform has been performing like a champ.
We still pay very close attention to number of objects, concise well-organized code, etc. to utilize every bit of additional RAM. Just because we have double the size, we aren't wasteful.
Still, it really demonstrates the power and coolness of this platform.
Also note that we're employing some techniques with the SD and eval() to "swap-in/out" JS functions/objects. I'm sure something similar could be accomplished with the module cache; be we needed a custom implementation. This technique has really maximized the RAM and capability.
-
Also very interested in this, and ran across the same code.
Since there is no HTTPS, I'm interested in HMAC SHA1 to sign HTTP requests to our REST API. Similar to how Amazon does it here: http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html
I've done this in the past and it works real well if you cannot implement HTTPS; and given that your data is not sensitive. Just a little measure to keep any private API less public.
Would love if this was opened up to a class or function we can use.
Ugh.
It never works correctly on A7-SPI1 even when you just enter the code via the console. It does indeed work on B15-SPI2.
I am not using Wifi during the console testing; and unfortunately, the CC3000 has been soldered onto the board (and works). Hmm, tho our expert engineers did the work, perhaps the CC3000 is causing an issue?