Kollisionsdetekteringsprotokoll för asynkron serielänk

[oJsan]

Ja, som trådrubriken säger... jag har behov av att skicka data (dubbelriktat, halv duplex) på Tip och Cold på en balanserad ljudsignal.
Bitkodningen sker genom att addera 0 eller 5V till både plus och minus-signalen på ljudsignalen... (ljudet förstörs inte eftersom det är balanserat). Mitt problem är hur man bäst skapar ett asynkront seriellt protokoll för dubbelriktad dataöverföring. Det kommer att finnas en "master" och tre eller flera slavar.
Men bortse från ljudet... det spelar egentligen ingen roll att det är där. Jag ska helt enkelt överföra data i ETT gemensamt medium. Skulle lika gärna ha kunnat vara luft (radio).. (annan liknelse är Ethernet)

Grundläggande är (gissar jag) att lyssna och "se" att det är fritt innan sändning påbörjas. Överföringslänken är konstruerad så att den bara går att tvinga låg men inte hög (tänk open drain). På så sätt går det att upptäcka kollisioner genom att lyssna på det man själv sänder.
Är mina antaganden korrekta eller finns det mer att tänka på?
Eller finns det rentav information här på forumet i ämnet.. eller om någon vet någon bra sida på Internet?

Jag vet att det är svårt att förklara på ett bra sätt, så jag har säkert missat något vitalt.. men fråga på bara..

[lgrfbs]

Min idé:
Master sänder ID1
ID1 svartar med sin info + klar signal
Master sänder ID2
ID2 svartar med sin info + klar signal
.
.
.
.
Master börjar om med ID1

[Icecap]

Ska det vara multi-master kommunikation?
Single-master?
Stora datapaket?
Hur många enheter?
Hastighet?
Max. svarstid?
osv.

Precis som lgrfbs skriver: Mastern frågar och rätt adress svarar.

En annan möjlighet är att man delar upp i tidslucker och mastern skicker en synkroniseringslucka regeltbundet, adressen avgör då vilken tidslucka som gäller för de olika enheter.

Ju mer information du ger ju lättare är det att svara....

[sodjan]

> Överföringslänken är konstruerad så att den bara går att tvinga låg men
> inte hög (tänk open drain). På så sätt går det att upptäcka kollisioner
> genom att lyssna på det man själv sänder.

Lite som CAN bussen alltså. Men där är å andra sidan alla "noder"
likvärdiga, det finns alltså ingen "master" och inga "slavar".

I ditt fall är det mycket enklare, (som flera har sagt) låt mastern styra
trafiken. Då behövs ingen kollisions-detektering...

> halv duplex

Jaha, då *kan* du ju inte ha kollisioner, för i så fall är det inte halv duplex...

> så jag har säkert missat något vitalt..

Kanse att du sannolikt aldrig kommer att få några kollisioner.
Det finns ingen anledning till det om du har en master som har
full kontroll över kommunikationen.

[oJsan]

Tack för alla snabba svar!
Ja ni har rätt, jag kanske krånglar till det för mycket... Jag har varit inne på lgrfbs´ idé som ju är enkel. Icecaps förslag om tidsluckor är ju också bra, men de bygger på pollning... frågan är om systemet blir tillräckligt snabbt?
Jag kommar att köra i 1200bps (8N1), dvs 120 byte/s
Med pollningsprincipen:
Om jag nöjer mig med paket om 2 byte (kommando+parameter) så skulle en pollningsloop med tre slavar ta 1/(120/(2*2*3)) = 1/10s.
Det borde räcka för att skicka knapptryckningar från ett tgb, men det lämnar inte inget headroom för vidare utbyggnad med fler slavar...

En viktig sak som inte framgick i första inlägget: varje slav är separat adresserbar (typ ChipSelect), data från slavar skickas dock till alla enheter.

Sodjan:
Definitionsmässigt, vad ger vad?
Om jag ställer halv duplex som krav, får jag då inga kollisioner, eller är det tvärtom... inga kollisioner->halv duplex? Eftersom jag bara har ett (gemensamt) överföringsmedium innebär det att jag måste tillämpa halv duplex (med den bitkodning jag använder).. detta i sin tur innebär ju att jag måste se till så att inga kollisioner sker. Det var så jag menade...

Jag klurar vidare och meddelar fortlöpande!

[Icecap]

Säg att du pollar.

Om du då delar upp i tidsluckor och bara om det finns något skickar slaven något och detta något är kort, typ 1 byte.

Alltså:
Master: "Någon som har något?"
Slav x (vid behov): "Jag!"
Master: "OK, slav x, vad har du?"
Slav x: "Jovars, här rasslar det på..."

Alltså är pollningen begränsat till 1,5 bytes tid/slav + Master sync. (lite glapp tillåtet) = 15 bits * 4 @ 1K2 = 50ms = 20 pollningar/sek.

Stramar du upp tillåtet glapp lite kommer du upp på snabbare svarstid, ett sätt som kommer in i min skalle just nu är att mastern enbart skickar startbitten och de enstaka slavarna svarar med sin respektiva bit via en open-collector kommunikation.

Mastern kollar sedan den inkomna byten: allt annat än 0xFF är request från en enhet om behov av service. Lite klurande behövs för att kunna skilja mellan de olika kommunikationer.

På detta sätt kan du polla 8 enheter på 1 bytes tid = 120 gg/sek

[sebastiannielsen]

men vad händer då om flera svarar på masters första fråga?

typ
"Master: någon som har något?"
"Slav1: Jag!"
"Slav2: Jag *KROCK*"

En lösning är att ha en viss väntetid. Innan ev slav skickar så väntar den (x-1)*20 ms, där x är slavens nummer.

Man kanske kan köra på flera kanaler (om detta är möjligt).
Så slav 1 kommunicerar med kanal 1, slav 2 kommunicerar med kanal 2....
Så kan man ju då oscillera signalen i olika frekvenser. (Ungefär som överföring via elnätet funkar).

*Undrar hur anticollision för RFID fungerar? Där är ju varje tag okänd för läsaren tills den har lästs in.*

[Icecap]

Jag kanske var otydlig men varje slav väntar till "sin" bit är aktuell, alltså svarer slav 0 direkt efter startbitten och blir då registrerat som 0x0-------, nästa svarer (vid behov) på nästa bit och blir då 0x-0------ osv.

Mastern kollar då om denna byte är annat än 0xFF, är den det kollar man varje bit efter slavadressor.

Det blir knepigt att få till timingen men definitivt möjligt.

Edit: stavning.
Men stabilt och säkert och hög hastighet på 1200 baud..... det hänger inte ihop.

[sodjan]

> frågan är om systemet blir tillräckligt snabbt?

Ja, det är nog bara du själv som vet svaret på det...

> men det lämnar inte inget headroom för vidare utbyggnad med fler slavar...

Det är lite svårt att diskutera implemantation om du inte vet
*max* antal slavar du vill stödja. Hur du än gör så kommer det
att finnas en praktiskt gräns för antal slavar...

> En viktig sak som inte framgick i första inlägget: varje slav är separat adresserbar (typ ChipSelect), data från slavar skickas dock till alla enheter.

Förtydliga. Har du en separat CS-linje till varje slav ???
Eller menar du någon slags "adress" ??

Mitt förslag, gör något robust som inte ligger "on the edge". KISS...

[lgrfbs]

Kan detta vara något?
http://www.nmra.org/standards/DCC/stand ... 004-07.pdf
isället för att hitta på hjulet igen....
men och andra sidan alla behöver inte 20" hjule heller

[oJsan]

IceCaps metod att bara skicka EN startbit och låta slavarna addera resten vid pollning, var en bra idé. Men tyvärr faller den på sin komplexitet... det måste vara enklare och jag tror att jag nöjer mig med TDM (time division multiplexing) och utvärderar det först. Då kan jag även använda hårdvaru-UART, (vilket är ett stort plus eftersom det spar klockcykler!)

nmra:s protokol är säkert bra, men också det är för komplext att implementera.
Direktiven i början var "gör det så generellt och anpassningsbart som bara går"! Nu verkar det inte vara så noga längre, så pollning av tre slavar skulle med största säkerhet funka.
Ett litet ovetenskapligt test gjordes nyss där jag konstaterade att jag som mest kan trycka på en knapp ca 8ggr/s som mest. Så pollning med 10Hz är fullt tillräckligt. Minskar jag paketlängden så går det ännu snabbare...
Snyggast vore givetvis ett "riktigt" protokoll av något slag.. men tack ändå för alla ideér och uppslag, man lär sig mycket av att bara diskutera också!

Sodjan: en 74hct125 används för att "addresserar" master-tx-data till EN (eller flera) slav.