You have to add that the STM32 processor still has some big advantages to the Kinetis MK66 and therefore is still the first choice for all future development of pin2dmd. There were a lot of problems we had to get around during the port due to the lack of peripheral functions in the kinetis mpu which speed up the processing of the data, but nevertheless it is working and took us only about 4 weeks to make it happen.

FYI:
Currently we are not able to release the pin2dmd firmware for MK66 because of the lack of information how to pack the firmware for the utasker bootloader (https://github.com/uTasker/uTasker-Kinetis) preloaded on DMDMK66 boards. The encryption option of utasker is activated for firmware updates and as long as we don´t have the encryption parameters (key, prime and shift value) the upgrade process is not at all user friendly and also not reversable. If pinballsp provides us the necessary information we can release the firmware almost instantly.

I released the PoC version of the firmware here https://github.com/lucky01/PIN2DMD/tree/master/firmware/latest/MK66
in case anyone wants to try out pin2dmd firmware on DMDMK66 hardware. Because of the activated code security on the DMDMK66
the conversion is not for unexperienced users. See instructions on github. Due to the lack of hardware support or differences in the
MPU peripherals not all pin2dmd features are supported (e.g serial side-channel for Stern SAM) but most should work just fine.

Although it uses almost the same components (M4 ARM CPU, RGB LED panels) it is very different on the software side. DMDMK66 is based on RGB.DMD from ecurtz which uses the smartmatrix library for the output part. I tried to use that code also for the output but soon found out that it not really suitable. Smartmatrix is very flexible but that brings a lot unneeded overhead. I ended up porting my own output routine to NXP MK66 which wasn´t as easy as I thought. One could think that both STM32F4 and MK66 are arm processors and should be able to do the same, but what makes the difference is not the core but the flexibility of the peripherals the processor offers. For example MK66 can only generate a single interrupt for a port group of 16 pins. Those ports then all share the same priority. STM32 can give different priorities to different pins and if you design it right this can be a big advantage in such a realtime application. Another example is the SPI interface. The NXP MK66 implementation is missing a lot of features like DMA doublebuffering, software slave select to clear the shift registers and support for both MSB and LSB slave input. Of course you can always rebuild the missing functionalities in software but that is just not the same when it comes to performance. Anyways I don´t think that this firmware will be of great use, because of the complicated installation procedure, but who knows. For me it was a great journey and helped me to optimize my own STM32 code because almost all had to be reviewed.

Just a quick test in my AFM