mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik LCD HLM8070


Autor: Jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hy

ich habe leider Probleme mit dem schreiben auf meinem Display von Pollin 
(HLM8070 mit M50530)

Pins sind:

Pin 01 Ground
Pin 02 5V
Pin 03 dimmer
Pin 04 OC1
Pin 05 RW
Pin 06 EX

Pin 07 DB0
Pin 14 DB7

Pin 15 OC2

Die Helligkeit kann ich regeln aber ich kann nichts schreiben!!

kann mir jemand nen Beispiel Programm in C geben?

Autor: Jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kann mir jemand den Ablauf erklären?

1. also ich muss wahrscheinlich erst das Display initialisieren (wie?))?

2. kann ich einfach Daten senden wie bei RS232? also lege die 8Bit an 
DB0-DB7 und das Display übernimmt es dann oder wie?

hab das Toturial durchgeschaut aber da steht nix zum Ablauf...

Autor: Jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kann mir jemand das Datenblatt erklären? auf Seite 4

wenn mir jemand das Datenblatt erklären könnte!!! könnte ich den Code 
übernehmen....

HELP!!

R/W ==?
RS   ==?
E     ==?

Autor: Matti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Jörn,
auf den ersten Blick hätte ich gesagt, dass in dem Ding ein Standard 
(Hitachi-HD44780 kompatibel) Controller verbaut ist. Ich hatte eben nur 
einen flüchtigen Blick auf das Datenblatt geworfen und es sind zumindest 
ein paar Sachen anders als beim Hitachi: Das Pinning ist ähnlich (D0-7 
oder D4-7 im 4-Bit Mode, E, R/W) aber er hat neben RS (I/O C1) noch 
einen zweiten I/O-Control Eingang I/O C2 außerdem hat er wesentlich mehr 
Ram. Man müßte sich jetzt mal intensiv durch das Datenblatt wühlen und 
nachsehen, ob und wie er sich vom Hitachi unterscheidet (Adressierung, 
Befehle etc.). Dann kann man sehen, ob man die Standard Hitachi Routinen 
verwenden kann; die Hardware-Beschaltung dürfte fast identisch sein.

Pinbelegung für Art.Nr. 120387

LCD-Pin  Funktion    Standard Hitachi

1  GND    GND
2  VDD +5V    VDD +5V
3  Kontrast    Kontrast
4  I/OC1    RS
5  R/W    R/W
6  ex    E
7  DB0    DB0
8  DB1    DB1
9  DB2    DB2
10  DB3    DB3
11  DB4    DB4
12  DB5    DB5
13  DB6    DB6
14  DB7    DB7
15  I/OC2

Autor: Matti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe gerade noch hier was gefunden:

http://ssl.bulix.org/projects/lcd4linux/wiki/M50530

"These displays are made by different manufactures, and come in various 
sizes. The main difference between the M50530 and the HD44780 is that 
the M50530 can control much larger displays (mine has 8 rows and 24 
columns).
"

Der Unterschied zum Hitachi scheint wohl wirklich die unterstützte 
Display-Größe zu sein (der Hitachi kann nur 80 Zeichen und bei größeren 
Displays werden einfach mehrere Controller verbaut).
Daher wage ich mal die Prognose, dass Du die normalen Hitachi-Routinen 
mehr oder weniger übernehmen kannst.

Autor: Michael (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hallo!

ich habe ein beispielprogramm in assembler für das pollin-lcd am atmega8 
geschrieben.
es funktioniert, ob das programm aber "sauber" geschrieben ist, kann ich 
nicht beurteilen.
vielleicht kann es jemand brauchen...

mfg michael

Autor: Jörn Ahrens (joerna)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kann man das in C übersetzen?? :D

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

eine Beschreibung über den Anschluss des Displays an einem Mega8 gibt es 
hier:

http://www.happy-micro.de/index.php?option=com_con...

Gruß,
Ralf

Autor: Björn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also mein Display zeigt mit Michaels Programm was an, allerdings nicht 
das, was es soll! kann das am Takt liegen?

Autor: Thomas K. (muetze1)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mensch, das hatte ich doch mal geschrieben und dann nachher nicht mehr 
genutzt. Ich habe die Quellen mal angehangen. Ich habe den im 4 Bit 
Modus betrieben und mit einem Logik Analyzer nach Datenblatt 
programmiert und lief super.

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich habe heute den Code von Thomas K. ausprobiert. Ich habe alles so 
angehängt, wie in M50530.h beschrieben. Trotzdem zeigt das Display nur 
eine Reihe schwarzer Balken an.

Kann mir jemand sagen, an was das liegen könnte und mir helfen, dieses 
Display zum Laufen zu bringen? Das wäre wirklich nett.
Sorry übrigens, dass ich den Thread wieder ausgrabe...

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du die Ports auch so entsprechend genutzt und wenn nicht, hast du 
die Definitionen im Header angepasst? Stimmt deine eingestellte 
Taktfrequenz in deinem Projekt mit der tatsächlichen Taktung auf dem 
Board überein? Sind die Fuses dahingehend auch ordentlich gesetzt?

Erstmal die Vermutung: falsch angeschlossen oder Timings stimmen nicht 
(delays zu kurz/lang)

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke erstmal für die schnelle Antwort.

Nachdem ich es jetzt einige Male überprüft habe wage ich zu behaupten, 
dass es richtig angeschlossen ist.

Mit dem Takt bin ich mir nicht sicher, im Makefile steht
F_OSC = 1000000
 und das Fusebit steht auf
100001: Int. RC Osc. 1MHz [...]
Bisher habe ich immer mit Bascom gearbeitet und da funktionierts so mit
$crystal = 1000000

Woher weiß ich, wie lange die Delays sein müssen?

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, ok. Ich hatte bisher immer mit AVR Studio gearbeitet und da wäre 
der Takt in den Projektoptionen einzutragen. Dieser Takt definiert dann 
das Symbol F_CPU und nicht F_OSC. Aber egal, da WinAVR meckert (die 
delay unit), wenn F_CPU undefiniert ist. Hast du vllt. irgendwelche 
Warnungen oder Hinweise beim Compilieren des Codes?

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
F_CPU ist nirgends definiert (zumindest hab ichs nirgends gefunden) und 
ich bekomme auch keine Warnungen. Ich habe jetzt aber wie bei
http://www.mikrocontroller.net/articles/AVR-GCC-Tu...
ein
#ifndef F_CPU
#define F_CPU 1000000
#endif
eingefügt. Es passiert aber das selbe wie davor...

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut dann setze ich mich nochmal hin und bau eine Schaltung auf und teste 
es mit deiner Konfiguration (Int OSC bei 1 MHz, Quellen aus diesem 
Thread). Ich melde mich dann nochmal mit den Ergebnissen.

Kontrastregler hast du schon verstellt?

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, der Kontrastregler funktioniert, es gibt helle und dunkle Klötze ;)

Danke für die Mühe, ich hoffe es läuft bei mir auch mal irgendwann...

Autor: Thomas K. (muetze1)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, ich habe nun mir einen ATMega32 und das ganze durchgespielt: es lief 
nicht. Dann den Logic Analyzer geholt und damit getestet - sah alles gut 
aus, aber es lief nicht. Dann die Timings und die Signale nochmal mit 
dem Datenblatt verglichen und es fiel auf, dass die Daten falsch waren 
zur Initialisierung. Also nochmal alle Signale überprüft und die 
Datenleitungen verhielten sich komisch. Im Endeffekt habe ich viel Zeit 
verbracht um festzustellen, dass der ATMega 32 ein JTAG Interface hat 
und dieses liegt auf Port D. Also deaktiviert und alles lief.

Ich habe nun die ganzen Timings (die waren zuvor sehr großzügig) 
nochmals gut gestrafft bzw. entfernt. Somit ist nun das Display auch 
recht schnell anzusprechen (auch mit internem 1 MHz Takt). Im Anhang die 
bis auf die Timings unveränderte Originalquellen in einem AVR Studio 
Projekt. Ziel ATmega 32 mit internem 1 MHz Oszillator. Das Timing Bild 
ist mit im Archiv enthalten.

Von daher nun die Frage: Welcher Controller? JTAG ist auf einem der 
genutzten Ports und eingeschaltet?

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Controller ist ein Atmega16, JTAG war aber schon aus. Mit dem neuen Code 
funktionierts aber scheinbar. Zumindest komm ich bis zum cls(). Juhuu.

Allerdings bekomm ich es nicht hin, was vernünftiges hinzuschreiben, 
kannst du mir ein Beispiel machen, das irgendwas hinschreibt? C kann ich 
nämlich nicht wirklich gut und deshalb bin ich mir nicht sicher, ob ich 
das mit den Strings richtig gemacht hab.

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Siehe Anhang. Da ist ein komplettes Projekt drin mit Ausgabe eines 
Textes ("TEST"). Genau diese Ausgabe ist auch in dem LA Diagramm zu 
sehen.

In wie fern kommst du zu "cls()"? Diese Funktion löscht den Bildschirm 
und setzt den Cursor auf die linke obere Ecke. Da dies aber der 
Standardzustand ist nach LCDInit(); solltest du keinen Unterschied 
feststellen. Was bedeutet in so fern bei dir "komm ich bis zum cls()"??

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab ein cls() nach dem LCDInit() gemacht, wusste nicht dass das 
unnötig ist. So hat es aus meiner Sicht funktioniert bis zum cls(), da 
danach das Display leer war.

Wenn ich jetzt etwas ausgeben will wird auch etwas ausgegeben. 
Allerdings nicht das, was es soll, sondern irgendwelche chinesischen 
Zeichen (zumindest sehen sie so aus). Woher kann das kommen?

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zeig doch mal deinen Code den du bisher hast. Und teile mal den 
Controller mit den du nutzt - und ob du die Belegung wie im Header 
gemacht hast oder andere Ports/Leitungen nutzt (z.B. alles an Port C, 
o.ä.).

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Belegung ist wie im Header mit einem Atmega16.

Der Code ist m50530.c, ergänzt mit
int main(void)
{
  _delay_ms(1000);
  
  LCDInit();

  LCDSend( 0, LCD_CMD_SETDISPLAYMODE | dmDisplayOn | dmCursorOn | dmCursorBlink);

  LCDWrite("TEST");
    
  return 0;
}

Also eigentlich deine Testfunktion, ich hab nur noch ein Delay 
davorgemacht, damit ich es besser überprüfen kann. Soweit funktioniert 
es auch. Erst ist das Display leer, dann (nach 1 Sekunde) kommen diese 
komischen Zeichen.

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, nur nochmal zur Sicherheit: JTAG Enable Fuse ist deaktiviert worden? 
Und du nutzt das 4x20 Zeichen Display von Pollin (HLM8070)? Oder hast du 
eine andere Konfiguration, also mehr oder weniger Zeilen oder Spalten?

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, JTAG ist deaktiviert, habs mal testweise angeschaltet, dann zeigts 
gar nichts an, mit abgeschaltet immer noch die chinesischen Zeichen.

Mein Display ist das hier: 
http://www.pollin.de/shop/dt/MjE2OTc4OTk-/Baueleme..., 
heißt schonmal gleich. Aber 4x20 Zeichen? Meins hat 4x16, wie bei Pollin 
angegeben.

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
4x16 ist richtig. Wir haben das gleiche Display wobei es bei dir tut, 
bei mir nicht. Ok, grundlegend scheint das Init hin zu hauen, somit 
sollten die ganzen Steuer- und Datenleitungen hinhauen. Mein Display 
zeigt bei dem Testprogramm "TEST" an, bei deinem chinesische Zeichen. 
Falls vllt. doch ein paar Datenleitungen Probleme machen, mach mal bitte 
ein Foto von den chinesischen Zeichen. Ansonsten, falls die Timings zu 
knapp sein sollten, der originale Beitrag von mir hat langsamere 
Timings. Schonmal wieder damit probiert?

Was hängt noch an dem Controller dran bzw. ist er auf einem Board? 
Welches Board? Was ist sonst noch angeschlossen?

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Er ist auf nem Steckbrett mit dem Display, sonst ist nichts dran. Ich 
probier jetzt nochmal das alte...

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann bin ich wirklich ratlos. Ich habe es mit Quarz, ohne Quarz 
(interner OSC), mit Oszillator, etc ausprobiert und es klappt alles. 
Einzig JTAG beim Port D und Aktualisierung der Taktfrequenz in den 
Quellen waren Stolpersteine. Ich hatte auch alles auf einem Steckbrett, 
nur das LCD dran. Der Controller aber war direkt auf dem STK500 was auch 
das Display mit versorgte.

Ansonsten schonmal nach der Initialisierung den Kontrastregler bewegt? 
Beim Schreiben des Originalcodes war ich auch dem verweifeln Nahe, da 
ich den Kontrast immer so eingestellt hatte, dass es uninitialisiert die 
1 1/2 Balken zeigte und nach der Initialisierung war nix zu sehen. Bis 
ich irgendwann mal den Kontrast nachregulierte und alles war auf dem 
Display zu sehen und funktionierte...

Ansonsten bin ich echt ratlos. Wie gesagt, ein Foto von den komischen 
Zeichen wäre nochmal nett. Ansonsten wenn das auch wirklich 4 Stück sind 
(wie auch der ausgegebene Text lang ist), dann würde ich aus lauter Not 
schon fast einen defekten Character Generator oder CG RAM vermuten, aber 
eigentlich ist dies eher unwahrscheinlich.

Autor: Daniel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ja, es sind 4 Zeichen, das würde schon passen...

Ich probier einfach noch ein bisschen rum, vllt klappts ja doch noch, 
ansonsten werd ich nächstes mal ein Standarddisplay kaufen und das 
einfach mit Bascom verwenden.
Trotzdem danke, ich melde mich, wenns geklappt hat.

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich das richtig sehe, dann sind die beiden letzten Zeichen gleich? 
Wenn dem so ist, dann überprüfe deine Leitung D5 vom Display, also PC1. 
Dieser ist entweder nicht richtig verbunden oder mit einer anderen 
Leitung zusammen geschlossen. Bitte überprüfe dies - vllt. eine 
Lötbrücke am Display vom Kabel anlöten? Pieps das mal bitte durch.

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tatsächlich waren die Pins 14 und 15 am Display zusammengelötet. Jetzt 
macht es aber grade gar nichts mehr, vllt ist beim rumprobieren was 
kaputtgegangen. Ich werd morgen nochmal probieren, obs doch noch will.

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na endlich. Ich dachte schon ich werd noch ganz blöde im Hirn. Nun dann 
hoffe ich morgen mal auf einen problemlosen Ablauf.

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wie sieht es nun aus? Eine gewischt bekommen an der negativen 
Kontrastspannung? Oder LCD weggeworfen?

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wies aussieht ist beim Auseinanderlöten von den Pins was kaputt 
gegangen, auf jeden Fall zeigts nichts mehr an, weder was richtiges noch 
chinesische Zeichen :(

Mal schauen wie meine LCD-Karriere jetzt weitergeht ;). Vielleicht 
probier ichs nochmal mit dem Display, vielleicht kauf ich aber auch 
eins, das mit Bascom kann, dann wirds einfacher...

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schade, gerade für den Preis von nichtmal 3 Euro bei Pollin ist das 
Display gar nicht mal so schlecht. Und bisher ist mir auch noch keins 
gestorben, alle verrichten ihren Dienst. Nur beim reinen auseinander 
löten sollte das Display im Normalfall auch nicht zerstört werden. Aber 
nun gut, ich hoffe das nächste Display klappt besser.

Autor: hufnala (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
irgendwie bekomme ich das Display mit den 2. Quellen und dem 
Testprogramm an meinem ATMega 16 nicht zum laufen. Habe die Ports 
entsprechend angepasst, die Steuerleitungen liegen auf PA2..PA5, die 
Datenleitungen auf PD0..4. Auf RW und Ex kann ich die beschriebenen 
Bitmuster sehen, aber auf den Datenleitungen kommt irgendwie immer nur 
auf DB5 ein Signal. Habe die Ausgabe "TEST" auch einfach mal in eine 
Schleife gepackt um besser messen zu können (analoges Oszi) aber da tut 
sich rein gar nichts.

Arbeite mit AVR Studio, die F_CPU habe ich gesetzt, der JTAG sollte 
dekativiert sein....

Die Ausgabe ist einfach eine Zeile schwarze Kästchen, und dann 1 Ziele 
halbe schwarze Kästchen?

Ein Testprogramm dass durch PortA einfach ein Schieberegister 
durchlaufen lässt, tut auf dem IC einwandfrei. Wenn ich versuche auf 
anderen Datenbits noch debug signale auszugeben, geht dass irgendwie gar 
nicht (z.B. PB0 toggeln).

Anbei mal meine Dateien...
Bin für jeden Tipp dankbar.

//

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JTAG sollte deaktiviert sein? Das ist wohl anscheinend nicht der Fall.

Autor: hufnala (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, mit "JTAG sollte dekativiert sein" meinte ich, dass ich das 
JTAGEN Fuse ausprobiert habe (beide Zustände gefused) sich aber nichts 
getan hat. Auch als ich die Data Leitungen auf PORTD gelegt habe, kamen 
keine sinnvollen Data Signale aus dem ATMEGA. Habe mein Testprogramm 
(einfaches durchschieben von Bits= auf alle Ports ausgeweitet, und hat 
auf ALLEN funktoniert.
CU
//hufnala

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, nun nochmal: Du hast die Datenleitungen auf DB0..DB4 angeschlossen? 
Das sind 5 Datenleitungen und keine 4. Danach schreibst du das die 
Datenleitungen alle nichts machen, ausser DB5 - und was liegt denn an 
der Leitung nun an?

Hast du beachtet die Datenleitungen wirklich an Port 0..3 
anzuschliessen? Wie kommst du dann auf die anderen beiden Leitungen? 
Wenn du andere Datenleitungen nutzt, dann musst du die Ausmaskierung 
abändern und die Bits noch entsprechend schieben.

Passt auch die F_CPU Definition zu der wirklichen Taktfrequenz deines 
ATMegas? Wenn du 8 MHz angibst und er nur bei 1 MHz int. Osc. läuft, 
dann klappt keine einzige delay Funktion.

Autor: hufnala (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Thomas,

hoffentlich habe ich mehr Probleme mit dem Tippen als mit dem Löten ;-), 
inzwischen habe ich das Display schon wieder abgelötet...

Die Steuerleitungen waren auf PA2..PA5.
Die Datenleitungen waren auf PD0..PD3, es waren die Datenleitungen des 
Panels DB 4..7 (Pins 11..14) gem. Pinning oben aus dem Thread.
(lt. "// data port, LCD signals DB4-DB7 have to be connected to P0-P3" 
aus der m50530.h).

Die Define Angaben in der 50530.h wurden entsprechend angepasst:
// data port, LCD signals DB4-DB7 have to be connected to P0-P3
#define LCDDATAPORT PORTD
#define LCDDATADIR  DDRD
#define LCDDATAPIN  PIND

  // control port, LCD signals RW, EX, I/OC1, I/OC2
#define LCDCTRLPORT PORTA
#define LCDCTRLDIR  DDRA
//#define LCDCTRLPIN  PIND
#define LCDPIN_RW   PA2
#define LCDPIN_IOC1 PA4
#define LCDPIN_IOC2 PA5
#define LCDPIN_EX   PA3

Auf "RW" und "EX" konnte ich zyklisch ein Signal messen, dass dem im 
Logikanalyzer entspricht.
Auf DB5 konnte ich zyklisch ein Signal mit dem Oszi messen, dass 
anscheinend dem 0x02 Signal bei ca. -350µs aus dem Plot entspricht.

Dieses Signal kommt zyklisch, leider konnte ich mit meinem Oszi die 
Zykluszeit nicht feststellen, da die Wiederholdauer verglichen zu den 
Peaks extrem ungünstig war.

Ich denke ich habe auch inzwischen die Ursache gefunden, aber keine 
Abstellmaßnahme: Die delay.h/delay.c scheint bei mir einen zyklischen 
RESET auszulösen. Keine Ahnung warum. Ich habe ein Programm, mit dem ich 
einfach eine "1" auf allen Ausgängen durchschiebe, dass hat mal mit der 
delay.h funktioniert. Die Aufrufe von _delay_ms in der main Schleife VOR
dem zyklischen ausführen [while(1)... ] scheinen IMMER einen RESET des 
µC zu verursachen.

Der ATMega16 lief die ganze Zeit mit Werkseinstellungen, geändert wurde 
ztw. das JTAG Fuse und die Oszillatoreinstellung von 1Mhz auf 8Mhz (und 
zurück) bei Anpassung des F_CPU und der Einstellung im Projekt. Den 
Watchdog etc. habe ich nicht bewusst initialisiert (Werkseinstellung?).

Software ist AVRStudio 4.17 Build 666

Der µC läuft jetzt mit anderer SW sauber (Soft-PWM), allerdings habe ich 
da anfangs genau das gleiche Phänomen festgestellt, aus irgendeinem 
Grund geht der IC in RESET wenn ich einen _delay_ms(xxxx) 
(xxxx=konstante, keine Variable) in der main aufrufe oder in einer von 
main aufgerufenen init-funktion. Mit dem toggeln eines Ausgangs in der 
Main beim startup habe ich es letzlich gefunden und so lange 
auskommentiert bis der _delay_ms als Ursache gefunden war.

Frage zur Delay Funktion: Kann ein falscher F_CPU (nicht passend zur 
gefusten Frequenz) ein solches Verhalten auslösen (Absturz/RESET)? Ich 
hatte bisher beim stöbern nur gefunden dass die Zeiten (natürlich!) 
nicht passen...

Danke für die Unterstützung.

//hufnala

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde bei sowas vllt. nochmal den WDT ausschliessen wollen. Also zum 
einen mal die Fuses nachschauen ob der WDT nicht vielleicht enabled ist 
und zum anderen auch mal den Reset Grund aus dessen Register auslesen. 
Dann kommt man der Ursache auch schonmal näher (vielleicht doch ein 
Brown-Out?).

Ansonsten kenn ich keine Resets aufgrund von Delays. Ich werde mich 
zumindest am WE nochmal hinsetzen und versuchen das ganze nachzustellen. 
Also HLM8070 Display an einem ATMega 16 mit interner Clock von 1 bzw. 8 
MHz und mit geteilten Ports (Signalleitungen/Datenleitungen). Ich werde 
mich dann auch mal näher mit deiner Anpassung beschäftigen. Ich gebe 
dann hier Rückmeldung.

Autor: hufnala (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Thomas,
alles klar, auch wenn ich bisher noch kein WDT Fuse gefunden habe 
sondern nur ein Register gehe ich da hinterher. Das mit dem RESET 
Register schaue ich mir auch an.

Vorgehensweise : ISR auf'n RESET und dann den RESET wert auf RS232 raus 
oder als BIN Wert auf'm Port (z.B. mit einer Case Anweisung?)? JTAG 
Interface habe ich leider keines.

Brown Out schaue ich auch nochmal, aber das Netzteil bringt 3A, ist 
eingestellt auf 1/2 A Strombegrenzung und da war ich bisher weit weg.
Davor sitzt noch ein (sauber entstörter) 7805. Aber für sowas habe ich 
ja das 20 Jahre alte Oszi :-)

Ciao Lars

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Lars,

Du kannst den Reset Grund aus dem MCUSR Register lesen. Dies muss vor 
der Initialisierung geschehen und wenn du es in eine Variable schreibst, 
muss diese von der Initialisierung ausgenommen werden. Ein Beispielcode 
dafür findet man in der WinAVR Hilfe die bei WinAVR mit beiliegt: 
http://www.nongnu.org/avr-libc/user-manual/group__...

Dort kannst du das MCUSR mit auslesen und dann später im Programm z.B. 
per UART ausgeben. Die Erklärung was nun anhand des Wertes den Reset 
ausgelöst hat, findet man in den Manuals zur MCU bei Atmel. Das wäre mal 
recht interessant zu erfahren, weil dann hat man schonmal einen guten 
Tipp in welche Richtung man suchen muss.

Grüße,
Thomas

Autor: hufnala (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi Thomas,

also dass mit dem RESET bin ich los, habe mal den Watchdog abgeschaltet, 
und bin alle Frequenzen nochmal durchgegangen. Das mit dem MCUSR habe 
ich anders gemacht, vermtl. funktioniert es deshalb nicht, habe einfach 
das Register in den Port kopiert.

Weiterhin habe ich jetzt hier die Leitungen zum Display nochmal 
verlötet, da war zwar alles ok, aber mit immer an und ablöten war mir zu 
blöd, jetzt geht's über'n Breadboard, und alles auf PORTA.

Generell bin ich soweit dass mein Programm läuft, aber das Display zeigt 
wie gehabt nur 1,5 Reihen schwarze Blöcke. Im Anhang mal meine SW. 
ziemlich viel auskommentiert. Jetzt messe ich gerade alles nochmal 
durch. Habe auf alle Fälle deutlich mehr signale als gestern, warum auch 
immer.

Habe den Code mal drangehängt, vielleicht fällt Dir ja was auf, die LED 
an PD5 wird schön brav alle 2ms umgeschaltet, d.h. dass timing sollte 
generell passen...

//CU Lars

Autor: hufnala (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Edit:
Habe die _delay_ms langsam von 500 auf 2ms verringert bis ich mit dem 
Oszi schön messen kann, am Ergebnis auf dem display hat das nichts 
geändert....

//Lars

Autor: hufnala (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Update:
Ich hab's. Es läuft. So ein blöder Fehler, vermutet habe ich es gestern 
ja schon fast, aber dann hat mich das mit dem RESET durch den Wind 
gebracht.

Wenn ich mein Netzteil einschalte, ist der Spannungsanstieg anscheinend 
zu langsam für das Display. Habe jetzt einfach mal den Stecker gezogen 
und dann wieder neu gesteckt, jetzt tut's manchmal dass was es soll!

Dass wollte ich gestern mit dem Delay am Anfang erschlagen und das 
Display erst nach 500ms initialisieren...

Vielen Dank einstweilen, ich muss mal sehen dass ich das jetzt SW 
technisch hinbekomme!

Schönes Wochende
Gruß Lars

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Lars,

Na sehr schön, das freut mich für dich. Und ich habe mir eine weitere 
Aufgabe am WE erspart. Aber Hauptsache das ganze läuft nun. Ich werde 
mir aber trotzdem nochmal auf die ToDo Liste setzen, dass man die 
Datensignale und Steuersignale auf unterschiedliche Ports legen kann.

Grüße,
Thomas

Autor: hufnala (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Thomas,

vielleicht doch noch eine kleine Hilfestellung:

Der Code
 _delay_ms(1000);    //StartDelay LCD?
 LCDInit();      //LED initialisieren
 LCDSend( 0, LCD_CMD_SETDISPLAYMODE | dmDisplayOn | dmCursorOn |  dmCursorBlink);
 //LCDWrite("TEST");
 _delay_ms(200);
  while (1)
  {
  PORTD ^= (1<<PD5);
  LCDSetCursorPos(1,1);
  _delay_ms(5);
  LCDWrite("TEST");
       _delay_ms(1000);
  }
return(0);
}
macht nicht ganz dass was ich will, nämlich an Zeile1 Spalte1 immer 
"TEST" ausgeben ;-).
Statt dessen kommt je nachdem wie ich mit den delays spiele (beim Init 
usw.) eine unterschiedliche Ausgabe. Bei kurzen Delays sinds TST oder 
TES, bei den jetzigen Delays sehe ich "T" "S" "T" immer an 1,1, wobei 
der Buchstabe nicht nach 1000ms immer durchwechselt. Muss ich da noch 
irgendwelche Delays einhalten, oder irgendwas anders konfigurieren? Das 
Display hat 4*16 Zeichen.

Gruß Lars

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Lars,

ich vermute du nutzt auch das HLM8070 von Pollin und an diesem habe ich 
den Treiber entwickelt und getestet. Die Ausgaben funktionierten bei mir 
einwandfrei ohne irgendwelche Delays dazwischen. Ich müsste es bei mir 
auch nochmal ausprobieren.

Grundlegend würde ich hier aber mal wieder auf eine anders lautende 
F_CPU Definition in den Projektoptionen tippen. Also eine andere 
Frequenz definiert als auf welcher der Controller im Endeffekt läuft.

Grüße,
Thomas

Autor: hufnala (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, ist dass von Pollin, Best Nr. LCD-Modul HLM8070
hm,
und wie kriege ich dass am sicheresten raus?

Die fuses stehen auf 0100 für CKSEL3..0 und die
F_CPU auf
#define F_CPU = 8000000UL;
Die Frquency im AVR Studio steht ebenfalls auf 8000000 und der 
Optimierungsgrad ist auf -Os
und mit
  while (1)
  {
  PORTD ^= (1<<PD5);
  LCDSetCursorPos(1,1);
  LCDWrite("TEST");
        _delay_ms(10);
  }
habe ich das gleiche und meine LED blinkt mit 10ms ON/OFF Time am PD5?
Der WritePGM ist auch nicht besser ;-(

Naja, da suche ich morgen weiter...
Schönen Abend noch, und Danke nochmals

Gruß
Lars

P.S. bist Du über ICQ, Skype oder so zu erreichen? Dann mülle ich hier 
nicht mehr länger das Forum voll...

Autor: Anton Aus tirol (bingo_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Ich versuche auch schon seit Monaten obiged LCD zum laufen zu bekommen.
Ich mag es an einen Arduino Duemilanove betreiben.
Also ATmega168, das sollte ja nicht so schwierig sein den Treiber 
anzupassen aba ich bekomme es nicht gebacken!
http://arduino.cc/en/Main/ArduinoBoardDuemilanove

Mit Arduino hat keiner Erfahrung???

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hufnala hatte es im Endeffekt hinbekommen, soweit ich weiss.

<ironie>Und was dein Problem ist, Rolf, ist eine Frage für die 
Glaskugel, schon allein bei den wenigen Informationen die du einem hier 
zum Fraß vorwirfst. Eine Pinbelegung ist überbewertet, Taktfrequenzen, 
Fuses und andere Belegungen braucht eh kein Mensch. Mit diesem Input 
sagt meine Glaskugel: da muss wohl ein Fehler vorliegen...</ironie>

Autor: Anton Aus tirol (bingo_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
test_LCD.pde Testdatei für Arduino IDE:
#include <m50530.h>

void setup()
{
// wait for power up
  delay(5000);
  LCDInit();
  LCDSend( 0, LCD_CMD_SETDISPLAYMODE | dmDisplayOn | dmCursorOn | dmCursorBlink);
  LCDWrite("TEST");

}

void loop()
{

}

In der m50530.h wurden nur die Ports angepasst (auf Port D):
  // data port, LCD signals DB4-DB7 have to be connected to P0-P3
#define LCDDATAPORT PORTD
#define LCDDATADIR  DDRD
#define LCDDATAPIN  PIND

  // control port, LCD signals RW, EX, I/OC1, I/OC2
#define LCDCTRLPORT PORTD
#define LCDCTRLDIR  DDRD
//#define LCDCTRLPIN  PIND
#define LCDPIN_RW   7  //alt PD13
#define LCDPIN_IOC1 6
#define LCDPIN_IOC2 4
#define LCDPIN_EX   5

Die Arduino IDE gibt Fehlermeldungen:
undefined reference to `LCDInit()'
undefined reference to `LCDSend(unsigned char, unsigned char)'
undefined reference to `LCDWrite(char const*)'

das ganze ist in irgendeiner Temp-Datei. Die Headerdatei (m50530.h) ist 
ja eingebunden... also warum bekomme ich den Fehler?

Zur Info:
Vorher habe ich eine anderen Treiber modifiziert (aus einem anderen 
Forum Link finde ich nicht mehr). Dieser lief Fehlerfrei, aber das LCD 
hat nichts angezeigt (nur die 1,5 Balken) -> Kontrtast geht... Nachdem 
ich so nicht weiter gekommen bin wollte ich nun diesen hier 
ausprobieren...

LCD ist so angeschlossen (4 Bit Mode):
LCD-Pin      Funktion
1      GND    -> Masse
2      VDD +5V  -> +5V (Rot)
3      Kontrast  -> auf Poti-Mittenlanschluss
4      I/OC1  -> I/O Pin
5      R/W    -> auf Masse, da nur schreiben
6      ex    -> execute Signal (2x/Zyclus verwenden da 4-bit)
7      DB0    -> nicht verwenden
8      DB1    -> nicht verwenden
9      DB2    -> nicht verwenden
10      DB3    -> nicht verwenden
11      DB4    -> Datenbus 1
12      DB5    -> Datenbus 2
13      DB6    -> Datenbus 3
14      DB7    -> Datenbus 4
15      I/OC2  -> I/O Pin

Ach es ist auch ein Atmega328

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf W. schrieb:
> Die Arduino IDE gibt Fehlermeldungen:
> undefined reference to `LCDInit()'
> undefined reference to `LCDSend(unsigned char, unsigned char)'
> undefined reference to `LCDWrite(char const*)'

Bedeutet von dem Treiber ist nichts enthalten. Durch den Header kennt er 
die Funktionen aber deren Implementierung kennt er nicht. Diese ist in 
der .c Datei und die hast du anscheinend nicht eingebunden. Somit wird 
von dem Treiber nichts genutzt.

> das ganze ist in irgendeiner Temp-Datei. Die Headerdatei (m50530.h) ist
> ja eingebunden... also warum bekomme ich den Fehler?

Weil die .c Datei nicht eingebunden wurde.

> Zur Info:
> Vorher habe ich eine anderen Treiber modifiziert (aus einem anderen
> Forum Link finde ich nicht mehr). Dieser lief Fehlerfrei, aber das LCD
> hat nichts angezeigt (nur die 1,5 Balken) -> Kontrtast geht... Nachdem
> ich so nicht weiter gekommen bin wollte ich nun diesen hier
> ausprobieren...

Was heisst für dich denn "funktionieren"? Wenn du die 1,5 Balken siehst, 
dann ist das Display nicht initialisiert. D.h. es der alte Treiber 
funktionierte somit genauso wenig.

> LCD ist so angeschlossen (4 Bit Mode):
> LCD-Pin      Funktion
> 5      R/W    -> auf Masse, da nur schreiben

Warum gibst du dann oben PD7 an, wenn das R/W Signal auf Masse liegt? 
Was für einen Sinn soll das haben?

Und mein Treiber liest btw. das BUSY Flag von dem Display, somit ist nix 
von wegen nur schreiben. Wenn du das so machen willst, dann nutze den 
vorherigen Treiber, der ja schon funktionierte.

Grüße,
Muetze1

Autor: Anton Aus tirol (bingo_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK mit einem:
#include <m50530.c> in der test_LCD.pde geht es ohne Fehlermeldungen 
(das compilieren).

Jetzt bin ich mit dem neuen Treiber genau soweit wie mit dem alten, ich 
kann es auf den Controller spielen, das LCD zeigt aba nix an.

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rolf!

Was ist mit dem R/W Signal? Auf Masse? Auf PD7?

Was ist mit dem USB Teil bzw. dem USART auf dem Atmel? PD0 und PD1 sind 
TxD und RxD - ist diese initialisiert?

Ändern sich die Pins von PORTD beim ausführen bzw nach dem Reset?

Grüße,
Muetze1

Autor: Anton Aus tirol (bingo_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
R/W ist am Display direkt auf Masse gelötet um das Kabel zu sparen. Kann 
man doch so machen? In der Software wollte ich es einfach auf einen 
unbelegten Pin legen.

Kann ich die PORTD Zustände mit einem Multimeter messen?

Ich versuche gerade die DB4-7 an andere Anschlüsse zu legen. Muss noch 
raus finden wie ich die in der Software einstelle....

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf W. schrieb:
> R/W ist am Display direkt auf Masse gelötet um das Kabel zu sparen. Kann
> man doch so machen? In der Software wollte ich es einfach auf einen
> unbelegten Pin legen.

Bitte die Antworten auch lesen sonst brauchen wir hier nicht weiter zu 
machen.

Autor: Anton Aus tirol (bingo_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry Thomas K., habe das aus dem vorherigen Beitrag nicht richtig 
verstanden mit dem RW.
Ich habe jetzt eine RW Leitung gelegt. Ich habe 3 verschiedene Arten zu 
LCD anschließen getestet (Port B, C, D) -> geht nicht.
Ich denke das Problem liegt in der Arduino IDE, ich bin mir nicht mal 
sicher wie ich die Pins in der .c-Datei nennen muss. In dem zugehörigen 
Forum bekomme ich Null Hilfe. Arduino soll einfacher sein weil es viele 
Sachen von "alleine" macht, ich spiele mittlerweile mit dem Gedanken mir 
ein normalen uC zuzulegen und die Arduino-Scheiße weg hauen...

Autor: Muetze1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rolf,

Hmm, ok, also wenn es auch mit dem angeschlossenen RW nicht 
funktioniert, wird es problematisch mit den Fehlerquellen. Ich kenne die 
Arduino Dinger nicht und kann somit auch nichts zu deren IDE oder 
Hardware sagen.

Sind denn nach einem Reset Aktivitäten an den Pins sichtbar? Also mal 
ein LED an einen Pin des Ports angeschlossen und nach dem Reset geschaut 
ob sie aufleuchtet (Widerstand nicht vergessen, und nur eine LED für den 
gesamten Port pro Versuch)? Sie sollten zumindest mal kurz rumflackern. 
Dies sollte sich auf allen Pins des Portes nachvollziehen lassen.

Grüße,
Muetze1

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rolf,

gibt es neue Erkenntnisse?

Grüße,
Muetze1

Autor: Anton Aus tirol (bingo_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bin noch dran.... ich hab das Arduino Forum durchsucht wie ich die DB 
ect schreiben kann (viele Stunden), jetzt versuche ich mehr Systematisch 
vor zu gehen und ein test-Projekt zu machen wo ich Ports testen kann.

Autor: Anton Aus tirol (bingo_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin "etwas" weiter gekommen:
Habe raus gefunden dass ich die PBx -> PINBx ändern kann, dann kann ich 
es mit Ardoini IDE kompilieren und drauf schieben, es tut sich bloß 
immer noch nix (LCD: 1,5 Zeilen mit Balken)

Autor: Anton Aus tirol (bingo_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke an Thomas K. für die Hilfsbereitschaft!
Ich gebe auf, da es bei Pollin ein 27x4 LCD mit Standard HD44780 
Controller für 5€ gibt. Dafür gibt es bei Arduino Treiber die ich bloß 
anpassen muss.
Schade um die raus geschmissene Zeit, aber 5€ für ein noch größeres 
Display mit Standard Treibern ist unschlagbar.

Autor: Nicolas G. (nicolas_g)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hatte bis gestern auch Probleme mit dem Display und dem C-Code von 
muetze1. Das Display wollte einfach nicht. Ich steuere es auch im 
4-Bit-Modus an und nutze einen Atmega8 als µC.
Im unitialisierten Zustand zeigt das Display ja diese 1½ schwarzen 
Balken an. Interessant war bei mir aber, dass es nach dem Aufruf von 
LCDInit() nur noch ein schwarzer Balken war. Ich habe dann 
herausgefunden, dass dies dann passiert, wenn die ersten 4 Bits 
übertragen wurden, aber die nächsten dann irgendwie verloren gingen.
Also habe ich mir mal den ASM-Code von Michael zu Gemüte geführt. Er 
steuert das Display zwar im 8-Bit-Modus an, aber interessant waren für 
mich die Delays und das Überprüfen des busy-Flags. Michael überprüft das 
busy-Flag nämlich gar nicht, sondern durchläuft stattdessen 255 eine 
Schleife mit einem NOP. Das hab ich direkt mal ausprobiert und meinen 
Code dementsprechend angepasst. Ich ignoriere das busy-Flag also und 
warte stattdessen ein paar NOPs lang. Und dann hat es direkt 
funktioniert. Die nächsten 4 Bit wurden angenommen und das Display war 
initialisiert. Von da an klappte alles.

Ich habe an dem Code von muetze1 aber noch ein paar Änderungen 
durchgeführt. Es ist nämlich jetzt möglich die vier Daten-Bits auf 
verschiedene Ports und Bits zu legen. Die Control-Bits sind aber 
weiterhin auf einen festlegbaren Port begrenzt, aber die Bits für EX, 
R/W, I/OC1 und I/OC2 kann man auf diesem Port frei wählen.

Im Anhang also der C-Code, der bei mir unter Ubuntu 10.04 mit eclipse 
und avrdude ohne Probleme kompiliert. Mein Atmega8 ist auf 1 MHz 
getaktet. Sollte also jemand einen µC nutzen, der eine höhere Frequenz 
hat, müssen womöglich an ein paar Stellen noch ein paar mehr NOPs 
eingefügt werden.
Der Code ist außerdem noch etwas mehr kommentiert als vorher, sollte 
also leicht verständlich sein.

Viel Spaß damit und falls jemand Sonderwünsche hat, so soll er sie 
stellen.

Autor: behle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas K. schrieb:
> Mensch, das hatte ich doch mal geschrieben und dann nachher nicht mehr
> genutzt. Ich habe die Quellen mal angehangen.

Danke Thomas K.
Die Header Datei angepasst, und es lief.
Zum Glück findet man immer mal wieder so etwas, auch wenn der Thread 
schon ein bisschen älter ist.

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gern geschehen - dafür sind Communities da.

Autor: Peter Schranz (cbscpe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo und zuerst mal Dank an alle die sich mit dem M50350 
herumgeschlagen haben und ihre Erkenntnisse hier gepostet haben. Es war 
sehr informativ.

So, nachdem ich mir 2 Nächte um die Ohren geschlagen habe läuft mein 
SAMSUNG 2138A LCD das auch auf dem M50530 basiert. Das Samsung 2138A ist 
ein 8 x 24 LCD, der M50350 unterstützt zwar nur 4 Zeilen, aber 
Hardwaremässig ist das LCD so aufgebaut, dass es vom M50530 als 4 x 48 
LCD angesehen wird. Dabei werden je 48 Zeichen auf die Zeilen 1&5, 2&6, 
3&7 resp 4&8 aufgeteilt. Das nur als Info für die Interessierten.

Ursprünglich wollte ich das Busy Flag testen um festzustellen wann der 
M50530 wieder ready ist neue Daten zu empfangen. Aber das hat einfach 
nicht geklappt (daher auch die 2 Nächte). Nachdem ich es dann einfach 
mit Delay Loops zum Funktionieren gebracht habe, bin ich auf die Suche 
nach "Busy und M50530" gegangen und auf diesen Thread gestossen.

So wie es aussieht haben alle die hier ein M50530 basierendes LCD zum 
Laufen gebracht haben entweder auch mit Delay Loops gearbeitet, oder 
aber die Abfrage nach dem Busy ist mit so vielen Delays vor, zwischen 
und nach dem setzen und löschen von EX versehen, dass es auch keine 
Rolle spielt. Einzig nach einem CH Befehl verlangt ja der M50530 mehr 
als 20usec um seine Arbeit zu erledigen (was dann erklärft warum die 
Initialsierung funktioniert, aber der sofort anschliessend geschriebene 
Text nicht, sondern nur Text der nach einem Delay von etwa 1.2ms 
geschrieben wird)

Ich habe sogar extra im Code abgefragt, wie oft das Busyflag getestet 
werden muss bevor der Controller Ready wird, aber ich kann machen was 
ich will, es kommt immer 0 zurück. D.h. temp nach Aufruf von waitbusy 
ist immer 0.
wait12c:
;
;  Wait 12 Cycles including the 3 cycles of the rcall
;  at 7.68MHz this is equivalent to 1.5usec
;
  nop      ; 1 cycle = 130ns
  nop
  nop
  nop
  nop
  ret      ; 4 cycle

waitbusy:
  cbi  LCDEX      ; EX = Low
;  rcall  wait12c
  cbi  LCDIOC1    ; IOC1 = Low  
  cbi  LCDIOC2    ; IOC2 = Low
  clr  temp      ; 
  out  porta,temp    ; Clear Port A
  out  ddra,temp    ; Set all 8 bits Port A as input
  sbi  LCDRW      ; RW = High -> Read
waitbusy010:
  rcall  wait12c    ; IOC Setup
  sbi  LCDEX      ; Raise EX
  rcall  wait12c    ; Wait 
  sbis  LCDDATA,7    ; Skip if Busy
  rjmp  waitdone    ; Busy = Low -> done
  cbi  LCDEX      ; EX = Low
  inc  temp      ; Count
  rjmp  waitbusy010    ; Execute RB again
waitdone:
  cbi  LCDEX      ; Ex = Low
  ret


Ich weiss der Thread ist schon über 6 Monate alt. Aber wer weiss 
vielleicht findet sich jemand der mein Problem bestätigen kann, 
respektive mir erklären kann warum das Lesen des BUSY immer Low zurück 
gibt. Ich würde eigentlich lieber mit der BUSY FlagAabfrage arbeiten, 
damit es F_CPU unabhängig wird. Über Hinweise bin ich dankbar.

Wie gesagt, mit Delay Loops entsprechend den Angaben im Datenblatt läuft 
mein LCD einwandfrei. D.h. es ist alles richtig verkabelt, der Code 
macht auch was ich will; bis auf die Abfrage des Busy Flag.

Autor: Peter Schranz (cbscpe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Autsch, das tut weh. Jetzt fällt es mir wie Schuppen aus den Haaren. 
LCDDATA=PORTA, dort müsste natürlich PINA stehen. Und nun, Wunder oh 
Wunder, funktionierts wie ich mir das schon immer vorgestellt hatte.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.