Hi, I’m wondering if the USART SPI is supported on Arduino by the library.
In the wiki under FastLED Design in section “Hitting the watertables, platform specific interfaces” it says “In addition, there’s an SPI controller that does bitbanging, and finally, there are plans for SPI controllers that use the SPI mode in a variety of MCU’s USART controllers as well, to provide more options for hardware accelerated output of led data”. Now my question is, is the USART SPI supported by the library? Is it already implemented? And how can I test if the library uses bitbanging or hardware SPI? I want to make use of the second SPI on the ATmega328. I’m using an LPD8806 strip and it has no CS pin. I want to use the native SPI port to communicate with other chips. Most libraries only support the standard SPI and not the USART SPI. If FastLED would support UART SPI I could just use that for my LED strip and there would not be the need to change any libraries to work with the USART SPI.
Helpful comments with references are appreciated.
Hm okay. That’s a pity. Then I think I will use the LED strip on the dedicated SPI port and try to make my other components work on the USART SPI.
Thank you for your advice. But I only use the Arduino for prototyping and I intend to put the mega328 in a circuit later, so the 16u2 won’t be there anymore. And since the ATmega328 has 2 SPIs, why not make use of them? I think its doable to make the USART SPI work though (from the sketches I have seen so far). I could either modify the FastLED library to work with USART SPI or other libraries I intend to use. Or maybe I design my circuit that way, that I use bitbanging first but use the USART SPI pins. And when the FastLED library gets updated I can make use of the USART SPI without modifying any libraries. Hm. I’m not sure yet. I will figure it out.
Yeah maybe I can have a look at that, but I’m not sure if I know how to update the FastLED library. If so, I will share my work.
I have the beginnings of the code in there, but Haven’t had a chance to finish it. I’m working on a bunch of hopefully quick things right now so I can see if I can get that in and working.
In the meantime, FastLED will silently switch over to using bitbang’d SPI if it doesn’t find any hardware options on the pair of pins that you give it. So you can just use the pins that the UART SPI would use for now and the only thing that will change is at some point the data will get written out faster 
That’s just a shortcut. If you name the hardware clock and hardware data pins it will automatically flip over to using the hardware SPI.
actually, I’m going to put a fix in that will allow you to use the miso pin however you want even when using the hardware SPI pins so that will be a non-issue. (That change is already done on the teensy 3.x side).
Is it documented somewhere that the library automatically switches to hardware SPI when defining the pins manually but the pins are the pins of the hardware SPI? That was confusing me. I was not sure if the library only makes use of the hardware SPI if you use the short version FastLED.addLeds<LPD8806, RGB>(leds, NUM_LEDS);. Someone could think that when you use the longer version with defining the pins, always bitbanging is used (even if you define the pins of the hardware SPI).
It was at one point but a lot of that documentation is currently being redone, so that may need to go back in there (But the library is named FastLED for a reason - it uses the fastest way to talk to your leds on whatever set of pins you give it It makes sense to me though, if you use the hardware SPI pins, it will use hardware SPI, if you don’t use the hardware SPI pins, then it will bitbang.
Thats right, I was also thinking that it would do that since it is named FastLED and the project cares a lot about making things fast. But I was not sure, since I didn’t find anything concrete on that. So maybe it would be a good idea to mention that again in the updated documentation
Well, this is irritating. I have the USART SPI output working on atmega328p based boards (I just have to get the clock speed selection code working, now and then I will check it in on the 3.1 branch). The USART SPI pins will be 1 for data and 4 for clock (PD1/PD4)
However, on the Leonardo, someone decided, in their infinite wisdom, to wire the XCK pin to the TX LED on the board. In other words, you can’t get at the clock pin on the leonardo. (This appears to be true for all the 32u4 based boards, including the Yún).
So, no USART SPI on any 32u4 based arduino.
Awesome that you made it so fast. And that with the leonardo is really dumb. But at least it is available on the atmega328p now/soon
Note that the Teensy 2 and Teensy++ 2 do support USART SPI mode on pins 8/23 and 3/5 respectively. https://github.com/FastLED/FastLED/wiki/SPI-Hardware-or-Bit-banging breaks down what pins on what boards use what SPI hardware.
(It is available now on the FastLED 3.1 branch)
Thank you so much!
No, you can’t on the Mega - because the mega doesn’t expose any of the XCK pins. As for the 16u2 - PD5 is the XCK line and that doesn’t appear to be exposed for the 16u2 on this pinout - https://raw.githubusercontent.com/wiki/NicoHood/HoodLoader2/pictures/pinout.png
Unless somsone buys/ships me a seeduino mega, I’m unlikely to add support for it - I’ve got enough boards here that I brought one or two of for testing but aren’t ever going to actually use in a project. Especially since for that price, people should just use a Due.
I suspect you can, I haven’t tested it at all yet however. There shouldn’t be other pins affected. And right now I don’t have it set up so you can toggle between USART mode and SPI mode, so you can’t use it as an RX. (That’s doubly true if you’re expecting to be able to receive data in the background/by interrupt).
Also, something to remember, the USART is what’s used by Serial on the Atmega328p based arduinos. So if you’re hanging leds off of it then you lose the ability to do Serial.print(…) and friends
Oh, also - I can’t do a shortcut for a second set of pins - the existing shortcut works because there is one set of hardware spi pins used, so that set of pins gets put in when you don’t specify pins.