Försöker skicka lite data med USARTen men det vill sig inte riktigt
När jag skickar till PCn så får jag bara en massa lustiga tecken.
Något spontant fel eller något jag glömt?
Nivåkonvertering är rätt kopplat? Rätt inställda start/stoppbitar och ordlängd? Får du alltid samma skräp? Ändras skräpet om du skickar andra textsträngar? Skicka ett känt mönster och se hur det beter sig, tex 0x55 eller 0xAA
Nivåkonvertering?
Kopplingen är det inget fel på, det fungerar med ett program jag skrev i assember, men nu när jag gav mig på C så gick det inget vidare.
Jag får olika skräp beroende på vilken textsträng jag skickar. Det är som att den bara byter ut tecken :/
Micke_s:
129 ska vara 2.4k baudrate på 20MHz utan BRGH satt, om jag förstått det rätt.
Nu väntar jag på TXIF också, om jag gjort det rätt.
Och tja, varför jag sätter på och stänger av TXen har jag inget bra svar på..
Sådär, nu börjar det bli något även av det här
Ända problemet är att den inte sänder de 3-6 första tecknena
Antalet tecken den inte sänder ut varierar på vilken sträng jag skickar med, men är alltid samma till antal i samma sträng.
Micke_s:
BAUDCON, BRG16 ? Hittar ingenting i databladet om det
Ska inte baudraten vara 129 med BRGH och 20MHz på 9.6 kbit?
Sodjan:
Om jag skickar ett tecken får jag 0xFF oavsett tecken.
Jag skriver så för att jag håller på och testar lite olika bitar, det underlättar för mig.
För övrigt så verkar jag få samma problem vilken baudrate jag än använder, både med och utan BRGH satt.
Jag använder den terminalen som följer med MikroC IDEet och har testat med andra liknande programvaror men får samma fel.
8/16 bitars baudrate register finns i de modeller som
har EUSART (d.v.s "Enhanced USART"). Dessa finns även
i (nyare) PIC16 modeller och är inget specifikt för PIC18
(även om det i och för sig var i någon PIC18 modell
som EUSART först dök upp),,,
PIC18F452 har den något äldre USART, men det kan
knappast vara problemet i detta fall...
Och som sagt, den stora fördelden med EUSART är just
16-bitars baudrate register, vilket i många fall gör
"avrundningsfelet" vid beräkning av devisiorn betydligt
mindre.
Sen, med det utrett...
> Om jag skickar ett tecken får jag 0xFF oavsett tecken...
Hm, så om du sänder *ett* tecken (vilket som) så
får du ett x'FF' till PC'n ?
Och om du sänder *ett* till så kommer det ytterligare ett x'FF' ?
När är det som du får "rätt" tecken ?
Och vad måste du göra för att sen få fel tecken ingen?
Räcker det med en paus, eller måste du start om allt (reset) ?
Det låter som om du får in "skräp" i "röret" mellan din
PIC applikation och ditt terminalprogram.
Det du måste göra är att ta reda på *EXAKT* under
vilka förhållanden som du får skräp respektive rätt tecken...
"while(PIR1.TXIF == 0){} //Väntar på TXIF"
är lite suspekt. När en kompiler läser ett bitvärde är det inte sällan att den maskar ut bitten enbart och värdet kan då bli 1, 2, 4, 8, 16, 32, 64 eller 128 allt efter bittens position.
Ett bättre sätt är då:
"while(!PIR1.TXIF); //Väntar på TXIF"
Sedan funderar jag lite på varför du väntar på PIR1.TXIF först när du sedan använder TXSTA.TRMT, om du kör rent pollad är den enda användbara flagga ju TXSTA.TRMT.
Alltså bör
while(data[i])
{
while(PIR1.TXIF == 0); //Väntar på TXIF
TXREG = data[i++]; //skickar innehållet
while (TXSTA.TRMT == 0);
}
egentligen vara
while(data[i])
{
while(!TXSTA.TRMT); // Väntar på att TX blir klar
TXREG = data[i++]; //skickar en byte
}