Що така? Нещо специфично ли е за зигби-то? За другите (индустриалните) си е приличен софтуер.

За бии-то... за една шепа сорс, такива глупости са натворили, че не е истина просто
чипа има РОМ и ФЛАШ, в ром-а са набутали части от драйверите... един вид closed source
и за да се "линкнат" с код и библиотеки .... мааазало ... иначе се свежда до инит на 2,3 пойнтера към таблици - да знае ром-а кво да прави

линкер-скрипта е темплате, CCS стартира едни JavaScript кодчета а те от едни конфиг подмушват в линкер-скрипта, секции, константи... динамично - няма краен файл
Почвам да налучквам (портвам го за GCC) ... и супорта ми вика - ами то зигбии е ограничен САМО за TI компилатор (собствена изгъзица на це-ланг) и TI-RTOS
убуу - тоя RTOS се използва само за превключване на два таска с помоща на два блокиращи семафора .... само ДВА семафора, нищо повече от ОС-а !?!?!
... дай да го портна ... и греда
не стига че използва на CCS Java глупостите, а и "изкуствено" дъмпват едни ЕЛФ файлове да си вземат 3 константни таблици с които да инициализират ОС-а,
който половината е в РОМ, част в ЛИБ и част в код... и на всичкото отгоре сложили и някъв XDC tool (квото и да значи това)
с който предефинират типовете .... int на xdc_UInt, a SDK-то обръща xdc_UInt на UInt
общо взето 4 гиги SDK ( и още толкова CCS и компилатор ) .... срещу 50 меги мой порт

за ся съм под крушата ( VScode / GCC + FreeRTOS ) - стига до JOIN и "гасне" - някъв сетинг или логика пропускам ... супорта мига на парцали и вдига рамене

На тексас SDK-тата са така от много години - доста много инструментариум около самия сорс - тия код генератори, инструменти за платформи и много други дивотии. Като казвам много години, говоря за 20+ - разните там GEL скриптове и многото автоматизация. Налагало им се е тогава за да могат да направят гъвкава и удобна развойна система, но се е получило нещо, дето работи само в контекста на техния use case. Средатата им (CCS) от много отдавна трябва да може да работи с много ядра паралелно, да синхронизира зареждане на разни инициализации и да прави последователност между разните ядра - например, закачи се към power management ядрото, поцъкай малко регистри през скрипта да пуснеш тока на други ядра и периферии, после се закачи към security ядрото, зареди му фирмуер и поговори и с него да го уговориш да не те изплюе, после се закачи към "нормално" апликейшън ядро, ама преди това инициализирай външни памети че да заработи.
За да могат да ги правят тия неща са си направили тоя фреймуърк XDC, които недолюбваш. Там имат абстрактни описания на хардуерни платформи, и на софтуерни компоненти, и могат да генерират проекти, линкер скриптове и хедъри/сорсове. Като цяло е твърде тежко за прости приложения, ама те допреди да изкарат MSP430 и после cortex-m3 от luminary купените, нямаха прости приложения
Туй с ром-а е също типично - слагат код в РОМ защото е по-евтин и лесен за защита, и после им се налага да мислят как евентуално да фиксват бъгове по-късно - т.е. да могат да пачват тоя ром с код във флаш. Имат си основание, щото разните стекове може да са няколко стотин кила и отгоре, и явно откъм РОМ е по-изгодно. Навремето слагаха на luminary-тата в РОМ библиотека от сорта на HAL (сега модерно му викат CSL - chip support library), и просто даваха линкер файл с адресите на функциите в РОМ-а, а ти си свободен да ги ползваш от там, или да си ги компилираш във флаша и да не ги ползваш (или смес от двете).

Незнам дали си гледал energia.nu - това им е arduino поддръжката за някой техни чипове (там по разните launchpad китове основно). Ако са си свършили работата добре, може там да има разни скриптове или нещо, което да е "липсващото звено" между класическото им СДК и ардуино-подобни платформи: https://energia.nu/ Гледам че има поддръжка за CC13xx, има и нещо за zigbee booster pack, но там сигурно е интерфейс да го ползваш от отделен апликейшън процесор: https://energia.nu/pinmaps/#_32_bit_cc13xx
Тука е ардуино core-а за CC13xx: https://github.com/energia/cc13xx-core

мдам ... и аз с "налучкване" (TIRTOS) ми остана да "попълня" една таблица a а тя ми изрева за 3,4 липсващи функции... и го заебах
енергия-ардуино ... стигнали са до радиото и са го заебали
демек клати пинове като бейсик ардуино борд

баси ... глей ко правят
API_foo(X) -> sendMessage() -> case: message -> semaphore(block) -> call ROM_Foo() -> ROM A=X, RES = OK, semaphore OK - END return result
абсолютно "линейна" операция, блокирана със семафор да сетнат пойнер А=Х
абсолютно линеен зи-стек ... прост супер луп ... и за два ненужни семафора слагат цял RTOS

BTW: даже не е РОМ фунцкия а прекомпилиран ЛИБ без сорс код

и сичко заради цялата горна "концепция"

Ех, грознично е това. Но е странно - мисля си че някой външен е правил "сглобката" - обикновено много стрикно си следят да няма такива неща. Имат си най-ниския слой дето е тоя CSL и той е без никакви OS-ове - в проектите му викат таргет "NORTOS", после имат техния SYS/BIOS като RTOS (който последната година го зарязват и го подменят с FreeRTOS), отделно има линукси драйвери примерно, който добавят точно ОС специфичен код, но отдолу викат функциите от CSL-а.
В определени случай цената на "концепцията" някой трябва да я плати - може би "липсите" като функционалности за оптимизация, които да открият този "олекотен" случай, са причината. За да може да работи оптимално и в двата случая, автоматиката трябва да успее да познае какви са условията в конкретния случай, а това иска, от една страна, информация в "проекта" (сорса) - да се знае кое в какъв контекст работи и има ли много тредове, и от друга, инструментите да могат да употребят тая информация. То това е и целия напън за нови езици и моделиране (пак езици) - да бъде по-ясни детайлите и да може инструментите (компилатора) да хваща такива ситуации и да ги оптимизира.
Якото е че са от малкото вендори, които имат bare metal и rtos съпорт за ядра като Cortex-А9/A15/A53/A72, и то не само РТОС но и мрежа, и файлови системи - повечето фирми намират някой да им портне линукса и дотам. А още по-мързеливите портват само андроид и викат "че то туй ни е таргет маркета".
Забелязал съм че при TI върви и един друг модел на работа - знам за няколко фирми, дето от нищото се закачиха за TI и предлагат определени специфични софтуерни решения, или по-точно интегрират за тексаски платформи. Т.е. тексас се навиват да плащат на такива фирми за да подкарат някакъв интересен софтуерен "продукт" (стек примерно) и после да поддържат. Ако ти е интересно можеш да ги видиш дали няма да искат да направиш нещо за тях. За тях е важно когато някой прасне в гугъл примерно "zigbee gateway" да изскочи техен референтен дизайн или нещо подобно, което да спечели клиенти да купуват TI чипове. Това, че другите товарят отгоре лицензи не им пречи - за разни неща дето съм проучвал "3rd party" фирмата казва "20000 еврака за лиценз" за да си легален - като искаш ползвай референтния дизайн дето има и схемите, и платките, на TI нищо не дължиш (купуваш чипа, разбира се), и на нас кихаш тия кинти. Отделно, за съпорт също плащах на третата фирма.

сигурно затова не ми дадоха контакт с девелоперите ... а да искам менъджер за "безаналогови, перспективни" идеи - просто става затворен кръг: тикет-форум-фае-тикет...
то в началото сигурно е било "просто" ... и самата компилация също го прави "просто"
впоследствие някой "индиец" го е разтегнал колкото да си взима заплатата

днес се пернах до zigbee2mqtt coordinator GCC+FreeRTOS ама настъпих пак мотика с OSAL-Timers абстракцията
тва ако тръгне чисто - Ардуино class попълва 3 таблици ZCL "инфо" и врътка 3,4 узер кoлбeка ... една педя сорс

ESP ще има Zigbee стек ( ZBOSS )
https://www.prweb.com/releases/espressi ... 263163.htm

тръгна
LoRa STM32WLE5JC

те така https://www.youtube.com/watch?v=qBeKqtzVa8E

Абе човек, евала, ти портира повече платформи за ардуино от всеки друг на тая планета! Изкарваш ли нещо от това, или го правиш за удоволствие?
Питам сериозно - имам някаква идея за нещо индустиално, което да се популяризира чрез даване на достъп на аматьори да пишат на ардуино или блокли. Сорсове, тулчейни и документация всякаква ще осигуря, като целта е да се върти setup() и loop() примерно, и да се закачи през API достъп до функционалостта на системата. Самият код е лесната част, но интеграцията в средата си го борил за ардуино и PlatformIO. Имаш ли интерес към такава задача да измислим задание и да кажеш глобата?
Даже по-скоро си мисля бидлването да е в облака - за да може да се следи кой какво прави и да се пази кода от опити да се пробива към неразрешени функции (дето ти е любима задача ). Попадал ли си на такъв модел някъде - билд процеса да е опакован и да се случва онлайн?

общо взето - плачевна история...
честно казано "големите" фирми са стиснати на тема Опен Сорс ... "Ардуино" ... етц ... от тях и едно "Благодаря" не дойде
меринджейте им са "артисти", а девелопърите лежат на: бах мааму - тоя ни резна заплатите...
за повече от 4 години на какви ли простотии не "чух" ... пример: $soft -> гаден хакер щото пуснах Ардуино за АжурСфера и "хакнах" линукса ... след една година го направиха как аз исках
с Расбери Пико -> "бил съм Трол !?!?" ... имаме 1 годишен срок - след около 6 месеца почвам да ги "ям" ... иначе 70 на ден го теглят ( ГитХъб статистика ... шот )


изкарал съм има няма ... 100$ ... "бирени" пари -> почерпка от фенове

ма кат имаш идея - пиши - все ще измислим нящо

Hack the Planet
Arduino clientSecure ( SSL ) с Quectel M66

Направо завиждам като чета как ги портвате тези проекти за разни платформи и как работят след това ...

Не знам само ако трябва да се направи крайно изделие с така портнатия код и да се произведе в десетки или стотици хиляди броя какъв ще е крайният резултат.

От нещо да тръгне, до нещо да работи наистина стабилно и както се очаква - според мен разликата е огромна.

Гледам на колегите като им дадат да добавят нова функционалност в съществуващ проект - фокусират се, намират местото където да се закачат и лепват новия код.
Чисто логически - програмата е ОК, но при изпълнение в реално време стават доста изненади, трудни за откриване и фиксване ... Кода на новата функционалност променя всички тайминги защото докъто се изпълнява - забавя хода на изпълнение на цялата система - и стой та гледай ...

За да се свърши работата както трябва - според мен трябва да се познава изоснови цялата програма, кое колко време отнема за да се изпълни, какъв е времевия запас на цялата система и т.н. ... Т.е. да се познава изоснови цялата програма не само логически, ами и времево... (говоря за системи в реално време - независимо дали с или без RTOS)

Евала

малко философия...

специално за горния "хак"
този модул използва SoC Mediatek MT6261 - това е най-продавания GSM 2G SoC в света ( много над милиард бройки ... ако ти говори нещо Nokia фенерче ... до сега)
та този SoC има Mediatek SDK, който обслужва 99% от софтуерната реализация
ВСИЧКИ жълтури използват Mediatek SDK + техните си реализации в случая с модула дабавени са само едни AT команди и малко плюс...
този ПЛЮС е OpenCPU ( автор неизвестен - не е китаец ) - демек едно орязано узер API дето ти дава възможност да пишеш С апп вътре в модула ( по подобие на "Змията Хапе" )
и тъй като жълтурите пари за софтуер не дават това API-OpenCPU е copy/paste без развитие сорс код от преди 10 години
и тоя дето го е мислил не е добавил SSL-а, който го има в кернела ( Mediatek SDK ) и РАБОТИ под формата на AT команди
аз просто го изведох ( 16 функции ) и го реализирах във формата на стандартна Ардуино библиотека
кода: https://github.com/Wiz-IO/framework-wiz ... ntSecure.h

BTW днес реверснах хардуерната ( SoC ) реализация на LCD ... ST7789/ILI9341 ( 320 / 240 ) ...
извади 7 фрейма в секунда ( сигурно ще извади повече фреймове, но жълтурковия кернел ме ограничава )
в тоя SoC има над 10 чипа дето реализират "Nokia фенерче" ... LCD, Keyboard, SD card, MP3...MP4 декодиране, FM радио...
които реално не се използват като GPRS модул с АТ команди

аз лично никой не карам да използва мой сорс код - има си жултурково SDK ( уж за професионални цели или АТ команди от преди 30 години технология )

относно IoT проекти в "реално време"
IoT и реално време звучи като да управляваш 1 кВ режеш лазер с Линукс
"Controlling a laser with Linux is crazy, but everyone in this room is crazy in his own way... " 2006, Linus Torvalds
няма IoT датчик, процес или протокол дето му трябват микро-секунди синхронизация за изпращане в ефира ( изключвам драйвери )
TCP/UDP сокети, MQTT, SSL ... всичко това е "бавно" ....

водомери, електромери ... предавателя е "жив" няколко секунди колкото да изпрати 10-тина байта някъде ... после "спи" с часове, дни и месеци
За реализатора на проекта му трябват живот на софтуера ~30 секунди ... та както и да напишеш софта - ASM, C, C++ Arduino, Python, Java - 30 секунди без бъг е реализацията

Т.е. да се познава изоснови цялата програма ... демек някой трябва първо да почете и екпериментира преди да прави PRO проект...

https://www.youtube.com/watch?v=fuOwQlhsU7s

16 frames per sec ( ST7789 - 240 х 240 ) ... 3D математиката е бавна в случая
не ми се занимава с DMA транспорта - тряя да изкара над 30 фр/сек