Някои може ли да даде линк към информация как да спретнем протокол за връзка между няколко устройства контролерчета през UART.
Пробвах да напиша нещо написах го но не успявам да го подкарам. Та си мисля ако взема и да прочета някъде как става как с еправи как да разсъждавам за да го направя и може да успея.

Най-простичкото > на пакети + LRC/CRC или примерно MOdbus< което е поооооочти същото , но зависи до каква степен го имплентираш / направиш
може да си орежеш FC , но защо пък да не си леко стандартен с MOdbus и който се върже да може да разбира какво става

Аз използвам S.N.A.P. - > http://www.hth.com/snap/

Интересно ми е как мислиш физически да свържеш няколко устроства по UART ( модем ли ще използваш, 485 ли, или нещо от сорта )

Ами зависи доколко искаш да си стандартен, в най-простия вид ,
старт байт 0xFF
получател 0xAC
дължина на пакета 0x06
данни 0x01
0x02
проверка CRC
CRC

като в зависимост от случая може а е по удачно плучателя да е след дължина на пакета, а и може да ти трябва и адрес на изпращача. Щом ще е RS аз бих ползвал и подмяна на байтовете което и да не е пак е добра идея. Примерно старт байта ти е FF и за да можеш да го различиш от данноте го правиш FF FF. Навсякъде в анните ако имаш FF го заместватш с FF 00 да речем, такак еднозначно с еопрееля старт байт и FF като число. Но това е малко по сложно, за момента прсто подкарай да си комуникират.
А за RS зависи какво искаш да направиш, ако ти работят на полиране, и един комуникира със всички тогава има някакви шансове само с 232 а минеш, за не големи дължини. Tx на полиращия към всички Rx, а всички Rx към Tx на полиращия. Тук обаче има едно елко дръвце, то пак няма да можеш да запазиш RS в оригинлниа му вид заради нивата, ще тябва да го смениш с токов кръг или нещоподобно .. което са малко .. безсмислени неща, най-добре 485 .. е или CAN . къето мнго от въросите които ще имаш са решение, но пък ще с епоявят други

Ами имам мастер устройство и 2 слейв. Мастер TX към RX на слейвовете и обратно слейв TX овеет към RX на мастера. Мастера праща пакет той съдържа инфо за кой слейв е и слейва реагира другият си трае. И обратно за да се получат данни от слейва към мастера първо мастера праща заявка за данни и после чака да му ги прати слейвът който е потърсен.
Тъй като това го правя чрез операционна система защото не успях да го реализирам без нея и сега имам проблем с приемането на данните от слейва. Получавам някви забивания рестарти и тн.
Та се надявах да се дообразовам може да открия какво пропускам.
Аз се надявах да открия нещо готово и лесно за внедряване ако съществува. Иначе ще си дебъгвам като пич до откат.
Най кофти е че на симулатор не се дебъгва както трябва т.е става хавата до колкото може да се зимулира. Но на платките е друга работа мистика

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

Не е задължително да са в тоя ред, както ти е по-удобно.

В приемника използвам прекъсване от USART. При приемане на байт пускам таймер, който отброява времето за приемане и нулирам указател към елемент от структурата. При приемане на първия байт прочетеното от USART слагам в ID, при втория слагам прочетеното в DLEN, при трети в CMD и така до запълване на цялата структура. При последния приет байт, правя изчисление на чексумата от приетия пакет и сравнявам с тази, която съм получил от самия пакет. Ако двете чексуми съвпадат, вдигам флага "valid". Ако случайно при комуникацията нещо се обърка и получа някой от елементите на пакета грешно (например получа грешна дължина на пакета) или чексумата излиза грешно, или изтича времето за комуникация, с което чистя флага valid. Оттук нататък обработката на пакета става лесно, примерно в главното тяло на програмата проверявам за флага "valid" и при вдигането му изпълнявам съответната команда.

Проблема е май в TxD линията на двете слейв устройства, не в софта. На TTL ниво ли правиш връзките ? Или през модем ? Щото няма как да свържеш изходите на 2 UART-а на TTL ниво (или RS232 ниво) към входа на трети и да искаш да не забива. 2-та изхода ще се бият по между си и който е по-силен той ще надделее. Евентуално можеш да ги свържеш серийно, изхода на първия влиза във втория, неговия изход в третия, изхода на третия във входа на първия. Слагаш адреси на устройствата и ако пакета не е за него, го препраща на следващото. Недостатъка е, че се препредават пакети от едно у-во на друго.

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

Отностно ОС, мисля че в този случай въобще не ти трябва такова животно.

Със S.N.A.P. съм правил управление на множество устройства по RS485, протокола е изключително елементарен, същевременно позволява лесна надстройка, въобще замислен е доста добре. Програмната реализация е точно както Predator_MF я описва, с тази разлика, че не използвам таймер, ами имам главен цикъл от 10ms на програмата, през който цикъл се завъртат всички задачи, като изтече един такъв цикъл броя времето от получаването на последния байт от протокола, ако е изтекъл timeout нулирам входния буфер и започвам да чакам на прекъсване от начало.

[quote="Predator_MF"]

В тоя вид структурата има размер 2048 + останалото. Наистина ли я предаваш цялата в тоя вид?

Ми направил си ... , аее открил си топлата вода , колега
сори , обаче дефакто е така, кофти е като го чуеш , но и на мен ми беше , не затова го казвам де.
КАзах го защото знам как ще реагираш и дано се усетиш , та ... на въпроса и по темата.

Modbus ASCII/RTU е твойто, но (1) в по-отчетлив вид, (2) стнандарт, (3) ходи по почти всякакъв интерфейс (даже си има Modbus Ethernet Ли беше -> т.е за ethernet мрежа лека модификация ... , абе не е лека

Та тъй

Аз лично почнах да си правя каквото има комуникация -> с modbus< вярно не са много неща - даже хич засега, но така всеки инжинер, дори подръжка с лаптоп ръга com, RJ11, RJ45 , каквото се сетиш и воаля.
гледа таблицата с FC и му става ясно

едит: м/увпрочем тук се вижда разликата м/у истински ANSI компилатор и наще истории Къде е динамизното заделяне или дори да го ползваш има мнооогоо условности.
Предатор аз лично бих подходил по друг начин, но ти пак ще тръгнеш с рогата напред .

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

Рек, не пълня цялата структура, масива "data[2048]" го пълня с това което получа по канала, ако получа 1 байт, пиша само в първия елемент. Кода го извадих от един тестови проект с ARM7, с който си играя в момента, въпреки това съм го използвал на много места, просто споделих моето виждане. Мога да го напиша с динамично алокиране на памет, може и с указател към буфер, в случая съм го написал така заради улеснения в debug-а...принципно, ако искаш и 10 байта можеш да си отделиш. Сигурен съм, че има хиляди стандарти, като Modbus, I2C, S.N.A.P., ZigBee и пр...аз използвам това, което показах.

@the_real_maniac
АБЕ МОМЧЕ! Извинявай, оценявам професионализма и познанията ти, но аз не го правя за да може всеки инженер да се закачи с лаптопа към шината и да слуша. Е, повЕрвай ми, не беше преоткриване на топлата вода. Ако смяташ структурата ми за нечетлива, погледни какво си написал над този пост, според мен това е доста по-нечетливо ...приятел, искаш да кажеш, че тоя протокол не мога да го пусна по всякакъв интерфейс ? ethernet...USB...USART...RF... ??

Аз също ползвам нещо подобно на Predator_MF-то като и аз му променям дължината на буфера според зависи от проекта.
Маниак - наистина на човек му е доста трудно да разбере какво пишеш и искаш да кажеш. Сега - разбираме, че си заобграден от красиви и същевременно умни колежки - ама дай го малко по-спокойно, та поне да можем да ти разбираме . А ти и самичък ще установиш след време, че жена и техника са две несъвместими понятия и това, което ти се привижда сега, не е това, което ще стане с тях след като завършат . Т.е. искам да ти кажа - говори си за MCU-та с пичовете - с колежките други неща можеш да правиш .

Predator_MF: не се коси, аз го ползвам от как са помня, дори последно го ползвах за UDP обмен...

Ми ок , извинявай, не съм те разбрал. Мислех че говориме за някакви сериозни контролери, което не значи че не са, но с възможност за визуализация (както аз го наричам , а мисля и така се води).

И в този случей никой не казва да допускаш Function(CODEs) за управление, само да се чете.

-> мене ми е още малко кипнало от http://www.hardwarebg.com/forum/showthread.php?t=90367 ,така че ако ми си се обидил да знаеш ( ама мразя да го казвам така->):
имам respect към хората тук , поради простичките причини -> опит и знания, и отношение (Разбира се), а не просто заради години(те Ви)
Звучи сухо така

едит: човек не казвам , че не можеш да го качиш ... можеш и по сателита да го пращаш се тая.
Говорим , че хората (направили / стандартизирали modbus) са си направили труда да направят modbus + и modbus Ethernet, за ethernet приложения като са взели някои специфични елементи на такава комуникация, изисквана скорост, прилжения и прочия.
А ти само ще сменяш хардуерния носител, всичко си остава същото, това е
А и пак казвам , ще дойде някои инжинер след тебе (примерно) и ще се закачи и нищо (говорим за визуализация, статус дори)

Дори ТИ БЕ ЧОВЕК !
Теглиш една от хилядите /айде 100-ната/ free modbus explorer-а и бам готово.
КОЕТО И ДА Е PC със съответният интерфейс.
А иначе твоята си програма ! примерно/или през JTAG,RS/SPI/ISCP прочие

Ами аз лично избягвам да позлвам готови неща, още повече универсални такива, това не е РС, не е етхернет комуникация, въпреки че и там "стандартните" неща не винаги вършат работа както показва практиката.
Това кето предатор ползва, е сигурно в основата и на този протокол който споменаваш, то реално, няма друг начн да организираш протокол, това което той е дал са стандартни елементи без които не става, как ще ги подредиш, как ще ги кръстиш и в какъв ред ще ги предаваш е според приложението. Относно мрежите, ами на пдобен протокол има навързни .. вече не помня, мож би стотина контролера едни силози, пусат е преди ....... май 6 години, писан е на Ф84 и Ф877 за концентратор .... и си работи перфектновсичките тия години. Този протокол съм му праивл един куп модификации, и в една согурно прилича на този на предатор, в друга на неий друг ....по важното според мен е човека да осъзнае как работи, основните принципи а другото ....

Струва ми се, че заорахте темата в неправилна посока. При това свързване, 2 TxD линии на късо към една RxD на 3 UART модула, каквито и протоколи да разпишете, каквито и буфери да използвате, протокола ще се продънва