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

Донякъде си прав, но това с ъпдейта не го разбрах - аз имам предвид да ползваш хардуер, което може да клати линукс, и съответно да си билдваш собствен имидж, или да ползваш готов такъв, който е мислен за "ембедед" употреба, и не се ъпдейтва а-ла-виндоус10. А от друга страна, това че може да се ъпдейтне е полезна екстра, която имат, общо взето, всички устройства, закачени в мрежата. И докато на линуското можеш да вземеш и ползваш проверени откъм защита и криптография платформи за OTA ъпдейт, то на микроконтролерчетата се прави кой както може - и много често дупките в тази посока са феноменални. Примерно, невъзможността да провериш качествено ауторититата на сертификатите те поставя в много неудобна поза за MITM атаки. Или липсата на secure boot е просто нерешима в по-сериозни продукти.
Да, с това се появява допълнителна грижа - да ползваш yocto или подобни системи, но ти носи бонуса да преизползваш готови стекове. И готови не в смисъла на просто безплатни, а такива, за които някой друг харчи ресурс да поддържа - което може да включва доста скрити разходи като плащане на достъп до стандарти и NDA-та, които за по-дребен производител са просто недостъпни.
Цената е че с полезните неща влиза и много плява, но пък масовото производство води до по-добра цена на хардуера за единица мощност, памет или друг ресурс. А плявата те праща да чакаш поне няколко секунди да бут-не устройството

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

Ниска консумация и етернет не са много често ползвани заедно - най-малкото, ако се опъва мрежов кабел, е кощунство да караш клиентите да слагат CR2032 да храни процесора...
Това с MAC по SPI е много специфична ситуация - имаш старо устройство с трудно портируем код и искаш да влезеш в новото време слагайки етернет. За тия цели си има готови eth-uart модули, които ще ти позволят изобщо да не пипаш основния софтуер (примерно щото компилатора, с който е правен, не върви на модерен виндоус). Както FTDI за USB-UART - ако искаш да изглежда че устройството ти е с usb - това е изборът. Ако искаш да постигнеш нещо повече в новия модел (примерно, по-бърз трансфер) ще си сложиш истинско USB с подходящия клас в твоя микроконтролер.
Както и да е, да приемем че една от опциите при правене на нов дизайн, за който се търси да има етернет, е да се ползва нещо с голям ОС. Има си предимства и недостатъци и без конктретните изисквания на всяко едно приложение никой не може да каже кое е по-подходящо. Но ще си позволя да повторя първото си мнение - ENC-а е сред силно недоклатените начини да добавиш етернет.

Едит: а, май изчезна едно мнение и изглежда че си пиша шизофренично - някой ме изработи

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

А, със сигурност има какво да уча - ама явно не искаш да ме образоваш с някаква конкретика. Все пак не включвам за много устройства с етернет и батерийно захранване - ама може да е някаква ниша, дето е далеч от моито области на интерес.
Обратната тенденция (захранване по етернет кабела) е масова, а напоследък и в индустриалния - примерно Ethercat P - https://www.ethercat.org/en/ethercat-p.html, някаква подобна дивотия имаха и сименс, и рокуел, но с тях нямам пряк досег и не мога да коментирам.
Или имаше предвид нещо извън изтритото ти мнение?

незнам за кое изтрито мнение говориш.
а за образоването - не се пъна да образовам никого.
идеше реч, че в момента тенденцията е да се докара етернет до едж девайсите демек всеки температурен датчик или за налягане, за дебит и т.н. дето го слагаш на върха на комина или охладителя на комина, или в някоя бака с химикал или тръба с петрол и т.н.
та тези дивайси нищо че се захранват по кабел(в повечето случаи) трябва да консумират изклчючително малко, заради повер бюджета на съответния полеви суич и т.н. да не говорим , ако ги слагаш във взривоопасна среда - там се прави сметка за всеки кондензатор/индуктор и т.н. колко енергия идва и колко може да се овободи при евентуална повреда на девайса... та всеки милиампер има значение.
и да се изпънеш и да какжеш как за такива неща ти трябва нещо от рода на разбери-то или друго подобно някакси не върви.
та правят ги големите като сименс, рокуел и т.н. и си въртят етхернет/ип профинет, опц-уа и т.н на малки(сравнително малки) контролери... цепят милиампера на 2 само и само да си докарат ниска консумация

и те така

Има ли такова нещо като Етернет ATEX?
Гледам рекламират конектори, ама ...тоците не са ли прекалено големи за взривоопасна среда?
Чудни ми стана...

Не знам дали съм се изразил достатъчно точно - линукс базираните са много добър избор за неща, които ще се подвизават в интернет. Ако говорим за изолиран сегмент, в който етернета е колкото да се преизползва физиката и малко отгоре, може и по-неотговорно.
Че се работи в посоката да се докарва мрежа, т.е. да го кажем IPv6, до всеки нод, е вярно. Но това не става през етернет, или поне не е "масово" така - 802.15, блутут и всякакви други такива, а всъщност най-масовото за битови цели са wifi и zigbee. Да не говорим че в доста от тези сфери не се пънат дори за IP стек, а се правят по-прости (и енергоефективни) мрежи (LORA, LTE-xxx), които после на някой border router или нещо такова се обръща на стандартни протоколи за през интернет.
За индустриални никой не пуска етернет до датчик - има IOLink примерно, все още се ползва и CAN, има и специфични бъсове (ваго/вайдмюлер e-bus) за модулни устройтва (coupler през филдбъс и I/O модули на него). Мисля си че няма много резон в опита да пуснеш мрежов кабел до сензор - за да можеш да направиш топология ще ти трябва или сериозен switch (с много дупки), или device level ring - ама да сложиш два MAC за един цифров вход, пък дори и аналогов, си е леко ексцентрично, и го правят тия, дето могат да си позволят да сковат един ASIC с трипортов суич и логика за конкретното приложение - това с два ENC-а не става. Кът са и "микроконтролерите" дето го могат - FIDO-то на AD, netX на хилшер, ситара на TI (опа, тия последните са с линукс-съвместим кортекс-А, но имат и добър RTOS за истински хардкор).
За енергоефективен етернет си има стандарти, съгласен съм - но предполагам си наясно че приличен SoM с cortex-A8 и lpddr3 примерно пада на 5мА стенд бай (suspend to RAM). Това дори allwinner го имаха за първия им (A10), тексасците го правят на по-съвременни. Оттам работата се заключава до това да има събуждане от мрежата, и това да работи при приспан процесор и мрежа. Доколко с ENC28J60 ще го постигнеш - не смея да гадая. Пък за индустриални цели ми е интересно приложението, което може да си ползволи да приспи сензор, и това докато машината е включена, и някой да го ползва такова? В смисъл - шалтера ако е он всичко тича и нищо не се приспива - ако някой има време да спи трябва да се преразгледа защо бездейства, вместо да кърти кинти за собственика, ако има карантина - шалтера е оф и тока го пестим централно. При нас се борим с другия негатив на линукса - бавното бут-ване - клиента вика тия 6-7 секунди горница са пари - може да е веднъж на 8 часа, ама пак натискат да цедим секундите. А сме имали приложения, в които е още по-дебело - модули (накрайници, ама големи - с електрониката на тях), които робот взима от "магазин" за различните операции - и всяко взимане включва тока на тоя модул и той трябва да е готов за времето, за което робота се завърта обратно до линията. Там смяната е на всеки няколко минути и това време за бутване беше голям проблем. Само че то даже не беше на линукс - bare metal arm система с DLR суич, SPI флаш и прилично много РАМ. Т.е. в тоя случаи бутването за 12 секунди беше от "добър" софтуер.... Какво има като алтернатива? Тексаският чип дето е на beaglebone-а (АМ3ххх) бутва RTOS имиджа си за под 120ms, ползвайки бърз QSPI флаш (не линукс, там е по-бавно). Следващата генерация (АМ4х) слиза под 100мс (това за няколко стотин КБ фирмуер).
Т.е. пак казвам, трябва да се гледат изискванията - ако има изискване за бързо бутване линукса е бита карта. Ако рядко се изключва, или може да стои в stand by (всякакви битови техники - телевизори, ...) линукса е избора по default. Ако бройките са наистина много, цената на хардуера може да доведе до икономии - ама едва ли говорим за прохождащи "фирми"/"ЕТ", които се захващат с майкрочип и ENC по SPI.
Покажи ми "малък" контролер с етернет на някоя от цитираните от теб фирми - интересно ми е да видя как цепят милиампера в устройство, дето спира всичкия power management (SMI) на чипа само за има поносимо interrupt latency за real-time обработка? Познавам известно количесто хардуер с Ethernet/IP и друго количество с PROFINET - сименсците ползват TriCore на по-малките, rockwell нямам информация какво точно, но гаранция етернета не е на външен MAC през SPI. Ако не е в трикор-а ще е в накое FPGA, дето едва ли помага за пестене на ток.
Бекхоф ползват две платформи - ARM с wince и x86/Windows с RT супервайзор, като на втората стигат до амнайсет ядрени ксенони - пак няма много мегдан за пестене на ток.
А пък това недоразумение opc ua е такъв прахосник на ресурси, че само академични разработки "в името на рекорда" се събират в микроконтролер.
За взривоопасни приложения нямам идея - сигурно там има нещо специфично. Все си мисля че етернета не е единственото решение, а и не виждам с какво помага? Ако се търси минимизиране на енергията какво пречи да се сложи кан, rs485, или друго подобно? Това ако се прави цигания - ако се прави както трябва си има оптика.
Преди години (десетилетия?) се радвахме на beck/ipc, после на майкрочип, тексас че излизаха микроконтролери с мак и фи. Но сигурно има причина такива да не се ползват масово. И търсейки защо, си мисля че една от причините са криптиранията - споменатите от теб като клас "не много големи микроконтролери", ако нямат достатъчно актуален ускорител на криптирането, отварят SSL за няколко секунди, че някой и за двуцифрено число секунди - споменатия пик18 с ENC-а си мисля че може да постави рекорд и да цепи минутата с текущите алгоритми? И поддръжката на тия протоколи/алгоритми струва пари - или назначаваш един като Миро да работи по това, или плащаш за добър стек и крипто библиотеки, които някой ще движи за да може ти да работиш по приложението си. Ако си корпорация менажирането може и да е друго и все да има някой свободен "клъстер" индийски програмисти, които да се хванат с това. Ако си беден ЕТ гледаш да минеш метър - mbedTLS с lwip, или линукс.

колко малък
по принцип всички съвременни SoC цепят милиампера до няколко микро в слип
пример от LPWA - Медиатек MT2625, Qualcomm 9205... LTE също може да падне под мили

също по принцип Linux не е удачен за low-power - иска си яка къстъмизация да преспиш цялата периферия и после да я събудиш работеща...

Не споря за това - има си места където линукс пречи - време за бутване, реакция на прекъсване, консумация. Всяко приложение трябва да се оцени дали е критично към тия недостатъци, и това да се съпостави с предимствата. Аз си мисля, че когато имаме "етернет" в заданието автоматично изчезва онова за ниска консумация - в смисъл дотолкова ниска, че да е непостижима с линукс.
То ясно че не бива да прахосваме енергията - къде за да пестим от термален бюджет, къде за да сме грийн. Но примерно индустриалните бъсове изрично пишат "да не се активира IEEE 802.3az".
За приспиването под линукс си хем прав, хем не - в смисъл там си има идея и подход как да стане така че процесора да заспи - има си протоколи и идеи и за това. Има и периферии, които да податливи на приспиване и будене, и такива, които просто са дървени.
Виж мобилните устройства - с цел да изкрънкат още някоя минута живот на батерията им се налага перифериите да спират и драйверите да разбират от power management. Че е по-лесно да организираш приспиването на дребен микроконтролер с проста периферия е ясно - но я му сложи на тоя микроконтролер usb host, pcie, с възможност там да се закачат разни устройства, примерно вифи, 3г/4г модеми, принтери, мрежи на pci/e, и ми кажи колко време ще ти трябва за да разработиш bare metal софтуера да се държи стъбилно с всякакви дивотии дето ползват разните клиенти? В тоя случай се отива на "препоръчани" или "сертфицирани" от нас периферии, които да пасват на "нашия" микроконтролер-дизайн - флашката само еди коя си, и то купена от нас, принтер еди кой си модел, и то точно с еди кой си фирмуер,... В тая посока линукс дава много код за преизползване, и да, взима своя данък - пари, бутване, бавна реакция, консумация.
По-скоро въпросът е дали системата поддържа, и има идея, за low power контрол на периферията - аз твърдя че линукс има, както и виндоус. Сравнението би трябвало да е - имаме два гранични use case-а - много проста система с един уарт примерно само, и друг с много сложна с възможност за добавяне/махане на опции. Смятаме колко ще яде във всеки от случаите линукс, и колко едно силно оптимицирана и настроена bare metal система. В простата система е много вероятно микроконтролерчето да бие с много. В сложния use case ще е обратното - просто защото няма да имаме сили или достъп до документация за да накараме един кой си усб модул или друг дивайс да спи.
А всъщност има много микроконтролерски продукти, дето не искат да се занимават с тоя проблем - а ако добавим филтър "има етернет", стават големия процент. Примерно много RTOS-че и bare metal дизайни (timer прекъсване и броим тиковете) още нямат tickless режим, какъвто има в линукс и виндоус и много прилични rtos-и - щото дискусията май има привкус че не трябва да се ползват изобщо ОС-ве, понеже те натрисат разни неща и става по-трудно. Което е валидно за всеки "компонент", т.е. екстремалното е да си напишем и tcp/ip стека и има резон за пълна независимост. Но това е преоткриване на топлата вода - в смисъл, ако някой се е хванал и написал стек, що не го предлага/продава - за собствените си продукти има свободата да прави каквото си иска и пълен контрол, външните клиенти снасят кинти горница - кое би отказал? Има обаче ефекта че едно е да го ползваш вътрешно, друго да го публикуваш и продаваш - документация, гъвкавост, портируемост, ... Т.е. има още разходи, за да го изкараш на пазара.
Линукса е обширна територия - може да се изтиска много и да се махнат много излишни неща, но това не пасва на идеята "да го ползваме наготово".

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

в германия има един завод на BASF, който е предоставен на един консорциум (APL) за да се тестват нови технологии в индустрията. нй-вече 10base-t1L, което е 10мб етернет по кабел с една усукана двойка и по който кабел може да се подава захванване. та големите и не толкоз големите батковци които са в този консорциум(виж си сам в нета кои членуват там) правят/преправят всякакви сенсори/уреди/свичове и прочие с този етхернет стандарт да си тестват възможности, взаимодействие и т.н. и т.н.
така че твоите представи как на сензорите само блутуут или лора се слага малко са грешни

както и да е бутвай линукс за 7 секунди и се радвай на живота

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

Според мен основния проблем на линукса е по ирония и най-голямото му usp - че е с отворен код. Това е като публична тоалетна. Мине един як батко и остави нещо, понякога по пода, даже и по стените... Така е и с линукса и затова при все че концепцията е правилна, реализацията доста куца. Затова в някои случаи се налага просто фирмата да инвестира малко отгоре и да си напише всичко "in-house" отколкото да пуска тото с линукс. Естествено има и хибриден вариант да си направиш изцяло къстъм билд и понякога си струва, но е въпрос на преценка за конкретния проект

първо дайте определение за сензор, щото Етернет-Сензор звучи налудничаво... та дори и за индустрилани приложения

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