Which SPI interface does the CC3000 use?

Does it use SPI1 or SPI3? (when connected to the Espruino board per instructions http://www.espruino.com/CC3000 )

This matters, at least as I understand things:
If the SD card reader is in use, that is on SPI2.
SPI1 can be on either B3/B4/B5 or A5,A6,A7.
SPI3 can only be on B3/B4/B5.

Thus, if we want to have both the SD card reader AND WiFi, if the CC3000 is on SPI1, there are zero available SPI interface, while if the CC3000 is on SPI3, we can still use SPI1 on pins A5-7.

It's on SPI1 - good point about this. I've created a bug for it. https://github.com/espruino/Espruino/iss­ues/237

Because SPI has a chip select line, you can still use the same SPI ports for other things as well (as long as you don't use CS, which is a standard GPIO) - so this isn't the end of the world at all.

Thanks :-)

I hadn't realized that SPI had a CS line - that makes some things easier (though it doesn't help if you want to drive WS2812's with that third SPI interface)

Glad I ran across this. We're trying to use WiFi, the SD, and drive a string of WS2812's. Having a bit of trouble. Any tips?

I'm looking into using the new software SPI class on another pin, such as A8; but having trouble getting it configured right. Help?

Gordon fixed this a while ago - it now uses SPI3, leaving the option of using SPI1 to drive the WS2812's off pin A7.

Software SPI doesn't help you - you need to be able to set the baud rate to control the WS2812's, but software SPI doesn't support that.

Thx for replying DrAzzy.

I'll go back to this approach (using A7). I did it earlier and got some strange results.

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.

Hm, I will see if I can reproduce that when I get home (right now I'm with family for the weekend, and I didn't think to bring any WS2812B's down. I have definitely driven WS2812's off A7...

I distinctly recall WS2812B's being addressed BRG...

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/WS281­2.pdf

But 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!

Are you using the latest version (1v61) of Espruino? There was a bug involving 2 characters being dropped in an earlier version...

So are you using WiFi/SD at the moment? Or do you get the issue with pin A7 even if you are not using those features?

This may be the culprit. I pulled 1v61, but before the SPI fix was applied. I'll get latest and build again. I'll post the results here. Thank you!

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.

I cannot reproduce your issue.

>SPI1.setup({baud:3200000,mosi:A7});                                
=undefined
>SPI1.send4bit([255,255,255,128,128,128,­255,128,255],0b0001,0b0011); //First pixel is white
=undefined
>SPI1.send4bit([255,000,255,255,0,0,0,0,­255],0b0001,0b0011);    //first pixel is Green
=undefined
>SPI1.send4bit([0,255,0,255,0,0,0,0,255]­,0b0001,0b0011);    //first pixel is Red
=undefined
>process.env
={
      "VERSION":"1v61",
      "BUILD_DATE":"Apr 10 2014",
      "BUILD_TIME":"16:10:27",
      "BOARD":"ESPRUINOBOARD",
      "CHIP":"STM32F103RCT6",
      "CHIP_FAMILY":"STM32F1",
      "FLASH":262144,"RAM":49152,
      "SERIAL":"34ffd505-41563235-08610743",
      "CONSOLE":"USB"
    }
>

Does it work when you're doing nothing other than driving the WS2812B's?

And yeah, it's GRB, not sure how I got it wrong above.

Ugh.

> SPI1.setup({baud:3200000,mosi:A7}); // OK

// First one blue, then almost white, blue-ish white, yellow/amber
> SPI1.send4bit([255,255,255,128,128,128,2­55,128,255],0b0001,0b0011);

// First becomes white, purple/pink, off, red
SPI1.send4bit([255,000,255,255,0,0,0,0,2­55],0b0001,0b0011);

// First becomes green, turquoise, off, red
> SPI1.send4bit([0,255,0,255,0,0,0,0,255],­0b0001,0b0011);

={
      "VERSION":"1v62",
      "BUILD_DATE":"Apr 22 2014",
      "BUILD_TIME":"16:28:21",
      "BOARD":"ESPRUINOBOARD",
      "CHIP":"STM32F103RFT6",
      "CHIP_FAMILY":"STM32F1",
      "FLASH":786432,"RAM":98304,
      "SERIAL":"3000d805-41413XXX-33481XXX",
      "CONSOLE":"USB"
    }
> 

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?

Weird. It looks like the two first bytes are being sent at the end....

But why isn't it happening to me?

Could it just be power supply issues? The WS2812s are really picky. Try putting a big capacitor and a 22uF ceramic across the power lines where the WS2812s are attached - and make sure the power supply can supply enough power.

Also check that Espruino shares the same ground as the LEDs - it's amazing how many people don't do that ;)

I've been playing with RGB123 arrays recently, and I find that it's at the stage where some USB phone chargers work and some don't - even when the display shouldn't be drawing anywhere near their peak current.