LCD problem/MikroC/PIC18F4550

PIC, AVR, Arduino, Raspberry Pi, Basic Stamp, PLC mm.
jorgenp
Inlägg: 91
Blev medlem: 23 mars 2009, 14:42:21
Ort: Stenungsund

LCD problem/MikroC/PIC18F4550

Inlägg av jorgenp »

Jag har lite problem att få min display att fungera på mitt egentillverkade kort. Det är en vanlig HD44780 display som krånglar.
Den fungerade fint på labbkortet och var inkopplad på exakt samma sätt som nu. Koden för LCD-displayen som fungerade bra på labbkortet fungerar inte på mitt etsade kort.

All annan funktionalitet fungerar bra, som t ex toggla lysdioder, känna av switchar och annat.

Kortet ser ut så här:
Bild

När man kör koden får man två rader med fyrkanter på displayen. Jag antar att det ser ut så om displayen inte initieras ordentligt?

Bild

Jag har tittat på alla utsignaler på PORTD (som är den som är kopplad till displayen) och allt som kommer verkar vara VCC på alla portar som hör till displayen.

Om jag istället kopplar bort displayen och gör en PORTD=~PORTD i en while-loop så får man en fin fyrkantsvåg i oscilloskopet. Så E, RS, D4-D7 har möjlighet att kunna komma fram till displayen iaf.

Jag använder MikroC och deras LCD-bibliotek (Jag vet, "skriv din egen funktion.") Men det som är märkligt är att E och RS är helt tysta (bara konstant VCC vad det verkar) när man kör ut text i while-loopen? Det borde väl märkas på oscilloskopet att nåt händer där?

Jag råkade designa kortet med R/W på RC6 och inte någonstans på port D. Men jag har kopplat RW på displayen till jord. När man initierar displayen med Lcd_Config så har jag sagt att R/W finns på RD1 (eftersom jag inte använder den till något annat). Kan det vara det som är problemet? Fast jag hade inte R/W inkopplad på labbplattan heller.

Min testkod:

Kod: Markera allt

#define POWERLED  PORTA.F4
#define SCANLED   PORTA.F5
#define FAULTLED  PORTA.F3

#define UV1      PORTA.F6
#define UV2      PORTC.F0
#define UV3      PORTC.F1
#define UV4      PORTC.F2

#define BUZZER   PORTD.F0

#define ROTBUTTON1 PORTA.F0
#define BUTTON2    PORTA.F1

void main(void) {
     TRISC = 0x0;     
     SPPCON = 0x0;
     SPPCFG = 0x0;
     PORTC= 0x0;
     PORTB = 0x0;
     UCON =  0x12;
     UCFG =  0x08;

     TRISB = 0xE0;

     PORTA = 0x0;
     ADCON1 = 0x0F;
     CMCON = 0x07;
     TRISA = 0x0;

     OSCCON = 0xFF;
     UV1=0;
     UV2=0;
     UV3=0;
     UV4=0;
     PORTD.F0=0;
     
     POWERLED=1;
     SCANLED==0;
     FAULTLED=0;
     count=0;

    //  RS = 2, EN = 3, R/W = 1, D7-D4 = 7-4
     TRISD = 0x0;
     Lcd_Config(&PORTD, 2,3,1,7,6,5,4);
     Lcd_Cmd(LCD_CLEAR);
     Lcd_Cmd(LCD_CURSOR_OFF);

     delay_ms(500);

     while(1) {
        Lcd_Out(1,1,"test");
//          PORTD= ~PORTD;
        if(ROTBUTTON1==1) {
                        BUZZER = ~BUZZER;
                        SCANLED=~SCANLED;
        }
        if(BUTTON2==1) {
                        SCANLED=~SCANLED;
        }
     }
}
sodjan
EF Sponsor
Inlägg: 43251
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping

Re: LCD problem/MikroC/PIC18F4550

Inlägg av sodjan »

Att två rader har fyrkanter brukar vara normalt när LCD'n har kört sin
interna själv (power-on) test och innan du har skickat någonting alls
till den. Helt normalt alltså...

Under normal drift (d.v.s då du försöker skriva till LCD'n) så ska det absolut
hända någonting på E varje gång ett (halv) kommando eller tecken skrivs.
Samma sak för RS, men bara när du byter mellan "kommando" och "tecken".

Om du inte tänker läsa från LCD'n, så är det enklast att lägga R/W hårt till GND
så sparar du en pinne. Sen vet jag inte om MikroC rutinerna i alla fall vill
ha en pinne till R/W, eller att du inte fungerar alls om de inte kan läsa från
LCD'n...

Jag skulle testa med någon annan LCD kod först för att verifiera
att kort och koppling är OK.

EDIT: En sak till...
Lägg en delay på en halv till en sekunds delay *innan* init av LCD'n.
Det är inte säkert att LCD'n har hunnit igenom sina självtester
innan processorn försöker skriva till den...
Användarvisningsbild
Icecap
Inlägg: 26660
Blev medlem: 10 januari 2005, 14:52:15
Ort: Starup (Haderslev), Danmark

Re: LCD problem/MikroC/PIC18F4550

Inlägg av Icecap »

Om allt fungerade på labb-plattan och inte nu och den enda skillnad är att du har tillverkat ett kretskort där du har monterat det är det inte kopplat som det var på labb-plattan! Så enkelt är det!
jorgenp
Inlägg: 91
Blev medlem: 23 mars 2009, 14:42:21
Ort: Stenungsund

Re: LCD problem/MikroC/PIC18F4550

Inlägg av jorgenp »

Jag upptäckte just felet och det var lite märkligt. Jag ville ha min gamla uppkoppling på labbplattan kvar så jag köpte bara en ny 18F4550 på Kjell som jag kunde använda till kortet.
Och med den gamla processorn (Också köpt på Kjell för en månad sen eller så) funkar så klart min gamla kod. Men med den nya processorn funkar inte displaykoden förrän man slår av XINST-flaggan i CONFIG4L.
Så det verkar vara olika versioner av 18F4550 jag fått. Lite värdelöst.

Så nu funkar min display med mitt etsade kort och den nya processorn.
Märkning på chippet:
PIC18F4550-I/P
0918EK1

Gamla processorn:
PIC18F4550-I/P
084168B

Känns som man borde gå till Kjell och byta ut den gamla processorn mot den nyaste versionen om det går.
sodjan
EF Sponsor
Inlägg: 43251
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping

Re: LCD problem/MikroC/PIC18F4550

Inlägg av sodjan »

Så vitt jag vet har "extended instruction set" alltid funnits med
i denna processor. Och alltså också XINST biten i CONFIG.

> ...förrän man slår av XINST-flaggan i CONFIG4L.

Men så hade du det väl redan innan, eller hur ?
Och om inte, varför inte det ? Ville du köra med "extended instruction set" ?
Stöder MikroC det fullt ut ? Har du samma version av MikroC nu som tidgare ?

Jag hittar inget i någon av Errata dokumenten om att det skulle
ha varit något problem med XINST biten...
jorgenp
Inlägg: 91
Blev medlem: 23 mars 2009, 14:42:21
Ort: Stenungsund

Re: LCD problem/MikroC/PIC18F4550

Inlägg av jorgenp »

Nej, när jag körde på labbplattan hade jag inte rört den flaggan av någon anledning så den var inte satt i MikroC. Man har två val, XINST_ON och XINST_OFF. Jag hade inte klickat i något val för den flaggan innan så jag vet inte vad den blir satt till då.

Men om man kör så på labbkortet med gamla processorn funkar det.

Kör man så på nya processorn funkar det inte.

Och det är bara MikroC's displayrutiner som inte funkar då, kan jag ju tillägga. Ännu en anledning till att inte använda sluten källkod där man inte har en aning om vad som händer under skalet.

Jag ska testa att koppla in displayen på labbrädan istället och testa med de tre olika XINST-fallen och se vad som händer då.
sodjan
EF Sponsor
Inlägg: 43251
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping

Re: LCD problem/MikroC/PIC18F4550

Inlägg av sodjan »

> Jag hade inte klickat i något val för den flaggan innan...

Exakt. Det är just det som är "felet".
Du ska välja det alternativ för *alla* CONFIG inställningar som du vill ha.

> och testa med de tre olika XINST-fallen

Varför det ? Ställ bara in det som du vill ha det.
(Tre fall ? Den kan väl bara vara "ON" eller "OFF" ?)
jorgenp
Inlägg: 91
Blev medlem: 23 mars 2009, 14:42:21
Ort: Stenungsund

Re: LCD problem/MikroC/PIC18F4550

Inlägg av jorgenp »

För att jag tycker det kan vara intressant att se exakt vilka inställningar som funkar på den gamla processorn och vilka som funkar på den nya.

Men hur som helst så funkade inte ens hex-filen som fungerade på den gamla processorn på den nya. Så nån skillnad måste det vara mellan de två hårdvaruversionerna.

Och det kan teoretiskt vara fyra olika inställningar för XINST såg jag nu eftersom MikroC använder checkboxar istället för radioknappar för CONFIG-inställningarna. Jag vet inte hur MikroC hanterar de två extremfallen. Om flaggan antingen är på eller av är ju enkelt. Men vad exakt den gör när man sagt att båda ska vara på eller ingen ska vara på vet jag inte. Men jag ska läsa lite i manualen och se om det står där.

Bild

Bild
Användarvisningsbild
vfr
EF Sponsor
Inlägg: 3515
Blev medlem: 31 mars 2005, 17:55:45
Ort: Kungsbacka

Re: LCD problem/MikroC/PIC18F4550

Inlägg av vfr »

Sätter du configbitarna i utvecklingsmiljön?

Sluta isåfall genast med det! :)

Det ställer till med mycket konstigheter. Sätt dom i källkoden istället, så är det ingen som helst tvekan om vad dom är satta till. Det här är ett typexempel på det!

Edit: Precis den skillnaden du säger med hexfilen som inte funkar på den ena processorn, kan bero på att flaggorna varit olika satta vid programmeringen. Sätter du dom i koden så kommer dom med i hexfilen.
Användarvisningsbild
Glenn
Inlägg: 36805
Blev medlem: 24 februari 2006, 12:01:56
Ort: Norr om Sthlm
Kontakt:

Re: LCD problem/MikroC/PIC18F4550

Inlägg av Glenn »

Jag tror inte microc hanterar det alls, utan dessa checkboxar sätter bara flaggorna och skickar med i asm-filen.

Lätt att kolla iofs, för du får väl ut den med ?
sodjan
EF Sponsor
Inlägg: 43251
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping

Re: LCD problem/MikroC/PIC18F4550

Inlägg av sodjan »

> Och det kan teoretiskt vara fyra olika inställningar för XINST såg jag nu...

Hm, jo, dels är det ju lite korkat att miljön i sig tillåter att man kan välja flera
alternativ som är sina motsatser. I processorn är det bara en bit som
naturligstvis bara kan ha två värden. Så det är helt ointressant att
testa *båda* "unchecked" eller *båda* "checked", *EN* av dom ska vara vald.

Ta t.ex inställningarna för val av oscillator där det finns upp till ett
tiotal olika alternativ. Har de också check-boxar så att man kan välja
vilka och hur många som helst av dom ? Det blir ju tusentals kombinationer
fast bara ett alternativ kan vara valt i processorn åt gången !

Jag hittade inget i dokumentationen om att ha CONFIG i källkoden, det är ju
annars klart enklast som vfr också sa. Men går det inte så går det inte... :-)

> Men hur som helst så funkade inte ens hex-filen som fungerade på den gamla processorn på den nya.

Men för att kunna säga något bestämt om det så måste HEX filerna jämföras.
Kolla vad som ligger på den aktuella adressen och kolla hur XINST faktiskt är satt.

Eftersom det inte finns något annat som pekar på att det faktiskt skulle vara
skillnad på processorerna (t.ex en Errata där det nämns) så tror jag just nu
att du bara har dribblat bort dig med filerna. I alla fall tills innehållet i de olika
HEX filerna har analyserats... :-)
Är inte filerna allt för stora så kan du ju alltid posta innehållet, eller i alla fall
de rellevanta (d.v.s CONFIG adresserna) delarna.
Användarvisningsbild
Glenn
Inlägg: 36805
Blev medlem: 24 februari 2006, 12:01:56
Ort: Norr om Sthlm
Kontakt:

Re: LCD problem/MikroC/PIC18F4550

Inlägg av Glenn »

fast nu var det väl en och samma hexfil som funkade på den ena picen och inte på den andra ? det är ju märkligt oavsett.

Är det f.ö SAMMA display du använder ? Sodjan var ju inne på det innan, men jag har ju gjort klantfelet med att ha för kort gracetid för displayinitialisering, vilket fungerade fint tills jag satte dit en annan (i mitt tycke likadan) display, då funkade det inte alls.. det visade sej att den tog lite längre tid på sej att initialisera.. sen dess brukar jag ta 1sec för säkerhets skull. (..Givetvis var ju det första fungerande exemplet på labbbrädan, och det andra ickefungerande på ett verokort, så man letade ju efter hårdvarufel helt i onödan..)
Användarvisningsbild
vfr
EF Sponsor
Inlägg: 3515
Blev medlem: 31 mars 2005, 17:55:45
Ort: Kungsbacka

Re: LCD problem/MikroC/PIC18F4550

Inlägg av vfr »

Men om nu configbitarna sätts i utvecklingsmiljön och inte i koden, så är det ju inget konstigt om det fungerar i den ena men inte i den andra. Configinställningarna var väl olika satta vid programmeringen av dom två kretsarna, även om det råkade vara samma/lika hexfiler.

Det skulle t.o.m kunna vara så illa att defaultinställningen (om man inte väljer varken till- eller från-inställningen av en bit) beror på olika omständigheter. T.ex vilken minnesadress i PC:n någonting råkar hamna, eller vad som helst.

Verkar mycket dåligt genomtänkt i utvecklingsmiljön. För det första att inte kunna sätta configbitarna i koden. För det andra att det går att sätta både till och från på en configbit samtidigt, eller ingetdera. Lika illa båda två. Användaren har ingen aning om vad som egentligen händer i någondera läget.
Användarvisningsbild
Glenn
Inlägg: 36805
Blev medlem: 24 februari 2006, 12:01:56
Ort: Norr om Sthlm
Kontakt:

Re: LCD problem/MikroC/PIC18F4550

Inlägg av Glenn »

jag utgick ju iofs från att kompilatorn skickade med dom bittarna man klickat i till asmfilen, men så behöver det ju förstås inte vara.
sodjan
EF Sponsor
Inlägg: 43251
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping

Re: LCD problem/MikroC/PIC18F4550

Inlägg av sodjan »

Glenn> jag utgick ju iofs från att kompilatorn skickade med dom bittarna man klickat i till asmfilen...

Jag utgår från att du menade "...till HEX filen".

När det gäller frågan om bytet av hårdvara (labbplatta => kretskort) så är
det naturligstvis en osäkerhet. Det *kan* t.ex vara så att på labbplattan
så hade inte LCD och processor samma matning, och alltså *kanske* LCDn
redan hade matningen på (och hade redan kört POT) när applikationen i
processorn startade. Och det *kan* vara så att med kretskortet så bryts/sluts
matningen till både processor och LCD samtidigt (och alltså hinner inte LCDn
köra POT innan applikationen startar). Det vet vi helt enkelt just nu. Det är
därför det är så jäkla svårt att göra "remote debugging" enbart via ett forum... :-)

Det är också lite märkligt/synd att MikroC inte har en möjlighet att lägga CONFIG
inställningarna i koden, med moderna kretsar börjar det ju bli så jäkla många
saker att hålla reda på.

(POT = Power On Test)
Skriv svar