+1

Дедо, дедо ...

За mynewt - sкоро четох някъде за проект, в който тръгнали да избират RTOS - нещо ембедед беше. Та гледали и взeли по спомен фухсията и почнали да копаят. След много борба човека заключи - ако сега трябва да избира ще вземе mynewt.
А това за драйверите - предпочитам да пише TODO отколкото "копнато от ST HAL библиотеките" (примерно).
Такива понятия като TCP/IP стек са подвеждащи - ово е набор от много на брой отделни протоколи. Всеки един от тях може да ми трябва отделно, да ми стига, или точно той да ми липсва.
HAL-ът е за предпочитане да е отделен и независим от ОС-а - което не гарантира качество ( СТ библиотеките ) но може и да го постигне - chibios HAL-а примерно, или libopencm3.
И аз се оглеждам за нещо свежо на хоризонта като кърнел (с тенденция към изгряване, а не към залязване). За момента разумния избор май е freertos-а по следните причини:
- хич да не е, позадържа се на пазара вече доста години
- почти всички чиподелци го подкарват за демо на техните камъни
- много инструменти за дебъг например вече го поддържат - gdb, eclipse плъгини, сегер туловете, трейсалайзър, ....
- не залита да разваля дизайна си заради не-ембедед неща като posix
- има SMP - най-прясно е в ESP32 дето някак клатят двете тенсилики заедно - колко успешно нямам идея де

Ти уби всичко детско в мен
Аз по принцип съм оптимист, винаги гледам да намирам нещо убаво във всеки RTOS. Не гледам за слаби страни, а и да видя такива гледам да ги спестявам. За апачито примерно не писах какво му куца ( и то не е липсата на драйвери - има някакви, просто не са си ъпдейтнали още документацията).
Единствено за freertos-a не пиша, щото колкото и да търся добри страни не мога да ги намеря Всъщност - да, ползва се. Което ме подсеща за вица дето един с Москвич спрял до един Майбах и се чудел дали върви щото не ги карали много такива...

ТСР стека е нещо различно от поддръжката на протоколи. те са по-високо ниво и не живеят в нивото на 'кърнъла', да го наречем така.
за да се справяш с по-сложни неща като фрагментиране на пакети, дисордер,купища изключения и особени случаи, да не говорим за съзнателни атаки, ти трябват мускули - много памет и много процесор. логично, в малките стекове (LWIP) това го няма и те могат да работят стабилно, само ако са във вътрешна мрежа, защитени от лошите вълци от реалния свят.

реализацията на протоколите е относително абстрактка, дори и при двойна реализация на IPv4 и IPv6.
на последното още не мога да намеря практичен смисъл. почти всички провайдери (у нас) го предлагат, ама нещо нещата все още са на поляната с кривата круша, нищо че го има вече 20 години. а би трябвало да е панацея на проблема с липсващите IPv4, особено в светлината на IoT. ама аз ли съм тъп и не виждам чара му, или нещо е измислено накриво?

За съжаление малко са rtos-четата дето имат ниво "над" прозт кърнел. А още по-малко са стековете дето хем да не живеят в кърнела, хем да могат да си съжителстват мирно и кротко... Като казвам малко имам предвид само един за който знам че е така - LwIP. От към TCP и протоколи не е нищо особено, но евала на авторите че са го направили използваем и не създава грижи.

Де да бяха всичките като LwIP... ей на аз продължавам да зяпам секюритита, като за секюрити поне няколко биха свършили работа, ама като стек едно не става... Май образУванието е кофти и не само нашето

Прав си, списъкът ми е малко отнесен и не технически. Но да добавя:
- голям брой поддържани архитектури - http://www.freertos.org/RTOS_ports.html - даже липсват доста портове като този за тенсиликата
- поддържа и големите батки - а8, а9 примерно
- не налага стекове - имат си някакви FreeRtos+TCP ама не влияят на конструкцията на ОС-а

Моите изисквания към ОС-а не са големи - тред, кю и горе долу това ми стига. Задължително условие е всичко да може да се създава и статично, т.е. ОС да може тръгне и без heap - някой известни сертификационни институции обичат да слагат "твърдо нье" като видят динамична памет, та се налага тя да бъде изтикана (да "изплува") нагоре в проекта към интеграционната част. То ако се ползва изобщо де, имам предвид че компонентите трябва да стават и за двата подхода.

Стекът е някакъв набор от няколко неща, дето са в "стек" щото би трябвало лесно да живеят заедно. Това води до опити нещата да се навържат предварително вътре в самия стек. Това е кофти подход - улесненията с тия "връзки" се правят на едно ниво нагоре, в определен wrapper който да улесни живота на web програмиста.
Може да се стиква и кърнел с хал и с tcp (tcp в кърнела ) и с наденица - според мен завръзването трябва да стане с интеграции отгоре запазвайки долните нива чисти.

На мен ми допада идеята по която nordic са организирали протоколите на bluetooth-а в тяхното сдк - стриктно разделени, прости сериализатори да го кажем, без вградени връзки от едно към друго (inversion of control). Подобна е идеята на paho-вската реализация на embedded c за mqtt-то - тотално разделени транспорт и пакетиране (той транспорта го играе пак вид протокол де, така че е валидно да кажем че просто са си отделили протоколите без много да конкретизираме).

То и тва е като Майбаха... толкоз рядко, че да се чудиш дали върви

Всеки си има своя религия... За мен щом съдържа буквичките OS трябва да идва с някаква идея как се правят основните неща, а не тепърва да се чудиш. А щом има и RT отпред, поне малко от малко да има идея за що е туй "време". А пък ако има и free отпред, трябва да не мислиш за пари.
При freertos-a ги има и трите съчетания, а в началото нито едно не отговаряше. Сега може да се каже, че последното е вярно, поне донякъде.
Просто ме дразни огромното разминаване между гръмко име и реално съдържание. Иначе като за "гол кърнел" хич не е лош, само дето не се казва така

Не схванах - явно някаква ирония има (за mqtt) но здраве да е. Идеята беше за организация на кода, не за конкретния протокол.
Между другото, не помня дали преди съм ти го споменавал, но има едно интересно ос-че дето автора му се бори да изстиска максимума от последните ревизии на c++ стандартите:
http://distortos.org/
https://github.com/DISTORTEC/distortos
ЧовекОт е сам и копа само за стм засега, но е хванал интересен път. Аз от години ползвам сборките му за gcc за арм - "bleeding edge toolchain" понеже ги държи доста актуални - последното е gcc 7.1.0:
http://www.freddiechopin.info/en/download/category/11-bleeding-edge-toolchain
Има ги във варианти за лин и вин, и включват и питонските неща за gdb-то май дето иначе често не ги слагат.

Ползва си съвсем просто и стандартно Ц++ човекОт

Те от С++11 нагоре изцяло забиха в шаблоните, а те малко трудно се прилагат в ембеддед. Аз пробвах ама с не много голям успех...

Е как така, точно те изглежда да са най-приложимите? Не че имам много опит с тях (с темплейтите) но всичко модерно яко ги ползва. Ако не бъркам те действат compile-time и не водят до овърхед в рънтайма? Щом и в ардуиното ги ползват значи хич не са тежки.
Вчера точно четох тема с негово участие (на "freddiechopin" - човекът се казва Kamil Szczygiel) на стм32 форума и той описваше в детайли кои екстри от 14-ката (и 17 / 1z) му позволяват да прави хитрини - конкретно му позволяват да прави кода "rom-able" дори за не-статични обекти. Затова си е билднал и gcc 7.1 за стм-а.

Не съм човекът за тази дискусия - затова и те бъзикнах с идеята да си кажеш мнението за неговата посока. Аз иначе съм противник на всичко което слага думата "абстракция" за всичко и едвам се сдържах да не се включа.
Отделно другото ценно е развитието на ламбдите и съответно с това c++ почва да ми привлича интереса като функционален език - rust-а е готин ама не е много популярен още, ocaml-а ми е над нивото в момента (а то както е тръгнало няма да се качва така че едва ли ще се срещнем скоро). Хаскел-а е необременени мозъци дето не са чували basic като език за програмиране. Хубаво ще е да има възможност да се ползват всякакви парадигми в един език - ако го постигнат (не виждам причина да не стане) ц++ ще живее още доста години.
Четох скоро една статия за функционално програмиране на c++ и ми хареса един абзац - по памет цитирам "от 50-те години в научните среди се говори за функционално програмиране и се предсказва как то ще измести обектното. Но в момента в топ 10 на използваните езици няма много функционални. Само че това не е точно така - реално останалите езици придобиха възможности да се прави функционално програмиране което потвърждава тезата на учените".
Идеята там е много хитра но мозъкът ми много бързо прегрява. Точно тази статия от която цитирах е първото четимо нещо по темата (освен една аналогия от въпрос на stackoverflow между ексел-а в който клетките са свързани помежду се през формули (функции) и реагират на промените).

Ще си позволя да сложа линковете тук - към форума дето участва фреди-то:
https://community.st.com/thread/39920-what-are-your-experiences-of-c-on-this-platform
Както и статии за функционално или по-точно "functional reactive programming":
https://www.youtube.com/watch?v=a2MmURgc6cU
https://meetingcpp.com/tl_files/mcpp/2016/Ivan%20Cucik%20-%202016-11--functional-reactive-programming--ivan-cukic--meeting-cpp.pdf
https://manning-content.s3.amazonaws.com/download/e/755016f-954c-4c32-9c8f-4599a91285c8/Cukic_FPinCplusplus_MEAP_V06_ch1.pdf
В този стил всеки хардкор линукс експерт ще разпознае стила на комбиниране на отделни малки инструментчета (тулчета) едно след друго.

Още едно филмче за Fucksia-та - този път е направо на смартфон.

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

Интересно ми беше че във тая фухсия, или в магентата, има поддръжка на MT6797 на медиатек - това е доста голям SoC мисля че с A53 ядра. Като се поогледах се оказа че ядрото им идва от "little kernel" проект, който пък се ползвал в стандартния андроидски бутлоадър. Затова и поддържа някой неща за qualcomm и mediatek SoC-ове.

Мда.. изглеждат и това беше причината да се хвана. Но теорията е едно, а практиката е друго нещо.
Проблемите които срещнах като цяло не са нещо фатално, но пък много и в крайна сметка почваш да се чудиш има ли полза от файдата.
Между другото аз го борех преди време, май тулчейна ми беше за Ц++11 и от там може да идват някои от треските. Сега може да е по-добре.
И вече малко съм ги позабравил, тъй че в момента ако трябва да направя списък на проблемите едва ли ще е пълен или степенуван правилно, но все пак:
1) Смесването е проблем. Усещането е като да седиш на два стола. И ако при РС за всяко нещо може да намериш 10-ки библиотеки, то при нас си
имаме код от 10-ки години писан без шаблони естествено и няма как да го махна или пренапиша. Най-малкото повчват да се дублират много неща, написани веднъж по единия, веднъж по другия начин. Но най-тежко е различния начин на мислене и да трябва в единия сорс файл да мислиш по един а в другия по друг начин.
2) Навигацията и изобщо проследяването на кода става кошмарно. Даже и еклипс не се ориентира и не помага. За сравнение при Ц++ само като чукнеш класче и виждаш наследяванията и нагоре и надолу. Докато специализациите при шаблоните понякога е доста трудно да й хванеш спатиите.
3) Кодът набъбва, особено дебъг версиите са направо ужас. На теория уж трябва да стават compile time много неща, ама не стават, което донякъде е добре че не стават, защото ако ставаха как ще ги дебъгваш?
Тъй като аз си портвах стандартни класове като String и т.н. реално имах абсолютно едни и същи неща веднъж разписани на чисто Ц++ веднъж с шаблони. Второто генерира в пъти повече код.
4) Много от нещата бяха неработещи, пак казвам с новите версии на gcc може да са оправени. Но примерно разни овърлоадвания при които имам и const и не-const версии винаги си предпочиташе не-const-a, как ли не го мъчех. Подобно беше дереджето и с инициализациите. Уж имаш много повече възможности да описваш константи данни, сам да си правиш формати и кво ли не. Но при малко по-сложна структурка и почват ядове. Я няма да иска да направи конструктор с инициализационен списък, я самия списък не иска да направи. Все нещо реве.

А това с ламбдите и функторите, ми хубуу като идея. Само че те тия неща са като пищоф и няма как да си ги закичиш на голия тумбак. Без контейнерите и без алгоритмите само ще се бъзикаш. А пък контейнерите и алгоритмите са ти всъщност STL-a, само че аз него директно дори не съм си и помислял да го слагам. Да, ползвал съм го за проби, ама просто НЕ става за малък контролер. Всъщност тръгва за тръгването... и работи в интерес на инстината, ама аз такова животно в нещо под М7 не бих ползвал.

Та така де, засега в старите проекти избягвам шаблони, но имаме няколко пилотни такива проектчета дето уж по-на чисто ще се ползват, ама да видим

Да си поспамя малко на тема стекове...

Значи имам устройства които имат различни интерфейси - gprs, wifi, btooth, usb, uart, ethernet. Някой от интерфейсите може да не е наситен, но софтуерно така или иначе трябва да се поддържа, за да няма хиляди варианти на фърмуерите. Някои от интерфейсите могат да са наситени с различни джелеза, примерно етернет phy-то може да е различно или пък grps модула и т.н.
Дотук нямам проблем. За всеки интерфейс имам стек, което ще рече че за софтуера изглежда унифицирано. Демек софтуера може да си отвори сокет към кой да е интерфейс и да си маже данни напред/назад без да се интересува от продбности. От своя страна всеки стек си живее отделно в свой процес, детектва си джелязото какво е, обслужва си заявките от клиентите и те така...

Ся, освен интерфейси имам и файлови системи, демек локални или не точно локални, но файлови сиситеми. В множествено число е защото обикновено са 2-3 носителя като дейта флаш, sd-карти и т.е. Съответно някои може да са FAT, но другите не са. Някои може да са винаги налични, други като примерно USB пишките само ако ги ръгнат и т.н. Като оставим подробностите, това са пак нещо като стекове, като по аналогия на лайнукс се монтират към руут-а и в зависимост от пътя се избира съответния носител/файлова система и т.н. Също като интерфейсните стекове и тук всичко е унифицирано, демек софтуера просто си отваря файл с някакъв път и толкоз.

Следващото ниво са разни "протоколи" от сорта на http/ftp. За съжаление тук малко са ни поомазани нещата в смисъл протоколите не са абстрактни и унифицирани класове. Демек за да ползваш ftp софтуера трябва да създаде точно такъв клас и да ползва неговите методи. Иначе от другата страна класът работи с унифициран интерфес, т.е. няма никакво значение дали ftp-то ще се достъпва през wifi/gprs/ethernet или друг интерфейс. Просто се подава интерфейса. Друга подробост е че изборът на интерфейс е ръчен и не става с автоматично рутиране тъй като има ситуации в които даден сървър трябва да се ползва през един интерфейс, в други през друг интерфейс. Зависи дали гони надеждност или цена на трафик или други неща, които не зависят от нас.

И последното ниво е "секюритото" от рода TLS/SSL/https/ftps и т.н., което сега се опитвам да вкарам в картинката. Не знам дали във всички ситуации ще се получи, но целта е да стане нещо като прозрачен слой между интерфейсите и протоколите.

Сега проблемите...
Първо абстракцията. Както казах вече сме я засрали малко с http/ftp класовете. За да стане ясно къде е проблемът, значи обикновено ситуацията е, че устройството трябва да обменя данни. Дали ще дърпа от някъде или ще качва някъде няма значение. Въпросът е, че това "някъде" почти винаги е въпрос на конфигуриране или пък на момента се въвежда от оператора. Демек не знам предварително къде и как. Съответно за да се прати/получи един файл се почват едни проверки, ама дали ще се праща по http или по ftp, съответно се създават едни или други класове и се викат едни или други методи... Крайният резултат е, че за един трансфер се пише доста код. А лошото е, че трансферите са много, демек на много места се пише почти идентичен код. Има известни разлики, щото не във всеки случай всички данни са налични и се събират в паметта, затова трансферът обикновено е на парчета и мазалото е голямо щото се редува малко код за трансфер, малко код за обработка на данните и пак трансфер и така. Абе грозно е и няма лесен начин да се изведе кода за трансфера дето се мултиплицира при всеки трансфер.
И ако досега трансферите се свеждаха до 2-3 варианта, то ако вкарам секюрититата без да ги скрия и за тях ще трябва да слагам if-ве и нещата мноого ще загрубеят.
Целта е всички комбинации да се унифицират в стандартно "пращане" или "получаване". Дават ми някакво URL и аз правя трансфер с това URL без да се интересувам дали в URL-то има http или https или ftp, дали е през wifi или през мръсния канал.

Втория кръг проблеми са свързани с детайлите около самите имплементации на драйвери/стекове/слоеве/файлови системи. Значи моята логика от самото начало е, че всеки драйвер се свежда до сериен интефейс с възможност четене и писане. НО доколкото малко или много става въпрос за RTOS демек малко или много трябва да се следи времето. Затова всяка операция може да е блокираща или неблокираща. Ако е блокираща задържително трябва да има вариант освен буфер и дължина да има и таймоут. Това сме го добутали от прости драйвери до всякакви стекове и протоколи и файлови системи. Сега обаче при секюритото тая дребност май ще ми разкаже играта, щото в нито една от библиотечките не виждам свястна поддръжка. Хайде в някои има нещо "като" такава концепция. Примерно ако искаш неблокиращи функции си регистрираш каллбак, после пак си викаш стандартната функция с буфер и дължина, но тя излиза веднага с пендиг и по някое време ти вика калбака. Това до някъде става, ама пък нямат механизми за канселиране и пак е почти невъзможно да се ползва произволен таймут. Въобще на тема блокировки и време хич не са измислени нещата, а пък тръгна ли да ги оправям ще трябва цялото секюрити да си го пренаписвам... а не ми се ще.

С две думи проблемите ми са в две направления - едните относно коцепцията, т.е. как да организирам стекове/протоколи и разните му слоеве тъй че да могат да се правя унифицирани трансфери. Другите са относно имплементациията най-вече секюрити и протоколи.
За съжаление май тия проблеми не са решени даже на ниво РС, примерно няма стандартен начин да кодираш в URL-то ако имаш няколко налични интерфейса през кой са стане работата...