LCD Ansteuerung error

[Franky (Gast)]

Hallo Liebe Leute,
mein erster Post hier im Forum! :D
Also ich habe im Zuge eines Studienprojektes im 7. Sem. die Aufgabe, ein 
LCD anzusteuern (mit Sensorauswertung bla bla, das is aber erstmal nicht 
wichtig). Da ich zwar Kenntnisse in C/C++ und so besitze, aber absolut 
keine Ahnung von LCD Programmierung habe, wollte ich mich schonmal vor 
Start des Projektes damit auseinandersetzen und hab mich hier auf der 
Seite nach folgendem Tutorial gerichtet: 
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung 
.

Also schwuppsdiwupps Hardware besorgt und fröhlich drauf los gelötet und 
siehe da, ich habe auch tatsächlich im ersten "Test" die beiden 
schwarzen Balken aufm LCD gehabt, Freude groß!

SO das Hauptproblem is aber eher dann der Code, da ich nich genau wusste 
wie ich anfangen soll, dacht ich mir "OK, bügelst einfach erstmal den 
"Testcode" hier drauf und guckst erstmal, ob überhaupt irgendwas 
passiert, eh de selber rumprobierst" (der Code ist ebenfalls obigem Link 
entnommen) . Naja und da tritt jetz mein erstes Problem auf, beim "F7" 
drücken bekomme ich folgenden Error:

../lcd-routines.c: In function 'lcd_enable':
../lcd-routines.c:16:21: error: 'PD5' undeclared (first use in this 
function)

Und dieser Error kommt für alle weiteren Port Variablen, also PD0 usw. 
usw. . Leider habe ich auch nach langem Forenstöbern bis heute früh um 5 
keine echte Lösung dafür gefunden. Diese Variablen sind eigentlich in 
der eingebundenen "lcd-routines.h" alle definiert und der Fehler oben 
sagt mir ja nur "hier ööööhm, diese Variable ist nicht global definiert, 
kann ich nicht benutzen" (aus Sicht der Funktion :D) Ich gebe aber offen 
und ehrlich zu, dass ich außer ganz guten C Kenntnissen sehr wenig 
Ahnung von AVR Controllern und so weiter habe, is halt "first time". 
Also ich hab keine Ahnung ob irgend ne Einstellung oder sonstwas fehlt, 
leider haben mir die zahlreichen Tutorials zu AVR etc hier nicht 
weitergeholfen.

So, was benutze ich:
AVR Studio 4
ATXMEGA 128A1 (is auch für das C Projekt als Controller eingestellt)

Das waren glaub schon die wichtigsten Hardware Hinweise. Wie gesagt, 
rein schaltungstechnisch funktioniert der LCD schonma.

Ich hoffe mir kann jemand helfen :D Ich hänge mal meine Files dran :)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Man sollte sich schon grundlegende Gedanken machen, WAS man da tut...
Insbesondere, wenn man schon fast fertig ist (7. Semester).

Soll heißen:
Hast du mal mit einem kleinen, selbst geschriebenen Programm eine 
einfache Leuchtdiode zum Blinken bekommen?
Ein Pilot fliegt ja auch nicht gleich nach Amerika, sondern er übt mal 
hübsch Zuhause...

[Franky (Gast)]

Huhu,
also ich habe mir grundlegende Gedanken gemacht, ich hatte das im ersten 
Absatz versucht zu formulieren :)
Habe auch jemanden an meiner Seite, der sowas schon gemacht hat und mich 
in AVR Studio eingeführt hat und mir auch erklärt hat wie man die HEX 
Files auf den controller packt und alle solche grundlegenden Sachen. Ich 
hab jetz nich einfach "drauf los geschossen" und mir auch einige Tuts 
angeschaut und auch wirklich versucht das Problem zu lösen, eh ich jetz 
hier anfange zu fragen.

Also was beduetet Prozessor definieren? Meinst du den Controller für das 
Projekt einstellen? Das habe ich getan.

mfG Franky

[Franky (Gast)]

Achso und ja, ich habe ein eigenes kleines Programm bereits 
draufgespielt wo zwei LED's auf dem Board leuchten, ging alles bestens 
:)

[Hubert G. (hubertg)]

Was hast du für ein Demo-file, mit dem ersten aus dem Tut compiliert es 
fehlerfrei.

[Franky (Gast)]

Habe das erste Beispiel genommen aus dem Tut... hmmm :/

[J.-u. G. (juwe)]

Das Problem scheint zu sein, dass für den XMEGA128A die Definitionen der 
IO-Ports nicht erfolgen. Ich kann das hier auch nachvollziehen (AVR 
Studio 4).

Während beispielsweise für einen ATMEGA324p die Datei "iomxx4.h" 
eingebunden wird, welche die Portdefinitionen enthält, erfolgt beim 
XMEGA128A die Einbindung von "iox128a1.h". Diese enthält aber keine 
Definition der IO-Ports. Deshalb ist PD5 undefiniert.

[Franky (Gast)]

Aha OK ... diese io.c Files hatte ich mir auch angeschaut, aber die is 
ja so mega lang gewesen :-O In die Richtung hatte ichs mir auch fast 
gedacht, wie geh ich denn da jetz ran? Muss ich das selber 
nachdefinieren? Ich schau mal in die anderen I/O Files, wie das da 
gemacht wird

[Franky (Gast)]

Oar ja stimmt, in dem File was du gepostet hast, wird das alles 
definiert... das mach ich das am besten per #define in mein 
lcd-routines.c mit rein . richtig ? trau mich nich, das i/o file 
umzuschreiben :D

[J.-u. G. (juwe)]

Franky schrieb:
> das mach ich das am besten per #define in mein
> lcd-routines.c mit rein . richtig ? trau mich nich, das i/o file
> umzuschreiben :D

Das wird nicht funktionieren, da der XMEGA mit Sicherheit andere 
Register für die IO-Ports nutzt, als der ATMEGA.

[Franky (Gast)]

Ich meinte auch nicht blind kopieren :))
Ich meinte die selbst erarbeiteten Definitionen, das mit den Registern 
versuch ich grad rauszufinden :)

[J.-u. G. (juwe)]

Schau mal hier:

http://www.stromflo.de/dokuwiki/doku.php?id=xmega-c-tutorial#i_o


Das IO beim XMEGA läuft etwas anders. Du müsstes die lcd-routines.h 
daran anpassen.

[Franky (Gast)]

OK, erstmal Danke für die Hilfe, mal schauen ob ichs hinbekomme

mfG

[J.-u. G. (juwe)]

Ändere in der lcd-routines.h die Zeilen:

#define LCD_PORT      PORTD
#define LCD_DDR       DDRD

nach

#define LCD_PORT      PORTD.OUT
#define LCD_DDR       PORTD.DIR

und füge davor noch

#define PD7  7
#define PD6  6
#define PD5  5
#define PD4  4
#define PD3  3
#define PD2  2
#define PD1  1
#define PD0  0

ein.

Dann sollte der Code kompilieren.

[Franky (Gast)]

Oh, danke, hätteste jetz nich machen müssen :)

[J.-u. G. (juwe)]

Ist ja nur ein kleiner "Workaround" für diesen Spezialfall und es hat 
mich selbst interessiert. Funtktionstest musst Du durchführen (ich habe 
keinen XMEGA).

Wenn Du Zeit hast, kannst Du ja mal ein allgemeingültiges Mapping der 
IO-Funktionen des ATMEGA zum XMEGA erstellen.

[Franky (Gast)]

Jo, ich muss jetz eh erstmal fummeln ... Bei 6 Adern halten iwie meine 
Lötpunkte nich so ordentlich, muss ich glaub nochma ins Geschäft gehen

Vielen Dank erstmal, das is auf jeden Fall erstmal ein Ansatz den ich 
jetz weiterverfolge

[Franky (Gast)]

Also die error Meldungen sind alle weg, das Hex File wird erstellt (bin 
mal auf Port C umgestiegen) . Passieren tut erstmal nix :D Meine beiden 
schwarzen Balken bleiben da :D (testprogramm 1 nach wie vor)

[Franky (Gast)]

Hm woran kann das jetzt liegen.
Ich habe mir mal das Datenblatt vom LCD angeschaut, die ganzen 
Wartezeiten die da so definiert worden sind im Programm, passen ganz gut 
zu denen ausm Datenblatt 
(http://www.produktinfo.conrad.com/datenblaetter/175000-199999/183342-da-01-ml-LCD_Modul_16x2_Zeichen_de_en.pdf).

Um zu prüfen ob meine Verdrahtungen soweit passen hab ich mal 
Widerstandsmessungen gemacht, wo keine Verbindung sein soll, is 
eigentlich auch keine. Interessanterweise gibt mein Controller aber ne 
Spannung an den Ports aus (3,3V sind das ja), das kann ja kein Zufall 
sein, also scheint ja schonmal irgendwas zu gehen.

Kann das eventuell am Kontrast meines LCD liegen? Ich habe im Moment 
keinen Poti hier und deswegen die Leitung einfach auf GND gezogen, gehen 
evtl. deswegen auch nach Initialisierung des Display meine schwarzen 
Balken nicht weg? Das wäre jetzt zumindestens Hardwaremäßig die letzte 
Sache, die ich noch nicht umgesetzt habe, aber ob das daran liegen 
könnte ...

[Sascha W. (sascha-w)]

Franky schrieb:
> Kann das eventuell am Kontrast meines LCD liegen? Ich habe im Moment
> keinen Poti hier und deswegen die Leitung einfach auf GND gezogen, gehen
> evtl. deswegen auch nach Initialisierung des Display meine schwarzen
> Balken nicht weg?
genau da würde ich mal ansetzen, die Balken sind bestimmt auch ohne das 
der xmega was getan hat zu sehen.

Sascha

[Franky (Gast)]

Ja, die sind bereits nach korrekten Anschluss an die Spannungsversorgung 
zu sehen gewesen (was laut Tut erstmal nich falsch ist) ... Hm naja dann 
auf auf nen Poti organ :D

[Franky (Gast)]

Und es gehht :D
Danke für die Hilfen :)

[Franky (Gast)]

Halli Hallo,
da muss ich mich mal wieder an euch wenden :)
Mein aktuelles Ziel ist es (nach einfachen Funktionstests der 
verschiedenen LCD Befehle, welche alle soweit gehen) über einen externen 
Interrupt (Tastendruck) das Display zu löschen bzw. einen Text aufs 
Display zu schreiben.

Ich bin jetzt soweit, dass ich mittels Stromflo Tutorial der Meinung 
bin, dass meine Interruptinitialisierung inklusive Initialisierung der 
Taster soweit erstmal geht. Das sehe ich daran, dass der String beim 
drücken des Knopfes tatsächlich auf dem Bildschirm erscheint, es stimmt 
aber nur der erste Buchstabe, der Rest ist, wie man so schön sagt, 
"kauderwelsch" ;).
Wenn ich den lcd_clear Befehl benutze, passiert sogar leider gar nix. 
Ich weise nochmal darauf hin, dass die Befehle, wenn ich sie in der 
main() benutze, alle funktionieren! Sie funktionieren nur nicht in der 
ISR

Weiß jemand einen Rat? Muss ich eventuell für die ISR eine Art 
Zeitpuffer setzen oder irgendsowas, damit der Befehl korrekt ans LCD 
geht?

Hier der Code:

#include <avr/io.h>
#include "lcd-routines.h"
#include <avr/interrupt.h>
#include <util/delay.h>


//Interruptroutine
ISR(PORTD_INT0_vect)
{
  lcd_string("Hallo Hallo");
}


int main(void)
{
  // Initialisierung des LCD
  // Nach der Initialisierung müssen auf dem LCD vorhandene schwarze 
Balken
  // verschwunden sein
     lcd_init();

  //TASTER initialisieren
  PORTD.DIR = 0x00;
  //Für alle Pins die Maske setzen
  PORTCFG.MPCMASK=0xFF;
  //Für alle Pins Pullup aktivieren
    PORTD.PIN0CTRL= PORT_OPC_WIREDANDPULL_gc;
  //Interrupt Level an PORTD festlegen
  PORTD.INTCTRL = PORT_INT0LVL_LO_gc;
    // Maske setzen alles Pins die auf 1 gesetzt werden
  // werden anschließend als Interrupt definiert
  // In diesem Beispiel alle des PORTD
  PORTD.INT0MASK = 0xff;
  //Für alle Pins die Maske setzen
  PORTCFG.MPCMASK=0xff;
  // Die Maske wird nun angewandt bei fallender
  // Flanke wird ein Interrupt ausgelöst
  PORTD.PIN0CTRL |= PORT_ISC_FALLING_gc;


  // Interrupts aktivieren und alle Level freigeben
  sei();
  PMIC.CTRL |= PMIC_HILVLEN_bm |PMIC_MEDLVLEN_bm|PMIC_LOLVLEN_bm;


  while(1)
  {
  }

  return 0;
}



Liebe Grüße, Franky

[J.-u. G. (juwe)]

Franky schrieb:
> Mein aktuelles Ziel ist es (nach einfachen Funktionstests der
> verschiedenen LCD Befehle, welche alle soweit gehen) über einen externen
> Interrupt (Tastendruck) das Display zu löschen bzw. einen Text aufs
> Display zu schreiben.

Hast Du die Taster entprellt?

> Wenn ich den lcd_clear Befehl benutze, passiert sogar leider gar nix.
> Ich weise nochmal darauf hin, dass die Befehle, wenn ich sie in der
> main() benutze, alle funktionieren! Sie funktionieren nur nicht in der
> ISR

Dann führe den Befehl doch in der while-Schleife der main() aus. In der 
ISR wird eine globale Variable (als volatile deklarieren) gesetzt. Diese 
Variable fragst Du in der while-Schleife ab, und falls sie gesetzt ist, 
wird der LCD-Funktion aufgerufen und die Variable wieder gelöscht.

[Franky (Gast)]

Hallo,
Thematik Tasterentprellung wurde ich gerade drauf hingewiesen, ich gebe 
zu, dass hatte ich nicht bedacht, ich arbeite dran :)

[Karl H. (kbuchegg)]

Merk dir gleich 2 Dinge

* LCD-Ausgaben in einer ISR sind bäh, böse, pfui
* Um Taster auszuwerten braucht man keinen externen Interrupt(*)
  Heb dir externe Interrupts lieber für die wichtigen Dinge auf.


(*) mit einer Ausnahme: Wenn der Taster den µC aus dem Tiefschlaf holen 
muss. Aber auch dann weckt der Interrupt lediglich den µC auf. Die 
Tastenauswertung macht man dann trotzdem immer noch mittels Polling (zb 
in einem Timer Interrupt).


Edit: Ich versteh natürlich, dass du nur zu Testzwecken, um externe 
Interrupts zu testen, einfach mal einen Taster an einen INterrupt Pin 
gehängt hast.

[Franky (Gast)]

Also sollte ich mich bei LCD Ausgaben an die Aussagen von Uwe halten? 
Sprich sowas besser in die while() von der main Funktion packen?

[Franky (Gast)]

Hallo,

Also ich habe gestern (und die ganze Nacht) an den Hinweisen von Karl 
Heinz gearbeitet und den Taster nicht per externem Interrupt, sondern 
per Polling über einen Timmer Interrupt aller 10ms realisiert. Nachdem 
sich trotzdem auf dem LCD nichts tat, war ichn bisschen am verzweifeln 
und hab erstmal versucht, ob ich mit dieser Variante denn wenigstens die 
LED's An- und Ausschalten kann. Und siehe da, das geht wunderbar (das 
hatte erst nen bisschen geflackert, aber mit nem 200ms delay ging das 
dann gut), was mich zu der Schlussfolgerung führt, dass ich es erstmal 
gepackt habe, den Taster per Timer Interrupt abzufragen :)  (was man an 
sich erstmal sehr freut).

Leider funktioniert das weiterhin nicht mit den LCD Funktionen aus dem 
Tutorial: 
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung 
.  Nun meine Frage: Woran kanns liegen? Ich vermute fast, dass ich 
irgendwas ganz triviales nicht beachte oder so, weil wie gesagt, 
grundlegend funktioniert meine Interrupt-Taster-Abfrage schonmal.


Freundliche Grüße und allen nen schönen Tag, Franky

[Franky (Gast)]

Achso und obige Hinweise bezüglich LCD Ausgaben in der ISR hab ich auch 
beachtet, ich setze in der ISR nur ne "volatile int" variable und frage 
die dann in der while() von der main() Funktion ab  (auch die LED's 
gehen so)

[Franky (Gast)]

Oh man ich bin am verzweifeln :((
Um das jetz nochmal "langsam" zu testen hab ich mal den Timer Interrupt 
auf 5sek gestellt und den button rausgelassen, einfach aller 5sek 
bildschirm schreiben/bildschirm löschen... es passiert nix :(( es bleibt 
mein initialisierungsstring stehen ._. vielleicht hat jmd mal zeit und 
lust in den code zu schauen :/

status im moment: timer interrupt aller 5 sek (LED's toggeln AN/AUS -> 
das geht) aber: LCD sollte auch AN/AUS (bzw leer/string) gehen -> das 
geht nicht

[holger (Gast)]

>bildschirm schreiben/bildschirm löschen... es passiert nix :(

Kein Wunder, ich sehe keinen Befehl der das macht.

[Franky (Gast)]

argh ja -.-
sorry ich hab das falsche C file hochgeladen ... ich hatte so viele 
versionen heute, da kommt man durcheinander xD

is der gleiche code wie im C file nur mit dieser while schleife:

  while(1)
  {
    if((FLAG==1)&&(LCD_AN==1))
  {
  LEDPORT.OUTTGL = 0b10101010;
  lcd-clear();
  FLAG=0;
  LCD_AN=0;
  }

  if((FLAG==1)&&(LCD_AN==0))
  {
  LEDPORT.OUTTGL = 0b10101010;
  lcd_string("test");
  FLAG=0;
  LCD_AN=1;
  }

  }

[holger (Gast)]

lcd-clear();

Syntax Error;)

[Franky (Gast)]

ok das war jetzn rechtschreibfehler.. sorry... solche sachen könnt ihr 
mal ignorieren^^ hatte grade drei stunden lang kollegen am TS, solche 
syntax sachen sinds nich (der code hat fehlerfrei kompiliert)... das 
geht jetz gradn bisschen auf die "ich sitze seit 15h vor dem 
zeug"-fehlerquote^^

[holger (Gast)]

>ok das war jetzn rechtschreibfehler.. sorry... solche sachen könnt ihr
>mal ignorieren^^

Keine. Poste den Originalcode. Ansonsten kannst du deinen
Fehler weiter alleine suchen.

[Franky (Gast)]

hast recht, so das sind jetz nochmal die files, die ich jetzt gerade mit 
AVR studio 4 kompiliert habe. 0 warnings

[J.-u. G. (juwe)]

Franky schrieb:
> lcd_init();
> lcd_string("Hallo!");
Wird "Hallo!" nach der Initialisierung angezeigt?

Vor dem Ausgabebefehl:
> lcd_string("test");

wäre es sinnvoll, dem Display mittels

lcd_setcursor

mitzuteilen, an welcher Position der Text ausgegeben werden soll.

[Franky (Gast)]

Also
1. Ja, den String nach der Initialisierung zeigt es an.

Die Idee mit dem setcursor dachte ich auch erst, aber bevor es zu diesem 
string kommt wird ja beim ersten Interrupt der display mittels

lcd_clear();

 gelöscht .... bzw viel mehr soll er gelöscht werden, aber bereits das 
geschieht nicht. Außerdem bewirkt der Befehl (laut Datenblatt des LCD) 
zusätzlich das rücksetzen des Cursors auf Startposition. Was, so wie der 
Code jetz dasteht, ein Reset hinfällig machen sollte.

[holger (Gast)]

Mach das mal so:

int main(void)
{
  // Initialisierung des LCD
  // Nach der Initialisierung müssen auf dem LCD vorhandene schwarze Balken
  // verschwunden sein
    lcd_init();
 
  lcd_string("Hallo!");

   while(1)
  {
    _delay_ms( 1000 );
    lcd_clear();
    _delay_ms( 1000 );
    lcd_string("test");
  }

  }
 
  return 0;
}

Geht das?

[Franky (Gast)]

Nein, auch diese, ziemlich coole Idee, geht leider au nicht :/
Es bleibt ganz stur "Hallo!" aufm Bildschirm

[holger (Gast)]

>Nein, auch diese, ziemlich coole Idee, geht leider au nicht :/
>Es bleibt ganz stur "Hallo!" aufm Bildschirm

Dann brenn mal die richtige HEX Datei.

[Franky (Gast)]

Eh sorry, aber mit der Aussage kann ich jetzt nichts anfangen.
Ich hab logischerweise die HEX Datei neu auf den Controller geladen, 
nachdem ich deine Änderung eingebaut hatte^^

[Karl H. (kbuchegg)]

Franky schrieb:
> Eh sorry, aber mit der Aussage kann ich jetzt nichts anfangen.
> Ich hab logischerweise die HEX Datei neu auf den Controller geladen,
> nachdem ich deine Änderung eingebaut hatte^^

Gegentest

int main(void)
{
  // Initialisierung des LCD
  // Nach der Initialisierung müssen auf dem LCD vorhandene schwarze Balken
  // verschwunden sein
    lcd_init();
 
  lcd_string("Juhu!");

   while(1)
  {
    _delay_ms( 1000 );
    lcd_clear();
    _delay_ms( 1000 );
    lcd_string("test");
  }

  }
 
  return 0;
}

wenn jetzt auf dem LCD Juhu! steht, dann glaub ich dir das richtige 
HEX-File.
Das mit dem HEX-File ist nicht böse gemeint. Das passiert jedem mal.

[holger (Gast)]

>Eh sorry, aber mit der Aussage kann ich jetzt nichts anfangen.
>Ich hab logischerweise die HEX Datei neu auf den Controller geladen,
>nachdem ich deine Änderung eingebaut hatte^^

Brennst du auch die richtige HEX Datei?

Ok, dann so:

int main(void)
{
  // Initialisierung des LCD
  // Nach der Initialisierung müssen auf dem LCD vorhandene schwarze Balken
  // verschwunden sein
    lcd_init();
 
  lcd_string("Blabla!");

   while(1)
  {
  }

  }
 
  return 0;
}

Dann sollte das Hallo weg sein;)

[Franky (Gast)]

Ihr seid gemein xD
Ja verdammt, es steht Juhu! darauf :DD oh wie fies xD

ich lösche jedesmal das file aus dem skript ordner und schiebe das neue 
(was nachm "F7" drücken entsteht) da hinein, resette den controller und 
schiebe es über die .bat datei drauf

[Franky (Gast)]

sehr witzig holger :P da bin ich aber wieder da, wo ich vor 2 tagen war 
:D

[Karl H. (kbuchegg)]

Franky schrieb:
> sehr witzig holger :P da bin ich aber wieder da, wo ich vor 2 tagen war
> :D

Mag sein.
Aber auf dieser Seite des Monitors ist damit eine mögliche Fehlerquelle 
ausgeschlossen worden :-)

[Franky (Gast)]

Ja, es is aber wirklich (ohne geflunker) der andere string auf dem 
bildschirm. ich habe übrigens diesbezüglich wirklich schon viel 
versucht, ich verstehe wirklich nicht, warum sämtliche befehle in der 
while() schleife "ignoriert" werden (aber jetz nür bezüglich des LCD. 
wie gesagt, LED's blinken lassen etc. hab ich alles hinbekommen in der 
schleife)

[Karl H. (kbuchegg)]

Franky schrieb:
> Ja, es is aber wirklich (ohne geflunker) der andere string auf dem
> bildschirm. ich habe übrigens diesbezüglich wirklich schon viel
> versucht, ich verstehe wirklich nicht, warum sämtliche befehle in der
> while() schleife "ignoriert" werden (aber jetz nür bezüglich des LCD.
> wie gesagt, LED's blinken lassen etc. hab ich alles hinbekommen in der
> schleife)

Zeig nochmal dein letztes Testprogramm.
Nicht Copy&Paste sondern das C-File so wie es ist anhängen.

[holger (Gast)]

>sehr witzig holger :P da bin ich aber wieder da, wo ich vor 2 tagen war
>:D

Ok, nächster Test:

int main(void)
{
  // Initialisierung des LCD
  // Nach der Initialisierung müssen auf dem LCD vorhandene schwarze Balken
  // verschwunden sein
    lcd_init();
 
  lcd_string("Blabla!");
  lcd_clear();
  lcd_string("test");

   while(1)
  {
  }

  }
 
  return 0;
}

[Franky (Gast)]

jo moment bevor ich das mache, habe ich grade was interessantes 
herausgefunden. ich habe das "juhu!" mal aus der main() rausgenommen und 
einfach mal in die while() schleife geschmissen und siehe da, es kommt 
"kauderwelsch" aufm LCD an


"Juhu!" wird zu "Nulue"   (sieht nach ner festen Verschiebung aus oder?)

[Franky (Gast)]

und @ holger: es bleibt "test" auf dem LCD stehen. das Hallo sieht man 
sicher net, weils so schnell geht oder

[holger (Gast)]

>und @ holger: es bleibt "test" auf dem LCD stehen. das Hallo sieht man
>sicher net, weils so schnell geht oder

So sollte es sein. Hast du einen aktiven Watchdog?

[Franky (Gast)]

mhh nein

[Franky (Gast)]

ach und holger, wenn ich das jetz mit

 lcd_init();
  lcd_string("Juhu!");
  _delay_ms( 1000 );
  lcd_clear();
  _delay_ms( 1000 );
  lcd_string("test");

bleibt Juhu! stehen ...

[h0rst (Gast)]

Vergiss es lieber gleich!

Bei dem Wissensstand kannst du dein Studium direkt an den Nagel 
hängen...bringt nichts....

Zumal man dort lernen sollte, selbstständig zu arbeiten und nicht 
ständig Mama und Papa zu fragen

[Franky (Gast)]

aso das c file fast vergessen

[Karl H. (kbuchegg)]

Franky schrieb:
> aso das c file fast vergessen

Ich hatte sowas in Verdacht

   while(1);
  {
  
  }

aber das ist es auch nicht.
Also für mich sieht es so aus, als ob der _delay_ms den Unterschied 
macht. Ich kann mir aber auf die Symptome keinen Reim machen, wenn der 
Watchdog wirklich in der Hütte ist.

[Franky (Gast)]

Also ich hab an solchen sachen wie Watchdog Timer absolut nich 
rumgespielt, sollte mich wundern, wenn der an ist.

[Franky (Gast)]

Kann das damit zusammenhängen, dass in den verschiedenen Funktion wie 
lcd_clear(); etc. ja schon bereits delay-Zeiten enthalten sind? 
Vielleicht beißt sich das ja ...

[Karl H. (kbuchegg)]

Den Watchdog könnte man noch abklären.
Ich hab jetzt deine LED Geschichte noch nicht durchschaut, das musst du 
eventuell anpassen.

int main(void)
{
  LEDPORT.DIR = 255;
  LEDPORT.OUTTGL = 0xff;

  lcd_init();
  lcd_string("Hallo!");

  LEDPORT.OUTTGL = 0x00;

  while(1)
  {
    _delay_ms( 1000 );
    lcd_clear();
    LEDPORT.OUTTGL = 0xff;

    _delay_ms( 1000 );
    lcd_string("test");
    LEDPORT.OUTTGL = 0b10101010;
  }
 
  return 0;
}

die Idee ist es, die LED parallel mit der Ausgabe blinken zu lassen.
Ich würde auch ganz gerne am Programmstart eine andere LED einschalten, 
damit man einen µC Restart deutlich sieht. Ich weiß aber nicht wie deine 
LEd verschaltet sind und wie man die bei Dir anspricht.

[Karl H. (kbuchegg)]

Franky schrieb:
> Kann das damit zusammenhängen, dass in den verschiedenen Funktion wie
> lcd_clear(); etc. ja schon bereits delay-Zeiten enthalten sind?
> Vielleicht beißt sich das ja ...

Nein. Was soll sich da beißen? Wird alles hintereinander abgearbeitet.

[Franky (Gast)]

Ach keine Ahnung, mehrere Delays hintereinander oder sowas^^ Hielts jetz 
selber auch nich für so wahrscheinlich^^

Die LED's sind an PORTE (8 Stück) deswegen auch das OUTGGL, das hatte 
ich gemacht um zu überprüfen, ob denn mein Interrupt überhaupt greift 
(also AN/AUS Toggeln). Das war ne reine Testroutine, die ich heute im 
Verlauf des Tages mit eingebaut hatte, um das halt zu prüfen.

[J.-u. G. (juwe)]

Franky schrieb:
> Die LED's sind an PORTE (8 Stück) deswegen auch das OUTGGL, das hatte
> ich gemacht um zu überprüfen, ob denn mein Interrupt überhaupt greift
> (also AN/AUS Toggeln). Das war ne reine Testroutine, die ich heute im
> Verlauf des Tages mit eingebaut hatte, um das halt zu prüfen.

Ist ja auch ein richtiger Ansatz. Blinken die LEDs denn exakt mit der 
gewünschten Frequenz?

[Franky (Gast)]

die LED's toggeln wunderbar im 1 sekunden takt... gibts doch nicht... 
ganz geschmeidig ... O_O wenn ich ne digicam hätte, könnt ich jan video 
machen xD

[Franky (Gast)]

und am LCD bleibt schön starr "Hallo!" stehen -.- (das Juhu hatte ich 
wieder weg gemacht)

[Karl H. (kbuchegg)]

Franky schrieb:
> die LED's toggeln wunderbar im 1 sekunden takt... gibts doch nicht...
> ganz geschmeidig ...

Ratlos

ist ja nicht so, dass das der erste lcd_clear im Programm wäre. Am Ende 
der lcd_init ist der erste. Und danach ist immer noch eine Ausgabe 
möglich. Also wirds der lcd_clear auch nicht sein.

[J.-u. G. (juwe)]

Mach doch mal statt lcd_clear ein lcd_init in die while-Schleife.

[Franky (Gast)]

Ja genau den Gedanken hatten wir heute auch schon!
Denn wenn man die Spannung einschaltet, is ja nen schwarzer Balken da, 
welcher von der lcd_init(); beseitigt wird. Ich bin halt genauso ratlos, 
sonst würd ich euch damit auch nicht so belästigen ...

[Franky (Gast)]

 while(1)
  {
  _delay_ms( 1000 );
    lcd_init();
    LEDPORT.OUTTGL = 0b10101010;

    _delay_ms( 1000 );
    lcd_string("test");
    LEDPORT.OUTTGL = 0b00000000;


  }

Die LED's toggeln fröhlich weiter, aufm LCD weiterhin "Hallo!" (2x 
überprüft obs richtige HEX File drauf is, indem ich immer mal andere 
LED's nehme)....

[Franky (Gast)]

ach übrigens was ich auch schon versucht habe, die OUTTGL Befehle in die 
Funktionen reinzuschieben, sprich den LED Toggle erst innerhalb von 
"lcd_clear", "lcd_command" etc. reinzuschieben, um zu prüfen, ob das 
überhaupt aufgerufen wird, auch da haben die LED's geblinkert

[Franky (Gast)]

hat noch irgendjemand eine idee?^^

[Walter (Gast)]

holger schrieb:
> lcd_string("Blabla!");
>   lcd_clear();
>   lcd_string("test");

wenn das geht und das

Franky schrieb:
> lcd_init();
>   lcd_string("Juhu!");
>   _delay_ms( 1000 );
>   lcd_clear();
>   _delay_ms( 1000 );
>   lcd_string("test");

geht nicht,
dann würde ich mal eine eigene delay-routine schreiben

[Peter D. (peda)]

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=102296


Peter

[holger (Gast)]

Irgendwie ist das alles sehr seltsam.
Versuch das mal:

int main(void)
{
  // Initialisierung des LCD
  // Nach der Initialisierung müssen auf dem LCD vorhandene schwarze Balken
  // verschwunden sein
    _delay_ms( 1000 );
    lcd_init();
    _delay_ms( 1000 );
    lcd_string("Test!");

   while(1)
  {
  }

  }
 
  return 0;
}

[J.-u. G. (juwe)]

Walter schrieb:
> dann würde ich mal eine eigene delay-routine schreiben

Ich hatte am Anfang auch "delay_ms()" im Verdacht. Daran liegt es aber 
nicht, sonst würden seine LEDs nicht in der richtigen Frequenz blinken.

[J.-u. G. (juwe)]

@holger:

Ist wahrscheinlich ein Versehen: in Deinen Code-Beispielen gibt es eine 
schließende geschweifte Klammer zuviel.

[Franky (Gast)]

Ja, es is wirklich seltsam ... Ich verstehs auch nicht... :/
Wie juwe sagt, blinken die LED's ja

[holger (Gast)]

>Ja, es is wirklich seltsam ... Ich verstehs auch nicht... :/
>Wie juwe sagt, blinken die LED's ja

Hast du meinen letzten Programmvorschlag ausprobiert?

[holger (Gast)]

Kann es sein das die RW Leitung vom LCD in der Luft hängt?

[Franky (Gast)]

RW hängt wie im tutorial beschrieben an GND, da in meinen einfachen 
Beispielen ein Einlesen des LCD unnötig ist

[Franky (Gast)]

hm achso und fast erwarteter weise kam bei deinem beispiel keine 
initialisierung des LCD ... also doch die delay befehle?

[Franky (Gast)]

aber andererseits hab ich auch schon routinen ohne delay befehle 
ausprobiert, wie zB meine interrups die ich über einen timer interrupt 
aller 5sek gemacht habe, da hab ich in die while schleife nur die 
"volatile int" variable abgefragt und dann was aufs LCD ausgeben wollen. 
das hab ich ohne delays gemacht

[Franky (Gast)]

ehrlich gesagt vermute ich mittlerweile auch, dass ich an der hardware 
was falsch verdrahtet habe...was ich aber schon mehrfach überprüft habe 
:/ aber wieso kommen dann die initialisierungsbefehle alle an? (ohne 
delays)

[Franky (Gast)]

so jetz hab ich statt delay_ms ne eigene warteschleife geschrieben ... 
es geht trotzdem nicht -.-

// Wartefunktion
void warten(void)
{
  for(int count1=0;count1<=500;count1++)
  {
    for(int count2=0;count2<=500;count2++)
    { asm volatile ("nop"::);}
  }
}

Die Warteschleife geht auch, habs mit LED's ausprobiert

 while(1)
  {
  warten();
  LEDPORT.OUTTGL = 0b10101010;
  warten();
  lcd_string("testen");

  }

Achso und ich könnte verstehen, dass ihr an meiner GLaubwürdigkeit 
mittlerweile zweifelt... aber ich kanns nich ändern, es is echt so :(

[Franky (Gast)]

sry das lcd_string("testen") gedanklich durch LEDPORT.OUTTGL = 
0b00000000; ersetzen

[Franky (Gast)]

interessant:

lcd_init();
warten();
warten();
lcd_string("Hallo!");

da spuckt mir mein LCD "Lelloe" aus (anstatt "Hallo!")

hm leider helfen mir da Google etc wenig weiter...

aber könnte aufn verdrahtungsfehler hinweisen oder?
ach man ich habs jetz 25x überprüft... da is nix locker oder so ...
und ohne delay kommt ja "Hallo!" an ... ahhhhh

[J.-u. G. (juwe)]

Franky schrieb:
> da spuckt mir mein LCD "Lelloe" aus (anstatt "Hallo!")

Das passiert, wenn  der Dateneingang DB6 des LCDs stängig auf "High" 
steht.


> und ohne delay kommt ja "Hallo!" an ... ahhhhh

Längere Pausen scheinen zu bewirken, dass der XMEGA den Pin DB6 nicht 
mehr auf "Low" ziehen kann.

Kannst Du Dir dieses Signal auf dem Oszi ansehen?

[Franky (Gast)]

Nein, sorry, so ne Möglichkeiten hab ich hier nich :/

[J.-u. G. (juwe)]

Franky schrieb:
> Nein, sorry, so ne Möglichkeiten hab ich hier nich :/

Tja, dann halt auf anderem Wege die Verbindung PC2 --> DB6 prüfen. Ich 
glaube hier könnte der Fehler liegen.

[Franky (Gast)]

jo ich hab zumindestens nen billiges multimeter hier rumliegen, damit 
müsst ich ja die spannung prüfen können

[Franky (Gast)]

Hmm so richtig finde ich damit auch nicht mehr raus.
Ich meine den Gedanken hatte ich auch schon. Die Möglichkeit, dass der 
an irgend nem Pin kein Low setzt würde vermutlich auch erklären, weshalb 
der LCD clear auch nich passiert.

Hm ich les mir nochma in Ruhe das Tutorial durch, vielleicht hab ich 
irgendwas vergessen

[Peter D. (peda)]

Ich rate Dir dazu, wie in meinem Beispiel, Bitvariablen zu verwenden.
Das ist dann deutlich übersichtlicher.

Natürlich kann jeder Profi |&~<< Ausdrücke verstehen, aber gut lesbar 
ist das nicht.
Es können sich also leicht Flüchtigkeitsfehler einschleichen und schon 
hat man irgendwo ein falsches Bit falsch gesetzt.


Peter

[Franky (Gast)]

Huhu Peda,

also ich hab einfach mal deinen Rat befolgt und jetzt mehr oder weniger 
im Schnelldurchlauf das LCD mit dem von dir geposteten Link 
programmiert.

Es geht tatsächlich, jetz hab ich schonmal 2 Wege was aufs LCD zu 
bekommen^^

Das Problem bleibt erhalten, baue ich eine Wartefunktion ein, kommt 
Schwachsinn auf dem LCD an ...


Anbei die neuen C Files (so wie es jetzt schon wieder "nicht geht")

[J.-u. G. (juwe)]

Bis zu welcher Wartezeit erfolgt eine korrekte Ausgabe?

[Franky (Gast)]

hm das is schwer rauszufinden

also ich habs jetz mal mit

 _delay_ms(100);

versucht. da kams korrekt an.

als extrembeispiel dann:

_delay_ms(500);
_delay_ms(500);
_delay_ms(500);

da kamm dann statt "teststring" -> "tewtwtvmng"
(alles in der main() funktion und mit dem "alten" Code-Beispielen)

[Franky (Gast)]

so habsn bisschen mehr eingeengt

_delay_ms(350);  <--- ging noch

_delay_ms(450);  <--- ging nicht mehr

[J.-u. G. (juwe)]

Franky schrieb:
> da kamm dann statt "teststring" -> "tewtwtvmng"

Was weiterhin dafür spricht, dass PC2 --> DB6 nicht richtig verdrahtet 
ist. Möglicherweise hängt DB6 in der Luft und hat nach ein paar hundert 
Millisekunden High-Potential angenommen.

[Franky (Gast)]

Hmmm aber DB6 ist doch Pin 13 am LCD und da messe ich zwischen LCD 
Kontanktstelle und Leitungsende einen Widerstand mit meinem Multimeter 
(ca. 1Ohm oder so, wackelt bissl dolle, aber messbar). Nach meinem 
elektrotechnischen Verständnis heißt das, es besteht ne Verbindung. 
Sobald ich eine Messspitze mal an nen andern Pin halte missts nichts 
mehr, auch korrekt, sonst hätt ich ja nen Kurzschluss

[J.-u. G. (juwe)]

Franky schrieb:
> Hmmm aber DB6 ist doch Pin 13 am LCD und da messe ich zwischen LCD
> Kontanktstelle und Leitungsende einen Widerstand mit meinem Multimeter
> (ca. 1Ohm oder so, wackelt bissl dolle, aber messbar).

Und zwischen µC-Ausgangspin und LCD-Eingangspin?

[Franky (Gast)]

habs jetz echt vom pin bis zum LCD anschluss genommen. Isn Widerstand 
messbar, der auch hinreichen gering is (also keine defekte Lötstelle 
oder so)

[Franky (Gast)]

Gott eh wenn ich mir überlege wie ich mich am ersten Tag gefreut habe, 
echt was auf dem LCd zu sehen, umso mehr bin ich jetzt völlig fertig xD

[Franky (Gast)]

Hmmm ich hab jetz mal ein bisschen am Systemtakt "rumgespielt"

Wenn ich den Takt auf 1 Mhz stelle dann wird der Code hier:

[c]while(1)
  {
     _delay_ms(500);
  LEDPORT.OUTTGL = 0b10101010;
  lcd_clear();
  _delay_ms(500);
  LEDPORT.OUTTGL = 0b00000000;
  lcd_string("hallo");

  }

Immerhin soweit ausgeführt, das Hallo aufm Display steht, aber danach 
clearen und wieder "drauftoggeln" tut er nicht

[Franky (Gast)]

andererseits wenn ichs mir überlege, führt das ja aufs gleiche problem 
zurück oder? nur das es mit nem andern takt halt an nem andern punkt 
hängen bleibt

[J.-u. G. (juwe)]

Also für mich sieht es so aus, dass es kein Softwarefehler ist. Der Wurm 
scheint entweder in Deiner Schaltung zu liegen, oder aber das LCD bzw. 
dessen Platine ist tatsächlich fehlerhaft (kann halt mal vorkommen).

Leider sind solche Defekte aus der Ferne schlecht diagnostizierbar, so 
dass zumindest ich Dir momentan nicht mehr viel weiterhelfen kann.

[Franky (Gast)]

Joar. So scheint es tatsächlich zu sein.
Auch wenns mir widerstrebt werd ich meine Schaltung wohl oder übel 
nochmal auseinander dröseln müssen^^

Naja, Vielen Dank erstmal