Из нашите устройства (и среди, в които продаваме) много се ползват протоколи за т.нар. fieldbus-и - които са измислени да се конфигурира и прехвърля информация между отделни устройства, свързани през ограничена като скорост медиа - примерно CAN или 485, а сега и етернет. Един от добрите протоколи там е CANopen - ползва се и с физика CAN, и с различни индустриални етернети - етеркет, powerlink. Това нещо е много удобно и изчистено като идея, особено по CAN, където самия бъс поема голяма част от ниското ниво (messaging слоевете). Сега обаче трябва да мисля подобни проблеми (каквито той решава), как да се решат върху физика УАРТ, и то ефективно.
Ровя за някаква идея на нещо утвърдено, което да може да върви през УАРТ - примерен use case е да си говорят един микроконтролер (от класа на стм32) с нещо по-голямо - примерно линукс хост (за идея да приемем че нещо като малинка).
Изискванията са:
- да има ефективно сериализиране на данните - естествено, бинарно, и без много-много излишни байтове освен примерно старт, размер, чексума - може би SLIP или подобно?
- да не изисква polling от "мастъра" - т.е. когато малкия има нещо да каже, да може да го прави веднага (т.е. противно на MODBUS примерно)
- да има идея за някакъв вид object dictionary на данните - по подобие на индустриалните fieldbus-и, например CANopen - да има идентификатори на "променливите", с цел организация

Каква е целта - има различни "микроконтролерни" модулчета, всяко с някаква специфична функция. Всички те могат да се закачат към някакъв хост - ПЦ, или друг контролер, който може да се приеме че ще е по-неограничен откъм ресурс. Самите модулчето може да имат голям брой "процес данни" - неща, които мерят, смятат, или изкарват навън. Всяка данна може да е от бит до голям структура/масив. Големият контролер, в зависимост от какво се иска от него (какво е приложението) трябва да може да си "избере" кои данни да обменя с малкия, за да може да оптимизира скоростта на комуникацията/честотата на контрола. В един случай може да му трябва един бит вход само, в друг всичките примерно 4К входни данни и още 4К изходни. Не бива да се обменя всичко винаги. Тука се сещам за два подхода:
- определен брой предварително дефинирани конфигурации (примерно 10), и хоста може да каже "искам конфигурация (маппинг) номер 7" - това е подобно на USB конфигурациите, които дивайса описва, а усб хоста активира по желание
- пълно конфигуриране в "контейнери" - хоста праща детайлна конфигурация на малкия да му каже "първия байт да е АЦП канал 0, после 4 байта брояч на импулси", после нов контейнер в който да има "първи байт цифров порт А, втори аналогов вход 7" - всеки контейнер си получава идентификатор, и после по транспорта върви само "аз съм контейнер 0, 5 байта идват, 00, 01, 02, А7, B8, CRC, .." - това е концепцията на CANopen, където контейнерите са PDO-та и при физика CAN са отделни съобщения.
Пак по аналогия на CANopen ще трябва да има някаква комуникация да се знае че двамата са живи - life tick, guarding, keep-alive.

Идеята е да се изгради (по-скоро използва наготово) някаква идея и тя да е независима от конкретната функция на микро-модулите, както и да има библиотечна имплементация на това ниво, което да дава услуги на приложения различни да си получат и предадат данните.
Говорим изключително за event-базиран обмен и publish-subscribe модел.
MQTT-SN е добра идея, но пак иска някой да го играе брокер, което трябва да е замисля доколко е практично (в микрото).

По аналогия с mqtt, искам приложнието с host-а да може да се "абонира" за данните, които му трябва от микро-модула, и да може да му праща обратно такива. Малко ми звучи като брокера да трябва да е микроконтролера - иначе всички промени в състоянието на микроконтролера ще трябва да "минат" по УАРТ-а за да стигнат до брокера в хоста, а това не е желателно. Точно уарт-а е тясното място и там трябва да минават само данни, които някой е обявил че му трябват (регистрирал се е за тях).
Има едно data distribution service - https://en.wikipedia.org/wiki/Data_Distribution_Service

Бях попаднал преди време на нещо като опростен CANopen за подобни цели, ама ровя и не го откривам - дали имаше нещо общо с ЕСП-тата.

CoAP ?! https://github.com/buczaq/coap-via-serial
LwM2M...

не съм чул за нящо готово

CoAP май си беше request-response като идея? Мен ми трябва pub-sub?

Ако имаш всичките протокол, контейнери и услуги работещи, не се ли свежда въпросът ти до реализацията през УАРТ? Казваш , че ви работи на 485 - чисто физически разликата от 485 не е много голяма, но я има и е доста съществена. Какво трябва да е мрежата - колко точки, какви дължини?
Извън въпроса - какво се спестява?

на една уарт жица колко джаджи ще има ... 1? или търсиш медия за "много"

MQTT-то - махни сокета, сложи r/w за уарт...

Имаме протоколи, които обаче са горни нива и се възползват от фичъри на долните нива, за да си свършат работата - т.е. пакетиране, арбитрация и т.н.
Единият подход е да се реализират тия услуги на ниско ниво за през УАРТ - примерно нещо като SLIP протокола, или подобно - да дава начало, дължина, проверка (чексума).
Тук идва другия "фичър" на кан-а - арбитрацията/достъпа до медията, само че вторият отговор е че ми трябва за point-to-point връзка - на един уарт на хоста има един микроконтролер модул. Но хоста може да има много p2p връзки - примерно 8 уарта, всеки отиващ от отделен микро-модул.
Транспортът на mqtt, мисля, не мога да сменя директно - трябва да имам поне старт/стоп/размер хедър, нищо че после има пак дължина - трябва да се опакова.

После, някъде трябва да има някакво олекотено подобие на брокер - заради "тясното" място през уарта - не мога да пращам всяка промяна на всяка променлива, която евентуално някой някога може да поиска - трябва да има "филтриране" в микроконтролера, което да пуска само "конфигурираните" публикации по уарта. В другата посока е същото - микрото може да има стотици изходни променливи (примерно - аналови изходи), а дадено приложение (конфигурация) да иска да ползва само един изход, и този изход да може да го сменя през няколко стотин микросекунди.
Друго, за което се замислям, е че може би ще е полезно да има "сесии" - нещо като повече от един сокет върху този уарт. Има ситуации, в които един MQTT клиент може да поиска да отвори няколко "сокета" към брокера, за да може да праща паралелно - в смисъл, нещо като quality of service - някакъв вид приоритет. По единия сокет може да е тръгнало дълга публикация, която ще тече примерно няколко секунди (много килобайти данни), и по средата да трябва спешно да се прати нещо по-приоритетно. В този случай някой "бъсове" имат чалъм да паузират дългото предаване, да вмъкнат краткото приоритетно, и после да продължат и довършат дългото. Е, това е рядка екстра - мисля че по TSN имат такова нещо, но CAN и Етернет го нямат де - т.е. това е твърде далечна екстра, до която едва ли ще се стигне.
Един от начините да се преизползва стар протокол, примерно CANopen, и да се емулира неговия стандартен транспорт - CAN-over-serial - това е по-лесен подход, и ще се закачи лесно към текущи стекове за canopen, които сме правили.
Знам че разни други протоколи са били първо върху сериен/485 - профибъс, или controlnet май беше предшественика на ethernet/ip.

Edit: значи, пълната динамичност на mqtt не ми е нужна - принципно дадена "конфигурация" може да се дефинира на стартъп и да не се променя (т.е. тая конфигурация описва връзките - кой за какво е абониран, и кой какво му е "разрешено/изискано" да праща). Много изчистено би станало, ако тази "конфигурация" се включва като променлива в сорс кода на микрото, и фирмуера му да се прекомпилира при всяка промяна на конфигурацията (която не е честа). Това би било максимално оптимизирано като размер на кода и производителност, но иска хост системата да флашва и може би прекомпилира/линква фирмуера при промяна на приложението (ако трябва да се задоволи изискването хоста самостоятелно да може да променя произволно конфигурацията). По принцип зареждането на ново "приложение" (което е обвързано с една или няколко фиксирани конфигурации) се случва от ПЦ инструменти, които съвсем лесно могат да прекомпилират, или поне линкнат наново фирмуера и да го флашнат.

Още малко ако обясниш и ще ти стане ясно съвсем .
Тия концепции, дето ги обясняваш са ми много далечни...ама е интересно да те чета.
Щом имаш CANopen действащ за хоста, има и разни библиотеки за ARM,
какво ти остава - да си съчиниш някакъв формат за конфигурация и парсер
за конфигурацията в МЦУто - портове,байтове и периоди.
Предавай си на воля към хоста

така е ама и не е така.
бих казал да ползваш някой протокол за като HDLC, или пакетно ориентиран.
така винаги ще имаш стант на фрейм/ край на фрейм и ще си спестиш много от проблемите на уарта.

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

Ако правилно съм разбрал искаш да закачиш няколко "малки" контролера на общ бъс, през който всеки един от тях по собствена инициатива да обменя данни с хост контролер. Искаш и бъса да е сериен и базиран на УАРТ.

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

От казаното до момента на физическо ниво ти трябва мултимастер бъс, от което следва, че "стандартния" 485 отпада. остават LIN (за къси разстояния), CAN и модифициран 485 с доминантно и рецесивно състояния.

Другото неприятно нещо е, за да се обслужва арбитрацията на този "софтуерен" мултимастер бъс, хоста трябва да измерва времената (паузите) между байтовете и пакетите, а ако и той трябва да може да започва комуникация по своя инициатива с тях - времето на излизане на бъса също е критично по отношение на арбитрацията. При PC-тата ограниченията не са от хардуера, а от драйверите на ОС-а. Предполагам, че и при разните там малинки и др. подобни проблема ще е подобен и произтичаш от това че ОС-а не е за реално време.

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

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

Има /не много/ нова мода за MCU-та с вграден CAN трансивър:
https://www.nxp.com/docs/en/brochure/75017050.pdf
https://www.mouser.bg/Search/Refine?Ntk ... =113104100
Не става ясно, в задачата фиксиран ли е микроконтролерът?

По-скоро не - в смисъл решения, които изискват точно определен контролер няма да минат - може да се наложи я да е стм, я да тексас, я инфинеон, я нещо друго - каквото им хрумне.
Мислех си за това на NXP, но то е малко уникат и не е ясно дали ще се спести от тая интеграция - то и там май са два кристала бондирани заедно, ама това ми е някакъв далечен спомен отпреди амнаис години, когато излязоха.
Гледам че цената на трансивърите не е толкова фрапантна - най-тънкото е атмелски ATA6561 - уж "почва от" 23 щатски цента. А изродът е даже FD съвместим, до 5Мбит/с, което обаче едва ли ще е някакъв бонус в случая.
Другото, което гледам, е документ на сименс (???), гледам от 96-та за бъс с няколко нод-а - само с по един диод вместо трансивъри. Принципно афиф работата, ама щом някой си "Dr. Jens Barrenscheen / HL MC PD Microcontroller Product Definition" го пише, си струва да се помисли и в тази посока. Говорят за нещо като 1 метър за бъса, което ми е предостатъчно - при мен ще са 10см преко сили. Абе опция е.
Едит: ей го нот-а, ама е 2 страници де: https://www.mikrocontroller.net/attachment/28831/siemens_AP2921.pdf