@Stuart_Taylor , welcome to the joys of being a small hardware company.
Are there any boards that are similar to the spark or the rfduino (aka combination of an ARM cpu and bluetooth or wifi technology?). If so, I can see about making FastLED available on some of them so that there’s more options available for folks in Europe.
@Daniel_Garcia what normally happens is Schenzen gets a hold of it, and starts cranking them out for $5 delivered. Of course they are just looky-likey and never work to spec.
At least the genuine teensy3.1 is now available here.
What’s your opinion on the electric imp? Worth putting on the list for porting? It does appear to be a cortex-M3 base - but not a lot of information on specifics. It also seems to be cloud-based for dev/upload, which while great for projects is such a pain in the ass for library development.
(Ah, nice. The electric imp uses an ARM core that’s in the same family as the spark core, so much of the porting work is “done” already. Of course, how much do you want to bet that the electric imp’s cloud based IDE integration is going to be even more of a pain to deal with/support than spark’s?)
I really don’t know. It’s a cool platform, especially if you intend making something that someone who isn’t so technical may use - such as a set of Christmas lights for a relative - they can get it on the internet simply and you can maintain it remotely.
Maybe you should speak to them, they seem pretty decent guys. I noted that most/all the Adafruit LED hardware is now loaded to the hardware driver library, but as a complete (and rank!) amateur, I have no idea how easy it would be to integrate.
It would be nice to only have to use one MCU and it is a bit of a waste using a whole Imp just to tell my Arduino what to do, but c’est la vie. I am using $4 Nano’s, so it isn’t so bad - just have to piss around with 3.3V<>5V conversion
Honestly, given my experiences importing and attempting to debug and bug fix FastLED on the spark core, I’m not entirely sure I want to add a second web-ide environment to my setup.
Seriously, the cycle of fix code, check in, re-import, re-validate, remove library from app, add library to app, compile, see build errors, run the whole cycle again is, well, let’s just say mindblowingly fucking irritating is me being polite.
@Daniel_Garcia I would avoid the imp. It has its place in this world, but yeah you are tied to a cloud based ide and its pairing is done via flashing LEDs 0.o
I think the concept is great, in that my grandmother could probably get some code working on the imp, and have it locked into ITTT but for those of us who like to talk to the hardware, and not some abstraction, your polite anecdote about the dev cycle on the spark, also holds true for the imp
That said also, the hardware underneath the spark core seems pretty solid, and there are a lot of boards or there that seem to use some variant of the stm32, so doing this work will be worth it for that. I’m also being fairly liberal in passing along issues to the spark core folks (mostly for things that I’d need in place to continue maintaining the library on the spark core/photon).
Sadly, while I suspect that my personal spark core dev will be using the command line, I can’t claim to support spark core unless the library works from the web ide.
(Minus the flashing by literally flashing leds)