hey, im getting some interference of some sort from linking arduino nano (clone) HM-10 (BLE CC2541) and fastled (super newest library) [arduino ide 1.6.8]
if i run the cc2541 code on its own, i have no real issues. type AT and i get an instant response.
if i add into the code, the simple blink code, then the AT code returns ok, but in between the delays (as expected)
if i replace the delays for EVERY_N_MILLISECONDS (500) then i get artefacts in the results, “O�”
this is replicated with using the colour palettes example. i guess the fastled library is quite intricate with its timings, but is there a work around?
or a different way of giving my leds bluetooth ble control?
http://pastebin.com/veYt6Jgz
here is my BT handler (never tried it on BLE)
http://pastebin.com/pd5QKWHj
What are you wrapping in the EVERY_N_MILLISECONDS(500)? It’s not clear from what you posted to the pastebin. Also - replacing a 10ms delay with a 500ms in between doing stuff, effectively, no wonder you’re loosing stuff.
Also - you don’t mention what kind of LEDs you’re using - but if you’re using WS2812 style LEDs, then you’re going to have a problem here, as serial input relies on interrupts for reading data in and FastLED disables the interrupts while writing out WS1812 LEDs. If you use an arm based MCU then you have the opportunity to run with interrupts enabled - but you’re not going to be able to do that on an avr. Take a look at https://github.com/FastLED/FastLED/wiki/Interrupt-problems
@Daniel_Garcia this is my key!
the every_n_milliseconds was me testing the blink code, instead of using the delay to flash. my main code uses a lot of every_n_milliseconds and the disrupting has been happening.
and yeah, im using the ws2812b pixels, which might be the more core issue!
as a curious sidenote, the serial data isnt garbled when i only send 1 (i think) byte of data. so if i code the bluetooth to send single digits, then it works like 95% with no corruption.
which isnt the greatest way, but it kinda works :-/