Svenska ElektronikForumet

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.

Vid normala matningsspänningar och normala temperaturer
så fungerar t.ex de nyare PIC's INTOSC ganska OK. Sen finns det
metoder att finjustera både baudrate registret och INTOSC.

> Hastighet?

Har ingen betydelse, det är avvikelsen från baudrate som är intressant.

Tänkte den maximala bithastigheten hastigheten som PIC kan köra med den inbyggda oscillatorn utan problem.. ?

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.

Helt fri hastighet. Tänker att eventuell styrdator kan använda en MCU som brygga. Finns ju dom med 2x USART. Iofs skulle man kunna använda ett protokoll som synkar om vid varje bit förändring och på det sättet klara riktigt soppiga klockor.

För AVR så funkar det helt problemfritt om man läser av
och använder sig av det inbyggda kalibreringsvärdet
för RC oscillatorn.
Kör man okalibrerat så blir det individberoende....
Har varit med om att detta bråkat.

Har kört 19200 i en del fall
övriga 9600

Swech

Om jag tolkar tabellen (sida 198) rätt så borde man klara 1Mbit/s på den interna OSC om man plockar bort CKDIV8-fusen (som dividerar den interna osc med 8).

blueint skrev:Om man skriver ett eget dataström protokoll som synkar om vid varje bitomslag så borde ännu slappare timing gå bra.

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.

Någon särskild anledning till att inte köra synkron data?

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.

> speakman, Vilken USART mode skall användas isåfall

Synkron mode, verkar väl rimligt...

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.

Sodjan, Det enda jag sett hittills av synkronmode på PIC/AVR är SPI och det skulle kräva att man blandar klocka och data externt. För att kunna få in det på en Signal+GND bus.
(rätt likt 1-Wire)

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"...