Programowanie komunikacji RS485 w języku C podobieństwa do RS232?

"Mariusz Dybiec" <mardyb@poczta.onet.pl> wrote in message
news:co2h1u$56c$1@atlantis.news.tpi.pl...
(...)

Jeśli full duplex to nie będzie RS485 tylko RS422. Jeśli jednak

RS485

czyli 1 para to dzięki "sprzętowemu" zwalnianiu magistrali nie

masz

echa.


zalezy czy "sprzet" zwalnia W gotowej karcie albo konwerterze
No tak ale on ma gotową kartę.
232/485 moze byc zrobione tak jak mowisz (w konwerterze nawet jest
to calkiem zrozumiale ), ale np. scalony driver we wlasnym
urzadzeniu mozesz podlaczyc roznie - uzywajac czegos do przelaczania
nadawanie/odbior lub nie.
Jeśli lubisz bohatersko przezwyciężać przeszkody które sam sobie

dla mnie) takie zle - mozna np. programowo sprawdzac kolizje w
systemie multimaster czy tez po prostu kontrolowac sprawnosc drivera
i linii.
No tak to jest twój świadomy wybór. Ale jak gość weżmie kartę 485 i

Piotr Gałka wrote:


W RS232 są osobne tory w dwie strony, a tu jest jeden wspólny.
W RS485 ramki mogą się "zderzyć" i trzeba to jakoś rozwiązać.
Nie mogą jeśli to jest RS485 bo wg standardu musisz zastosować
Master-Slave. Slave nie może nadawać spontanicznie tylko jest
odpytywany.

Nie będę się upierał ale nie przypominam sobie żeby EIA/TIA-485
dopuszczało więcej niż jeden master. Na 75176 obciążonym 50ohm
możesz
sobie rzeźbić dowolnie ale to nie oznacza, że efekt będzie zgodny z
RS485 czyli "Recommended Standard".
W tym przypadku gość ma dość prosty układ - miernik który pewnie nie
jest masterem i pc który może i powinien być masterem. Pisanie mu o
wersjach RS485 dwu i czteroprzewodowych o echach i kolizjach jakie
muszą
towarzyszyć wersji 2 przewodowej wprowadza chaos pojęciowy.

Jeśli lubisz bohatersko przezwyciężać przeszkody które sam sobie
tworzysz. Mi do tej pory wydawało się to proste. Jeśli robie
urządzenie
odpytywane zdalnie przez 485 ( czyli 1 parka) to ono ma nasłuchiwać
na
linii. Jak dostanie komendę to przełączy się na nadawanie, wypluje
wynik
i znowy zacznie nasłuchiwać.

Użytkownik "Mariusz Dybiec" <mardyb@poczta.onet.pl> napisał w
wiadomości news:co3a1b$ac9$1@nemesis.news.tpi.pl...


Jeśli lubisz bohatersko przezwyciężać przeszkody które sam sobie
tworzysz. Mi do tej pory wydawało się to proste. Jeśli robie

urządzenie

odpytywane zdalnie przez 485 ( czyli 1 parka) to ono ma nasłuchiwać

na

linii. Jak dostanie komendę to przełączy się na nadawanie, wypluje

wynik

i znowy zacznie nasłuchiwać.


Za proste. A jak to jest czujka alarmowa to będziesz ją odpytywał 10x
na sekundę (zanieczyszczając środowisko naturalne falami EM i
zużywając zasoby energetyczne globu ) aby raz na 10 lat dostać
odpowiedź.
Ja bym ci radził podłączyć tę czujkę przez GPIB

Użytkownik "Mariusz Dybiec" <mardyb@poczta.onet.pl> napisał w
wiadomości news:co2hjk$gno$1@nemesis.news.tpi.pl...

Piotr Gałka wrote:


W RS232 są osobne tory w dwie strony, a tu jest jeden wspólny.
W RS485 ramki mogą się "zderzyć" i trzeba to jakoś rozwiązać.

Nie mogą jeśli to jest RS485 bo wg standardu musisz zastosować
Master-Slave. Slave nie może nadawać spontanicznie tylko jest

odpytywany.

Według jakiego standardu ?
Standard RS485 nie definiuje żadnego protokołu komunikacji, za to
wymaga, aby nadajnik wytrzymał zderzenie z drugim nadajnikiem.
Owszem nie definiuje protokołu ale zaleca konfigurację Master-Slave.
Odpytywanie to najprymitywniejszy protokół komunikacji.
A jeśli jest 256 Slave-ów, które sporadycznie (raz na godzinę) mają
coś do wysłania, ale powinno wtedy być jak najszybciej (na przykład
kilka ms) i linia powinna jak najmniej siać zakłóceń.
To już nie będzie Master-Slave

P.G.

Za proste. A jak to jest czujka alarmowa to będziesz ją odpytywał
10x
na sekundę (zanieczyszczając środowisko naturalne falami EM i
zużywając zasoby energetyczne globu ) aby raz na 10 lat
dostać
odpowiedź.
Ja bym ci radził podłączyć tę czujkę przez GPIB