B1n4ry: Som du skriver så är det nog lättast att använda sig av någon form av hårdvarulösning när det gäller slumptalen. Har man t.ex. en tempsensor så är det ju mycket lätt att läsa ett slumpvärde från den!
Vad säger man om spänningsmatning då?
Min tanke var att jag kunde använda en fyrpolig tvistad kabel där två ledare används till rs485 och två till en ~12volts DC spänningsmatning, sedan stabbar man spänningen till lämplig nivå på varje enhet (För de enheter som drar lite ström)
En stor fördel med att spänningsmata bussen centralt är att det blir lätt att fixa batteribackup.
/Nicke
bygga buss...
Att polla är inte alls så tokigt! Räknar du på det så inser du att det ändå kommer att gå väldigt snabbt! Efter lite snabbräkning så får jag fram att om du har 20 enheter på bussen och kör i 57600kbit/s så hinner du med ca 100 pollningar/enhet per sekund. (Väldigt snällt räknat) En pelletspanna kan ju ändå inte vara såå kritisk! En eller två sekunder hit eller dit gör ju inget.. en vanlig tempgivare brukar ju även har en viss frdröjning... så om bussen har en fördröjning på 0,01 eller 0,5s kvittar ju faktiskt!Croaton skrev:$tiff:
Det enda problemet som jag ser det är att jag skulle vilja att vilken "enhet" som helst ska kunna skicka data på bussen när som helst. Dvs om jag har en enhet som t.ex. övervakar temperaturen eller larm från min pelletsbrännare så vill jag att den skall skicka denna status så fort som eventet sker.... Problemet är ju att undvika kollisioner när flera enheter vill skicka data samtidigt.
Den enklaste lösningen är ju att låta servern/mastern polla data från de olika enheterna i tur och ordning.... men den lösningen är inte lika snygg.
/Nicke
oJsan: 57600kbit/s känns _lite_ för fort för mig. För att kunna köra "bit-banging" på t.ex. en PIC12 krets så tänkte jag försöka köra max 9600 bps på bussen.
Om man då räknar med ca 10 byte i en "förfrågan" (Poll och Svar) så borde man hamna på runt 10ms för datat, utan delayer så hamnar man alltså på 0,2 sekunder för att polla 20 enheter vilket känns ganska fort det också...
Det kanske inte är en så dum idé ändå.. någon som har mer input angående detta?
/Nicke
Om man då räknar med ca 10 byte i en "förfrågan" (Poll och Svar) så borde man hamna på runt 10ms för datat, utan delayer så hamnar man alltså på 0,2 sekunder för att polla 20 enheter vilket känns ganska fort det också...
Det kanske inte är en så dum idé ändå.. någon som har mer input angående detta?
/Nicke
Den data man skickar över protokollet (bussen) bör vara riktigt skyddad med checksumma, gärna CRC. Detta tillsammans med framing (start- och stopptecken på framen), adressering och datan i sig själv gör att ett datapaket blir ett antal byte stort. _Hur_ stort beror naturligtvis på adressering, checksumman och datan.
Däremot måste inte nödvändigtvis själva pollningen vara ett normalt datapaket. Jag har jobbat med protokoll där pollningen skickas som en byte med högsta biten satt (ger upp till 128 möjliga adresser), kallat Enquiry. Finns ingen data så skickas en svarsbyte med högsta biten nollad, kallat End of transmission. Nästa enhet pollas. Om däremot en enhet har data att sända så skickas istället ett datapaket som svar.
Alla datapaket är "framade" med start/stopp-tecken. Dessa väljs t.ex ur den övre datamängden, $F0- $FF, och minskar adressrymden ytterligare lite grann. För att hindra att datan i paketet innehåller start- och stopptecken så måste dessa "escapas", d.v.s bytas ut mot en sekvens av andra tecken. Nu lägger man till en adresseringsbyte i paketet plus t.ex 2 byte checksumma och man har ett robust och relativt kompakt protokoll som går att köra på alla UART:ar även utan 9-bitsadressering. Man kompletterar också med ett ACK-meddelande och omsändning vid uteblivet svar.
Anledningen till att pollningen i sig inte nödvändigtvis måste ha checksumma, är att den frågas ju hela tiden om igen. Skulle det bli en störning och början av ett datapaket misstolkas som EOT så svaras med samma datapaket vid nästa poll. Om man förutsätter att det inte är kontinuerligt fel på linjen så kommer det igenom rätt förr eller senare. Och skulle det vara helt fel på linjen så kommer inget fram ändå.
Edit: Stavning
Däremot måste inte nödvändigtvis själva pollningen vara ett normalt datapaket. Jag har jobbat med protokoll där pollningen skickas som en byte med högsta biten satt (ger upp till 128 möjliga adresser), kallat Enquiry. Finns ingen data så skickas en svarsbyte med högsta biten nollad, kallat End of transmission. Nästa enhet pollas. Om däremot en enhet har data att sända så skickas istället ett datapaket som svar.
Alla datapaket är "framade" med start/stopp-tecken. Dessa väljs t.ex ur den övre datamängden, $F0- $FF, och minskar adressrymden ytterligare lite grann. För att hindra att datan i paketet innehåller start- och stopptecken så måste dessa "escapas", d.v.s bytas ut mot en sekvens av andra tecken. Nu lägger man till en adresseringsbyte i paketet plus t.ex 2 byte checksumma och man har ett robust och relativt kompakt protokoll som går att köra på alla UART:ar även utan 9-bitsadressering. Man kompletterar också med ett ACK-meddelande och omsändning vid uteblivet svar.
Anledningen till att pollningen i sig inte nödvändigtvis måste ha checksumma, är att den frågas ju hela tiden om igen. Skulle det bli en störning och början av ett datapaket misstolkas som EOT så svaras med samma datapaket vid nästa poll. Om man förutsätter att det inte är kontinuerligt fel på linjen så kommer det igenom rätt förr eller senare. Och skulle det vara helt fel på linjen så kommer inget fram ändå.
Edit: Stavning
Senast redigerad av vfr 4 januari 2006, 10:55:38, redigerad totalt 1 gång.
En annan möjlighet är att koppla alla enheter i en slinga. Alltså ut ur mastern, in i nod 1, ut ur nod 1 in i nod 2 och så vidare till ut ur nod n och in i mastern. Varje nod skickar vidare allt han får in, kollar om han är adresserad i paketet och lägger i så fall till sitt svar.
Gör man så och ger alla noder ett unikt ID så kan en pollningsförfrågan vara generell och funka ungefär såhär:
Master skickar:
POLL:END
Nod 1 kollar om han vill skicka data och i det fallet skickar han till nod 2:
POLL:NOD1=J:END
Nod 2 som inte vill skicka data skickar till nod3:
POLL:NOD1=J:NOD2=N:END
Det Mastern får tillbaka blir alltså en lista med alla noders status.
POLL:NOD1=J:NOD2=N:NOD3=J:NOD4=N:....:NODn=N:END
Kommandon skickas på samma sätt från nod till nod men endast den adresserade noden lyssnar. T.ex kan mastern skicka ett "läs av temperatur-kommando" till nod 5:
READ=5:TEMP:END
svaret blir då:
READ=5:TEMP:NOD5=23.5:END
Som bonus kan man skicka kommandon till flera noder:
READ=2,3,6:VOLT:END
svaret från bussen
READ=2,3,6:VOLT:NOD2=11.6:NOD3=11.4:NOD6=12.0:END
Om man vill så kan man ju låta en nod initiera en dataöverföring, t.ex. genom att skicka en interrupt om något händer. Nod 12 upptäcker låg nivå och skickar ett paket:
INT=12:LEVEL=LOW:END
Detta lyssnar ingen på förutom mastern som dock på något sätt kanske bör kvittera till Nod 12...
Det enda negativa med detta är att slingan måste vara en logisk ring. Men det löser man ju enkelt även om man vill ha en fysisk stjärna genom att skicka med ett extra par i kabeln. Sedan får man bygla mellan noderna på något snyggt sätt vid centrala noden.
Detta blir ju faktiskt ett rätt enkelt sätt att adressera valfritt antal noder...
//B1n4ry
Gör man så och ger alla noder ett unikt ID så kan en pollningsförfrågan vara generell och funka ungefär såhär:
Master skickar:
POLL:END
Nod 1 kollar om han vill skicka data och i det fallet skickar han till nod 2:
POLL:NOD1=J:END
Nod 2 som inte vill skicka data skickar till nod3:
POLL:NOD1=J:NOD2=N:END
Det Mastern får tillbaka blir alltså en lista med alla noders status.
POLL:NOD1=J:NOD2=N:NOD3=J:NOD4=N:....:NODn=N:END
Kommandon skickas på samma sätt från nod till nod men endast den adresserade noden lyssnar. T.ex kan mastern skicka ett "läs av temperatur-kommando" till nod 5:
READ=5:TEMP:END
svaret blir då:
READ=5:TEMP:NOD5=23.5:END
Som bonus kan man skicka kommandon till flera noder:
READ=2,3,6:VOLT:END
svaret från bussen
READ=2,3,6:VOLT:NOD2=11.6:NOD3=11.4:NOD6=12.0:END
Om man vill så kan man ju låta en nod initiera en dataöverföring, t.ex. genom att skicka en interrupt om något händer. Nod 12 upptäcker låg nivå och skickar ett paket:
INT=12:LEVEL=LOW:END
Detta lyssnar ingen på förutom mastern som dock på något sätt kanske bör kvittera till Nod 12...
Det enda negativa med detta är att slingan måste vara en logisk ring. Men det löser man ju enkelt även om man vill ha en fysisk stjärna genom att skicka med ett extra par i kabeln. Sedan får man bygla mellan noderna på något snyggt sätt vid centrala noden.
Detta blir ju faktiskt ett rätt enkelt sätt att adressera valfritt antal noder...
//B1n4ry
haha, ta bort ett k där i mitt förra inlägg så blir allt rätt! jag tror att det är få pic-kretsar som klarar mer än runt 115 kbit/s med "normala" kristaller! Jag hade räknat på 57600 bit/s... så du ser att det inte går så långsamt som man tror att det ska göra, så 9600 skulle också rulla på i bra tempo!
(Men däremot så tror jag att du har räknat fel någonstans... jag tycker att det borde ta ca 2s att polla 20 enheter i 9600bps. Kom ihåg att bps betyder baud-per-sekund (bitar) och inte bytes-per-sekund!)
Som vfr skriver så kan det ju vara bra med någon form av protokoll för data/adressering... men i ditt fall tror jag att det funkar utan också eftersom det antagligen är ett tämligen statiskt system när det väl är byggt! Det är risk att det blir onödigt krångligt annars.
Att göra en slinga känns inte som en bra lösning. Det förutsätter att ALLA enheter är igång och 100% pålitliga! Och vad händer om slingan stannar någonstans, eller om en eller flera uC har hög belastning och på så sätt fördröjer stafettpinnen?!
(Men däremot så tror jag att du har räknat fel någonstans... jag tycker att det borde ta ca 2s att polla 20 enheter i 9600bps. Kom ihåg att bps betyder baud-per-sekund (bitar) och inte bytes-per-sekund!)
Som vfr skriver så kan det ju vara bra med någon form av protokoll för data/adressering... men i ditt fall tror jag att det funkar utan också eftersom det antagligen är ett tämligen statiskt system när det väl är byggt! Det är risk att det blir onödigt krångligt annars.
Att göra en slinga känns inte som en bra lösning. Det förutsätter att ALLA enheter är igång och 100% pålitliga! Och vad händer om slingan stannar någonstans, eller om en eller flera uC har hög belastning och på så sätt fördröjer stafettpinnen?!
annars kan man väl göra så att man använder RS485 (borde inte vara svårt att sätta ihop då man kan använda PIC:ens inbyggda USART och en interface krets) och så frågar mastern hela tiden sina slavar om dom har något att säga... lite som tokenring men ändå inte =)
eller att man har en ledning som slaven sätter hög när den har något att säga och sen väljer mastern bara att fråga ut om en pinne blir hög... mastern kan ju använda MCP23X08 (eller MCP23017 så kör man bara en OR på interrupt pinnarna till RB0) då borde den ju i alla fall få tillräckligt me I/O portar.
Feedback?
eller att man har en ledning som slaven sätter hög när den har något att säga och sen väljer mastern bara att fråga ut om en pinne blir hög... mastern kan ju använda MCP23X08 (eller MCP23017 så kör man bara en OR på interrupt pinnarna till RB0) då borde den ju i alla fall få tillräckligt me I/O portar.
Feedback?
Jag tycker man skall försöka undvika speciella lösningar som extra pinne/tråd för påkallande av uppmärksamhet, slingkoppling (i.e Token ring) eller adressering som kräver speciella UART:ar. Det kanske löser ett problem kortsiktigt men på längre sikt blir det ofta mer problem.
En någorlunda standardiserad tvåtrådsbuss som t.ex 485, LIN, SIOX eller liknade tror jag är den bästa grundstrukturen. Sedan en adressering som går att köra på vilken UART som helst o.s.v enligt mitt tidigare inlägg.
oJsan> Vad menar du med att det är statiskt och inte borde behöva adressering och protokoll?
Adressering är naturligtvis bara nödvändig om man kör mer än två noder, men ett protokoll måste man ju ha. Det är ju ett protokoll även om man bara kör något enkelt med t.ex. en byte i varje riktning. Checksumma tycker jag definitivt att man skall ha, även om den givetvis kan vara enklare än en CRC. T.ex en-bytes addition eller XOR-checksumma.
En någorlunda standardiserad tvåtrådsbuss som t.ex 485, LIN, SIOX eller liknade tror jag är den bästa grundstrukturen. Sedan en adressering som går att köra på vilken UART som helst o.s.v enligt mitt tidigare inlägg.
oJsan> Vad menar du med att det är statiskt och inte borde behöva adressering och protokoll?
Adressering är naturligtvis bara nödvändig om man kör mer än två noder, men ett protokoll måste man ju ha. Det är ju ett protokoll även om man bara kör något enkelt med t.ex. en byte i varje riktning. Checksumma tycker jag definitivt att man skall ha, även om den givetvis kan vara enklare än en CRC. T.ex en-bytes addition eller XOR-checksumma.
Njaa, bps betyder bitar per sekund. Det brukar sedan jämställas med baud/baudrate även om detta inte är en helt korrekt jämförelse. Baud är ett mått på antalet diskreta tillstånd eller händelser per sekund och är alltså beroende på moduleringen.oJsan skrev: (Men däremot så tror jag att du har räknat fel någonstans... jag tycker att det borde ta ca 2s att polla 20 enheter i 9600bps. Kom ihåg att bps betyder baud-per-sekund (bitar) och inte bytes-per-sekund!)
Hur lång tid det tar att polla är ju helt beronde på vilket protokoll man pollar efter. Utan den uppgiften är frågan/svaret ganska meningslöst. Tar man mitt exempel med enbytespollning följt av enbytessvar plus lite dötid emellan så kanske en pollning på 9600 tar 1+1ms i datatid plus säg 2ms i dötid, d.v.s 4ms per pollning. Detta skulle ge ca 250 pollningar per sekund. Låter man däremot en pollning bestå av ett datapaket på säg 10 byte fråga och 10 byte svar så blir det 20ms plus dötid på 2ms = 22ms. Detta ger då ca 45 pollningar per sekund. Så 20 tycker jag är ganska pessimistiskt räknat.
vfr: Jepp, jag tänkte ha någon form av frame samt checksumma, däremot så behöver man ju inte köra någon överdriven avancerad checksumma.
Om man bygger protokollet enligt "paket-tänket" så borde man ju kunna köra något sånt här:
[Kommando/Start - 1 byte] [Destinations Adress - 1 byte] [Datalängd (Payload size) - 1 byte] [Data - 0 till 256 byte(s)] [Checksum - 2 byte?]
Det går ju självklart att lösa detta på tusentals sätt beroende på vilka krav man har.. men jag tror att jag kör på något liknande. Sedan måste jag bara bestämma mig för om jag skall köra master-slave(s) eller multi-master stuket, men det borde ju gå att köra samma paket oberoende av det.
/Nicke
Om man bygger protokollet enligt "paket-tänket" så borde man ju kunna köra något sånt här:
[Kommando/Start - 1 byte] [Destinations Adress - 1 byte] [Datalängd (Payload size) - 1 byte] [Data - 0 till 256 byte(s)] [Checksum - 2 byte?]
Det går ju självklart att lösa detta på tusentals sätt beroende på vilka krav man har.. men jag tror att jag kör på något liknande. Sedan måste jag bara bestämma mig för om jag skall köra master-slave(s) eller multi-master stuket, men det borde ju gå att köra samma paket oberoende av det.
/Nicke
vfr: Jag borde inte skriva saker så sent på nätterna inser jag, det smyger sig in en hel del felaktigheter då! 
Jag menade inte att skippa protokoll.. ett protokoll behövs, men ditt såg lite väl krångligt ut, men nu inser jag att det inte är så dumt ändå! Vad jag ville få fram var att man kanske inte behöver fördjupa sig alltför mycket i att göra ett robust protokoll eftersom det i det här fallet är ett system som inte är så modulär. Det behöver ju bara fungera i just det här fallet och behöver inte fungera i alla andra tänkbara konfigurationer.
När det gäller bitar/baud så är det som ju som du säger, bps=bitar-per-sekund (fel av mig igen) men just för RS232 så råkar det bara vara två tillstånd. antar att det är därför det lätt blandas ihop...
Jag menade inte att skippa protokoll.. ett protokoll behövs, men ditt såg lite väl krångligt ut, men nu inser jag att det inte är så dumt ändå! Vad jag ville få fram var att man kanske inte behöver fördjupa sig alltför mycket i att göra ett robust protokoll eftersom det i det här fallet är ett system som inte är så modulär. Det behöver ju bara fungera i just det här fallet och behöver inte fungera i alla andra tänkbara konfigurationer.
När det gäller bitar/baud så är det som ju som du säger, bps=bitar-per-sekund (fel av mig igen) men just för RS232 så råkar det bara vara två tillstånd. antar att det är därför det lätt blandas ihop...
Jag har kört på en del enklare checksummor tidigare (typ 1-byte addition/XOR) men dom har en otrevlig nackdel. Ingår det en nollbyte i paketet och man tappar den helt så ändras inte checksumman. Det ser alltså ut som ett paket med korrekt checksumma. Gör man en sådan variant så skall man definitivt ha med längdbyten så att man den vägen kan se att en byte saknas.
En reflektion till: Om checksumman inte stämmer så skall man INTE svara på meddelandet utan låta det gå till omsändning istället. Många gör det felet att man sänder ett Error-svar tillbaka vid felaktig checksumma. Problemet med det är att även node-adressen i paketet skyddas av checksumman och är checksumman fel så kan noden inte längre garantera att paketet verkligen är "till den" och då kan det bli så att flera enheter svarar.
En reflektion till: Om checksumman inte stämmer så skall man INTE svara på meddelandet utan låta det gå till omsändning istället. Många gör det felet att man sänder ett Error-svar tillbaka vid felaktig checksumma. Problemet med det är att även node-adressen i paketet skyddas av checksumman och är checksumman fel så kan noden inte längre garantera att paketet verkligen är "till den" och då kan det bli så att flera enheter svarar.
