Då har jag lekt med en uppkoppling runt PIC16F886 på lab-plattan ett tag och bestämde mig för att flytta över projektet till ett lab-kort med lödöar för en lite mer rigid känsla. Sagt och gjort.
Bakgrund: (Detaljerad beskrivning. Hoppa till slutfrågan om ni har bråttom =)
I projektet så använder jag EUSART-modulen för att kommunicera med PC. Detta fungerade utmärkt innan jag flyttade över komponenterna på "löd-kortet" men nu går det inte så bra längre.
Innan flytten så användes 19,2kb/s som överföringshastighet utan problem med väldigt låg "fel-procent". Det var ibland efter omprogramering av PICen som första skickade ASCII-tecknet (PIC->PC) kunde bli galet. Jag brydde mig inte så mycket om det eftersom det aldrig blev fel efter det så vitt jag kunde se.
Efter flytten så var det tvärt om. Ibland blev första tecknet rätt efter omprogramering av PICen och efter det blev inte ett tecken rätt. Det blev dock oftast samma "fel tecken" som sändes.
Jag skrev om koden, så att det enda den skulle göra var att sända en given ASCII-kod när man trycker på en knapp, för att vidare analysera problemet.
Det visade sig att fel-procenten var betydligt lägre vid lägre hastigheter. Jag provade ner till 2400kb/s och där blev det rätt i mer än 99% av fallen men inte alltid.
Slutfråga:
Jag använder mig av den interna oscilatorn snurrande i 4 MHz. Kan det vara så att denna inte har tillräcklig tolerans för lite snabbare EUSART?
Om inte: Vad skulle ni med mer erfarenhet tro att felet kan bero på?
Ha en fin Söndag!
/Tottish
duger INTOSC för RS232? (PIC16F886)
Jag har använd mig av INTOSC på 4MHz i en PIC16F628A och den mätar lite grejer och skickar resultatet med 19,2 kbaud och det fungerar alldeles utmärkt.
En sak du kanska ska tänka på: När du initierar UART'en ställer man ju TX på porten till ut, sätt även den till '1' i nivå under initialiseringen, då kan du nog klara dig utan skräptecken i början.
En sak du kanska ska tänka på: När du initierar UART'en ställer man ju TX på porten till ut, sätt även den till '1' i nivå under initialiseringen, då kan du nog klara dig utan skräptecken i början.
Tyckte det lät lite konstigt om det skulle vara INTOSC som spökade...
Icecap: Menar du att jag ska sätta PORT för TX-pinnen till 1? Trodde att PORT-värdet ignorerades efter att man satt TXEN till 1 men den kanske funkar som vanlig I/O-pinne tills man vill sända något? Tack för tipset, ska prova det.
JockeE: Jodå jag använder samma avkoppling nu efter flytten. En keramisk 33nF och en rejäl elyt, på cirka 5mm respektive 20mm avstånd från PICen så det borde väl inte vara felet?
Edit: Matning tas fortfarande från lab-agget.
Edit2: Jag smäller av! Icecaps tips ovan löste hela problemet! Skickar nu felfritt ända upp till 19,2kb/s!
Av ren nyfikenhet: Hur kan egentligen detta komma sig? Jag använder samma kod här som innan flytten och det funkade alldeles utmärkt då utan att PORT för TX pinnen var satt hög.
/Tottish
Icecap: Menar du att jag ska sätta PORT för TX-pinnen till 1? Trodde att PORT-värdet ignorerades efter att man satt TXEN till 1 men den kanske funkar som vanlig I/O-pinne tills man vill sända något? Tack för tipset, ska prova det.
JockeE: Jodå jag använder samma avkoppling nu efter flytten. En keramisk 33nF och en rejäl elyt, på cirka 5mm respektive 20mm avstånd från PICen så det borde väl inte vara felet?
Edit: Matning tas fortfarande från lab-agget.
Edit2: Jag smäller av! Icecaps tips ovan löste hela problemet! Skickar nu felfritt ända upp till 19,2kb/s!
Av ren nyfikenhet: Hur kan egentligen detta komma sig? Jag använder samma kod här som innan flytten och det funkade alldeles utmärkt då utan att PORT för TX pinnen var satt hög.
/Tottish
Jag har haft problem med den interna oscillatorn, trots avkoppling och stabila spänningar. Tröttnade och sätter numera en extern på allt som behöver kommunicera. Vet inte exakt vad orsaken var, men felen var inte direkt förutsägbara. Ett kort som fungerat felfritt i flera veckor kunde helt plötsligt bara skicka skräp utan att något ändrats. Visserligen hade de svårt med temperaturen i rummet, men det var inte bara det.
Numera verkar det bara vara mitt eget fel om det inte fungerar.
Numera verkar det bara vara mitt eget fel om det inte fungerar.
Tottish: min erfarenhet är att vissa processorer (jag använder lite olika familjer) förvisso övertar kontrollen över portpinnen när man startar upp UART'en men att de först går i rätt läge när man skickar en byte. Om man då börjar med att sparka den rätt och SEDAN låter UART'en ta över blir det rätt hela tiden.
Jag har INTE kollat om detta gäller PIC, jag har bara gjort det som en bra regel att hålla.
Kom till din Edit2 och tydligen är mitt råd inte helt fel
Vissa saker har jag iaf. lärt mig, den viktigaste är: se till att arbetsförutsättningerna är OK, det finns rikligt annat som skiter sig ändå.
Att det fungerar med det råd KAN vara för att du skickar ut data i så snabb följd att hela mottagningscykeln blir flyttat en eller fler bit. Detta kan även uppnås med en viss minimum paus lite då och då.
Jag har INTE kollat om detta gäller PIC, jag har bara gjort det som en bra regel att hålla.
Kom till din Edit2 och tydligen är mitt råd inte helt fel
Vissa saker har jag iaf. lärt mig, den viktigaste är: se till att arbetsförutsättningerna är OK, det finns rikligt annat som skiter sig ändå.
Att det fungerar med det råd KAN vara för att du skickar ut data i så snabb följd att hela mottagningscykeln blir flyttat en eller fler bit. Detta kan även uppnås med en viss minimum paus lite då och då.
-
bengt-re
- EF Sponsor
- Inlägg: 4829
- Blev medlem: 4 april 2005, 16:18:59
- Skype: bengt-re
- Ort: Söder om söder
- Kontakt:
Kolla dock på hur väl delningsfaktorerna stämmer vid önskad baudrate, finns tabell i databladet - är det mycket off så välj annan baudrate eller kristall istället då du annars kommer att riskera att få skumma fel ibland om spänningen är lite avvikande eller om kretsen är varm/kall. Ids du så gör en en noggranhetsanalys basrat på tolleranserna på IntOsc vid din temp och din spänning och avvikelserna givna i databladet för UART-modulen.
