10base-t1l е интересен и сме го обсъждали - да, той е подходящ за подобни цели. Само че намесваш съвсем нов стандарт, за който повечето колеги тук само сме чели. Ако изкарате микроконтролер с вграден MAC и такова PHY ще е интересно.
Но за момента, с класическите физики, визарда го каза лаконично - звучи налудничаво. Макар че дефиницията за "сензор" е достатъчно разтеглива - има такива с цени хилядите евро и, има камери с гигабит - все е сензор...
Тоя "консорциум" APL не го открих - виждам че правят такъв стандарт "Ethernet-APL", който все още не е приет от IEC. Не намерим много информация - виждам че е мислено да покрива доста интересни use case-ове и тия EX зони - ако са го мислили и в посока разпределение на времето по шината и лесна (евтина) топология има бъдеще.

от миналата година има релийзнад иее стандард IEEE 802.3cg - всеки може да си го получи.
засега ние и тескасците(може би) копаме според този стандард.
а за микроконтролер с вграден MAC и такова PHY... незнам дали е бизнес оправдано.
иде реч особено в билдинг аутомейшъна се цепи стотинката на 2, така че взимаш най-евтиният микроконтроллер до който се докопаш, и му закачаш MAC + PHY на SPI интерфейса и си го имаш на километър кабел 10 мбита етернет (например за кабина на асансьор). а иначе когато е само PHY само подменяш интерфейса, а всичко останало и сертифицирано що е електроника и софтуер си остава същото. то това е идеята да запазиш всичко съществуващо и да се увеличи пропускателната способност до 10 мбита и етхернет, отгоре на който кеф ти модбъс/профинет/ бакнет/......

Не знаех че 1 мое мнение ще предизика такава полемика. Според мен най-добрият подход е този на който му разбираш. При условие че не съм в час с linux - това не е опция за мен. LowPower and LowPrice вариантите са доста редки случай. Няма смисъл да правиш нещо през 5-10 лева поне аз така мисля. Но все пак всеки има право да няма вкус !!!

Що бе , стана интересно.......
жалко ,че карадев.нет загуби интерес.

сигурно му е спрял етернета

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

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

Извинявай можеш ли да пишеш малко по-смислено. На моменти си мисля, че това твоето е македонски , но явно не съм прав. (Това е само молба !!!). Погледни линка който ти изпратих малко по-нагоре. Това съм го пускал на 8 MHz процесор (atmega 8) и нямаше никакъв проблем с бързодействието. Ако искаш погледни и wiznet - W5500. TCP/UDP/ICMP/PPPoE/ARP слоевете се в чипа, и не се налагат толкова обработки. Цената е 2.23 USD в Комет.
https://store.comet.bg/Catalogue/Product/18188/
PS. Не съм запознат с архитектурата на Microchip, но за какво ти се налага използваето на голям стек. printf & scanf и сродните им единственно използват повече стек заради va_arg. Ако не дефинираш големи по размер локални (в тялото на функцията) нестатични променливи, за какво ти се налага голям стек ?! Дори и при влагане на прекъсвания или някаква псевдо-многозадачност 128 байта са предостатъчни.
Поздрави.

ЕЕЕ Това беше в кръгът на шегата Не че аз пиша мого правилно. Ако имаш нещо нужда от помощ пиши тук или на PM прати някакъв телефон или email. Мога да потърся онзи проект и да ти го пратя.
Поздрави.

Що пишеш "болд"?

Аре бря 16MHz ... преди много много години ( га имаше само RTL-ки на ISA ... то и google нямаше тогава )
сме правили мрежи с PIC16F почти на асемблер ... стек, капризи ... с трафик до 200к

та и FPGA сме учили
https://www.fpga4fun.com/10BASE-T1.html

Крадев, да не си ти бе, братчет? Що не каза по-рано, че да не се злагаме пред хората?!

Edit: Еий, к'во забрайх да напиша
Всяка правописна грешка не е случайна!

отдавна сте писали, ама чак сега се зачетох...

Причината да не се ползват малки контролери е най-вече щото няма стекове за тях. А стекове няма защото TLS стандарта не е писан за малките риби. Ако трябва да бъда честен, не е мислен изобщо за контролери по принцип. То и за големи пак е недомислен, просто при големите по-лесно се замазват недомислиците. А те са едни и същи при всякакви стандарти свързани с крипиране, примерно и при TPM е същата боза.
В началото на пакета/команда идиотите слагат неща като дължина или чек сума, т.е. неща които няма как да знаеш, ако нямаш целия пакет предварител. Така на практика стековете не могат да пратят и един байт, преди да са получили целия пакет и са го обработили. А това значи много памет. При TLS препоръчителния минимум, който трябва да се поддържа е 64К в едната посока или 128К/сокет. И това е само за криптирането и при условие, че се работи със zero copy. Като сметнеш, че обикновено трябва и мрежов стек и за него си трябва памет и за приложението, че и за генерирането на самите пакети, щото има обработка на сертификати и т.н. Абе грозна картинка си е.
Аз лично съм резнал пакетите на 8К, но това е само защото знам с какви сървъри работя и разчитам, че няма да ме флууднат. Освен това, за да не ми се налага да буферирам данните съм дублирал логиката на два паса. За първия пас ми трябва само дължината на данните и правя всички сметки на сухо без самите данни. На втория пас вече имам нужната информация и мога да криптирам и стриймвам данните on the fly. Голям гърч си е... досега не съм видял друг да го прави така.
Иначе скоростта на криптиране няма грижи, това е най-малкият проблем.

ХАХА въобщр не ми мина през ума , че става дума за TCP Stack. Помислих че не му стига стека на процесора което много ме учуди.