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

Аз ползвах на времето Simatic NITP (Non-Intelligent Terminal Protocol)

http://www.hth.com/snap/ - това е лесен и бърз за изпълнение протокол

Това, което ми бърка в г.за е халф дуплекса, тоест необходимостта от превключване между приемане и предаване и, съответно, логика, която да решава кое у-во да предава.
Дали има фул-дуплекс 485 чипове?

Има. Ще ти трябват разбира се 2 усукани двойки.

Но двата проблема "превключване между приемане и предаване" и "кое у-во да предава" са отделни. Пълният дуплекс решава първият от тях, а вторият само в частния случай на point-to-point връзка. Ако имаш повече от 2 устройства на шината ще трябва и някакъв начин да се регулира достъпа до споделената медия.

Колко у-ва имаш на шината ? На каква скорост ще предаваш ? Колко пакета в секунда, с какъв размер са, контрол някакъв имат ли ?

Най-простия начин за регулиране на достъпа до средата е всяко у-во да следи за активност и когато шината застане в idle mode да отброява някакво време, умножено по адреса си на шината, след което време ще може да предава. При малко на брой у-ва ( да речем 10-15 ) и при малки пакети ( 20-тина байта ) няма да се забележи несъвършенството на алгоритъма за достъп до средата.

RS485 по дефиниция е half-duplex, не съм виждал full duplex.

Да, ама на това му се вика RS-422. ADM2487 може да свърши работа, ако трябва да е изолиран.
При 485 няма начин да имаш full duplex, защото два активирани предавателя по една линия се сбиват - получава се колизия.

Нека дефинираме какво е фул дуплекс. От прочетеното в постовете на Реконструктор-а мисля, че той няма в предвид "фул дуплекс - т.е. едновременно приемане и предаване в двете посоки, а по скоро пита за това как да не се превключва 485 чипа в режими на предаване и приемане. (ако правилно съм схванал идеята де).

Ако говорим за по-горе описаният вариянт - решение има, но с известни ограничения.
Идеята е на 485 чипа винаги да му е разрешено приемането (RxEnable - active), а Предаването да се разрешава само. когато Тх = 0. Т.е. TxEnable на 485 чипа се свързва към TxData на процесора, а TxData входа на 485 чипа се забива на маса (не помня нетрябваше ли да се инвертира някой от тези 2 сигнала). В този случай 485 линията ЗАДЪЛЖИТЕЛНО трябва да се "поляризира", а не само да се терминира. По този начин когато трябва да се предаде "1" - то тя се получава на бъс-а от поляризиращите резистори. Когато трябва да се предаде "0" - то изхода на съответният 485 чип се разрешава и той обръща поляритета на линията. Т.е. идеята е схемата на мрежата да се модифицира и да стане с "ДОМИНАНТНА НУЛА" (подобно на CAN-а) . Е, разбира се протокола трябва да не е колижън фри (т.е. трябва да решава проблемите с колизиите при едновременно достъпване на линията на 2 и повече устройства), но това не е чак такъв проблем.
Друго ограничение е баудрейта. Той е лимитиран и зависи от стойностите на поляризиращите резистори на 485 шината.
По подобен начин имам изградени мрежи, които работяд на 62500 bps на разстояние 150м.

За мен това е напълно достатъчно. Даже и по-малко би свършило работа, нямам чак какво толкова да предавам, наистина.
Как си реализирал протокола?

Аха, става въпрос за auto enable на драйвера значи. Ето тук е описан малко по-различен подход (фиг. 4 на стр. 4):

http://www.embeddedsys.com/subpages/res ... _RS485.pdf

Относно протокола - Формата на фрейма е:
1-ви байт преамбъл - 0х00
2-ри байт -Адрес на получателя
3-ти байт - Адрес на изпращача
4-ти байт Дължина на следващите в пакета данни
5 - N-ти - Данни
N+! -ti байт Simple CRC

Бъса не е колижън фри. Всеки трансфер започва след GAP ("тишина" по линията за 1mS) Следва фрейма описан по-горе. След това АКНОЛИДЖ фрейм от получателя, като времето между фрейма и акнолиджа трябва да е по-малко от GAP времето (За да е ясно, че това е акнолидж).

"Мастера" на линията (протокола е мултимастер) след като открие гап започва предаването на преамбъла по бъс-а. Той следи ехото на всеки един изпратен байт и проверява дали е такова, какъвто е и байта. Ако настъпи колизия - то ще е различно. В този случай той трябва да "рестартира" предаването, да изчака намирането на GAP и след това отново да започне предаването.

Както забелязвате - теоретично колизия може да настъпи само в първият момент след "излизане" на линията и то по времето на първият ( и вторият) байт от пакета. (Е, разбира се некоректно работещи устройства могат да омазват бъса по всяко време, но нека за момент се абстрахираме от тях). Та "мастера" ако коректно получи ехото от първите 2 предадени от него байта - приемаме, че той е спечелил арбитрацията и колизия няма. Предават се и останалите байтове от пакета. Те могат да се предадат и пакетно (с DMA) с компромиса, че не се следи за колизия повреме на предаването им. Пък ако искаш - не използвай ДМА, предавай байт по байт и следи за ехото му.

Важното при протоколите с колизия е, че колизиите не са страшни, независимо кога се получават. При коректно работеши устройства - те се получават само в началото (първите 2 байта). Дори да има за момент колизия - приемника приемайки пакете ще изчисли грешна CRC и няма да отговори с акнолидж. Тогава "мастера" ще повтори грейма (повторения от по 10 - 15 пъти е предостатъчно). 485 бъса е "доработен" да е с доминантна "0" и нищо няма да изгори при колизия, така че проблем няма.

Ключов момент е намирането на na GAP на линията. Разбира се вариянтите са много и са специфични за конкретната имплементация на UART-a в съоответните микроконтролери. Някои имат статус флаг "започна приемане" (открит е стартов бит) - други нямат такъв. Няма да се впускам в подробности, тъй като многообразието е голямо.

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

@Реконструктор

Винаги когато използваш някакъв вид многоточкова линия, трябва да държиш сметка за това кой, кога и как ... . Освен това при токовите кръгове, винаги има паузи след предаване за утихване на линията, т.е. не трябва да се включва друг предавател преди да е минало време, мин. равно на продължителноста на един байт. Имам схема на преубразувател RS232 - 485, който работи както в автоматичен режим, така и драйвера да се управлява от сигнала RequestToSend на RS232 интерфейса. Изпробвано е и работи безотказно. Между другото Рек, използването на полудуплекс при токовите интерфейси си има своите предимства, напр. по време на предаване и приемника може да е включен, при което се получава ехо, и то от страната на усуканата двойка, т.е. може да се контролира интерфейса, защото ако линията е прекъсната - ехо няма как да се получи. Ако те интересува или ако някой друг го интересува, ще постна схемата. А по отношение на протоколите: все си мисля, че създаването на собствен протокол, съобразен с конкретното приложение, е най - добре. Ако искаш все пак да използваш пълен дуплекс, тогава трябва да използваш чипове за RS422, но това както сам разбираш, не значи че slave устройствата могат да си предават кой когато си иска. По принцип, ако имаш нужда подчинените ти устройства да си пращат пакети по тяхна инициатива, то тогава се използва текнологията first-listen-then-speak, като се използва ехото, за да се види дали няма колизия на линията, и ако да, то малко пауза, рзлична във всеки slave или пък случайно избрана, решава въпросът. Ако използваш стриктна технология въпрос-отговор, нямаш никакви проблеми.

Незнам защо, но такива протоколи някак не ги възприемам. Генерират много ненужен трафик по линията, а и "евентите" от крайните устройства пристигат до сървъра с някаква "латентност" зависеща от периода на полирането им ... Ако латентността трабва да е малка - полирането е много на често - и по линията в 99% от времето върви някакъв "ненужен" трафик ...
При мултимастер протоколите линията през повечето от времето е "тиха" и не тече никакъв трафик. Е, от време на време - да кажем през минута или десет - устройствата могат да се супервизират, но и това е опционално. Та така през повечето време процесорите (ако приложението позволява де) могат да са в някой от слип режимите (позволяващи буденето им по приемане от UART-a)и като цяло консумацията на системата драстично да се намали. Някак си това ми изглежда по-елегантно решение, като в същото време софтуера по протокола не се усложнява кой-знае колко ...

Има още един вариант - token ring, където всеки Out е свързан с In на съседа. Пуска се адресиран пакет, който се препредава между устройствата, докато не стигне получателя.
Изобщо, варианти много, но ми трябва нещо просто и готово, както казах, не ми се пише такова нещо. В крайна сметка, ако не намеря нищо, просто минавам на варианта USB с едно PC като хост и се приключва.