Kommunikation mellan PIC processorer?
Re: Kommunikation mellan PIC processorer?
Om man önskar ett RS485 nät med cirka 40 meters längd som både hanterar enkla sensorer och relän, men även vissa videoströmmar (100 - 1000 kbit/s), hur gör man då? Gärna så att de enkla enheterna inte behöver kunna klara av de högre bithastigheterna.
Re: Kommunikation mellan PIC processorer?
Det här med addresseringen blev väl lite rörigt.
Låt säga att man vill sätta upp sin RS485 nod, då får man ställa in i ett register vilken address man har.
Om man sätter upp ett can-nätverk har man möjlighet att sätta upp en lista på addresser man vill lyssna på, eller lyssna på allt.
Jag skrev även att det är ett multimaster system
Men man kan skriva koden på ett sätt så att det t.ex finns en nod som kan skicka meddelanden och göra inställningar på övriga noder och att noderna i sig skickar ut data på bussen som någon lyssnar på. Eller att vissa noder bara svara om de tar emot ett meddelande till sig själva. I detta fallet kallar jag en av noderna master och resterande svavar.. Kanske fel benämning men det var så jag menade.
Om man skall lyssna av meddelanden och presssentera på t.ex en display så måste meddelandet innehålla information om vem som skickade meddelandet. Annars vet man inte att temperaturen är för vänstra delen av altanen om man har flera temperatursensorer.
För att göra det hela så enkelt som möjligt utan att man behöver lära sig hela CAN protokollet och alla möljigheter menade jag att man kan sätta upp slav-noderna (som inte är slavar i riktig bemärkning) på att lyssna på sin en specifik address (eller ID som det även kan kallas) och även skicka med denna information när man berättar sin status.
ursäkta missförståndet jag försökte bara hålla det så enkelt som möjligt.
Låt säga att man vill sätta upp sin RS485 nod, då får man ställa in i ett register vilken address man har.
Om man sätter upp ett can-nätverk har man möjlighet att sätta upp en lista på addresser man vill lyssna på, eller lyssna på allt.
Jag skrev även att det är ett multimaster system
Men man kan skriva koden på ett sätt så att det t.ex finns en nod som kan skicka meddelanden och göra inställningar på övriga noder och att noderna i sig skickar ut data på bussen som någon lyssnar på. Eller att vissa noder bara svara om de tar emot ett meddelande till sig själva. I detta fallet kallar jag en av noderna master och resterande svavar.. Kanske fel benämning men det var så jag menade.
Om man skall lyssna av meddelanden och presssentera på t.ex en display så måste meddelandet innehålla information om vem som skickade meddelandet. Annars vet man inte att temperaturen är för vänstra delen av altanen om man har flera temperatursensorer.
För att göra det hela så enkelt som möjligt utan att man behöver lära sig hela CAN protokollet och alla möljigheter menade jag att man kan sätta upp slav-noderna (som inte är slavar i riktig bemärkning) på att lyssna på sin en specifik address (eller ID som det även kan kallas) och även skicka med denna information när man berättar sin status.
ursäkta missförståndet jag försökte bara hålla det så enkelt som möjligt.
Re: Kommunikation mellan PIC processorer?
blueint: RS485 är "vanlig" seriell kommunikation, med RS485 menas enbart vissa spänningsnivåer på dataöverföringen.
Så för att köra 1000kb/sek måste baudrate vara minst 1,25 MBaud och ska det signaleras "ovanpå" detta måste baudrate såklart vara högre. Det behövs alltså ung. 1,5 MBaud för att det ska köra - och då blir det svårt, det är inte många UART i µC som klarar dessa hastigheter.
Man måste även lägga en del omtanke i drivkretsarna, en del är bandbreddsbegränsade till 125 kBaud osv.
Så för att köra 1000kb/sek måste baudrate vara minst 1,25 MBaud och ska det signaleras "ovanpå" detta måste baudrate såklart vara högre. Det behövs alltså ung. 1,5 MBaud för att det ska köra - och då blir det svårt, det är inte många UART i µC som klarar dessa hastigheter.
Man måste även lägga en del omtanke i drivkretsarna, en del är bandbreddsbegränsade till 125 kBaud osv.
Re: Kommunikation mellan PIC processorer?
Det där blev väl inte riktigt rätt, map bps vs Baud.
Bit per sekund är ju självförklarande men Baud betyder ungefär Symboler eller modulationsförändringar per sekund. En symbol kan innehålla mer än en bit beroende på typ av modulation. Det betyder att Baud-raten är lika med bps eller lägre, inte högre.
För vanlig seriell kommunikation, oavsett RS232 eller RS485 så är bps=Baud. Däremot för modem så överfördes många bits per Baud.
Bit per sekund är ju självförklarande men Baud betyder ungefär Symboler eller modulationsförändringar per sekund. En symbol kan innehålla mer än en bit beroende på typ av modulation. Det betyder att Baud-raten är lika med bps eller lägre, inte högre.
För vanlig seriell kommunikation, oavsett RS232 eller RS485 så är bps=Baud. Däremot för modem så överfördes många bits per Baud.
Re: Kommunikation mellan PIC processorer?
ie: och vad är fel?
För att överföra 1 byte med UART behövs 10 bit: 1 startbit, 8 databit och en stoppbit, alltså 10 bit/byte. 1Mbps blir alltså en baudrate på (1000000 / 8 * 10 =) 1,25MBaud.
RS485 har bara ett nivå per bit så allt dravel om symboler osv. är just dravel. Likaså har UART bara ett nivå i tiddomän, alltså även där en faktor på 1.
Så vad ett "analogt" modem kan överföra känns mycket likgiltigt i detta, det har aldrig varit inblandat i frågan innan du tog fram det, helt utan anledning.
För att överföra 1 byte med UART behövs 10 bit: 1 startbit, 8 databit och en stoppbit, alltså 10 bit/byte. 1Mbps blir alltså en baudrate på (1000000 / 8 * 10 =) 1,25MBaud.
RS485 har bara ett nivå per bit så allt dravel om symboler osv. är just dravel. Likaså har UART bara ett nivå i tiddomän, alltså även där en faktor på 1.
Så vad ett "analogt" modem kan överföra känns mycket likgiltigt i detta, det har aldrig varit inblandat i frågan innan du tog fram det, helt utan anledning.
Re: Kommunikation mellan PIC processorer?
Jag skulle nog inte använda CAN till att skicka video.
det finns 2st 2 olika CAN format:
vanlig:
16 bit id
8 bit data
16 bit crc
=> 20% data
extended
32 bit id
64 bit data
16 bit crc
=> 55% data
antalet bitar är ungefärliga eftersom det tillkommer kontrollbitar mm i meddelandet.
"Bit rates up to 1 Mbit/s are possible at network lengths below 40 m. Decreasing the bit rate allows longer network distances (e.g., 500 m at 125kbit/s). The improved CAN (CAN FD) extends the speed of the data section by a factor of up to 8 of the arbitration bit rate."
även om baudraten är 1Mbit så borde du får ut max 200kbit resp 500kbit om allt går hand i hand med solen i ryggen utan några omsändningar eller pauser mellan meddelanden.
det skulle kanske gå att skicka en del data i ID fältet.
Men det är som Sodjan säger, CAN är inte byggt för att streama data
det finns 2st 2 olika CAN format:
vanlig:
16 bit id
8 bit data
16 bit crc
=> 20% data
extended
32 bit id
64 bit data
16 bit crc
=> 55% data
antalet bitar är ungefärliga eftersom det tillkommer kontrollbitar mm i meddelandet.
"Bit rates up to 1 Mbit/s are possible at network lengths below 40 m. Decreasing the bit rate allows longer network distances (e.g., 500 m at 125kbit/s). The improved CAN (CAN FD) extends the speed of the data section by a factor of up to 8 of the arbitration bit rate."
även om baudraten är 1Mbit så borde du får ut max 200kbit resp 500kbit om allt går hand i hand med solen i ryggen utan några omsändningar eller pauser mellan meddelanden.
det skulle kanske gå att skicka en del data i ID fältet.
Men det är som Sodjan säger, CAN är inte byggt för att streama data
Re: Kommunikation mellan PIC processorer?
Hur tänkte du där?dangraf skrev:vanlig:
16 bit id
8 bit data
16 bit crc
=> 20% data
Enda (nästan iaf) skillnaden mellan standard och extended ID är 11 vs 29 bitar. Mängden data är variabelt 0 till 8 bytes, inte fixed 1 vs 8 som du skrivit.
Överkurs, men om man är ute efter mer prestanda så börjar CAN-FD komma nu. Där skickar man upp till 64 bytes data på samma utrymme som vanliga CAN skickar sina 8 byte.
Re: Kommunikation mellan PIC processorer?
Nej, så är det inte. 1 Mbps = 1 MBaud i "vanlig" seriell kommunikation. Behöver du överföra t ex 1000 bytes per sekund så är det startbit + 8 bit + stopbit = 10 bits per tecken * 1000 bytes = 10000 bps eller baud. Behöver du lägga på t ex CRC eller så så ökar bps/baud motsvarande.Icecap skrev:ie: och vad är fel?
För att överföra 1 byte med UART behövs 10 bit: 1 startbit, 8 databit och en stoppbit, alltså 10 bit/byte. 1Mbps blir alltså en baudrate på (1000000 / 8 * 10 =) 1,25MBaud.
RS485 har bara ett nivå per bit så allt dravel om symboler osv. är just dravel. Likaså har UART bara ett nivå i tiddomän, alltså även där en faktor på 1.
Så vad ett "analogt" modem kan överföra känns mycket likgiltigt i detta, det har aldrig varit inblandat i frågan innan du tog fram det, helt utan anledning.
Se även http://sv.wikipedia.org/wiki/Baud
Det är för när du börjar använda mer än två signalnivåer (olika amplitud eller faslägen som i modem) som baud-hastigheten blir lägre än bps. Om du istället för 0/5V signalering implementerar ett system med t ex 0, 1.7, 3.4 5.0V så kan du överföra 2 bps per baud.
