Hoe checken of LCD nog werkt? (HD44780)

KaRamBa, had het ook onlangs gezien en meteen geprobeerd maar helaas dat werkt ook niet, ook geprobeerd met andere pinnen aan de GND te leggen maar ook zonder succes.

Ik laat hier nog iets weten als ik mijn nieuwe LCD heb.

ik lees hier dat je nog 2 PIc's liggen hebt,
heb je toevalig nog een db9 poort aan je pc zitten?

zoja dan kun je volgende schakeling mss eens proberen op een breadbordje (mits je PIc in de lijst staat) :
http://feng3.nobody.jp/en/rcd.html

bij mij is hij werkende,

en trouwens zijn er niet veel tut's hoe je een lcd meot gebruiken
weet niet of het ok eentje is met een atmega8515

Waar zit je? Ik zit in delft. Je mag van mij langskomen om jou LCD bij mij te testen of mijn LCD op jou ding te testen.

Een LCD is redelijk basis en ik heb nooit problemen gehad met een LCD aan te sturen. Ik denk dat ik ze vorig jaar stuk heb gemaakt en wou ze nu eens testen, als ik de nieuwe LCD heb zullen we met zekerheid kunnen zeggen of ze stuk waren of het de schakeling was!

En helaas neen, ik werk met Windows op een Macbook Pro voor m'n microcontrollers te programmeren.

Edit:
@rew: Ik ben van Astene, Belgie

Op 2 april 2012 22:02:21 schreef WouterDS:
Edit:
@rew: Ik ben van Astene, Belgie

Nou, je bent nog steeds welkom, maar het zou een behoorlijke trip zijn. Een kennis van me woont in de buurt van Sint-Niklaas, en dat vind ik al een heel eind rijden....

Ik verwacht echt niet dat je LCD kapot is. Z'n led brand, de controller kan de bitjes aansturen (blokjes laten zien). Dit zijn precies de symptomen van het niet goed aansturen van de LCD.

't vervelende is dat er altijd precies DIT gebeurt en helemaal niks anders als je ook maar iets verkeerd doet, en dat het in 1x werkt zodra je het wel goed doet. Er is niet iets van "het werkt een beetje" en dat je kan zien aan wat dat beetje is, waar je naar moet zoeken om te vinden wat er mis is.

Heb je al gekeken of je wel D4...D7 hebt gebruikt zoals reeds eerder gemeld?
Volgens mij zit daar niets aan op de foto, wel aan D0...D3.

Ik stem: Arco heeft gelijk.

vond dat ook al raar,
dacht ook al datde verkeerde databussen gebruikt werden marja,

_{ps: sint-niklaas is beste stad in B}

Moet toch de schakeling of het programma geweest zijn.
Programma en configuratie van lib eens opnieuw gedaan en volledig opnieuw geschakeld en nu werkt het !!

Ja,

Geen wonder, de datalijnen zitten nu wel op D4...D7.

Arco ik heb dat veel vroeger gezien voor het hier gepost werd maar het werkte toen ook niet ..

Even iets anders, de AVR draait nu op 8Mhz. Nu is mijn delay van 1000 ms (met de _ms_delay functie uit util/delay.h van AVR Studio) iets van een 100ms schat ik. Is dit normaal dat deze "standaard" library hierdoor niet meer werkt of zou die daar op de een of andere manier rekening met moeten houden? Wat is hier een eenvoudige fix voor?

[Bericht gewijzigd door WouterDS op zondag 8 april 2012 23:35:40 (63%)]

Voor delay_ms om goed te werken moet je de macro "F_CPU" correct zetten. 8000000UL .

Als je 1000ms delay ongeveer 10x te snel gaat, dan vermoed ik dat je F_CPU op 1000000UL (1MHz) hebt staan, en het dus 8x te snel gaat.

De delay functies weten namelijk van een paar instructies hoeveel clock cycles ze duren, en voegen dus net zoveel van die instructies samen om de delay vol te maken.

Ik had laatst

_delay_us (0.5);

Dus een halve microseconde wachttijd nodig. Dat is dus vier clock cycles op 8MHz. Daar maakt ie dan

         rjmp 1
1:       rjmp 1
1: 

van. Dus twee jumps die ieder 2clocks duren.

Zou ik m'n CPU op 1MHz draaien ipv 8, dan duurt dit nog stees 4 clocks, dus 4µs en niet 0.5. Als ik dan de F_CPU macro aanpas, zal het wel een enkele

      nop

worden: Dat duurt dan 1 µs dus in ieder geval langer dan de 0.5 die "moest".