FastLED doesnt work with Arduino MKRZero

[javierru3]

I tried to compile a working program with FastLED and Arduino UNO/Pro Mini on MKRZero and it doesn't work. I become the following warning:

warning "No pin/port mappings found, pin access will be slightly slower.

and a lot of compilation errors that didn'nt appear when i choose UNO in Boards. It's Known when Arduino MKRZero will be suported? Could i help in the process? or it's easier to rewrite the program without Library?

[Daniel-dk]

the MKRZero has a SAMD21 ( ARM ) on it, not a Atmega 328 ( Uno / Pro mini )
if the pin/port mapping is differnet from the arduino Zero You'd have to add the pin and port difinitions to the files in FastLED\platforms\arm\d21

if they are the same then you can simply use the Zero as your board selection
( dont have time to add it at the moment, might get some near the weekend to check pin/port mappings for Zero vs MKRZero )

[javierru3]

Thanks I will try to do it! If the pinports in Zero and MKRZero are the same, I shouldn't have problems if I compile the program with zero configuration... Am I right?

[javierru3]

Hello,
I have been trying for a while to compile my Skript using Zero as my board selection, and it works, with the only problem that the pins on Arduino IDE arent the same as in the board.
I would like to use the SD slot on my MKRZero, but since i am not using the MKRZero as a board selection i can not use the MKRZero command "SD.begin(SDCARD_SS_PIN)" there is a way to know which CS should i use to select my sd card?

Daniel: I tryed to add the pin definitions to FastLED but i havent the needed knowledge :/
Thanks

[WyattJordan]

javierru3

Did you ever figure out how exactly the FastLED\platforms\arm\d21\fastpin_arm_d21 file needed to be changed? I just ran into the exact same problem as you and have done a TON of work on a project that requires the MKRZero to use the FastLED library (with the SD card) and would greatly appreciate a solution if you found one, thanks!

[WyattJordan]

For anyone who runs into this problem in the future I found a solution. Go to the FastLED\platforms\arm\d21\fastpin_arm_d21.h file and add this code as one of the platform pin mapping cases:

#elif defined(ARDUINO_SAMD_MKRZERO)
#define MAX_PIN 22
_DEFPIN_ARM( 0, 0, 22); _DEFPIN_ARM( 1, 0, 23); _DEFPIN_ARM( 2, 0, 10); _DEFPIN_ARM( 3, 0, 11);
_DEFPIN_ARM( 4, 1, 10); _DEFPIN_ARM( 5, 1, 11); _DEFPIN_ARM( 6, 0, 20); _DEFPIN_ARM( 7, 0, 21);
_DEFPIN_ARM( 8, 0, 16); _DEFPIN_ARM( 9, 0, 17); _DEFPIN_ARM( 10, 0, 19); _DEFPIN_ARM( 11, 0, 8);
_DEFPIN_ARM( 12, 0, 9); _DEFPIN_ARM( 13, 1, 23); _DEFPIN_ARM( 14, 1, 22); _DEFPIN_ARM( 15, 0, 2);
_DEFPIN_ARM( 16, 1, 2); _DEFPIN_ARM( 17, 1, 3); _DEFPIN_ARM( 18, 0, 4); _DEFPIN_ARM( 19, 0, 5);
_DEFPIN_ARM( 20, 0, 6); _DEFPIN_ARM( 21, 0, 7);
#define SPI_DATA 8
#define SPI_CLOCK 9
#define HAS_HARDWARE_PIN_SUPPORT 1

I went through and did all the mapping and turns out its the same as the #elif defined(ARDUINO_SAMD_MKR1000) case, you just need to make a case for #elif defined(ARDUINO_SAMD_MKRZERO)

Also turns out the WS2812B LEDs can run off of a 3.3V signal so you don't need a logic converter between the MKRZero and the LEDs, cheers!

[ubidefeo]

@WyattJordan thanks for this, I was wondering why it worked on the MRK1000 and not the ZERO (we also ran into some pin mapping issue with the Feather M0, same SAMD21).
It would be nice if you could issue a Pull Request for this, unless the developers already implemented the definition (in the PlatformIO version it's not working yet)

[rogertheriault]

Thanks. Only one line needs to change, since the settings are the same

 #elif defined(ARDUINO_SAMD_MKR1000) || defined(ARDUINO_SAMD_MKRZERO)

[adidahiya]

Thanks @WyattJordan and @rogertheriault.

For the MKR WIFI 1010, the code change is:

#elif defined(ARDUINO_SAMD_MKR1000) || defined(ARDUINO_SAMD_MKRWIFI1010)

[tigoe]

It seems to work well with:

````

elif defined(ARDUINO_SAMD_VARIANT_COMPLIANCE)

````

as well. All the MKR boards in the SAMD core of Arduino feature that particular define, so it should work for MKR Zero, MKR 1000, MKR 1010, MKR 1400, etc. I've only tested with the Zero, the 1000, and the 1010, though.

[ubidefeo]

thank you @tigoe for pointing this out.
I've always manually defined ARDUINO_SAMD_MKR1000 when using FastLED in the past.
It's nice that such define for generic SAMD exists :)

[tigoe]

Don't quote me on it though, Check with @cmaglie to be sure.

On Fri, Jan 11, 2019 at 2:06 PM Ubi de Feo [e-mail] wrote:

thank you @tigoe https://github.com/tigoe for pointing this out.
I've always manually defined ARDUINO_SAMD_MKR1000 when using FastLED in
the past.
It's nice that such define for generic SAMD exists :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/FastLED/FastLED/issues/414#issuecomment-453623574,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAXOn2NsWwePtT0hWvil2bSzS3g5cd48ks5vCOC0gaJpZM4MNWQ5
.

--
Tom Igoe

[ubidefeo]

@tigoe @cmaglie I went to check the builder's verbose messages and found that ARDUINO_ARCH_SAMD is defined during build (-D ARDUINO_ARCH_SAMD) hence this should be generic enough, but I haven't found trace of the definition you mention.
I've tested in Create production but not in the Java IDE

[tigoe]

Yours is probably more correct, then. I was using the Java IDE, FWIW, and
found it in the variant.h file of the samd core.

t.

On Fri, Jan 11, 2019 at 4:41 PM Ubi de Feo [e-mail] wrote:

@tigoe https://github.com/tigoe @cmaglie https://github.com/cmaglie I
went to check the builder's verbose messages and found that
ARDUINO_ARCH_SAMD is defined during build (-D ARDUINO_ARCH_SAMD) hence
this should be generic enough, but I haven't found trace of the definition
you mention.
I've tested in Create production but not in the Java IDE

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/FastLED/FastLED/issues/414#issuecomment-453665852,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAXOn-_TVGqUgXlxNzmjuBZdgQGYoyXMks5vCQULgaJpZM4MNWQ5
.

--
Tom Igoe

[matthijskooijman]

But wouldn't using such a generic define mean you will apply the same pinout to all SAMD boards? Maybe all current SAMD boards use the same pinout, but this might not be true in the future (and it would be better for the compiler to throw an error on new boards that might or might not be supported, than to have no error and have Fastled toggle the wrong pins).

If one would want to catch all boards with the same pinout, than a define that identifies the variant used could be appropriate (since typically all boards using the same variant use the same pinout), but I'm not sure if the variant is available in a define? Also, there is nothing that would stop variant files from subtly modifiying the pinout based on other defines, so only checking the define might not be sufficient either (in the future).

[ubidefeo]

@matthijskooijman all MKR boards have the same pinout and quite a high level of customisation to add/re-route SERCOMs and other hardware.
Different boards which have extra modules (Vidor, GSM, LoRa and so on) are connected to extra hardware using the other pins of the chip not routed to the main headers :)

[tigoe]

For example, the SD on the MKRZero is routed to a different SPI SERCOM, if I recall correctly, which is why it works with the generic define, I assume.

@matthijskooijman's approach is a valid, conservative approach, though. It takes more maintenance, but it means any exceptions that pop up in the MKR line in the future are more likely to get addressed.

[elektrowolle]

Nobody is talking about this anymore, but I made a fork a year ago, changing it exactly as @adidahiya did 00f17a84dab9105e40d0632ae614e90b034c75fb. Worked fine for me on many devices so far.

[tigoe]

Just ran into a student from someone else's class that was trying to use this library with one of the MKR variants, and found it didn't work still. We had to modify the lib using #elif defined(ARDUINO_SAMD_VARIANT_COMPLIANCE) again. So it seems that these changes haven't yet made it to the current version.