Като цяло по-началното ниво би трябвало да е линукс на виртуална машина, после ембедед. Имам предвид че трудно някой ще е ефективен в разработката на ембедед линукс устройство ако няма базата от ПЦ. В смисъл един човек, който се е занимавал с вин GUI програмиране трябва да се ориентира преди да почне да пише за ембедед.

Като самостоятелен елемент тези платки имат своя ниша на приложение което един микроконтролер без приличен или мощен OS няма как да замени.
Когато се комбинира периферия + такава платка (както при Arduino/RPi) нещата стават качествено различни.
В конкретния случай говорим обаче за пълно функционален Линукс върху платка от $15 до $35. На такъв Линукс се пише с лекота на стандартно C, писане на скриптове, има огромно количество информация и т.н. и т.н.

Примерна ситуация - един или два или три специфични периферни хардуера - твърде различни като комуникационни протоколи. Това всичкото искаме да го направим за работи като едно цяло за външния свят. Става още по-криво ако външния свят иска данните да се изчекват според както му харесва. Е, това се поема от Линукса... кеф ти TCP, UDP, JSON, XML, отдалечени бази данни (за локални HDD or SSD), WEB сървър - примерно Apache, SSL и още какво ли не.

Тия платки ги ползвамe само в команден ред, графичната среда се изключва от основния SETUP и не се зареждат никакви нейни компоненти. По този начин Линукса започва по-ефективно да регулира и честотата на процесора според средното изчислително натоварване.

Скоро няма да умре бизнеса с периферията и микроконтролерите, но ще претърпи някакви изменения според новите неща които се задават. Личното ми мнение е, че в много ситуации ще се мине на оптимизирана периферия + някой едноплатков Линукс и от там вече един TCP сокет към някой сървър. А дали това е най-доброто, най-правилното, най-евтиното, най-бързото, най-надеждното... трудно е да се каже.

Е то ясно, че без основа не става. Дори само да успееш да крос компилираш дистрибуция (ядро + юзерспейс) си е добра отправна точка т.е. да пуснеш един скрипт в конзолата и да запишеш резултата на една карта от която да буутне платката и да видиш всичко през серийнитя интерфейс. Пък после и по сложните неща ...

Мда. Голяма част от линукс програмирането се изразява във борба с туловете. Що за успех би трябвало да е сглобяването на крос компилация? Мен ако питаш, никой не трябва да се занимава с това, освен единици фирми на които да се плаща да го правят като хората, а другите само да ползват.

Вместо да ковеш дъски, който да вадят директно пари, ти се бориш да създадеш чук с който да си забиеш пироните.

Тази логика е валидна и за ембеддед - защо да трябва да се бориш с регистрите на някаква периферия, производителя трябва да ти дава HAL, ставащ за без ОС и с ОС някакъв. Т.е. като имаш HAL/OS се ограничаваш до писането на "приложението", точно както под линукс при налична дистрибуция и драйвера.

Това е много важна стъпка от обучението!
Изобщо не става въпрос само да си създадеш чука, а да разбереш един различен стил на организация на софтуера. Да видиш, че безброй софтуерни модула, писани от безброй калпаци *могат* да работят заедно. А могат и да не работят, което също е полезно в известен смисъл, особено ако се научиш да се ориентираш какво не работи и защо

Ако само една или няколко фирми се занимават с това, то най-вероятно ще се убие идеята. Даже аз самият често се изкушавам като забивам пироните, да ги забивам така че друг да не може да ги вади и пипа. Винаги става така като работиш сам.

С две думи, това че някои неща в лайнукс стила изглеждат дървени е донякъде подвеждащо. Просто те са така неслучайно. А че има и инструменти дето се влачат още от 80-те години на миналия век - има. И има какво да се желае по тях и вероятно ще бъдат актуализирани рано или късно. Не се бърза, защото като има нещо работещо и то е работещо, ползвано от хиляди и ако ти мислиш за съвместимост наистина няма да ти е първата мисъл точно това да барнеш...

О да не зачекваме дискусията Това дето го пишете ми е ясно. Просто като напише някой, че обучението почвало със сглобяване на крос компилация и тръпки ме побиват, като знам, че на мен понякога са ми трябвали седмици... Ако пусна един заек там, не че няма да се обучи, а най-вероятно ще го загубя като кадър на 2-рия ден.

Е, те работят заедно защото следват модела на дадената операционна система. Т.е. има строго дефиниран начин за писане на кърнел модул и ако го спазиш може и да ти тръгне модула, ако не гориш.
Т.е. нищо по-различно от всеки друг "framework", ОС или спецификация за писане на софтуерен компонент.
Имат си инструменти, свързани и отговарящи на техния стандарт. Пак нищо уникално, доколкото общо взето всеки ОС си има някакъв вид правила и API. И под виндоус имаш милиони софтуерчета който работят, писани от пак толкова калпаци. Това за мен е модела на "операционна система с общо предназначение" - GPOS, за разлика от "специализирана ОС", каквито са ембеддед операционните системи, най-често дето им викаме "RTOS".
В единия случай целта е да се направи модел, който да е лесно използваем от всеки ("web програмист"), в другия случай фокуса е изместен върху ефективност, скорост, надеждност, real time. Съответно GPOS опитват да генерализират всичко и всичко да е файл/стрийм, device independent I/O дето го дискутирахме още по златните година на форума (когато TGI пишеш ) докато такава концепция за ембеддед е по-скоро грешна според мен.
GPOS търсят максимална гъвкавост, което се постига точно с тази генерализация, излишъци, сорсове на кърнела/СДК от 3Гб (като за оранже пи-то) и стоварване при мен на няколко хиляди драйвера за платформи, който още преди да почна да тегля е ясно че посмъртно няма как да се ползват на моя хардуер. И съответно инструменти (kconfig и подобни) да отсееш какво ти трябва.
Сега с тия "device tree" пак залитнаха - да билд-нат кърнел който може да върви на различни хардуери непроменен. Т.е. или ще трябва да имам в кърнела излишни модули (драйвери) за нещо дето никога няма да тръгне на тоя хардуер, или да имам зареждаеми модули дето да ми бавят стартъп-а и да имам някакъв init дето за тоя хардуер пак е уникален, никога не се променя и бонуКса от него е да ми забавя стартъп-а, да усложнява изпълнението от флаш (XIP).
В тази посока можеха да си инвестират усилията да подобрят инструментите и примерно да се теглят софтуерните модули само ако се ползват в конфиг-а на дадената платка?
Ембеддед за мен значи строго специализиран в смисъла на възможно най-ефективно изпълняване на заданието.
Абе ембеддед си значи - за тая платформа се налива един монолитен фирмуер и това е. В смисъла на уникален кърнел за тоя хардуер дето си има всичко необходимо и нищо излишно. Както HEX-чета на микроконтролерите. Какво не им харесва в този вариант? Да, трябва да се компилира за всяка нова платка. Да, ама новата платка все си иска внимание, независимо дали това ще е някой да направи драйвери, да напише инициализации или да конфигурира/напише приложен софтуер.
Има смисъл от някаква стандартизация на API-тата за OS и HAL. Но дотам - другото по-скоро пречи. Каква ми е ползата че има начин през /dev или /sysfs да си намеря колко SPI порта или UART-а има тая платка, ако приложния ми софтуер пак ще има нужда някой да му каже на кой точно от тия портове да работи? Да, ще се размина с пипане само в приложението, но ще съм натоварил системата да ми конфигурира и пусне всичките, понеже не е знаела кой от тях ще се ползва.
Не съм експерт, но май точно в тая насока се правят оптимизациите когато се търси бързо boot-ване на системата и оптимизиране на размера на фирмуера - да си прегледаш приложението, да установиш кое ползваш и кога, какви са точно зависимостите тръгвайки от приложението и слизайки до хардуерни блокове на процесора за да не ти се налага да пускаш SPI който няма да ползва.

Едит: доколкото съм ползвал няколко инструмента за билдване на ембеддед дистрибуции (OpenEmbedded, ptxdist, buildroot) те отиват точно в посоката да улеснят процеса и да го ускорят. Там сорсът на пакета се тегли само ако си го активирал в твоята конфигурация, логично и само тогава може да се билд-не.

Цецо, то няма "единствено правилен" подход...
И не споря дали твоя подход е сбъркан, а че трябва да има някакъв баланс. Едната крайност е силно централизиран подход, една фирма да коли и да беси и всичко да затваря. Другата крайност е безброй модули и да трябва да вадиш от 1000 кладенеца вода преди да можеш да сглобиш нещо.

Всеки сам си намира баланса. Но за по-правилен избор е добре да се познават и двете страни. Много windows програмисти изобщо НЕ ЗНАЯТ друга алтернатива и каква е разликата. Това ме дразни мен лично, а не че са избрали чисто комерсиалния подход...

Освен това проблемите с крос компилациите на нов таргет отшумяват рано или късно. И аз съм губил време...Сега с една apt-get команда мога да си инталирам и gcc и gdb и т.н. Преди трябваше да свалям, да конфигурирам, да пачвам, да компилирам, да инсталирам... Но не смятам това за загубено време.



Концепцията за модулност, не е свързан с дадена операционна система. Макар, че повечето идеи произлизат от UNIX, разните лайнукси просто ги следват...


Въпросът изобщо не е дали работят или не. Както казах и под юниксо-лайнуксите често не работят.
Говорим за съвместна работа на един модул с друг модул, на едно приложение с друго приложение, на една библиотека с други библиотеки и т.н. Защото като тръгнеш да сглобяваш кърнел или тулчейн или каквото и да е било ще видиш как мейк вика линкери, вика компилатори, вика скриптове, скрипотовете викат хиляди външни команди, все приложения и модули, правени от различни хора/фирми/организации.
Разговорът тръгна от приказката, че трябва да е един монолитен "чук" - не, не трябва! Силата му е именно в това, че не е един, а се събира от хиляди парчета!
И това изобщо не е типично за windows, там типичен е комерсиалния продукт - едно ЕХЕ и инсталираш VStudio/IAR/Keil.... Нищо не събираш, нищо не сглобяваш и нищо не работи с друго нещо, щото ако трябва да сглобиш нещо дето има един модул, който е писан за VStudio друг с IAR, трети с Keil и си преибан отвсякъде!

За какво едно exe говориш? Нещо не схванах - темата беше за билдване на BSP на някакъв борд.
Ако трябва да правим аналогия с продуктите на майкософт може би най-близо е Windows CE или Embedded. Там нещата са си точно на компоненти, които добавяш, махаш и т.н. И пак са разделени на bootloader, kernel и user част.
Колкото до линк-ването на кодове между различни компилатори/среди - въпрос на спазване на стандарт. И с GCC не можеш да линкнеш ако не е еднакво ABI-то (т.е. пак си толкова преибан ако нямаш сорса), или дори ако компонентите ползват различна версия на glibc или друга библиотека.
Да де, с една команда си вземаш toolchain-а - чудесно, точно така е на VS/IAR/Keil от много време, а не "сега" чак, както и с GCC за хост windows и таргет арм? Няма разлика и забележи че никъде я няма ключовата дума "линукс". Има GNU, има отворен код, но нищо специфично за или по заслуга на линукс. Голямата гъзария да си билдваш toolchain-a от сорс изведнъж се оказа че май била излишна, т.е. дори който може да си го билд-не предпочита да го вземе готово...
Идеите за модулност, за които говориш, ги има и в другите OS-ове, били те GPOS или RTOS, комерсиални, свободни, unix базирани или майкрософтски. Един аспект в тая връзка е динамичното линкване, което е важна част от тях. И което е нужно за да се решат проблемите за които писах преди, и които липсват ако се ограничиш до класическо статично линкване на кода до монолитен фирмуер (разбирай - кърнел без loadable модули). Тогава и оптимизацията на кода върви по-добре, предполагам че и LTO няма да работи с динамични библиотеки.
Тая работа с модулност може да се прави и на ниво компилиране на кода, обекти и библиотеки, разбира се при модификация ще трябва да се прекомпилира и деплой-ва нов код. Което и иначе е така, пак трябва някак това устройство, пред което няма физически потребител/администратор, да получи новия код. Има си предимства, не споря, но трябва да се ползва само ако има нужда от него. Иначе си има и проблеми.

и двете ПИ-та според мен са само играчки, да покажеш на мацката, че си имаш собствен плеър за филми, залепен с изолирбанд за телевизора.

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

---
на оранжевата платка не виждам PHY? аз ли съм кьорав, или са вкарали доста специфична аналоговщина на 'цифров' кристал?

Говоря за практиката да се прави завършен И затворен продукт. Типичното приложение идва като една инсталация или едно ЕХЕ и възможните промени са сведени само до настройките, които авторът е направил и потребителят може да цъка с мишката. И дотолкова всички сте свикнали с тоя начин на мислене, че дори не схващате защо някои неща не са направени по тоя начин и се налага разучаване как да се сглобят...


Нищо общо с това, за което говоря... Писал съм драйвери за WinCE, сглобявал съм BSP-та.


Да, има стандарти... но над всички стои начинът на мислене. Щото ти каквито и стандарти да имаш, пак ще осереш пейзажа ако не мислиш. Прост пример от нашите приятели дето пишат PEEDI - там се използват "агенти" за тестване на SDRAM, за флашване на външни памети. Кодът на даден агент обикновено е общ и не зависи дали ще се изпълнява на АРМ, MIPS, PowerPC или нещо друго. Зависи си само от алгоритъма на съответната външна памет. Но все пак трябва да го компилираш за всички платформи, които поддържаш. И това е само една малка и незначителна част от процеса на бюлдване на фърмуера на PEEDI. Как се прави с GNU или по-точно unix ориенирана среда е ясно, въпросът е как би го направил с типичен windows "чук"?
Уж всичките следтват стандарти, даже такива като IAR си пишат един куп стандарти за сигурност за какво ли не. Но като стане дума за съвместимост изведъж се оказва, че един и същ код трудно може да го компилираш за различни таргети. Компилатори от една и съща фирма не са съвместими помежду си. Да не говорим, че понякога различни версии на компилатор за един и същ таргет от една и съща фирма не винаги са съвместими.
Не че при гну-то няма проблем със съвместимостта... Но има огромна разлика в начина на мислене. Това се забелязва като погледнеш майллистите как в сериозните проекти отсвирват веднага всякакви предложения дето водят до несъвместимост.


Модулността не се ограничава само до библиотечен код. Готовите приложения също може и трябва да могат да се ползват от други приложения. Затова и команд промпта е толкова важен в света на лайнукс. Дори когато се прави графичен интерфейс, обикновено първо се прави конзолен интерфейс и върху него се надгражда графичен или се дублира по друг начин. Докато при windows практиката е първо графичен, после евентуално плъгини и само в краен случай команд промпт.
И отново говорим за начин на мислене. Примерно сещам се за костенурката, първо направиха интегриране с windows explorer а най-накрая команд промпт интерфейс. А работата с cvs/svn/git хранилища е толкова важно да има и команд промпт интерфейс, колкото и графичен. И обратно при лайнукс винаги първо се прави конзолна версия и ако имаш късмет излиза и работеща графична такава.

Нямаше да са първите... ползвал съм луминарита с вградено phy и нямам оплаквания за разлика от проблемите с външните phy-та

Но сякаш имат външно такова, виж ботома как вървят пистите и къде отиват... точно като на phy ми мяза на мен

цЪ - не е PHY (ако имаш предвид 20-пиновия QFN). той по-скоро е някакво захранване или аудио.
пък и е от на друго място, загледай се. жиците за нета си отиват направо в SOC-а.

подобен чип иска десетина захранвания. гледам, че са ги направили с разни малки чипчета в SOT23-5 по $0.30
за сикуенси явно се говори в широки граници, да не говорим за други параметри в захранията. китайска му работа

и на мен луминари май са ми единствения известен вариант за MCU+PHY.
има и един вариант на пика, дето е с оня 10Мбитов етернет 'контролер' две-в-едно. но той си е пълна пръчка.
може би WizNet също влиза в тази категория, ама той и сам по себе си има проблеми с греенето.

за SOC е много смело. или компромисно. без да пипна чипа, не мога да кажа нищо конкретно, освен че никой не го прави. аз лично мисля, че такайчетата надали са толкова добри в силиконирането.

апропо, алуинър къде си печатат чиповете?

Пак не сте чели темата - H3 е с вградено 10/100 фи.
Миро, тия неща нямат връзка с ембеддед. Както и да го въртим, накрая има завършен продукт, на който производителя е качил фирмуер някакъв и който той гарантира че работи според задание. Дали е линукс, друг ос или без, няма значение.
Разработката на продуктите става на отделни нива, слоеве, които могат да се правят от различни хора без организация, в една фирма от един човек, в една фирма от много хора или в много независими фирми.
Аз се опитвам да направя аналогия със слоевете в софтуера - принципна грешка е да се прескачат или смесват слоеве. Даден слой консумира интерфейс от този под него и имплементира интерфейс за този над него. Опитът да караш PLC програмиста да пише кърнел модули щото в машината отдолу имало линукс, е странен, най-малкото, и има много недостатъци. Макар че това би било най-ефективния вариант да се реагира на прекъсване и да се светне една лампа...
Когато тоя ПЛЦ програмист пише се интересува от документацията на PLC-то и не се вълнува от това как е написан драйвера в линукса. Когато някой сервизен техник трябва да ъпдейтне устройството на линията не му пращаш конфигурация на кърнела да си го билдне, нали? Дори да ти го поиска с аргумента че е страшен фен на линукса и обещава че той ще се оправя с шефовете си ако заводът изгори? Или да му дадеш root права на PEEDI-то или друг твой продукт?
Какво е за него това устройство тогава - кутия с интерфейси, документация, и "фирмуер", по всяка вероятност криптиран. Къде е линукса, многото девелопери и отвореността на системата? Останаха за ПЦ-тата, разни ей такива платки дето са за любителска работа или за единични вътрешнофирмени решения. В момента в който трябва да изкараш завършен продукт не оставяш вратички за софтуерчета, дето могат да ти изядат паметта, напълнят или износят флаша и тем подобни. А и никой не го очаква - можеш да си качваш произволен софтуер (динамично линкване) на домашния или служебния компютър, на телефона, на рутъра, но колкото и да искаш няма да го направиш на машината в цеха, нищо че има линукс, дори да имаш права за това.
Това е голямата разлика между GPOS за компуфони и ембедед системите, където трябва да се гарантира някакво ниво на отказите. Опитите да се подкарат GPOS на ембедед продължават, но са възможни само ако тези GPOS понасят да бъдат принципно модифицирани преди това. Двете области на приложение има различни и в големия си процент противоположни изисквания.