Kommunikation mellan kretsar. Val av överföring?
Drivkretsar med automatisk strobe har jag heller aldrig sett. Däremot finns det 485-omvandlare med funktionen inbyggd. Men då är det en monovippa eller mikrokontroller som sköter strobningen. En monovippa blir lite halvdant. Man måste sätta tiden på vippan till strax över en teckentid för att vara säker på att få med alla bitarna. Men har man då 0-bitar i sista tecknet så får man en lite onödigt sen avstängning på stroben.
Däremot kan man ha en mikrokontroller som reagerar på startbiten och sedan räknar bittider för att sedan återtrigga på nästa startbit o.s.v. Då kan man få en väldigt exakt avstängning.
Givetvis är det bäst om sändande mikrokontroller själv kan stänga av stroben när sändningen är klar. Dock är det inte alltid möjligt. Har man t.ex en repeater eller en omvandlare "på vägen" någonstans så måste man göra på annat sätt.
Däremot kan man ha en mikrokontroller som reagerar på startbiten och sedan räknar bittider för att sedan återtrigga på nästa startbit o.s.v. Då kan man få en väldigt exakt avstängning.
Givetvis är det bäst om sändande mikrokontroller själv kan stänga av stroben när sändningen är klar. Dock är det inte alltid möjligt. Har man t.ex en repeater eller en omvandlare "på vägen" någonstans så måste man göra på annat sätt.
Vads du måste tänka på är följande:
RS485 tvåtråd, dvs halvduplex.
Det är avsedd för master/slav kommunikation, dvs slaven kan aldrig initiera kommunikation, enbart mastern gör det, detta oavsett typ av protokoll.
Detta gäller i princip också fyrtrådsanslutning, då du kan få problem med bus-krockar annars (komplicerat att hantera).
Så vad du i detta läge måste göra är att hela tiden polla slavarna och fråga om de har nått att rapportera, därefter vänta en liten stund, slaven svara med nånting, fråga nästa slav osv.
Protokoll, tja KISS:
1 byte start (STX)
1 byte address
1 byte kommando
1 byte kontrollsumma
1 byte slut (ETX)
Totalt 5 byte, häng på mer efter kommandot om du vill skicka data till slaven också.
Vänta sedan den tiden det tar att skicka 2 byte eller så.
Sedan skall slaven skicka ett svar, oavsett om den har nått att rapportera, byt ut kommandot mot data i detta fallet.
Slaven skickar alltid sin address.
Sedan upprepar du det hela med nästa slavaddress.
Kontrollsumman behöver inte vara så komplicerad, XORa alltihopa, byte för byte, utom naturligtvis kontrollsumman själv och ETX-byten.
dvs:
CS=00 XOR STX
CS=CS XOR ADDRESS
CS=CS XOR Kommando
Ungefär så.
RS485 tvåtråd, dvs halvduplex.
Det är avsedd för master/slav kommunikation, dvs slaven kan aldrig initiera kommunikation, enbart mastern gör det, detta oavsett typ av protokoll.
Detta gäller i princip också fyrtrådsanslutning, då du kan få problem med bus-krockar annars (komplicerat att hantera).
Så vad du i detta läge måste göra är att hela tiden polla slavarna och fråga om de har nått att rapportera, därefter vänta en liten stund, slaven svara med nånting, fråga nästa slav osv.
Protokoll, tja KISS:
1 byte start (STX)
1 byte address
1 byte kommando
1 byte kontrollsumma
1 byte slut (ETX)
Totalt 5 byte, häng på mer efter kommandot om du vill skicka data till slaven också.
Vänta sedan den tiden det tar att skicka 2 byte eller så.
Sedan skall slaven skicka ett svar, oavsett om den har nått att rapportera, byt ut kommandot mot data i detta fallet.
Slaven skickar alltid sin address.
Sedan upprepar du det hela med nästa slavaddress.
Kontrollsumman behöver inte vara så komplicerad, XORa alltihopa, byte för byte, utom naturligtvis kontrollsumman själv och ETX-byten.
dvs:
CS=00 XOR STX
CS=CS XOR ADDRESS
CS=CS XOR Kommando
Ungefär så.
Ett problem med detta protokoll: om man överför värdet 0x02... hur ska man då detektera det? Är det STX eller 0x02?
Jag har av den anledning ung. samma sätt som beskrivs men alla värden skickas som ASCII med kommaseparering, varje block avsluts med ETX.
Busenkelt att tjuvläsa, dekoda, ta emot (STX = rensa inbuffer, ETX = behandla färdig block) men visst, en del mer overhead och en del mer minne... men fungerar i alla lägen.
Jag har av den anledning ung. samma sätt som beskrivs men alla värden skickas som ASCII med kommaseparering, varje block avsluts med ETX.
Busenkelt att tjuvläsa, dekoda, ta emot (STX = rensa inbuffer, ETX = behandla färdig block) men visst, en del mer overhead och en del mer minne... men fungerar i alla lägen.
Om du är smart nu så titta i protokoll som kan arbeta AC-kopplat, mycket bra när du vill galvaniskt isolera mellan mottagare och sändare med en enkel liten trafo typ Ethernettrafo.
Även om man kanske tänker använda UART och per definition tänkte åt RS232-sättet men med RS485-buffrar som de flesta gör så kan man med smart tänkt bittmöster matat till UART ändå få en signalering som klarar att AC-kopplas.
Med algoritm så menar jag DC-neutral översändning - dvs lika många '1' som'0' efter visst antal bitar, scrambling så att man inte får 8 bittar '1' eller '0 efter varandra och flera byte efter varandra, synksekvens ala 10101 i en eller 2 byte före varje paket, identifiering av paket så att man slänger allt man inte känner igen - tex. klara vitt brus på UART-ingången utan att det kraschar eller slöar ned.
bygger man så att man kan AC-koppla så behöver man inte optokopplare och massa arragemang för att välja trafikflödesriktning beroende på vem som pratar till vem i halvduplexfallet etc. utan det räcker med just en trafo
Trafo hindrar inte energiflöden i någon riktning utan tillåter energiflöden i båda riktningarna samtidigt - medan en optkopplare så är det tvärstopp i ena riktning - och optokopplarlösning måste också ha dubbel strömförsörjning som är isolerad gentemot respektive sida - en trafo behöver inget av det - den bara 'är'
När man designade Ethernet så tänkte man på detta och har en passande modulation för detta.
Har man fria händer att välja protokoll så bör man inte missa chansen att göra den bättre med AC-kopplingskapabilitet än i allafall standard RS232 med DC-nivåkrav.
Även om man kanske tänker använda UART och per definition tänkte åt RS232-sättet men med RS485-buffrar som de flesta gör så kan man med smart tänkt bittmöster matat till UART ändå få en signalering som klarar att AC-kopplas.
Med algoritm så menar jag DC-neutral översändning - dvs lika många '1' som'0' efter visst antal bitar, scrambling så att man inte får 8 bittar '1' eller '0 efter varandra och flera byte efter varandra, synksekvens ala 10101 i en eller 2 byte före varje paket, identifiering av paket så att man slänger allt man inte känner igen - tex. klara vitt brus på UART-ingången utan att det kraschar eller slöar ned.
bygger man så att man kan AC-koppla så behöver man inte optokopplare och massa arragemang för att välja trafikflödesriktning beroende på vem som pratar till vem i halvduplexfallet etc. utan det räcker med just en trafo
Trafo hindrar inte energiflöden i någon riktning utan tillåter energiflöden i båda riktningarna samtidigt - medan en optkopplare så är det tvärstopp i ena riktning - och optokopplarlösning måste också ha dubbel strömförsörjning som är isolerad gentemot respektive sida - en trafo behöver inget av det - den bara 'är'
När man designade Ethernet så tänkte man på detta och har en passande modulation för detta.
Har man fria händer att välja protokoll så bör man inte missa chansen att göra den bättre med AC-kopplingskapabilitet än i allafall standard RS232 med DC-nivåkrav.
Glömde visst en viktig del: LEN samt att det förmodligen är EOT istället för ETX, vilket iofs har ringa betydelseIcecap skrev:Ett problem med detta protokoll: om man överför värdet 0x02... hur ska man då detektera det? Är det STX eller 0x02?
Jag har av den anledning ung. samma sätt som beskrivs men alla värden skickas som ASCII med kommaseparering, varje block avsluts med ETX.
Busenkelt att tjuvläsa, dekoda, ta emot (STX = rensa inbuffer, ETX = behandla färdig block) men visst, en del mer overhead och en del mer minne... men fungerar i alla lägen.
Så det skall vara så här:Protokoll, tja KISS:
1 byte start (STX)
1 byte address
1 byte kommando
1 byte kontrollsumma
1 byte slut (ETX)
Protokoll, tja KISS:
1 byte start (STX)
1 byte address
1 BYTE LEN
1 byte kommando
1 byte kontrollsumma
1 byte slut (ETX) eller (EOT)
LEN är den totala längden inklusive STX och ETX.
Detta är i princip ett något förkortat kommersiellt protokoll, som är rätt vanligt.
finns lite mer bröte i det, framförallt kommando/datadelarna som är lite längre.
Men det används i hela världen, upphovsmännen är ett mycket stort danskt företag, och används av i princip alla deras produkter (med lite ytterligare modifikation och anpassning).
Orginalprotokollet är 9N1 (kan vara 9O1 eller 9E1) är lite osäker på paritetsbiten dock.
Paketet startar alltid med STX dvs 0x02 och slutar alltid med ETX dvs 0x03 alternativt EOT dvs 0x04.
Eftersom det är enkla tempgivare du skall driva, kan du stömförsörja från mastern, med ett extra par.
Dock är det naturligtvis bäst om man kör RS485 isolerat, vilket det finns mängder av bra kretsar som fixar.
Kör du via trafo, behöver du nog en del elektronik som snyggar upp det innan du matar in det i uC'n.
