For my edification... about what timing does the WS2812 need, and is that an example of where time diverted for an ISR can't be tolerated so interrupts have to be disabled briefly?
According to the Adafruit suite, the neopixels need 800 Khz (the earlier version based ont he WS2811 need 400 Khz), and looking at the code, it disables interrupts before starting to update all of the leds (which are done in a serial fashion), and interrupts are enabled after all of the pixels have been updated.
The code uses assembly language for the AVR to minimize any timing issues. They use different asm code for 8Mhz and 16Mhz AVRs and for the older 400 Khz WS2811 vs. the 800 Khz WS2812s.
For the Arm case, Paul has contributed special code for the Teensy 3.0, and if it isn't Teensy, it assumes it is a Due. Unlike the AVR, it looks like it is mostly C code for the arm.
Now presumably the native cpu on the Galileo is fast enough, but the problem is
ALL of the GPIO's are done via a Cypress i2c expander, and the Cypress i2c port expander that does all of the I/O can only run at 100 kHz (the Galileo processor itself can also run i2c at 400 kHz). But even at 400 kHz, it is not fast enough, since each i2c transaction presumably takes a few bytes over the wire. The neopixel documentation says that other Linux systems on a chip like Rasberry Pi, Beaglebone Black, pcDunio, etc. have similar limitations, and that you really need a dedicated 8Mhz or faster microprocessor.
In addition, since the LED state is kept in memory (at least 3 bytes per pixel), you have problems if you want to have more than a 100 or so lights on small memory systems like ATtiny85 systems (digispark, trinket, gemma, etc.).
The software versions of serial, pwm, servo, and spi drivers would also have problems, in that the drivers have to match an external timing spec. In a few cases, you could use the hardware version, but a lot of times in Arduino land, people fall back to the common denominator and do software bit banging.
