Kommunikation i hemmanätverk mellan µc:s typ RS232

[rickardg]

med en sådan fast delay blir det problem med varierande paketlängd alternativt går det inte packa paketen lika tätt

det löses iofs om man läser in hela headern och räknar ut en mer anpassad delay från det så blir det möjligt att packa paketen tätare, kräver dock separat CRC för headern för att det inte ska bli felaktiga delayer om det kommer en störning.

något som däremot är svårt att komma ifrån är att om sändaren själv upptäcker en kollision (vid sändning läser annat än vad den skriver) så är det inte bara att avbryta och börja om som man kan vid 9-bits kommunikation utan måste skicka färdigt eller vänta lika länge som om paketet skickats

men å andra sidan har du kanske inte så höga prestanakrav så en fast delay duger fint å då blir det enklare att utveckla så projektet kan bli färdigt inom rimlig tid

[E85]

När jag behöver skicka 8-bitars värden med 8-bitars uart brukar jag dela upp i två bytes. bit 7:5 kan t.ex vara kommando, bit 4 vilken del av datan som skickas och bit 3:0 datan.

0bKKKNDDDD

Om kommando nr 3 ska skickas med datan 0b010001011 så blir det alltså två bytes:
0b011 0 1000
0b011 1 1011

[MiaM]

Du råkar händelsevis inte mena 75176 (tex 73-149-66) instället för 75186?

Jo, jag måste ha hållt fingrarna ett steg för långt åt höger på tangentbordet...

.... var inte krav på 15kV utan snarare att 2kV verkade vara för lite då några procent av drivkretsarna dog i (ej ESD-säkrad) labmiljö, problemet försvann efter uppgraderingen till tåligare kretsar, sen om det var själva ESD-tåligheten eller att kretsen var allmänt robustare vet jag inte.

Intressant! Jag har varit med att bygga ljus-prylar som använde 75176 för DMX-512 över XLR-kontakter, och de prylarna användes vad jag vet ett antal år utan problem med att kretsar pajade. Alla kretsar som pratade DMX512 hade gammal "tung" transformator och var helt galvaniskt skiljda från allt annat via optokopplare. DMX-sändaren byggde vi iofs inte själva, där användes en Westermolåda (loppisfynd, tror jag).

Det där med galvanisk isolering har kanske lite med ESD-tåligheten att göra också? I alla mottagare satt det minst en halvmeter kabel mellan XLR-kontakterna och 75176-kretsen. Det kan kanske vara så att kapacitansen i den kabeln ökar ESD-tåligheten en del genom att spikarna delvis leds över till kabelns skärm = signaljord, och sedan lyfts potentialen på hela mottagarelektroniken delvis av ESD-urladdningen.

Jag inser nu att jag vet faktiskt inte var eventuella överslag sedan skett vid enormt stor ESD-urladdning. Både den klassiska nättrafon och utgångarnas optokopplare var goda kandidater här...


Iofs så har det här bygget använts mestadels på sommaren (dessutom utomhus), då är ju ESD-problemen som minst.

nackdelen är att det inte går att använda en sådan konverterare du köpt för att kommunicera på bussen med då PC-uart:er inte stödjer 9 databitar.

Jag googlade lite, det verkar faktiskt som att den gamla 8250-UARTen (och därmed troligen dess efterföljare) klarar 8 bitar plus "mark/space"-paritet. Om man kan leva med att behöva "byta paritet" varje gång man växlar mellan data/adress så går det nog att få sändningen att funka. Mottagningen kan ju ske med bara 8 bitar. Antagligen inte så jätteeffektivt, men ändå... Däremot är väl frågan om dagens drivrutiner till serieportar på PC faktiskt fortfarande klarar mark/space-"paritet"? (Jag inser att jag inte orkat googla på om paritetbiten sänds först eller sist, men antar att den sänds på slutet, strax efter MSB, och då "ersätter" den 9:e biten).

Går det inte att ställa om 9-bit-kretsarna till att köra 8 bitar men ändå låta högsta bit'en styra interrupt?

Man kan ju enkelt säga att om startbyte och adress inte detekteras korrekt så skippar man att kolla på kommunikationen på säg 50ms på så sätt slipper man interupta varje byte i kommunikationen.

En variant är att direkt efter adressbyten skicka en byte som talar om hur länge det är läge att "sova". Om alla dina mottagare kommer använda samma krets så kan ju tiden som skickas ut vara i nån "enhet" som passar eventuell inbyggd timer i kretsen, så du slipper göra omräkning i varje krets.

något som däremot är svårt att komma ifrån är att om sändaren själv upptäcker en kollision (vid sändning läser annat än vad den skriver) så är det inte bara att avbryta och börja om som man kan vid 9-bits kommunikation utan måste skicka färdigt eller vänta lika länge som om paketet skickats

Det problemet slipper man å andra sidan om man har två par för kommunikationen, ett där datorn sänder till alla slavar, och ett par där slavarna sänder tillbaka till datorn, och dessutom har ett protokoll som gör att slavarna bara sänder när de blir tillsagda och datorn ser till att inte säga åt mer än en slav att prata i taget (och sköter eventuellt behov av omsändning om det blir knas i alla fall. Nån form av checksumma på headern är nog helt klart att rekomendera. För övrigt kan det väl vara läge att skicka med info om checksummefel (iaf en bit som säger "checksummefel har inträffat") i det som slavarna skickar tillbaka, så kan servern logga sådana fel för att man ska få en uppfattning om hur bra/dåligt kommunikationen funkar...

Edit: la till massor av text och fixade citeringen. Sorry att fel inlägg låg ute såpass länge, under tiden har jag också stoppat det mesta av tangentbordet i diskmaskinen och städat bort spill på skrivbordet...

[v-g]

Så för att då uppdatera och kanske avsluta denna tråd så ska jag skriva vad som blev resultatet:

SUCCÉ!

Först, den 9:e BIT:en fixar man enklast genom att använda paritet. Jag ställer helt enkelt om pariteten i runtime beroende på om jag vill skicka adress eller data. Det fiffiga med detta är att PIC:en totalt ignorerar allt som inte har den 9:e satt om jag uttrycker mig som så. Är den 9:e satt så går den i interupt och jämför med sin egna unika adress vilket går enormt snabbt.

Adaptern jag köpte fungarar iaf helt perfekt och för 25 spänn så var det inte mycket att bråka om precis.

För att kunna köra envägs kommunikation kan man byta rs232-->rs485 rakt av. Ska man däremot "svara" med µC krävs en till pinne som man sätter hög (i detta fall 5V) för att kunna sända dvs man kan inte sända/motta samtidigt (normalt knappast ett problem). Datoradaptern löser detta troligen genom att sätta motsvarande enbart vid sändning.


Nuvarande kod klarar av att växla en lysdiod om paritet=1 OCH adressen stämmer annars gör den inget alls. Koden är väldigt enkel och det bästa är att hårdvaran sköter allt dvs PIC:en borde inte beröras nämnvärt om man skickar massor med data på porten. Interuptkoden är nämligen endast ett par rader (förrutom de obligatoriska raderna då).

Känner mig rätt nöjd med dagen

Tack för alla som hjälpt mig i tråden! Hoppas någon kan ha nytta av denna någon gång.

[blueint]

Hur är det med störningstoleransen på långa ledningar?, samt hur hanteras förvanskade bitsträngar på linjen?, multi-drop, duplex?

[v-g]

Återstår att se

Just nu är ledningarna c:a 15 centimeter och ännu inga problem