Някой да се е сблъсквал с портване на Codesys runtime към микроконтролер? На сайта си твърдят, че имат работещи портове за Cortex M4/M7.

Работи си на всичко, вкл. и на по-малки от Cortex-M4. За 8-битови нямам данни, но преди 20 годин го пускахме на 16-битов микроконтролер.
Иска си ресурс като РАМ и ФЛАШ, но в областта на стотиците килобайти, като много зависи какво искаш да включиш. Цялото е като компоненти и си гласиш какви да сложиш в платформата, като например лиценз мениждъра може да глътне 4 мегабайта флаш. Разни мрежови стекове и секюрити протоколи по презумция си искат място и няма алтернатива.
Предполагам, знаеш че там се лицензира с royalty - т.е. плащаш малко кинти за всяка бройка устройство, отделно имаш и солидна такса да почнеш (десетки К евро). Поне така беше преди години.
Яко е защото необходимо ако ще влизаш на пазара на индустриални PLC-та и подобни - но не е достатъчно условие да почнат да купуват твоето. Там са закостенели потребители и трудно сменят вярата, или дори вендора.
Напоследък все по-рядко го ползват на микроконтролери - цените на линукс-базирани въшки паднаха до такава степен, че нищо не пестиш. Разните екстри като по-добър real-time или бързо стартиране рядко могат да убедят някой клиент да си зареже комфорта да им има мрежова връзка. По-бързите задачки не изискват такава гъвкавост на програмиране и са fixed function устройства с определена степен на конфигурируемост. Има и програмируеми на други езици, и тия с кодесиса взех(ме) да ставаме редки динозаври.
Колкото и да не е, самият им рънтайм си хапва ресурс и от CPU-то, езикът и компилатора им не е на нивото на модерните C/C++ toolchain-и и нишата им става доста тясна.

Благодаря за информацията. Нашите клиенти искат определен продукт (с mimxrt1166) да може да се програмира с codesys. Продуктът има доста компоненти - дисплей, PWM, аналогови и цифрови входове и изходи, CAN, RS485 и други.

Не ми е ясно как става самото портване още, но не съм се ровел из това, за следващ проект е. Интересува ме codesys върху съществуваща апликация ли "стои" (например codesys библиотека извиква определени функции за пин контрол, които клиентът трябва да подаде).

Да, горе-долу е така. Реално е компилатор от IEC езиците към конкретна архитектура - не минават през C. Мъчат се да генерират машинен код и един от компонентите се води "компилатор".. Вътре е компонентно-ориентирана архитектура като те доставят голям брой компоненти и отделно продават още.
Има два типа "runtime" (това, дето тича на PLC контролера, другото е "IDE"-то дето е на ПЦ-то и компилатора). Единият рънтайм е за големи ОС-ове - LInux, винбоуз, мисля че имаха и QNX. Там ползват динамично линкване (DLL/SO) и всеки компонент е динамична библиотека (има опция при билдване на runtime варианта да се вкарат определен набор базови компоненти в самия рънтайм, за да не се бави зареждането). Има си скелет за компонент, разни описания в XML, използват GNU m4 за сорс код темплейти и т.н.
За микроконтролери е другия рънтайм - там няма динамично линкване, всичко се компилира монолитно във фирмуера. Кодът на компонентите съдържа доста предкомпилатор и m4 темплейти за да са абстрактни и да могат да се ползват и на двата вида рънтайм (през компилаторски дефиниции).
Ценното е че си е доста завършена платформа с удобен дебъг, визуализации и т.н. Имат екстри, които в индустриалните приложения са важни - например, можеш да подмениш един компонент с друга версия/вариант без да спираш останалата част от програмата.
Ако клиентите ти го искат, имай предвид че не е евтина платформа, т.е. не излиза сметката за дребни серии - ако ще е нещо под няколко хиляди на година няма и да ти обърнат внимание (имат royalties, т.е. плащаш някаква сума за всяка бройка от твоя контролер). За ориентировка - при малки серии могат да ти поискат 100-на еврата на бройка за лиценз - като независимо от това ще ти поискат 10-20К евро за начални лицензи, SDK, и т.н.
Ако не си голям играч опцията е RPi или beagleboard - там си продават лицензи на дребно, ама виж каква е цената в store-а им в момента.

За портването - както при повечето PLC–та, вход/изходите са мап-нати като битове и байтове - т.е. нямаш API "SetOutput" и да го имплементираш с твоя HAL. Всъщност, то си има и такова ниво в софтуера, но потребителите виждат I/O image - което се очаква да се опреснява от базовите ти функции, а PLC кода вижда тези данни и работи с тях. Стара и ръждива концепция, но това очакват PLC програмистите. Навътре из софтуера, ако тръгнеш примерно от порта за STM32, ще видиш как се ползва HAL-а на ST и съответно можеш да го подмениш с друг (NXP примерно).
За по-сложните (и нови) неща ползват "модерния" OOP подход и е през API-та, които са просто изгъзица спряма класическите API-та за мрежи, файлови системи и т.н.
Постарали са се едва ли не да дублират разните API-та от големите OS-ве - имат си техен тертип за TCP/IP, за сериен и т.н. За твоята платформа трябва да адаптираш NXP кода да имплементира техните интерфейси - това го правят за да имат стабилно API което не зависи от производителя на контролера.
По-рано правеха компоненти на C/C++ и за по-високото ниво - например MODBUS, CANopen и разни етернет интерфейси. Последните години се опитват да изместят фокуса и да пишат все по-голяма част от кода на IEC езиците (structured text основно). Т.е. по рано имаха C имплементация на Modbus master, който викаха от IEC кода. Сега Модбъс мастъра е написан на IEC/structured text и пак се вика и ползва от приложението. Искат да изчистят още повече от native кода. Не им се получава съвсем, защото компилаторите им (от IEC/structured text към машинен код) не могат да се мерят с оптимизациите на модерните gnu/clang и сие - накрая кода им си е по-бавен, което не пречи на клиените им - те си харесват другите предимства.

За imxrt ще е микро рънтаима и монолитен фирмуер - т.е. ще трябва да дадеш библиотеки/сорсове за компонентите за I/O - нищо инвънземно като задача, имайки предвид че ще имаш и документация, референтни имплементации и съпорт (срещу споменатите NN K евро). Една от референтните платформи е STM32H753I-EVAL, което трябва да е близо до твоето.