Seriell LCD igen. Hjälp mig...

klasg · Inlägg av **klasg** » 12 augusti 2005, 23:33:47

"Kolla TXSTA.TXEN på sid 78. TXEN bör nog vara = 1."
TXSTA var har jag ju redan satt till ett. På rad 61. fixade det när jag skrev "EDIT. Uppdaterade zipen igen, såg en miss." men såg att det av någon anledning inte blev upplaggt på ftpn.

"Du ska nog inte testa PIR1.TXIF utan TXSTA.TRMT i sendchar."
OK, fixat.

"Om du sätter BRG16=1, så måste du ladda både SPBRGH *och* SPBRG..."
Den är ju nollad.

Ska gå igenom allt grundligt imorron.

sodjan · Inlägg av **sodjan** » 13 augusti 2005, 01:56:51

Hej.
Har hittat två saker :

1. "movfw txreg" skall vara "movwf txreg".

2. F688'an startar inte upp i 8 Mhz som default. Man får sätta OSCCON
till rätt hastighet (vilken man nu vill ha). Jag satte OSCCON=h'70' (=8 Mhz)

Jag har kopplat upp en "riktig" F688's och jag får nu ut "Hello" på USART'en.
Med SPBRG = d'51'.

Sen, jag hade i hastighten fel på TXIF/TRMT. Och TXEN var ju =1, som du säger. Samt BRG16=0, jag såg fel. Ursäkta !

/Janne.

klasg · Inlägg av **klasg** » 13 augusti 2005, 10:27:20

Hej.

Nu tror jag nästan att det går lite framåt. Helt fantastiskt.

1. Åhh. det borde jag ha märkt själv. Gick mycket bättre när jag ändrade det.

2. Okej, det är också fixat.

Men det är fortfarande någonting som inte stämmer riktigt. För mig så skriver den ut t.o.m. '1'. Efter '1' så står den bara och väntar. Uppdatering.
/Klas

EDIT. Uppdaterat zipen.

sodjan · Inlägg av **sodjan** » 13 augusti 2005, 11:28:03

OK.
Nu har vu alltså börjat få ut *någonting* på displayen, right ?

Det borde betyda att kommunikationen fungerar i princip.
Det känns som det nu är frågan om att rätt förstå hur "kommandona" till LCDn skall se ut.

Det kan vara fördröjningar mellan LCD-kommandon som spökar. Jag skulle försöka att köra LCDn med den lägsta hastighet som den stödjer. Enligt en kommentar i källkoden så skall det inte behövas några fördröjningar vid 2.400 baud.

Sen, har du verifierat att dina delay rutiner ger *rätt* fördröjning ? Kolla med "stopwatch" i simulatorn. Sätt breakpoints direkt föra anropet till MDLY och sätt ett direkt efter. Nolla stopuret vid första och läs av vid det andra. Jag vet dock inte hur känslig LCDn är för detta...

> "För mig så skriver den ut t.o.m. '1'. "

Är inte "1" ett LCD-kommando (rensa skärmen) ? Skriver den ut en 1'a på skärmen ?

Hur som helst, det verkar som om koden i sig i alla fall skickar något till LCDn, och eftersom jag inte har tillgång till någon LCD, så har jag lite svårt att komma mycket längre...

klasg · Inlägg av **klasg** » 13 augusti 2005, 11:49:05

Naj, jag har inte tillgång till LCDn nu under helgen tyvärr, så jag vet inte om det kommer komma ut någonting. Men när jag simulerar så ser jag att den skickar ut h'fe' på txreg och sedan '1', som mycket riktigt är ett LCD-kommando. Efter att den kommit till '1' så står den bara och studsar i sendchar. Den försöker alltså skicka h'fe' igen men det går inte. Simulerat alltså.

Blir iaf spännande att testa på måndag

/Klas

sodjan · Inlägg av **sodjan** » 13 augusti 2005, 11:57:37

Kolla "Simulator -> Settinings", där finns en flik som heter "UART I/O" eller något liknande. Där kan man klicka i "Enable UART I/O" och välja mellan I/O till fil eller till ett fönster.

klasg · Inlägg av **klasg** » 13 augusti 2005, 12:16:05

Funkade inte. Hmm...
(Blir offline ett par timmar)
/Klas

PS. Måste bara tacka igen för all hjälp. Jättebussigt att du tar dig tid!

klasg · Inlägg av **klasg** » 13 augusti 2005, 21:47:46

Nu har jag kikat igen. Det är någonting med txif. Den blir nollad efter '1', den andra h'fe' skrivs aldrig ut. Tar jag däremot bort hela holdsend-grejen så värkar den skriva ut allt, men då får jag istället ett meddelande som lyder: "UART-W0001: Overrun, write occured over a full TXREG SFR. Data lost"...skit också. Det som gick så bra ett tag

/Klas

sodjan · Inlägg av **sodjan** » 13 augusti 2005, 23:34:51

Vad som händer är att USART'en inte hinner sända i tid (och överföra TXREG till det andra registeret (vad det nu hette) varifrån datat shiftas ut), så TXREG "skrivs över".

Sa du att TXIF blir=0, men att skip intruktionen inte verkar "se" det ?
Det var så jag förstog det...

När jag tänker efter, så kanske jag fick lägga till någon extra "banksel". Alltså detta

Kod: Markera allt

sendchar    bank0
holdsend    btfss   pir1,txif       ; Check before transmitting.
            goto    holdsend
            movwf   txreg           ; Send if it's OK 2 send.
            return

såg ut ungefär så här (ur minnet !) när jag körde :

Kod: Markera allt

sendchar
                 banksel pir1
holdsend
                 btfss      pir1,txif       ; Check before transmitting.
                 goto       holdsend
                 banksel  txreg
                 movwf   txreg           ; Send if it's OK 2 send.
                 return

Det kan också har varit på flera ställen, kolla där du byter register och lägg till banksel om det saknas. (I verkligeten behövs ju inte banksel så länga man ligger kvar i samma bank, men jag har inte kollat upp i databladet...)

klasg · Inlägg av **klasg** » 14 augusti 2005, 00:06:37

Ah... Kom på en sak. Jag har alltid klickat på "Animate" när jag simulerat (för att lätt se allt som händer i registren). Nu. Klickade jag "Run" istället. Och vipps: "~1~2Hello"

Antagligen så funkar det då också med animate-knappen, fast det tar ett bra tag innan det händer något.

Fixade det där med bankerna också.

Spännande att testa programmet på måndag

/Klas

EDIT: När jag simulerade med animate så kommenterade jag så klart bort mdly. Annars hade jag fått vänta i dagar...

sodjan · Inlägg av **sodjan** » 14 augusti 2005, 00:17:19

När man kör animate, så körts ju allt långsammare.
Dina iaktagelser tyder på att även USART'en körs lika långsamt, sannolikt för att få timing'en mellan koden och USART'en att stämma.

Det skulle betyda att det hade "släppt" om du bara hade väntat.

Det var nog inte många baud ut från den USART'en...

EDIT : Glömde, använd breakpoints istället för animate ! Betydligt smidigare...

klasg · Inlägg av **klasg** » 16 augusti 2005, 10:43:33

Tja.
Nu har jag testat skiten(!) och det funkar så klart inte Varken vid 2400 eller 9600 baud. Typiskt.

Först när MPLAB har programmerat picen så kommer det upp någonting på displayen, dessa tecken visas bara någon mikrosekund och skrivs sedan över av samma meninglösa tecken som första gången, fast i en annan ordning eller nåt. Är ju bara mongotecken så det är svårt att se...

Det som jag är lite fundersam över är att TX-porten blir ettställd efter programmeringen, ska det vara så? Borde inte TX bli noll när datan är skickad? En konstant etta är ju dessutom "testsignalen" för displayen. +5V på SER ingången till displayen får den att skriva en testslinga. Den signalen som ligger på TX-porten efter programmeringen är inte exakt +5V, utan något lägre, 4,95V - vilket gör att den skriver ut lite skit-tecken istället (enligt mig).

Hoppas att jag förklarade ordentligt nu.

Skulle det föresten vara/bli lättare att felsöka med en riktig debugger, in circuit?
/Klas

Icecap · Inlägg av **Icecap** » 16 augusti 2005, 10:51:14

En Uart i "viloläge" skickar ut en '1', jag antar att det har med att göra att man då kan känna av om ledningen är bruten eller det bara är inaktivitet.

Men inte sändar något = '1'
Startbitten är en nolla så det passar ju bra.

En ICD är DEFINITIVT en trevlig grej, jag har hittat MÅNGA klantigheter med den, uträkningar som blev fel osv. Jag ska kanske skaffa ICD2 (eller en klon) men inte i nu-läget, jag håller på att gå bort från PIC....möjligen, luter lite åt PIC18...

Hursomhelst är en ICD guld värd om man håller på en del, man kan debugga, programmera osv, köra programmet i full hastighet på aktuell hårdvara, stoppa vid breakpoint, allmänt kolla registre, minne osv.

Nära nog ett måste om man vill vara "seriös".

klasg · Inlägg av **klasg** » 16 augusti 2005, 11:39:06

OK.
Då är alltså en etta helt normalt... hmm... Vad kan vara fel då?

Har länge funderat på att köpa mig en egen programmerare, och har då funderat på denna från olimex. Kan den vara nåt?

sodjan · Inlägg av **sodjan** » 16 augusti 2005, 13:27:01

Jag misstänker att det är något med hur själva hårdvaran "ser ut" på PICkit1.
Alltså kanske någon konflikt mellan de prylar som redan sitter på kortet och de pinnar som du försöker använda till LCD'n. Jag har ingen själv, så det är lite svårt att kolla...

Sedan, som har sagts här så ligger TX utgången hög i viloläge.
Det verkar helt ortroligt att detta skulle vara något självtestläge, möjligen om den ligger hög *innan* spänningen slås på !? Hur som helst, databladet för LCDn borde klargöra det.

"är inte exakt +5V, utan något lägre, 4,95V - vilket gör att den skriver ut lite skit-tecken istället (enligt mig)."

Vadå, att någon spänning är 4.95 istället för 5.00 volt ? Inte en chans...

Jag tror att det är dags att ta ett steg bakåt och verifera allt igen.
Hur LCDn är inkopplad. Delar den pinne med något av allt det andra på PICkit1'an ?
Kan du programmera och köra något av demo programmen som följer med PICkit1'an ?
Sitter 16F688'an i "Evaluation socket" ?
Kolla de scheman som finns i PICkit1 manualen igen. Delas de pinnar du har valt till LCD'n med något annat på kortet ?
Har du ställt om INTOSC till 8 Mhz ?

Har du tillgång till ett oscillioskop ?
Då är et ganska enkelt att verifiera dels hastigheten på F688'an, dels om det kommer ut något alls från USART'en.

I LCD manueln står det : "When the BPI-216 is first powered up, it requires about 750 milliseconds (ms) to initialize the LCD and get ready to receive data. Programs should wait about a second after powerup before sending data to the BPI-216."

Gör du det ?