I’m going a bit crazy. I’m trying to use an Ethernet Featherwing powered by a Teensy 3.2, connected to a Teensy Prop LC. I am able to read UDP packets up until the first call to FastLED.show(), and then I can’t read any more from the Ethernet side of things, but LED updates continue to work fine. I’m using SPI transactions, and putting the CS LED pin high and low. Here is a gist of the simple example: https://gist.github.com/jerrytron/376e4f57264ed36a135f94942e5f3e4e
Also, the FastLED library, Ethernet library, and SPI library are all the latest I found in the PJRC repositories. PLEASE help!
Sigh. NO idea why it is posting a GIANT image of my avatar… Apologies.
What is the purpose of the SPI transaction code that FastLED.show() is sandwiched in?
First off, how do you have things wired - most led chipsets don’t recognize the CS pin, so unless you have something in place to recognize it, and cut off clock/data to the ethernet and leds as appropraite, it won’t mean much.
The other thing is FastLED configures SPI at the start of every call to .show() and then uncofnigures it at the end (it does this to support things like using hardware SPI on 4 combinations of pins on the teensy 3.x even though there’s only one hardware device). My guess is that the ethernet library doesn’t expect to share the SPI configuration - or at least isn’t expecting the SPI hardware to be shut down when it tries to do its thing, so it just falls over.
The transaction code is for getting the right SPI settings in place for the LED work, as the Ethernet is doing the same for its work. I’m using a Teensy Prop LC shield as mentioned, which provides a CS pin for the LEDs (pin 7). From what I can tell, the PJRC Ethernet library is setup to play nice with other slave SPI devices.
Also note, on the Teensy Prop website, it provides the code snippet of using SPI transactions if you are using other SPI devices. Here is the page: https://www.pjrc.com/store/prop_shield.html
@Daniel_Garcia Do you know if your concerns are true for the existing PJRC ethernet library? https://github.com/PaulStoffregen/Ethernet
Ah well. I guess you just can’t use Ethernet and control LEDs at the same time on a single SPI channel. This is a real bummer.
It’s possible that there are changes I can make to how FastLED is driving SPI to make it friendlier in environments like this - but I’m not really doing active work on the library at the moment, so I couldn’t make any promises as to when I’ll have that fixed/working.
@Daniel_Garcia Fair enough. I’m just confused because everything I’m reading says this should work. They both have CS pins I’m putting up and down correctly (tested each independently to be sure) and both appear to be good SPI citizens (though I’m not an expert there). I’m guess the second one is where the flaw is… but if so, it is too deep for me. I’m working around the problem at the moment.