AVR/PIC RS232 med interna RC oscillatorn

[blueint]

Jag kan styra det precis hur jag vill. Men det underlättar med hårdvara som sköter bitbangandet.
Det jag söker är i princip en USART som kan skicka 64 bitar långa "tecken". Och då kommer det förstås att behövas synk lite oftare än normalt som t.ex. manchester kodning åstadkommer.

(Kan bli längre sekvenser än 64 bit, men det är medelfallet iaf)

[sodjan]

OK, right, det är ju helt andra förutsättningar. Alltså 64 bitar utan omsynkning under tiden ?

Då behöver du sannolikt en självklockande kodning, t.ex Manchester som du nämner.

Men vad har detta med USART modulen att göra ?
Det var ju den du frågade om från början !?

Och om du nu kan styra allt i båda ändar, varför inte bara dela
upp datat i 8 bitars tecken och köra vanlig USART ?

En annan sak...

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

Dels skiljer det sig från PIC til PIC (USART, AUSART, eller EUSART),
dels går det att räkna ut m.h.a databladet. Det beror även på typ
av INTOSC (4, 8 eller 32 MHz). Slutligen beror det även lite på vad du
menar med "problem"...

[bearing]

Om du ska skriva en mjukvaru-USART kanske du kan få inspiration från AVR USB.
http://www.obdev.at/products/avrusb/index.html

RC-oscillatorn (som varierar 1-2%) är inte tillräckligt stabil för USB. De har därför implementerat en lösning som innebär att flanker då och då väntas in för att förbli i synk. Hastigheten är 1.5 MBit/s vid klockfrekvensen 12.8 MHz för RC-varianten.

[blueint]

Sodjan, Det jag undrar är om det finns något självklockande mode för långa bitsekvenser. Ang bithastighet så vet jag att det skiljer sig. Men jag tänkte mest vad man kan uppnå som mest med PIC12-PIC18.

bearing, AVR USB ger ju en vink om hur hårt man kan pressa MCUn.

Som det ser ut nu är nog någon självklockande mjukvarubitbang det som ligger närmast till hand om inte 8-bit asynk signalering väljs. Rätt likt 1-wire faktiskt

[speakman]

Jag kunde inte hitta där du bara vill ha signal + jord, men varför fungerar inte 485 då?

Annars skulle jag rekommendera HDB3 som inkluderar både klocka och data och ger dubbla baudrate mot t.ex. manchester. Populärt använt i bl.a. telenätet.

[Marta]

Gör nu inte det enkla komplicerat. Har kört med INTOSC jättemycket helt utan problem. 1% frekvensfel plus 1% fel på delningstalet är inga problem, det fungerar perfekt ändå. Använd annars OSCCAL för att dra den rätt.

Eller varför inte göra det riktigt komplicerat och implementera något med PRML så skall det nog fungera även om signalen är aningen rå och jittrig... Skall komplexiteten höjas så är det lika bra att ta steget fullt ut.

[bearing]

Men om frekvenserna skiljer 2% kommer de väl hamna ur synk efter 50 bitar redan? kanske redan efter 25 bitar då de ligger en halv bit fel.

Eller innehåller USARTen något som synkar om vid varje startbit?

[sodjan]

> Eller innehåller USARTen något som synkar om vid varje startbit?

Ja, hur skulle det annars fungera att skicka flera MB ??
Stop/start bitarna är just för att synka mottagaren mot dataströmmen...

[Marta]

Startbiten får mottagaren att börja räkna och efter 1.5 bittid startar samplingen om den nu bara skall läsa en gång mitt i varje bit. Stopbiten fungerar som en "slack" som tar upp felet mellan varje byte. Den kan vara allt från 1 bit till hur lång som helst och allt däremellan.

[bearing]

Jag har skrivit mjukvaru-UARTs, så jag känner till hur det funkar med en sampling per bit. Hur metoderna som samplar flera gånger per bit funkar jag har inte satt mig in i. Att 64 bitar vore ett problem gjorde mig osäker på om UARTen synkar en gång om per byte.

Men nu förstår jag; blueint önskade skicka en hel QWORD på en gång - utan start&stop var 8:e bit.

Då undrar jag också vad anledningen till att krångla med egna bitbangande lösningar är. USARTen lär vara snabbare, ta mindre processortid/programutrymme, och vara mer tillförlitlig vid samma hastighet.