AVR/PIC RS232 med interna RC oscillatorn
AVR/PIC RS232 med interna RC oscillatorn
Hur pass bra fungerar det att använda den interna INTOSC RC oscillatorn för RS232 antingen med USART eller mjukvaruversion därav ..?
Hastighet?
Om man skriver ett eget dataström protokoll som synkar om vid varje bitomslag så borde ännu slappare timing gå bra.
Hastighet?
Om man skriver ett eget dataström protokoll som synkar om vid varje bitomslag så borde ännu slappare timing gå bra.
Menar du valfri hastighet bland standardhastigheterna eller helt valfri?
Modulen kan kan ställas in att sampla olika många gånger per bit. För att nå höga hastigheter måste få samplingar per bit väljas. Om signalen är i lite fel hastighet och samtidigt är ful kanske få samplingar per bit ger problem.
Ofta blir hastigheten någon tiondels procent till några få procent fel då standardhastigheter väljs. Det beror på att bitfrekvenserna ofta inte är jämnt delbara med den andel av klockfrekvensen USART:en använder. Väljs en bitfrekvens som är jämnt delbar med klockan blir felet 0.
Med minsta antalet samples/bit (som jag antar är 1 eller 4) är maxhastigheten 2 Mbit/s vid 8MHz för 16f886. Högsta standardhastigheten med mindre än 1% fel (som jag hittar) är 57.6kbit/s vilket ger 0,8% fel.
Modulen kan kan ställas in att sampla olika många gånger per bit. För att nå höga hastigheter måste få samplingar per bit väljas. Om signalen är i lite fel hastighet och samtidigt är ful kanske få samplingar per bit ger problem.
Ofta blir hastigheten någon tiondels procent till några få procent fel då standardhastigheter väljs. Det beror på att bitfrekvenserna ofta inte är jämnt delbara med den andel av klockfrekvensen USART:en använder. Väljs en bitfrekvens som är jämnt delbar med klockan blir felet 0.
Med minsta antalet samples/bit (som jag antar är 1 eller 4) är maxhastigheten 2 Mbit/s vid 8MHz för 16f886. Högsta standardhastigheten med mindre än 1% fel (som jag hittar) är 57.6kbit/s vilket ger 0,8% fel.
Re: AVR/PIC RS232 med interna RC oscillatorn
Det finns redan färdiga protokoll som klarar ganska mycket variation. LIN t.ex. Det synkar upp till bitströmmen i början av varje paket och är gjort för att klara billiga UART-lösningar med RC-oscillator isf kristall.blueint skrev:Om man skriver ett eget dataström protokoll som synkar om vid varje bitomslag så borde ännu slappare timing gå bra.
Enkelhet! Nästan alla mikrokontrollers idag har en UART inbyggd och det går att få tvåtrådskommunikation med enkla funktioner för sändning och mottagning. Visst, skall man bygga på funktioner för synkning på bitshiften och liknande så blir det genast mer komplicerat och kommer mer och mer att likna synkron kommunikation. Samtidigt är den fortfarande UART-kompatibel och har man bra klockor så är det bara att köra på som vanligt. Med andra ord så är det lätt att komma igång med och sedan går det att lägga till sådana här funktioner på vägen.
vfr, http://en.wikipedia.org/wiki/Local_Interconnect_Network ..?
Färdiga funktinsförslag för synkron kommunikation?
speakman, Vilken USART mode skall användas isåfall ..?, verkar bara finnas
asynkron samt SPI. Och SPI är inte direkt 1-bits opencollector / EIA-485
kompatibelt. Då SPI behöver tre trådar för att fungera.
Färdiga funktinsförslag för synkron kommunikation?
speakman, Vilken USART mode skall användas isåfall ..?, verkar bara finnas
asynkron samt SPI. Och SPI är inte direkt 1-bits opencollector / EIA-485
kompatibelt. Då SPI behöver tre trådar för att fungera.
Japp, just den LIN!
Jag antar att Speakman menade synkron i den mening som t.ex HDLC och liknande. I motsats till synkron med separat klocka som SPI, I2C, Microwire mm. Då får man antingen ha speciell hårdvara som klarar denna typ av synkron kommunikation eller köra mjukvaruimplementation i lägre hastighet. En del U(S)ART har support för detta också, men inte så ofta dom i mikrokontrollers.
Jag antar att Speakman menade synkron i den mening som t.ex HDLC och liknande. I motsats till synkron med separat klocka som SPI, I2C, Microwire mm. Då får man antingen ha speciell hårdvara som klarar denna typ av synkron kommunikation eller köra mjukvaruimplementation i lägre hastighet. En del U(S)ART har support för detta också, men inte så ofta dom i mikrokontrollers.
USART : Universal Sync/Async Receiver Transmitter.
Det är inte riktigt samma sak som SPI/I2C fråm MSSP modulen.
Dock är det inte heller riktigt samma sak som självkloclande
synkrona protocol som HDLC och liknande...
Man var inte svaret till grundfrågan OK ?
> Iofs skulle man kunna använda ett protokoll som synkar om vid varje bit förändring
Problemet är att med vanlig asynk komm så har du inga garanterade bit-ändringar
utom start och stopp bit. Och där har du synkning i alla fall.
Kan du styra hur det är implementerat i båda ändar ?
Jag fattade det som att du skulle hänga på något på någon befintlig "styrdator"...
Det är inte riktigt samma sak som SPI/I2C fråm MSSP modulen.
Dock är det inte heller riktigt samma sak som självkloclande
synkrona protocol som HDLC och liknande...
Man var inte svaret till grundfrågan OK ?
> Iofs skulle man kunna använda ett protokoll som synkar om vid varje bit förändring
Problemet är att med vanlig asynk komm så har du inga garanterade bit-ändringar
utom start och stopp bit. Och där har du synkning i alla fall.
Kan du styra hur det är implementerat i båda ändar ?
Jag fattade det som att du skulle hänga på något på någon befintlig "styrdator"...