Det har diskuterats mer än en gång hur kritisk timingen är vid seriekommunikation. Tänkte bidra med mina egna erfarenheter, då jag vill göra det enkelt för mig och använder den interna oscillatorn i 8MHz istället för extern kristall i de AVRmega328P jag använder.
Jag har ett par enheter som pratar med varandra via XBee-radio. Den ena ber om en temperaturmätning och den andra svarar med mätvärden. AVR-en pratar med Xbee-modulerna med 9600bps.
Kommunikationen med Xbee sker med datapaket med CRC checksumma.
Enhet 1 använder den inbyggda UARTen. Inga CRC-fel på över 400.000 mottagna paket.
Enhet 2 kör med bitbangad seriekommunikation (interupt-kontrollerad). 3 CRC-fel på över 400.000 mottagna paket.
Mao ord kommer man väldigt långt med den inbyggda oscillatorn.
Seriekommunikation med AVRmega, egen observation
Re: Seriekommunikation med AVRmega, egen observation
Har du testat detta över det totala temperaturområdet, spänningsintervallet för processorerna samt chip från olika batchar? Utan detta kan man tyvärr inte direkt säga något.
Jag gjorde lite lätta tester för ganska länge sedan och att bara lägga kretskorten i frysen och sedan försöka så kunde man få lite spännande fel.
Efter detta har jag som praxis att alltid ha en kristall. De finns i storlekar ner till 2.5mm x 1.6mm och 10 kr/st så plats/pengabrist kan man inte direkt klaga på.
Jag gjorde lite lätta tester för ganska länge sedan och att bara lägga kretskorten i frysen och sedan försöka så kunde man få lite spännande fel.
Efter detta har jag som praxis att alltid ha en kristall. De finns i storlekar ner till 2.5mm x 1.6mm och 10 kr/st så plats/pengabrist kan man inte direkt klaga på.
Re: Seriekommunikation med AVRmega, egen observation
Och vill man kan man ta en keramisk resonator. De brukar vara utan belastningskondensatorer, starta snabbare, tåla mycket mer stryk (fysisk) och kosta mindre än kristaller.
Re: Seriekommunikation med AVRmega, egen observation
Temperaturstabilare också?
Angående temperaturstabiliteten av interna oscillatorn. Om det finns en capture-pinne över kan man dra RS232-ingången till den pinnen och mäta bitlängden. Sedan finjustera OSCCAL för att få synca ihop de två enheterna.
Den tekniken används i VUSB-protokollet. Förut var det en bugg i den koden, som jag fixade, så jag har labbat en del med detta. OSCCAL är ett 8-bitars register och varierade +-3 steg med isbit resp glödlampa mot kretsen, har jag för mig.
Angående temperaturstabiliteten av interna oscillatorn. Om det finns en capture-pinne över kan man dra RS232-ingången till den pinnen och mäta bitlängden. Sedan finjustera OSCCAL för att få synca ihop de två enheterna.
Den tekniken används i VUSB-protokollet. Förut var det en bugg i den koden, som jag fixade, så jag har labbat en del med detta. OSCCAL är ett 8-bitars register och varierade +-3 steg med isbit resp glödlampa mot kretsen, har jag för mig.
Re: Seriekommunikation med AVRmega, egen observation
Mäter du bitlängden med en timer i så fall? Blir det inte fel då eftersom timern är beroende av den inbyggda oscillatorn, och om den går fel blir väl mätningen fel också?
Re: Seriekommunikation med AVRmega, egen observation
Ja precis, capture-funktionen i en timer.
Klockan kommer bli lika fel som den andra enhetens klocka. Om den andra är en bluetooth-modul antar jag att den innehåller en kristall och därför har mycket bättre klocka än inbyggda oscillatorn.
Exempel
Med 9600baud och 8 MHz klocka är den väntade bitlängden 833 cykler. Ifall timern har gått färre cykler betyder det att interna oscillatorn är för långsam, så man får öka hastigheten ett steg med OSCCAL. Alternativt tvärtom när klockan är för snabb. Sen ett område som anses tillräcklig nära för att inte göra något. Är nog förresten bättre att synka på samma flank (d.v.s tiden för två bitar), så att inte assymetriska upp/ned-flanker påverkar.
Jag har faktiskt kört den här algoritmen med RS232, minns jag nu. Men då synkade ja inte kontinuerligt, utan skickade några 0x55 (eller 0xAA, minns inte) för att synka, och antog sedan att temperaturen inte skulle ändras tillräckligt för att behöva synka under drift. Men det borde ju också gå, trots att slumpmässig data skickas, om man lägger till några rimlighetskontroller av vad timern mätt, så att man vet att det är 2 bitars längd som mätts.
Klockan kommer bli lika fel som den andra enhetens klocka. Om den andra är en bluetooth-modul antar jag att den innehåller en kristall och därför har mycket bättre klocka än inbyggda oscillatorn.
Exempel
Med 9600baud och 8 MHz klocka är den väntade bitlängden 833 cykler. Ifall timern har gått färre cykler betyder det att interna oscillatorn är för långsam, så man får öka hastigheten ett steg med OSCCAL. Alternativt tvärtom när klockan är för snabb. Sen ett område som anses tillräcklig nära för att inte göra något. Är nog förresten bättre att synka på samma flank (d.v.s tiden för två bitar), så att inte assymetriska upp/ned-flanker påverkar.
Jag har faktiskt kört den här algoritmen med RS232, minns jag nu. Men då synkade ja inte kontinuerligt, utan skickade några 0x55 (eller 0xAA, minns inte) för att synka, och antog sedan att temperaturen inte skulle ändras tillräckligt för att behöva synka under drift. Men det borde ju också gå, trots att slumpmässig data skickas, om man lägger till några rimlighetskontroller av vad timern mätt, så att man vet att det är 2 bitars längd som mätts.
-
lillahuset
- Gått bort
- Inlägg: 13969
- Blev medlem: 3 juli 2008, 08:13:14
- Ort: Norrköping
Re: Seriekommunikation med AVRmega, egen observation
"Autobaud" är en gammal fin teknik. Kör man det spelar hastigheten ingen större roll, man bara justerar så båda enheterna går lika fort.
Re: Seriekommunikation med AVRmega, egen observation
Det borde ju vara så att den µC som mäter bitlängd med en Capture-funktion mäter på signalerna från den andra µC. Att den mäter på egen är ju helt utan värde.
Sedan har jag gjort något liknande med PIC: Ett paket var "packat" in mellan STX och ETX - men var även delad av tid.
Jag hade massor av CP-tid över så jag lagde in en rutin som kollade dels om tiden mellan blocken fanns och när den var kollade jag första tecken när det kom något. Var det inte 0x02 (STX) kollade jag värdet och trimmade OSCCAL ett steg åt gången i rätt riktning.
Var första tecken 0x01 kör den interna klocka för snabbt och ska vevas ner, var värdet högre än 0x02 går den för långsam varför jag skruvar upp för hastigheten. Detta check utföras konstant och fungerar därför över hela temperaturområdet.
Men enklast är att trycka dit en keramisk resonator, då är saken biff.
Sedan har jag gjort något liknande med PIC: Ett paket var "packat" in mellan STX och ETX - men var även delad av tid.
Jag hade massor av CP-tid över så jag lagde in en rutin som kollade dels om tiden mellan blocken fanns och när den var kollade jag första tecken när det kom något. Var det inte 0x02 (STX) kollade jag värdet och trimmade OSCCAL ett steg åt gången i rätt riktning.
Var första tecken 0x01 kör den interna klocka för snabbt och ska vevas ner, var värdet högre än 0x02 går den för långsam varför jag skruvar upp för hastigheten. Detta check utföras konstant och fungerar därför över hela temperaturområdet.
Men enklast är att trycka dit en keramisk resonator, då är saken biff.
Re: Seriekommunikation med AVRmega, egen observation
Jag undrar ju hur du kom fram till att jag skulle menat att utgående signal skulle mätas. Inte ens skoförsäljaren skulle väl kunna tro att det skulle funka. Ett helt orimligt antagande, och även om jag av misstag skulle skrivit bakvänt hade det ju varit uppenbart vad jag egentligen menade. Jag skrev så klart att ingående signal skulle mätas, d.v.s att CCP kopplas ihop med RX.
Kristall/resonator är väl inte alltid den bästa lösningen eftersom att de drar så mycket mer ström. Sen är det ju inte säkert att saken blir biff, eftersom att om den andra enhetens klocka går fel blir resultatet bättre med justerbar intern oscillator. Visserligen kan man då istället ändra i BAUD-registret, men det har större steg än OSCCAL, har jag för mig.
Kristall/resonator är väl inte alltid den bästa lösningen eftersom att de drar så mycket mer ström. Sen är det ju inte säkert att saken blir biff, eftersom att om den andra enhetens klocka går fel blir resultatet bättre med justerbar intern oscillator. Visserligen kan man då istället ändra i BAUD-registret, men det har större steg än OSCCAL, har jag för mig.
Re: Seriekommunikation med AVRmega, egen observation
Dock, att mäta bit-tid är ingen lätt metod att få robust. 
Tex om det kommer mycket data där sekvenser med 10101010 inte kommer, då kan man få fel ganska så rejält.
Det man får göra är lägga in mer logik för att kolla dessa fall med multiplar.
Men man får ha tungan på rätt vinkel när man skriver koden så man får med alla special fall, efter det borde metoden vara ganska okej.
Tex om det kommer mycket data där sekvenser med 10101010 inte kommer, då kan man få fel ganska så rejält.
Det man får göra är lägga in mer logik för att kolla dessa fall med multiplar.
Men man får ha tungan på rätt vinkel när man skriver koden så man får med alla special fall, efter det borde metoden vara ganska okej.
Re: Seriekommunikation med AVRmega, egen observation
Förutsatt att elektroniken har någon sorts kapsling som begränsad snabba temperaturvariationer behöver nog inte koden stega OSCCAL oftare än en gång i minuten. Åtminstone inte oftare än varje sekund, i värsta fall. Så det finns nog tid/möjlighet att lägga ordentliga rimlighetskoller samt ett långsamt filter på värdena för att göra det robust. Tror jag.
Kan nog vara bra att ha extra logik för att synka på andra sekvenser än 1010, som du föreslår. Eller det är nog helt nödvändigt, om det ska vara en allmän rutin som inte får hjälp av att protokollet skickar specialtecken ibland för att synka, det har du rätt i. I vissa applikationer kanske samma tecken skickas kontinuerligt, alltid, och då måste den ju kunna synka på det. Men det är nog svårt att få en sån lösning helt robust, jämfört med om protokollet innehåller synktecken.
Kan nog vara bra att ha extra logik för att synka på andra sekvenser än 1010, som du föreslår. Eller det är nog helt nödvändigt, om det ska vara en allmän rutin som inte får hjälp av att protokollet skickar specialtecken ibland för att synka, det har du rätt i. I vissa applikationer kanske samma tecken skickas kontinuerligt, alltid, och då måste den ju kunna synka på det. Men det är nog svårt att få en sån lösning helt robust, jämfört med om protokollet innehåller synktecken.
