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

С LIN съм правил само един прототип, 2 master конролера + 5-6 slave. Заработи в саксийни условия. Без да се напъвам особено. Иначе LIN също е правен за коли, 12 волтов е, би трябвало да държи на доста здрави смущения. Обаче народа масово минава на CAN. Включително и аз. Само дето там програмите са доста страшнички. Много нещо има да се инициализира и следи. Един ПИК има към 100 служебни регистъра с общо предназначение, а само за CANа са към 200

Аз съм правил веднъж нещо подобно с RS485

RS485 разделено с галванични разделители на AD. UTP кабел за Lan беше кабела за връзка. Всяка крайна точка с 2 конектора в паралел. Един да влезе линията един да излезе. Ключе за включване терминираща верига е удобно да бъде изведено на всяка точка и при монтажа да се щтракне само на крайното по линията.
Захранване на крайните точки по линията през DC-DC а на PH чиповете на крайните точки директно от линията.

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

Захранването на всяка крайна точка минава през самовъзстановяващ се предпазител последователно с нормален на по голям ток или резистор с такава функция /това го разбрах след първата сериозна гръмотевична буря че трябва да е така/.След предпазителите супресор.

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

В общи линии това е изпълнението на RS485 за тежки условия. Това съм го правил за обект където често падат мълнии наблизо и връзки около 100 метра устройство до устройство като имам и репитери с които линията е около 3 км в единия си клон. Преди повече от година е пуснато в експлоатация след въвеждането на допълнителния предпазител поддръжката на системата си я прави щатния им техник. Понякога някой предпазител или резистор да смени и това е.
И е правено с АТMega16 ки които определено не са най устойчивите контролери като за тази цел.

И не правете като мен. Като правите надежна техника и не сте си прибрали парите залагайте софтуерни капанчета. Още не съм си прибрал по голямата част от парите от това :)

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

благодаря за мненията!

Само предложение ! От доста време ми се върти в главата да закакча един CAN трансивър към UARTа на някой контролер. Ама пусто все няма време. На пръв поглед ми изглежда добре, няма нужда да се изключва чипа за икономия на ток, държи до +/-40V. На втори поглед ми мяза на петниста махараподаба. Ще ми се някакво странично мнение.

от КАН по готино нем аако трябва да е 6умоустои4иво.

на лоу спеед кан -до 130кбит в секунда по спецификация на кан може да опане6 и 100 метра кабел.
аз ли4но имам неста за коли- имат и 2 та и бавен и бърз кан и са тествани на стандартни тестове.
На едно от изделията ми изкарва до 270 Волта на мертър обла4ване в огромен 4естотен спектър -от 1мега херц до 2 гига херц

а и ако ползва6 кан -НЕ ползваи микро4ипски ИЦ та -големи болклуци са.
Специално за трансиверите -по готини от Филипсовите в момента няма.

бавен кан - TJA1054 ili 1055
за бърз - TJA 1040 ili 1041

изпитани са многократно.

Ако позволите едно мнение, струва ми се, че тук се смесват физическото и протоколното нива.
Що се отняся до физическото - 485 (422 - duplex) си е напъно достатъчно. При шинна организация,
обаче, ако някой нод се скофти и реши да предава нон-стоп, нищо не те спасява, освен ако не
се предвиди някакво външно управление на захранването, чрез което да ги изключваш един по
един докато откриеш гада, но се предполага, че това е мнооогоооо малко вероятно.
Що се отняся до протоколното ниво, ако не ти трябва някакъв стандарт, не се занимавай с CAN, LIN, PROFY и т.н.
Според мен това са много тежки протоколи, които строго погледнато, като че ли са създадени само, за да
хранят създателите си и да ограничат достъпа до съответните проекти - мое мнение.
Ако ще правиш нещо, в спецификацията на което изрично не е заложено използването на някой точно
определен протокол, напиши си свой със съответните чек суми, кодиране на данните, ако е необходимо и
потвърждения на пакетите. Той във всички случай ще заеме по - малко ресурси и ще отговаря по - точно на
конкретните ти необходимости. А физическото ниво би могъл да го решиш с който и да е диференциален
трансмитер. Ако държиш 100% при сгафване на някой от тях, системата да остане работоспособна, предвид
малките разстояния и малкия брой нодове, би могъл да ги разделиш на отделни кабели с един мултиплексиращ се UART.