Доброго дня, Максим!

Якщо цікаво — запрошую в SmartAnthill Project. Більше деталей: dou.ua/forums/topic/12050

PlatformIO не має відношення до «hardware API», все це реалізується через development platforms and frameworks які ідуть в комплекті. Насправді, Ви можете використовувати будь-який фреймворк, в тому числі і Cosa і тд. Те що Вам код від Arduino & Energia виглядає подібним — так це заслуга Wiring Framework, поверх його і написані вищезгадані фреймворки.

PlatformIO — це не фреймворк і не API, це інструмент для збірки коду, організації embedded бібліотек. Щоб Ваш код був cross-embedded сумісний — то Вам і прийдеться його таким робити. Іншими словами, Ви пишете один єдиний код, а дальше в ньому «розрулюєте» define-ми відносно тієї платформи, яка Вас цікавить. А ось зібрати Ваш код на різні платформи із необхідними тулчейнами, флагами і тд — це робота PlatformIO.

Для прикладу, ось поглядіть на native варіанти, де немає жодних фреймворків:
github.com/...link/src/main.c
github.com/...link/src/main.c

Це дуже влучне зауваження, оскільки більшість людей з світу Open Source не зрозуміють використання бінарних файлів невідомого походження.

Людина може сама собі зібрати пакет і засунути його в ~/.platformio/packages якщо не довіряє моєму.

Таким чином ви зав’язуєтесь на одну версію бінарника і автоматично відмовляєтесь від усіх покращень та фіксів, навіть критичних. А якщо це буде критичний security bug? Тому ніхто і не любить бінарних пакетів, що «жорстко» вшиті в софт.

Це Ви не мені задавайте запитання — а Йоржику :) Я то якраз _НЕ_СЛІДКУЮ_ за патчами, а обновляю тулчейни/пакети, беручи їх із відповідної спільноти. Той же приклад з «gcc-arm-none-eabi». Я мав на увазі, якщо уже є опен-сорс спільнота яка підтримує відповідний тулчейн і час від часу його релізить — то я його і використовую. А не стягнув до себе master branch, раз відбілдив, запхнув в пакет і забув на роки. Тобто, не я слідкую за безпекою пакетів, а спільнота, яка їх підтримує.

Якщо ви не змінюєте вихідні тексти, а лише змінюєте структуру, то є сенс подумати над тим, як це обійти(не змінювати gcc-arm-none-eabi, а зробити це на стороні PlatformIo). Це зменшить об’єм коду, що необхідно супроводжувати.

Ну, якщо саме про «gcc-arm-none-eabi» — то використовується оригінал спільноти, а по завантажених бінарниках запускається такий скрипт: github.com/...s/fixsymlink.py

Так як потрібно «відв’язатися» від «жорстких» лінків.

«the (?) missing library manager»

Забув... а тут ще цікавше. Вам не потрібно гуглити в пошуках потрібної бібліотеки для Вашого сенсора чи чогось іншого. І не треба прописувати її в -I includes чи і слідкувати за обновленням. Просто:

$ platformio lib search ...

$ platformio lib install ...

$ platformio run
# Якщо Ви у своєму коді використаєте один із хідер-файлів тієї бібліотекаи — PlatformIO її атоматично заінклудить в процесі компіляції.

$ platformio lib update

# в пошука обновлень
...

Перше враження від сторінки, що це якись уніфікований API для тих платформ («Run everywhere»),

Так і є: один вихідний код, множина environments в platformio.ini — кросс-компілюються у різні development платформи. А щодо «Run everywhere» — малось на увазі, що весь процес кросс-компіляції має одинакову поведінку під різними системними платформами і працює будь-де. Вас не повинно турбувати на якій Ви зараз ОС і чи є там Makefile or GCC — це все робота PlatformIO.

Саме це малось на увазі. Переклад: platformio стягне бінарні файли невідомого походження з невідомого джерела і буде їх запускати. Це дуже, дуже погана ідея. Принаймні в лінуксі так робити не прийнято.

Ви мене дивуєте: а стягнути, поставити PlatformIO і запустити його — Вас не страшить? По Вашій логіці, уже сама команда «$ platformio —help» має виконати «rm -R /». Щодо пакетів — частина з них переукомплектована з тих, які підтримуються спільнотою. Частина зібрана мною. Я немаю часу витрачати на те, щоб слідквати кожного для за різними «патчами» і вносити їх до avr-gcc or gcc-arm-none-eabi. Якщо Вас це так сильно турбує — можете завантажити ті пакети і подивитися що там в середині. Для прикладу, той же «gcc-arm-none-eabi» — це оригінал із launchpad.net/...cc-arm-embedded , тільки адаптований для PlatformIO. Поправлені symlinks і тд.

Поцікавтесь, як час буде. Проект відомий, і скажімо мені «аналог buildroot для avr / tiva / etc»

Ви мене спеціально не чуєте чи я недоступно пояснив на сайті PlatformIO і його документації? Повторю ще раз: PlatformIO — не аналог Вашого "buildroot«-а, і немає нічого спільного. Якщо для Вас те що і вони і я використовую avr-gcc і «пакетну» логіку — це спільне, то тоді омжнацю тему закрити. PlatformIO — немає аналогів, це АБСТРАКТНИЙ і ВИСОКИЙ рівень над embedded розробкою. Людині не треба знати: хто такий компілятор? де він? Як його ставити? Як конфігурувати? І також: не треба розбиратися з Makefiles і переходити на Linux заради "buildroot«-а.

PlatformIO — мульти-ОС підтримка (тобто, працює ВСЮДИ) і уміє збирати Ваш код на різні development platforms. У «buildroot» Ви маєте справу з тулчейнами, мейкфайлами і тд — тут, Ви маєте справу тільки із своїм кодом і HIGH-LEVEL Environments. Всю іншу роботу PlatformIO робить за Вас. У нього багато чого уже попередньо сконфігуровано. Але ніхто Вам не заважає розрулювати більше складну логіку, в тому числі з опційними флагами і тд. Це все можна і описано тут docs.platformio.ikravets.com/...rojectconf.html

ніж «the (?) missing library manager» та «development platform».

Що тут не так? Я просто за свої слова відповідаю. Заперечите слово «the missing»? Чекаю посилання в студію.
«development platform» — і? :) У нас з Вами, мубуть, різне розуміння англ. визначень. Для мене «system platform» and «development platform» — це 2 різні речі. Знаходячись у «system platform», я можу розробляти щось у «development platform». Вибачаюсь, за тавтологію.

Особливо toolchain-и. Оце малось на увазі під «scons-файлами», бо я так зрозумів, що там scons десь був

Стоп... Я наче тепер розумію де Ви знаходитесь. Причому тут «toolchain» і «scons-файлами»?
«toolchain» — це одна «парафія», а Scons — інша. SCons — кросс-платформенна альтернатива Makefiles. Саме його і використовує PlatformIO. Немає Makefiles. Я Вам вище дав лінк на SCons-build скрипти, там усе наглядно видно.

Поцікавтесь як виглядають ebuild-и, pkgbuild-и, srpm-и, deb-и, packages з buildroot. І навіщо вони потрібні, в то числі в плані вимог GPL. Це не нова проблема, багато людей її вирішували.

У Вас в голові сидить один «buildroot» і те, що «PlatformIO» — це повний відстій і клон "buildroot«-а. Я б на Вашому місці краще проінсталював, зробив тестовий проект — і за 2 команди його зібрав і загрузив на плату без жодних «танців з бубнами», причому — ще прогнав це все у вірт. машині на різих системних ОС — от тоді у Вас би всі питання про «клонування» відпали.

PlatformIO — це аналог «buildroot», і не «кривий велосипед» того, що Ви написали " ebuild-и, pkgbuild-и, srpm-и, deb-и«. Насправді, у нього зовсім інші задачі і цілі. А це про що Ви пишете вплані «тулчейнів» і «пакетного менеджера» — це все робота нижнього рівня, її завжди можна довести до того, що Вам хочеться бачити. А точніше, підписані ключом пакети і тд. Ціль не в цьому. Та і проблема не в цьому. Це лише як механізм для організації і підтримки актуальності пакетів для платформ. Але ж не для цього робився PlatformIO.

------------------
А тепер українською опишу Platformio-Flow і чуть наперед забіжу по командам із релізу, який мав би вийти на днях:

1. Ви купили embedded-board. Давайте для старта візьмемо те, з чого більшість людей починає — Arduino. Як виглядає робота з нею без Platformio?

а) Ви качаєте готову Arduino IDE і там уже іде в комплекті «тулчейн» з Wiring-Framework. Додатково ставите Java. Наче і все. Але: не всіх влаштовує та IDE без автодоповнення кода, відладки і тд., і не у всіх є можливість виділити «500Мб RAM» під того монстра (на Raspberry Pi чи BeagleBoard — Ви далеко не заїдете )

б) Ви самі за допомогою пакетного менеджера Вашої ОС ставите тулчейн, бінарні утиліти для обробки прошивки і тд. Дальше, пишете свій Мейкфайл чи шукаєте в інтернеті готове рішення і наче з консолі Ви можете щось там збілдити, попередньо скачашви Arduino-Framework з його потрохами. А що робити з дистрибутивом де немає потрібного тулчейна в пакетах? Або той же Windows? Збирати руцями все? Ну добре, що у Вас це все виходить і Ви любите такий процес інсталяції софта, але інші люди навіть не чули що таке avr компілятор. Вони лише знають як підключити ардуіно до компа, натиснути Build + Upload і все у нього працює.

Тобто, процес інсталяції потрібно софта — буде специфічним на кожній системній платформі, конфігурація мейкфайлів — аналогічно, та і під Windows там не все так радісно.

А що, якщо у Вас появилась нова платка? чи кілька нових? У всіх свої тулчейни , і тд? так, Ви можете піти шляхом Б) і знову назбирати/накомпілити все те, що Вам треба. Але як на майбутнє? Ви хочете убивати час і це все підтримувати в актуальності?

А якщо у Вас іде проект — і у кожного різні ОС/системні платформи? Один буде плюватися що у ньог опроблеми, а інший буде йому кричати: «Переходь на Лінукс, бо тут є dpkg, apt or yum?».

---------------
А тепер PlatformIO (описую функціонал релізу 0,10,0 — зараз те ше робити не можна, але все можна обійти іншою послідовністю)

1. Ставимо його на будь-яку ОС (Win, Mac, Linux +ARM Arch). Складнощів там немає
2. Маємо кілька плат, назву їх знаємо. Дивимось їх правильну назву з пред-конфігурованими налаштуваннями в PlatformIO Tool:

# шукаємо свою платку
$ platformio boards arduino uno
# появиться списочок по нашим критеріям, для «Ардуіно уно» — назва «uno» і там для всіх плат, головне вибрати ці «ключові» ID плат

# створюємо новий проект для плат які у нас є. Тобто, буде 1 код, а компілювати його і вигружати будемо на різні development/embedded platforms
$ platformio init —project-dir %шлях_до_пустої_директорії_де_буде_Ваш_проект% —board uno —board raspduino —board lpmsp430g2553
#... покажеться багато цікавї інформації куди класти свій код і тд

# Все, на цьому етапі нам завели проект , розповіли і показали де все лежить і запросили «запустити» наш проект. Робимо це

$ platformio run —target upload
# Якщо у Вас на даний момент немає проінстальованих платформ для цих плат — тоді Вам запропонують їх поставити

Все. Проект зкомпільовано і вигружено прошивку в девайси.

Висновок: Ви нічого не знаєте про «тулчейни», Вам не треба писати мейкфайли, у Вас один єдиний інструмент на всіх різних системних платформах, який має _ОДНАКОВУ_ поведінку і логіку. І що саме цікаве, Ви можете вибрати будь-який редатор коду чи ІДЕ та інтегрувати їх з PlatformIO. Тут більш детально — docs.platformio.ikravets.com/...latest/ide.html

-------

P.S: Вибачаюсь за довгий коментар. Просто ми з Вами будемо безкінечно один одному пояснювати, хто «клон» і хто «велосипед з квадратними колесами».

Дякую! :)

Зауваження 2: якщо ви вже запхали туди Google Analytics, я хочу бачити прямим текстом на першій сторінці що саме аналізується і навіщо воно потрібно.

Забув сказати, що Ви її можете виключити прямо у CLI:
$ platformio settings set enable_telemetry no

Йоржик, спасибі Вам за коментар!

Нічого не зрозуміло, чесно кажучі, якщо дивитися тільки на сторінку. Презентація для маркетоідів та нуль технічної інформації.

Це про яий проект мова іде?

Фактично ви намагаєтесь зробити аналог buildroot для контролерів, але написаний за принципом AUR + AUR helpers, с метаданими на сервері. Це все, що я зрозумів. Якщо так, ну нехай буде, але напишіть це якось прямо.

Так там же на головній сторінці написано:

Development Platforms
You have no need to install any IDE or compile any tool chains. PlatformIO has pre-built different development platforms including: compiler, debugger, uploader (for embedded) and many other useful tools.

Я ж не можу на головну сторінку впихнути безліч інформації на одну тематику. PlatformIO фактично складається з 3-ьох частин, коротко про них і описано на стартовій. Дальше є посилання в правому кутку на документацію — там уже розписано що? звідки? і куди береться :)

Щодо «buildroot» — чесно, не чув про цю штуку. Але PlatformIO — трішки інший інструмент, як мінімум — він не прив’язаний ні до яких платформ в плані OS і подальшому Development. Зараз готується до виходу новий реліз — так там взагалі буде дозволено кінцевим користувачам самому створювати свої платформи через JavaScript GUI Generator. Достатньо буде тільки вибрати пакети які потірбно включити у платформу і задефайнити build flags для компілятора , лінкера і загружчика.

Зауваження 1: завантаження та запуск будь-якого кода без sandbox’а та без можливості його переглянути перед запуском це *дуже* погана ідея.

Знову ж таки — уточняйте про який проект мова іде. Якщо про PlatformIO — то Ви самі ж пишете свій код, відповідно і бачите його. Якщо Ви мали на увазі SmartAnthill — так, кінцевий девелопер «не бачить кода» який динамічно згенерувався і зкомпілювався у прошивку. Але весь код доступний в GitHub. Я візьму це до уваги, щоб якось дозволити показати юзеру, що було згенеровано для компіляції.

Я хочу бачити, звідки і як береться toolchain.

Ви вибираєте платформу яка Вас цікавить і встановлюєте її через:
$ platformio install %PLATFORM_NAME%
Дальше, всі пакети з платформи розпаковуються по дефолту у ${HOME}/.platformio/packages директорію. Щодо самих _ПАКЕТІВ_ - вони також у відкритому доступі

А також код для scons.

Будь ласка, github.com/...tformio/builder

Зауваження 2: якщо ви вже запхали туди Google Analytics, я хочу бачити прямим текстом на першій сторінці що саме аналізується і навіщо воно потрібно.

Дякую за зауваження. Уже були скарги. Я відключу телеметрію на старті, але буду запитувати у користувача чи готовий він ділитися інформацією про використання PlatformIO. Ніяка особиста інформація не збирається, лише тип команд, платформ і назва плат які виокристовуються. Мені потрібно розуміти що саме цікаво для користувачів, щоб в подальшому знати на чому акцентувати розвиток проекту. А взагалі — на цю тему також відкритий код: github.com/...io/telemetry.py

Якщо будуть запитання — радий буду відповісти!

Доступ до Z-Wave, ZigBee, Wi-Fi, Bluetooth, CAN, low-cost Wireless Transceiver/Receiver (433Mhz) and etc реалізовується через різного виду Bridges на 2-nd layer (Data link). Якраз на них і буде акцент, в першу чергу буде орієнтація на існуючі wireless технології. SmartAnthill — не конкурент ZigBee or Z-Wave — це швидше «дравейр» між HIGH-Level and HARDWARE-Level.

Ідея, дозволити девелоперу (C, Java, Python, PHP, JavaScript and etc) взаємодіяти із девайсами різного типу на Network рівні. На апаратному рівні — це «залізяка», а на програмному для кінцевого девелопера — це «мережевий девайс».

SmartAnthill може бути легко інтегрованим в уже існуючі системи побудови розумного дому, по типу OpenHab і йому подібні.

Якщо у Вас є кошти на дорогі «девайси» — можете купляти їх, наша ціль — дозвлити «девелоперам» самим вибирати яку вони хочуть використовувати технологію передачі даних і виробника відповідних чіпів. У когось є кошти на Z-Wave/ZigBee, а у когось їх хватить лише на Arduino за 5$ і на якийсь там low-cost RF. Доречі, можна обійтись одним MCU + Serial. Але це уже провідний варіант буде.

Із PlatformIO — я думаю, що все зроузміло? Там на Home Page є архітектурні схеми основних частин.

Щодо SmartAnthill — прошу глянути в документацію. Там є описані власні протоколи у порівнянні із моделлю OSI.

Документація трішки застаріла, багато чого змінено і там не відображено, але наближена концепція відповідає дійсності.