RS232 <-> RS485, Hur kontrollera DE?

Croaton · Inlägg av **Croaton** » 16 augusti 2006, 23:58:11

Hejsan,

jag har länge tänkt bygga ett RS485 nätverk i huset för att kunna mäta / styra diverse saker. Min idé har alltid varit att använda en Linux server som bus-master via en RS232 till RS485 konverter, och på så sätt lätt kunna logga / styra olika enheter i RS485 nätet.

Från början tänkte jag köra ett duplex system med 2st trådpar för rs485 data, men ju mera jag tänker på det desto mer sugen blir jag att köra simplex med endast ett trådpar... Problemet är att jag i så fall måste kunna kontrollera RS485 drivarens "Driver Output Enable" (DE) pinne på ett vettigt sätt.. och det är här som elektronikforumets eminenta medlemmar kommer in i bilden

Efter lite googlande så har verkar det som om det vanligaste är att man använder RTS pinnen för att kontrollera DE på rs485 drivaren. Detta verkar ju vara en vettig lösning om jag lyckas kontrollera RTS pinnen från ett C prog...

Någon som har synpunter / förslag på en bättre / smidigare lösning än detta?

/Nicke

cyr · Inlägg av **cyr** » 17 augusti 2006, 00:11:34

Om du har USB på servern så kan du ta en FT232BM. Den har en pinne för att automatiskt aktivera en RS485-driver (kolla databladet).

Croaton · Inlägg av **Croaton** » 17 augusti 2006, 07:36:16

cyr: Det där såg ju intressant ut, har du testat det själv?

/Croaton

vfr · Inlägg av **vfr** » 17 augusti 2006, 09:58:17

Att styra stroben (DE) via RTS på PC brukar fungera sådär. Problemet är att det är svårt att få den att släppa precis när meddelandet är färdigskickat. Detta gäller, vad jag har sett iallafall, både Win och Linux. Det som händer isåfall är att du får busskollisioner med svaret på det meddelande som du skickade ut om man inte har väldigt långa tider mellan meddelandena. Och har man långa tider så blir inte bussen speciellt väl nyttjad.

Lösningen är ofta att sätta en lite mer intelligent omvandlare mellan RS232 och RS485 på PC-sidan. Har man en omvandlare med datastyrd strobe så funkar det. Vill man bygga detta själv så kan man göra det enkelt med en monovippa (74HC123 t.ex) som triggas av seriedatan och sedan håller stroben aktiv ca 1-1.5 teckenlängd (beroende på bithastighet) efter sista 0-biten i dataströmmen.

Problemet med denna lösningen är att man inte vet säkert när sista 0-biten i meddelandet kommer. Det kan vara första biten (startbiten) om man sänder $FF eller t.ex sista databiten om man sänder något med högsta biten=0. För att vara säker på att stroben alltid är aktiv minst hela teckentiden så får man utgå ifrån första fallet och lägga tiden på minst en teckenlängd. Sänder man då något med nolla i sista databiten så kommer stroben istället att ligga aktiv nästan en teckenlängd efter att datan är färdigsänd. Eftersom RC-länkar ofta är ganska dåliga på noggrannheten så sätter jag den ofta till ca 1.5 teckenlängd.

Eftersom stroben ibland kan bli längre än nödvändigt, så måste man fortfarande säkerställa att nästa meddelande (t.ex. svaret) inte börjar skickas innan strobetiden hunnit gå ut. Denna tid blir dock avsevärt mycket kortare med den här metoden. Med 1.5 teckenlängd i strobetid så kan se till att ha t.ex minst 2 teckentider från mottaget meddelande tills man börjar sända igen.

Den allra snyggaste metoden är att hålla reda på startbit och räkna databitarna för att sedan släppa stroben "exakt" vid rätt tidpunkt. Kan göras med t.ex en liten PIC10F som sköter den biten i omvandlaren. Men det är överkurs i det här fallet.

cyr · Inlägg av **cyr** » 17 augusti 2006, 16:30:11

Jag har inte testat FT232BM-varianten själv nej, men det såg smidigt ut.

Fördelar är att man får matningen i samma kontakt och man behöver inte tänka på att styra datariktningen alls - bara skicka data.

vfr · Inlägg av **vfr** » 17 augusti 2006, 16:43:45

USB-kretsen är en intressant lösning där det faktiskt tillför ett mervärde att köra en virtuell comport istället för den riktiga.

Det jag saknar i deras datablad, iallafall vad jag kan se, är hur den här automatiska stroben fungerar och vad den har för timing. Helst ska stroben läggas aktiv lite före själva sändningen och ligga kvar ett kort stund efteråt (typ en bittid eller liknande) för att vara säker på att allting är stabilt under själva sändningen. Detta verkar det inte finnas någonting om i databladet.

Croaton · Inlägg av **Croaton** » 17 augusti 2006, 20:05:15

vfr: Det låter som om du har arbetat lite med RS485, så jag får helt enkelt lita på dig

Jag har faktiskt läst om timing problematiken på några siter, så jag har förstått att det verkar vara ett "stort" problem.

Grundtanken har varit att hålla ganska låg hastighet på bussen ( < 19200 bps) , anledningen till detta är endast att jag prioriterar korrekthet över snabbhet... det får dock inte vara hur slött som helst

Om jag accepterar att det blir lite slött, är det då acceptabelt att köra med RTS, eller upplever man problemet även vid så låga hastigheter som 9600 bps?

Alttså rätta mig om jag har fel, men egentligen är det ju inte överföringshastigheten som ställer till problemet utan "delayen" mellan det att olika noder skickar data på bussen!?

/Croaton

vfr · Inlägg av **vfr** » 17 augusti 2006, 22:32:03

Helt rätt ang. delayen!

Ja, jag jobbar en del med 485 genom jobbet och vi övergav PC-styrning av stroben för många år sedan. Däremot kommer jag inte ihåg riktigt vilka tider det handlade om. Dessutom hade det en tendens att variera väldigt mycket beroende på vad systemet i övrigt gjorde.

Problemet har myckat att göra med hur UART:en fungerar. Man behöver hårdvarustöd i UART:en för att göra det riktigt snyggt. Antingen ett avbrott som kan utlösas när ett tecken är färdigsänt (i motsats till när det är ledigt för att buffra nytt tecken som man vanligtvis använder). Andra varianten är att UART:en kan ställas in att själv deaktivera RTS-signalen när det är färdigsänt. UART:en som sitter i 68HC11 kör den första varianten medan t.ex Motorolas 68681 UART kör den andra varianten. Vad jag har förstått så saknar 8250 och dess derivat som sitter i PC:n båda dessa möjligheter. Tidiga PIC-processorer i t.ex 16-serien saknar också dessa funktioner.

Har man inte det hårdvarustödet så måste man antingen polla UART:en eller drivern för att se om det är färdigsänt och sedan deaktivera manuellt, eller sätta upp någon form av timeravbrott. Timer funkar ju men är kladdigt och kräver extra hårdvara såväl som stöd i drivrutinerna. Möjligen kan det gå att sätta ihop någon form av hyfsad driver under Linux med dess timerfunktioner, men det är en ren gissning.

Men kör du på antingen USB-varianten eller monovippa. En monovippa blir inte särskilt mycket extrakomponenter.

speakman · Inlägg av **speakman** » 17 augusti 2006, 22:58:47

Jag hade nog kostat på mig ett Moxa CP-132.
Inbyggt termineringsmotstånd (dock valbard genom bygel) och automatisk kontroll av DE.
Dessutom fullständigt kompatibelt med både Windows och Linux. Till Windows finns API för VB, C, m.m.
Det blir inte enklare än så!

Mvh
speakman

Croaton · Inlägg av **Croaton** » 17 augusti 2006, 23:45:59

speakman: Moxa kortet ser mycket trevligt ut, men då kostar det ~1500 SEK också.

Med tanke på att man slänger ihop en egen för några tjugor så känns det lite väl dyrt för ett hobbyprojekt.

Frågan är om det inte är billigast, enklast och bäst att kosta på sig ett duplex system och helt enkelt köra med 2 trådpar för kommunikationen!?

Ett annat alternativ är ju att försöka hitta en billigare kommerciell konverter. Alla förslag är välkommna!

/Croaton

vfr · Inlägg av **vfr** » 18 augusti 2006, 09:31:14

Jag skulle inte köra 4-trådslösning. Mer kabel, mer att koppla, mer terminering, mindre flexibelt. Men det är jag, det!

Kommerciella grejor finns naturligtvis. Westermo Teleindustri har ett bra sortiment med sånt. Men det är inte billigt...