Försöker skriva ut tecken till en PC rs232 port med denna kod för PIC 18F458. Använder en 25 MHz kristall som oscillator. Nedanstående kod förväntas skriva ut bokstäverna A B C. Resultatet blir istället att ACAC skrivs ut och att char count blir 8 (använder real term serial capture program 2.0.0.70). Detta begriper jag inte.
Kan nämna att samma koppling användts för ett C program som skriver ut text med printf utan dessa problem.
Icecap skrev:
Mina hatobjekt:
goto $-2 ; Är det problem att göra en label istället?
Inte mitt hatobjekt. Behöver skriva mer för att använda labels och det kan bli väldigt många labels i ett program om man har många sådana här små loopar.
Icecap skrev:
bsf TXSTA,TXEN,0 ; Den ska finnas i initieringen! Inte i utskriftrutinen!
bsf PORTC,RC6,0 ;Sätt RC6 TX hög ; Varför då? Den är ju redan hög! Det är vid initieringen man ska sätta den hög!
sodjan skrev:> Resultatet blir istället att ACAC skrivs ut och att char count blir 8
Char count, är det något som RealTerm räknar ?
Kan du ställa om RealTerm i något "hexdump" läge så att
du ser vad dessa 8 tecken består av ?
?
Ja så förstår jag det. Om jag ändrar display as till hex så skrivs hex koderna ut för tecknen ACAC men char count blir då 4. Har sett att det finns två ascii val (förstår inte varför). Det ena av dessa ger ett char count dubbelt så stort som antalet skrivna tecken.
sodjan skrev:>
> bsf PORTC,RC6,0 ;Sätt RC6 TX hög
Varför ?
En start bit ska vara hög och gå låg. Har för mig att i ett gammalt program jag gjort behövde detta göras för att det skulle fungera.
T.ex om jag skriver A B C D så blir resultatet A D A D. Skriver jag bara två tecken A B så blir det A B A B. Lägger jag in raderna för att skriva C D inuti loopen så skrevs bara en massa C ut. Vid försök att en gång skriva ABCDEF skrevs istället FAFA
Låter som något timing strul.
Antingen har du fel när du kollar att/om USART'en är ledig
eller så är det baudrate fel (inte så troligt, det verkar stämma).
Om du lägger in en rejäl delay mellan varje tecken så att det
inte enbart är sänd-flaggan som styr, vad händer då ?
(Och har du inte testat det redan ?)
Oscilloskop är guld när man felsöker sånt där. Bara att skicka samma tecken oavbrutet.
Jag skrev en fungerande serieportsrutin i assembler till ABC80 när jag gick på högstadiet, så det är inte så himla komplext. Den körde visserligen bara 300 bps, men där använde jag alltså inte ens en UART utan bitbangade. (Assemblerrutinen anropades sen från basic för att skicka och ta emot tecken, tror vi pollade vid mottagning t.o.m.)
Har du kollat i hedumpen vad du får för värden och skrivit upp dem i binär form för att se?
Att skicka A (0x40) är kanske inte smartaste för felsökning. Det är ju 0100000 binärt.
0x0F (Ctrl-O), 0x33 ("3")och 0x55 ("U") kan vara vettigare mönster att testa med. Fast då måste du ju köra hexdumpläget när du tar emot.
Binärt blir de:
0x0F=00001111
0x33=00110011
0x55=01010101
Då är det lättare att se om det är timingfel, om bitar blir förskjutna eller överlappar.
sodjan skrev:Låter som något timing strul.
Antingen har du fel när du kollar att/om USART'en är ledig
eller så är det baudrate fel (inte så troligt, det verkar stämma).
Om du lägger in en rejäl delay mellan varje tecken så att det
inte enbart är sänd-flaggan som styr, vad händer då ?
(Och har du inte testat det redan ?)
Vad *har* du egentligen gjort för felsökning ?
Jag har försökt med 9600 baud (samma konstiga resultat) och att skriva ut olika antal skilda tecken både i och utanför loopen för att kunna se ett mönster i det hela. Och jag ser faktiskt inget mönster. Endast en del av mina tecken skrivs ut och det ibland i fel ordning.
Försökte med föreslaga 0x0F 0x33 0x55 inuti loopen och fick detta hex utskrift resultat
0F 33 0F 0F 55 55 33 33 0F 55 55 55 33 0F 0F 55 FF
Har inte ännu försökt med delay mellan varje tecken (jo bortsett från ett pat NOP instruktioner). Detta har inte behövts vid användning av USART på andra PIC. Och med dom så får man väl inte den önskade hastigheten på överföringen
På den där hexutskriften ser man ju att de enskilda tecknen blir rätt, det som händer är att du tappar tecken. En modern dator ska inte ha problem med att ta emot data i 9600, så mest troligt är att du tappar tecken vid sändningen.
Som Sodjan skrev: Kan det vara så att du skriver över UARTens sändbuffert innan den hunnit sända tecknet?
Men sen menade ju inte jag att du skulle skicka de där tecknen tillsammans, utan var för sig.
Alltså först prova att skicka en massa 0x0F, sen en massa 0x33 och sen en massa 0x55. Men i det här fallet kan vi se felet ändå, inget av de där tecknen kan ju misstolkas som ett annat av dem på grund av timingfel.
