LCD Ansteuerung error

Gast #2348425
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 :)
Angehängte Dateien:
Moderator (Firma: Titel) Persönliche Seite #2348457
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...
Gast #2348464
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
#2348479
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.
Gast #2348482
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
Gast #2348487
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
#2348514
Ändere in der lcd-routines.h die Zeilen:
1
#define LCD_PORT      PORTD
2
#define LCD_DDR       DDRD
nach
1
#define LCD_PORT      PORTD.OUT
2
#define LCD_DDR       PORTD.DIR

und füge davor noch
1
#define PD7  7
2
#define PD6  6
3
#define PD5  5
4
#define PD4  4
5
#define PD3  3
6
#define PD2  2
7
#define PD1  1
8
#define PD0  0
ein.

Dann sollte der Code kompilieren.
#2348528
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.
Gast #2348538
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
Gast #2348605
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)
Gast #2348682
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 ...
#2348697
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
Gast #2348699
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
Gast #2351901
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
#2351915
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.
#2351923
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.
Gast #2353153
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
Gast #2353205
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)
Gast #2353550
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
Angehängte Dateien:
Gast #2353619
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;
  }

  }
Gast #2353630
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^^
Gast #2353638
>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.
Gast #2353673
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
1
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.
Gast #2353676
Mach das mal so:
1
int main(void)
2
{
3
  // Initialisierung des LCD
4
  // Nach der Initialisierung müssen auf dem LCD vorhandene schwarze Balken
5
  // verschwunden sein
6
    lcd_init();
7
 
8
  lcd_string("Hallo!");
9

10
   while(1)
11
  {
12
    _delay_ms( 1000 );
13
    lcd_clear();
14
    _delay_ms( 1000 );
15
    lcd_string("test");
16
  }
17

18
  }
19
 
20
  return 0;
21
}

Geht das?
Gast #2353697
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^^
#2353702
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
1
int main(void)
2
{
3
  // Initialisierung des LCD
4
  // Nach der Initialisierung müssen auf dem LCD vorhandene schwarze Balken
5
  // verschwunden sein
6
    lcd_init();
7
 
8
  lcd_string("Juhu!");
9

10
   while(1)
11
  {
12
    _delay_ms( 1000 );
13
    lcd_clear();
14
    _delay_ms( 1000 );
15
    lcd_string("test");
16
  }
17

18
  }
19
 
20
  return 0;
21
}

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.
Gast #2353705
>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:
1
int main(void)
2
{
3
  // Initialisierung des LCD
4
  // Nach der Initialisierung müssen auf dem LCD vorhandene schwarze Balken
5
  // verschwunden sein
6
    lcd_init();
7
 
8
  lcd_string("Blabla!");
9

10
   while(1)
11
  {
12
  }
13

14
  }
15
 
16
  return 0;
17
}

Dann sollte das Hallo weg sein;)
Gast #2353708
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
Gast #2353720
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)
#2353722
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.
Gast #2353723
>sehr witzig holger :P da bin ich aber wieder da, wo ich vor 2 tagen war
>:D

Ok, nächster Test:
1
int main(void)
2
{
3
  // Initialisierung des LCD
4
  // Nach der Initialisierung müssen auf dem LCD vorhandene schwarze Balken
5
  // verschwunden sein
6
    lcd_init();
7
 
8
  lcd_string("Blabla!");
9
  lcd_clear();
10
  lcd_string("test");
11

12
   while(1)
13
  {
14
  }
15

16
  }
17
 
18
  return 0;
19
}
Gast #2353725
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?)
Gast #2353728
>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?
Gast #2353731
ach und holger, wenn ich das jetz mit
1
 lcd_init();
2
  lcd_string("Juhu!");
3
  _delay_ms( 1000 );
4
  lcd_clear();
5
  _delay_ms( 1000 );
6
  lcd_string("test");

bleibt Juhu! stehen ...
Gast #2353733
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
#2353735
Franky schrieb:
> aso das c file fast vergessen

Ich hatte sowas in Verdacht
1
   while(1);
2
  {
3
  
4
  }

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.
Gast #2353742
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 ...
#2353745
Den Watchdog könnte man noch abklären.
Ich hab jetzt deine LED Geschichte noch nicht durchschaut, das musst du 
eventuell anpassen.
1
int main(void)
2
{
3
  LEDPORT.DIR = 255;
4
  LEDPORT.OUTTGL = 0xff;
5

6
  lcd_init();
7
  lcd_string("Hallo!");
8

9
  LEDPORT.OUTTGL = 0x00;
10

11
  while(1)
12
  {
13
    _delay_ms( 1000 );
14
    lcd_clear();
15
    LEDPORT.OUTTGL = 0xff;
16

17
    _delay_ms( 1000 );
18
    lcd_string("test");
19
    LEDPORT.OUTTGL = 0b10101010;
20
  }
21
 
22
  return 0;
23
}

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.
Gast #2353750
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.
#2353752
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?
Gast #2353761
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 ...
Gast #2353766
1
 while(1)
2
  {
3
  _delay_ms( 1000 );
4
    lcd_init();
5
    LEDPORT.OUTTGL = 0b10101010;
6

7
    _delay_ms( 1000 );
8
    lcd_string("test");
9
    LEDPORT.OUTTGL = 0b00000000;
10

11

12
  }

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)....
Gast #2353771
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
Gast #2354793
Irgendwie ist das alles sehr seltsam.
Versuch das mal:
1
int main(void)
2
{
3
  // Initialisierung des LCD
4
  // Nach der Initialisierung müssen auf dem LCD vorhandene schwarze Balken
5
  // verschwunden sein
6
    _delay_ms( 1000 );
7
    lcd_init();
8
    _delay_ms( 1000 );
9
    lcd_string("Test!");
10

11
   while(1)
12
  {
13
  }
14

15
  }
16
 
17
  return 0;
18
}
Gast #2355604
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
Gast #2355608
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)
Gast #2355717
so jetz hab ich statt delay_ms ne eigene warteschleife geschrieben ... 
es geht trotzdem nicht -.-
1
// Wartefunktion
2
void warten(void)
3
{
4
  for(int count1=0;count1<=500;count1++)
5
  {
6
    for(int count2=0;count2<=500;count2++)
7
    { asm volatile ("nop"::);}
8
  }
9
}

Die Warteschleife geht auch, habs mit LED's ausprobiert
1
 while(1)
2
  {
3
  warten();
4
  LEDPORT.OUTTGL = 0b10101010;
5
  warten();
6
  lcd_string("testen");
7

8
  }


Achso und ich könnte verstehen, dass ihr an meiner GLaubwürdigkeit 
mittlerweile zweifelt... aber ich kanns nich ändern, es is echt so :(
Gast #2355747
interessant:
1
lcd_init();
2
warten();
3
warten();
4
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
#2355791
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?
Gast #2355886
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
#2355916
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
Gast #2355974
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")
Angehängte Dateien:
Gast #2356014
hm das is schwer rauszufinden

also ich habs jetz mal mit
1
 _delay_ms(100);

versucht. da kams korrekt an.

als extrembeispiel dann:
1
_delay_ms(500);
2
_delay_ms(500);
3
_delay_ms(500);

da kamm dann statt "teststring" -> "tewtwtvmng"
(alles in der main() funktion und mit dem "alten" Code-Beispielen)
Gast #2356037
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
Gast #2356134
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
Gast #2356146
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
#2356164
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.
Gast #2356174
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

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 15 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.