Varför kortsluta CTS# till RTS# på ft232?

[sodjan]

Kom gärna tillbaka med det verkliga felet så att tråden inte
bara slutar i ett tomt ingenting. Och hintar har du ju fått så
det räcker och blir över här...

[christoferivarsson]

Ok, här kommer min seriekommunikations serie62.C som är inkluderat i huvudprogramkoden och alltså styr UARTen. Även en serie62.h fil finns men den klistrar jag inte in för den säger inte så mycket mer.

Terminalprogrammet jag använder heter DSA´s MTTTY men det skulle likaväl kunna köras med windows hyperterminal


Jag har testat tre olika huvudprogramkoder

1. echo.c = ekar tillbaka motsvarande tecken som du skriver på tangentbordet
2. HelloWorld.c = skriver Hello World i terminalfönstret när PICen startas
3. comp.c = PICen ställer en fråga, man svarar på frågan, svaret jämförs med en sträng i programmet. Om rätt svar skrivs "rätt, grattis", om fel svar skrivs "tyvärr fel"

Jag kan klistra in koderna men det blir så svårt att läsa tråden.

Nu till saken. PICen kör 8bitar, 1 start och en stopbit, ingen paritet. Alltså totalt 10 bitar. I terminalen kan man inte ställa in startbit(?) men man ställer in 8-bitar ingen paritet och en stoppbit. Det enligt min kurslitteratur så det skall va rätt.

Hur somk helst. Koden för alla 3 program skriver ut förväntat antal tecken men med fel tecken, alltså en massa skumma syboler i stället för typ Hello World. När jag ställer om terminalen till 7bitar, 1 stop ingen paritet så blir det rätt.

Ok allt fine tänker ni, men nu e de så att echo.c samt hellowrold.c funkar fint men i comp.c så måste jag ju svara på en fråga och när jag då försöker skriva in tecken till PICen så svarar den inte på "return" som den skall. Om jag nu ställer om till 8-bitar igen så svarar PICen på "return" dvs den tar emot mitt svar men nu e tecknen fel.

Har försökt beskriva det tydligt tycker jag även om det är svårt. Med lite tur kan jag låna ett oscilloskop idag och se om kommunikationen stämmer.

Är det någon som har erfarenhet av FTDI FT232r chipet? jag köpte sladden på ELFA och programmerade om den med MPROG. Kan det blivit fel där?

Kod: Markera allt

/* seriF62x.c getchar, putchar, initserial for 16F62x  */
/* Function prototypes is in seriF62x.h                */
/* 16F628: Serial output is at PORTB.2 ( pin 8 )       */
/* 16F628: Serial input is at PORTB.1 ( pin 7 )        */

void initserial( void )  /* initialise serialcom port */
{
   SPEN = 1;
   BRGH = 1;  /* Async high speed   */
   TXEN = 1;  /* transmit enable    */
   SPBRG = 26-1;  /* 9600 Baud @ 4 MHz-clockfrequency */
   CREN = 1;  /* Continuous receive */
   RX9  = 0;  /* 8 bit reception    */
   TRISB.2 = 0;  /* serial_out is output */  
   TRISB.1 = 1;  /* serial_in is input   */  
}


bit putchar( char d_out )  /* sends one char */
{
   if(d_out == '\0') return 0; /* refuse to send 0 "end of string" */
   while (!TXIF) ;   /* wait until previus character transmitted   */
   TXREG = d_out;
   return 1; /* done */
}


/* If two (or more) char's are recieved, but not read, the reciever will be locked! */
/* To unlock the reciever, run function OverrunRecover()                            */

void OverrunRecover(void)
{  
   char trash;
   trash = RCREG;  /* the two char's that locked the reciever  */
   trash = RCREG;  /* are read and ignored                     */
   CREN = 0;       /* the unlock procedure ...                 */
   CREN = 1;
}


char getchar( void )  /* recieves one char */
{
   /* One start bit, one stop bit, 8 data bit, no parity. 9600 Baud. */
   char d_in;
   while ( RCIF == 0 ) ;  /* wait for char */
   d_in = RCREG;
   return d_in;
}

[thepirateboy]

Vad har du ändrat med Mprog? Sladden ska funka direkt utan att något ska behöva ändras. Jag kör med sådan sladd dagligen. Ett enkelt sätt att testa sladden är att koppla ihop TX/RX och skicka något från PC:n, då ska det komma tillbaks i terminalen.

[christoferivarsson]

Det enda jag gjorde va att ändra namnet på koppling, dvs det som visas i windows när man kopplar in sladden, samt att jag ändrade till lock serial number för att den alltid skall få samma comportsnummer.

Den fungerar fint när jag kopplar samman Tx med Rx.

Visst räcker det med att köra gemensam Jord också? Jag matar kopplingsdäcket via PicKit2 och inte via FTDI-sladden, däremot har jag sammankopplat Jorden. Det måste väl räcka?

[sodjan]

> jag köpte sladden på ELFA...

"sladden" ? OK, det är möjligt att det stog tidigare vilket
artikelnummer det var, jag kan inte se det just nu.

> alltså en massa skumma syboler i stället för typ Hello World.

Ett exempel vore väldigt bra. Gärna i hex.

> Terminalprogrammet jag använder heter DSA´s MTTTY...

OK, men du skrev tidigare :

> Jag kan inte kopiera text från terminalen....

Men vad har menyvalet "Edit" -> "Copy contents to clipboard" för funktion då ?
Varför kan du inte kopiera texten från terminalfönstret ?

Eller byt terminalprogram till ett där du antingen kan kopiera texten eller
som kan visa kommunikationen i HEX (helst båda...) Eller koppla på
ett oscillioskop på "linan" och titta på vad som sänds. Du kan även prova
med att justera SPBRG ett "snäpp" upp eller ner för att se om det är
hastigheten som ligger på gränsen. Jag skulle även rekomendera att du
stoppar dit en PIC med den nyare och mer exakta INTOSC. Eller hänger
på en kristall, så minskar risken för att det är baud-rate rellaterat.

[Nerre]

Jag kan inte kopiera text från terminalen men så här kan det se ut när jag skriver ett tecknet m flera gånger 'mmmmmmmàmmmmmmmmmmàmmàmmmm

En sak som slog min nu är att du vet ju inte om det är ett m som blir ett à eller om det är TVÅ m som blir ett à. Eller om det dyker upp ett extra à mellan två "korrekta" m.

Om du provar att skriva abcdefghijklmnopqrstuv etc så märker du ju tydligare om det bara är enskilda tecken som påverkas eller om det blir tappade tecken.

[christoferivarsson]

Jo jag vet att ett feltecken motsvaras av ett annat endast. Har nämligen kört med inkopplat "echo" och då ser jag först det tecknet jag trycker ner på tangentbordet följt av ett á.

Sodjan, sladden nämndes tidigare i tråden. Vad heter den nyare 16f628 som har bättre nogrannhet?

[sodjan]

I princip alla med 8 Mhz INTOSC.
Jag har för mig att F88 var en av de första, men nästa alla
som har kommit efter det hör till den generationen. Du kan hitta
dom i Microchips sökverktyg. De jag har på kontoret
finns på http://www.jescab.se/Prod_PIC.html

[christoferivarsson]

Nu har jag kollat upp signalerna med oscilloskopet.

Tecknen som sänds till PIC är alltid korrekt och samma(förväntat). 104 uS per bit vilket ger 6915 Baud. Helt ok!

Tecknen som sänds till datorn från PIC varierar mellan ibland 10 bitar och ibland 9. Eftersom MSB kommer sist så vlir det såklart helt andra tecken som skickas.

När PIC sänder 10 bitar är det med hastigheten 100uS ber bit. När den skickar 9 bitar är hastigheten 96-98 uS per bit. Alltså varierar Baudraten från PIC till i värsta fall 10200 Baud.

Varför skickar PICen fel tecken?

En fråga till. Totalt skall det vara 10bitar varav 1 startbit, 8 teckenbit och 1 stoppbit. Är startbiten alltid 0? Är stoppbiten 1? Om jag räknar bitar på oscilloskopet så är det 9 om man inte räknar med sista biten som är hög. Svårt att säga om det är en bit eftersom nivån sen stannar på hög i viloläge.

[bearing]

Ja, startbiten är alltid låg, stopbiten hög. Jag tror inte på att andast 9 bitar sänds ibland.

Gör ett program i vilket du kan öka/minska kalibreringsvärdet för oscillatorn genom att skicka t.ex.'+' och '-'. Prova att minska hastigheten lite tills bittiden varierar kring 104 istället för 96-100. Laddar programmet kalibreringsvärdet ifrån EEPROM, föresten?

[sodjan]

Enklast att kolla om det är baudraten som "spökar" är att hänga på en kristall.

Du kan också skriva ett litet program som t.ex genereat en fyrkantsvåg
på en pinne och sedan bevaka denna ett tag för att se om det är
oscillatorn som är instabil.

Det är inte så lätt att "se" en USART kommunikation på oscilloskopet, det
underlättar om man har ett program som hela tiden sänder om samma tecken,
så att man kall skruva på triggern och få en statisk bild.

Slutligen så skulle jag nog skippa denna lite äldre PIC och ta en modern istället...

[Nerre]

Viloläge för en serielina är 1.

Startbiten måste därmed vara 0, mottagande sida ska alltså starta mottagningen på flanken mellan 1 och 0.

Stoppbiten är egentligen ingen "bit" utan bara "viloläge" (d.v.s. 1) en stund (för att man ska kunna trigga på nästa startbit).

Det är normalt på sändande sida som man måste välja om det ska vara 1 eller 1,5 eller 2 stoppbitar och det måste man anpassa till hur lång tid mottagande sidan behöver på sig innan den är redo att ta emot nästa byte.

Om mottagande sidan klarar 1 stoppbit så klarar den även 1,5 eller 2 stoppbitar (eftersom det går inte att se nån skillnad mellan 2 stoppbitar och en stoppbit och lite extra paus mellan tecknen).

[christoferivarsson]

Det står i readme.txt fien till min seri62x.c som jag bifogade att den gäller


Tx(PIC) =8bitar
Rx(PIC) = 7bitar

Är det möjligt att ha olika antal bitlängd på Tx och Rx?

Skall läsa igenom databladet...

[vfr]

Varför testar du inte med kristall med en gång?

Det har både jag och Sodjan föreslagit. Då kan du direkt få svaret om det är oscillatorfrekvensen som är problemet eller inte. Det måste ju vara det viktigaste att ta reda på. Annars är det ju bortslösad tid att felsöka något annat. Och tvärtom. En kristall på 3,6864 MHz ger fina baudrater direkt nerdelade i faktorer av 2. Är det inte oscillatorn som är problemet, så kan du ju ta bort kristallen igen och återanvända till något annat om du vill. Men då vet du iallfall om det är det som är problemet och behöver inte famla i blindo.

[christoferivarsson]

Jo jag skall testa men har ingen kristall hemma...