$30 ‘Leonardo with wifi’
I’ve received but haven’t starting playing with the DFRobot “WiDo”, which is basically a Leonardo with wifi (and an SD card slot).
http://www.dfrobot.com/product/product?product_id=1159
It uses the WG1300 chip and an updated version of the Adafruit CC3000 driver library[1]. The wifi and SD card use the hardware SPI pins; LEDs will have to hang off other pins – or fight it out with device-select-fu.
I haven’t fired it up yet, but for US$30, I can see a whole lot of potential use-cases for these – especially if it can be made to play nice with FastLED.
-M
[1] The Adafruit CC3000 wifi library lets you read and write semi-asynchronously, but the ‘connect’ method is synchronous – so you can’t easily keep LEDs animating while you make network connections. Also, I have no idea what the interrupt situation is, but the wifi might or might not play with the disabled interrupts. We have a future feature release coming for FastLED that may help address the interrupt situation, but it ain’t here yet.
I haven’t even hooked this up yet and I’m starting to be dissatisfied with the sample code already.
#IWillNotWriteFastWiFi
#IWillNotWriteFastWifi
#IWillNotWriteFastWifi
So bad 
I was already replacing all my home lights with led strips 
After trying this with the Yun (same thing, but $70), I can tell you it’s a dud. By the time you use 1500 bytes of the Leonardo’s memory for the leds array, the library which talks across to the wifi microcontroller won’t run for lack of RAM.
The wifi sketch upload is nice if your piece is wall mounted and inaccessible though.
What do you htink about the DigiX ? It should be able to manage wifi AND leds, isn’t it ?
Sure, but it’s seventy bucks! I’m still really looking forward to the RFDuino support, in the hope its 8k is enough that it can walk and chew gum at the same time.
I like the DigiX, but again, there’s that synchronous networking library problem. I mean srsly, it’s not like a microcontroller might be controlling anything.
I have lost count of the number of Arduino-connected devices that I’ve had to re-write the library for to make it asynchronous. Either two or three. I’m dragging my feet on wifi integration because of this.
#IWillNotWriteFastWiFi
#IWillNotWriteFastWiFi
#IWillNotWriteFastWiFi
Isn’t the synchronous networking library problem only a problem when using strips based on tight timing, unlike the LPD8806, for example? I would be happy if you library only supported it, in the WiFi version, if that would make the WIFI support possible. And that’s of course because it’s what I got.
And it also the same problem with the Spark Core? (I assume that…)
Well yes and no. I was particularly referring to the scenario that I have in mind where there’s some 30-updates-per-second animation running, and you want to retrieve information from the web and keep the animation running. If the retrieval takes even just one second (ha!), the animation locks up.
What I want is an API that instead of “connect()” [and wait blocked synchronously for it to connect], gives me something like “beginConnecting()” and returns right away, and I could then poll once each time through loop() with something like “isConnectedYet()” until it is – and in the meantime I could keep animating the LEDs, which is after all te most important thing above all else.
So is the only answer to make a hybrid, like the Electric Imp, where the Imp does all the IoT/Wifi stuff and talks to your Arduino over i2c or serial or similar, leaving it to handle the animations uninterrupted (sic)?