ks 0108 avr problem...

sven · Inlägg av **sven** » 30 december 2004, 18:45:54

niet, ingen skilnad.. tror felet ligger nån stans i mina minimala codingskills =) ska skriva en ny driver med lite hjälp från avrfreaks så får vi se..

chille · Inlägg av **chille** » 30 december 2004, 19:58:21

Jag skulle råda dig att göra typ såhär:

ldi temp, 0b10101010
out PORTB, temp

i assembler. då ser du exakt vad som skickas osv

Lär bli lite lättare att felsöka då, kan ju vara så enkelt som att man missat ett & eller ~ eller något annat skumt tecken.

Funkar det fortfarande inte kan du ju sega ner den som en tok och koppla på lysdioder för att se att det verkligen är rätt data som kommer. Är allting rätt och det fortfarande inte funkar, så är det nog fel

eller så är displayen trasig

cykze · Inlägg av **cykze** » 30 december 2004, 20:49:13

Du har väl gjort det stora felet att använda _BV() när du inte ska göra det. Ta bort alla _BV(x). Ersätt alltså alla _BV(E) med E osv.

Och som sagts; förläng delay:sen överdrivet mycket. Sen är det smidigt att lägga in alla initieringskommandon i en array som du sedan loopar igenom. Det blir mycket lättare så, och betydligt mindre risk för att man gör något litet slarvfel.

$tiff · Inlägg av **$tiff** » 30 december 2004, 23:27:26

hoppas du inte glömt något så trivialt som att ställa in kontrasten

sven · Inlägg av **sven** » 31 december 2004, 01:39:23

jo ja funderar på att styra över till assembler.. men tycker det är så krångligt att få till delays osv i det.
tänkte att när jag lärt mig hur lcd fungerar, (om jag gör det) så ska jag styra in den i nått större projekt, och då äre ju bra mycket lättare med c...

näe har vart å fingrat med kontrasten oxå och de blir tyvärr fortfarande inget =/ satt och kikade i databladet till avren och såg att pin 1, och 2 tror jag det var i portc användes till i2c bussen oxå. kan inte ha nått med det att göra så avren är ställd i i2c läge?

chille · Inlägg av **chille** » 31 december 2004, 03:21:24

Nä, vad jag vet ska alla portarna fungera som vanligt om man inte själv har ändrat dom. Enklaste är väl helt enkelt att mäta med en multimeter, eller kolla med en lysdiod (när det gäller µC:s och liknande brukar man kunna skippa motstånd) om det är etta eller nolla.

Men du, har du satt DDRx rätt? Altså, det registret som talar om ifall det är en in- eller utgång.

EDIT: Glöm det, kom ju på att det bara var att gå till sida 1 i tråden och kolla själv

Om det är till något hjälp kan jag alltid porta koden till assembler och så kan du själv mecka med den. Är ju lite enklare att komma igång med assembler om man redan har kod som man vet vad den gör. Dessutom är det enklare att hålla koll på vad som egentligen händer. Och bäst av allt är ju att man kan köra koden genom debuggern i AVR Studio och se exakt hur alla portar/register/räknare ändras. Det är gult värt och har sparat många timmar i felsökandet.

cykze · Inlägg av **cykze** » 31 december 2004, 12:02:17

sven skrev:jo ja funderar på att styra över till assembler.. men tycker det är så krångligt att få till delays osv i det.
tänkte att när jag lärt mig hur lcd fungerar, (om jag gör det) så ska jag styra in den i nått större projekt, och då äre ju bra mycket lättare med c...

näe har vart å fingrat med kontrasten oxå och de blir tyvärr fortfarande inget =/ satt och kikade i databladet till avren och såg att pin 1, och 2 tror jag det var i portc användes till i2c bussen oxå. kan inte ha nått med det att göra så avren är ställd i i2c läge?

De två pinnarna du pratar om är väl till för JTAG. JTAG måste väl inaktiveras innan du kan använda dom pinnarna som vanligt. Det sker väl via någon fuse-bit eller något. Det står i databladet hur du gör. Tyvärr sitter jag på modem och kan inte ladda hem det själv.

Enklast kanske är att skippa dessa två pinnar tills vidare.

Det där jag skrev om att du skulle ta bort _BV() gällde i din första kod. Såg sedan att du hade fixat det i din andra kod. Sorry.

Annars tycker jag att du ska testa lite olika kombinationer på utsignalerna och sedan mäta på LCD-pinnarna att du får dom signaler du har tänkt dig. Kan ju vara fel i förbindelsen mellan AVR:en och LCD:n också.

chille: Det går väl att debugga i AVR Studio om man kör C också. Jag har för mig att jag har gjort det någon gång.

sven · Inlägg av **sven** » 31 december 2004, 14:04:12

har testat en 5-10 olika varianter nu =/ har mätt på port c och fått finfina 5v på alla pinnar så dom verkar funka.. jaja ska fixa me de där imorrn för nu äre ju nyår.. gott nytt år på er!

klopaz · Inlägg av **klopaz** » 2 januari 2005, 15:49:36

Vilken AVR modell kör du?
Mät alla pinnar på port c och kolla så att du kan få både 5 V och 0 V på kommando. Det är inte säkert att en utgång fungerar "normalt" bara för att den spottar ut 5 V när du mäter.
Reset ska ha 5V så den kan du dra till VDD.

Har som sagt kod som jag kör på en mega32 med den där displayen. Slänger upp koden om någon dag när jag får tillgång till rätt dator.

sven · Inlägg av **sven** » 2 januari 2005, 19:27:53

ska ta och kolla upp det klopaz..

har suttit å försökt fått ihop ett nytt program nu i asembler, men är verkligen inte så haj på det..
gjorde en delay loop med avrdelaygenerator som genererar en delaykodsnutt som ser ut såhär:

ldi R17, $1F
WGLOOP0: ldi R18, $AB
WGLOOP1: dec R18
brne WGLOOP1
dec R17
brne WGLOOP0
delaying 3 cycles:
ldi R17, $01
WGLOOP2: dec R17
brne WGLOOP2

nop

tänkte jag skulle lägga in den i en subrutin så jag bara kan kalla på den när jag behöver den, så jag slipper få så mycket kod, hur gör jag då?

karlstedt · Inlägg av **karlstedt** » 2 januari 2005, 19:50:13

I ditt huvudprogram anropar du en subrutin med instruktionen rcall och ett namn, där namnet är ett valfritt namn på din subrutin.
Lägg sedan koden mellan din "label" och instruktionen reti

Var försiktigt med register som används i subrutinen så att de inte har fel värde då du hoppar tillbaks till huvudprogrammet. Spara även undan SREG på stacken om det är nödvändigt.

Kod: Markera allt


rcall subrutin
.
.
.
subrutin:
asm
asm
asm
reti

sven · Inlägg av **sven** » 2 januari 2005, 20:21:34

ok... jo jag förstog hur man kallade på en subrutin men eftersom min subrutin använder sig av flera labels så tänkte jag att det skulle bli nå tok..

sven · Inlägg av **sven** » 3 januari 2005, 17:54:35

äntligen! har nu fått lcdn att fungera som den ska!
tack så mycket för all hjälp! nu ska jag bara försöka mig på att få ut nått vättigt på den och inte bara några pixlar

$tiff · Inlägg av **$tiff** » 3 januari 2005, 17:56:18

Var det något specifikt fel då?

sven · Inlägg av **sven** » 4 januari 2005, 01:25:37

jahapp.. trodde nu att jag hade kontroll över lcdn men så var det ju givetvis inte,

skrev ihop en kodsnut med alla nödvända komandon och trodde jag skulle få en fin vit pixel på lcdn, men icke, fick istället halva displayen full med vita pixlar utan nån som hellst ordning.

kapade ner snutten mer och mer för att se var felet var:
#include <avr/io.h>
#include <inttypes.h>
#include <avr/delay.h>
#define RS PC6
#define RW PC5
#define E PC4
#define CS1 PC3
#define CS2 PC2
#define RST PC1

int main()
{
DDRB = 0xff;
DDRC = 0xff;
PORTB = 0x00;
PORTC = 0x00;

_delay_loop_2(10000);
_delay_loop_2(10000);
_delay_loop_2(10000);
_delay_loop_2(10000);

PORTC |= _BV(CS1);
PORTB = 0b00111111;
PORTC |= _BV(E);
_delay_loop_2(12000);
PORTC ^= _BV(E);
PORTC ^= _BV(CS1);
PORTB = 0x00;

och när jag hade så här mycket kvar så fick jag fortfarande en mängd pixlar på displayen även om jag bara använt "display on" kommandot (00111111) och inte enns satt RS(skriva till ram minnet kommandot)hög ... mysko

enligt databladet så ska första biten i 0b0011111(x) styra om displayen är på eller inte, sätter jag den till 0 så blir det inget och 1 så blir det massa tok bara.

dvs. är första biten till "display on" satt till 1 så visar den det som finns i ramet, men ramet bör ju vara tomt om man inte skrivit något till det.
men tydligen så finns det en massa tok i ramet som den visar.

chip select kommandona verkar fungera så detverkar inte vara ngt fel på styrkommandona i kretsen heller..