Hallo zusammen Ich bin ein relativer Neuling was Mikrocontroller anbelangt. Ich habe mir vor einigen Tagen das STK 500 board besorgt und mit dem dazugelieferten Atemga8515L erfolgreich einen 16x1 LCD angesteuert. Nun wollte ich einen AD Wandler benutzen und kaufte mir desshalb den Atmega8 16PU von Conrad. Ich konnte diesen auch erfolgreich anschliessen und programmieren. Allerdings tut sich auf dem LCD nichts mehr. Mein erster Gedanke war, dass ich vielleicht eine unterschiedliche Taktfrequenz im Makefile und in den Fuses in AVRStudio 5 eingestellt habe. Ich benutzte bei den Fuses die EXTCLK_6CK_64ms option, so wie ich das auch vorhin tat. Das bedeutet meines Wissens nach, dass der Mikrocontroller den Takt von dem STK board bekommt, welcher mit 3686400 Hz läuft. Ich habe, da es so nicht geklappt hat auch mal den internen Takt des Atmega8 genutzt (z.B. 4mHz ) und natürlich auch wieder in dem Makefile den Eintrag F_CPU dementsprechend angepasst. Ich habe auch, nur um zu sehen, ob der Controller überhaupt etwas tut ein LED- Blinkprogramm draufgeladen, welches funktionerte, das heisst der Chip lässt sich programmieren und funktionert. Ich habe im obigen Teil meiner Beschreibung eigentlich nur die Taktfrequenz angesprochen, weil der LCD für die Initialisierung gewisse Wartezeiten fordert, welche vielleicht nicht mehr eingehalten werden? Kann mir jemand weiterhelfen, vielleicht übersehe ich ja etwas grundlegendes? Ach ja, habe gerade vorher wieder den alten Chip eingebaut und der LCD ging wieder, das heisst, es ist alles richtig gesteckt. Liebe Grüsse, Roman
:
Verschoben durch User
Atemga8515 und Atmega8 haben doch ein völlig anderes Pin-Layout. Möglicherweise hast Du bei der Konfiguration der Ausgangspins des Atmega8 einen Fehler gemacht.
- Programm für den M8 kompiliert? - gibt es beim M8 auch die Portpins an denen das LCD programmtechnisch hängt, der 8151 hat mehr davon als der M8 - JTAG deaktiviert um die Portpins frei zu bekommen Gruß Timo
Hallo Juwe Danke für die schnelle Antwort! Ich benutze für den LCD nur PORT B (Daten) und PORTD (Control). Diese PORTS kann ich doch bei beiden Controllern identisch ansprechen, bzw. sie existieren bei beiden Controllern?
Hallo Timo Danke auch dir für die Antwort. Ja, ich habe im Makefile den MCU als Atmega8 angegeben. Über die Sache mit dem JTAG war ich mir bisher gar nicht im klaren. Allerdings benutze ich den PORTC gar nicht für den LCD. Ausserdem kann ich im AVRStudio 5 das Fusebit JTAGEN nirgendwo finden, was auch immer das bedeutet. > - gibt es beim M8 auch die Portpins an denen das LCD programmtechnisch > hängt, der 8151 hat mehr davon als der M8 hier weiss ich nicht genau was du damit meinst, kannst du mir das bitte genauer erklären? Liebe Grüsse Roman
Ich sollte vielleicht etwas konkreter zu der PIN Belegung werden. Ich benutze für den Datenaustausch mit dem LCD wie gesagt den ganzen PORTB, also alles 8 PINS. Für die Controls, als RS, RW und Enable benutze ich die PINS 2,5 und 7 des PORTD. Gibt es irgendwelche dieser PINS welche ich ohne Voreinstellungen nicht benutzen kann? Wenn nicht, dass bin ich der Meinung, dass die PIN Belegung nicht das Problem ist. Was meint Ihr? Liebe Grüsse Roman
Roman schrieb: > Gibt es irgendwelche dieser PINS welche ich ohne Voreinstellungen nicht > benutzen kann? Wenn du den ISP Programmer zur Sicherheit auch noch abziehst, dann sollten da keine Probleme auftauchen. > Was meint Ihr? Das wahrscheinlichste ist, dass dein Timing nicht stimmt. LCD darf man nicht überfahren, d.h. zu schnell takten. FÜr alle Vorgänge gibt es Mindestzeiten, die einzuhalten sind. Langsamer ist kein Problem. Aber schneller als diese Mindestzeiten geht in die Hose.
Klappt das Programmieren? Stimmt die Quarzfrequenz? Programm hier mit angeben! Sind alle PINs als Output definiert? Ist ein einfacher Spannungswechsel an den LCD-Ports B mit dem Oszi nachweisbar? joe
ISP läuft auch über Port B. ISP-Kabel nach dem Programmieren entfernen! Joe
Hallo Karl Das mit dem ISP Kabel habe ich auch versucht, hat aber nichts gebracht. Meiner Meinung nach hat es auch etwas mit den Wartezeiten des LCDs zu tun. Das muss ja dann heissen, dass meine _delays im Programm falsch ausgeführt werden, sprich es stimmt etwas mit der Taktfrequenz nicht. Allerdings habe ich da alles soweit ich weiss richtig eingestellt. Wie gesagt im Makefile steht F_CPU 3686400 Im AVR Studio unter Board Settings steht bei Clock Generator 3.686 MHz Das Fuse Bit, welches die Taktquelle bestimmt habe ich auf EXTCLK_6CK_64ms gestellt, das heisst der Chip sollte genau die Frequenz des Clock Generators verwenden und alles sollte eigenlich gut gehen. Wie gesagt mit dem Atemga8515 funktioniert der LCD einwandfrei...
>Das Fuse Bit, welches die Taktquelle bestimmt habe ich auf >EXTCLK_6CK_64ms gestellt, das heisst der Chip sollte genau die Frequenz >des Clock Generators verwenden und alles sollte eigenlich gut gehen. Dummerweise hängt dein LCD Datenport aber an PB6, PB7. Das sind XTAL1 und XTAL2. An einem von den beiden wird der externe Clock eingespeist. Wie soll das gehen?
Roman schrieb: > EXTCLK_6CK_64ms gestellt, das heisst der Chip sollte genau die Frequenz 'sollte' ist schon mal schlecht. Tut er es oder tut er es nicht? Das sind deine einzigen 2 Möglichkeiten - aber kein sollte. Wenn du nicht sicher bist, dann teste es eben! SChreib dir ein Programm, welches mit _delay_ms eine LED blinkt (zb 1 Sekunde an, 1 Sekunde aus). Da _delay_ms von der korrekten einstellung der Taktfrequenz abhängt, kannst du sehen, ob der µC mit 3.irgendwas Mhz läuft oder nicht. Entweder ein _delay_ms(1000) dauert 1 Sekunde oder er tut es nicht. Wobei du nicht auf Zehntel-Sekunden schielen musst, denn du hast sowieso nur 3.irgendwas Mhz und 1Mhz zur Auswahl. Das ist ein Faktor von 3. Und 1 Sekunde von 1/3 Sekunde oder von 3 Sekunden zu unterscheiden, dazu braucht man kein Messgerät.
Hi
>Ich benutze für den LCD nur PORT B (Daten) und PORTD (Control).
PB6 Ist in deinem Fall der Takteingang des Controllers.
MfG Spess
Im Anhang ist noch mein C code und das Makefile, welches ich benutze. Die Initialisierung habe ich in der Funktion LCD_Init() vorgenommen. Ich weiss, ich habe dort nicht sehr viel kommentiert, aber ich habe die Befehle laut dem Datenblatt des LCD geschrieben und mit dem anderen Chip klappt ja alles. Ich denke also am Code sollte es nicht liegen.
Spess53 schrieb: > Hi > >>Ich benutze für den LCD nur PORT B (Daten) und PORTD (Control). > > PB6 Ist in deinem Fall der Takteingang des Controllers. Mist. Daran hab ich natürlich wieder mal nicht gedacht.
Hi
>Im Anhang ist noch mein C code und das Makefile, welches ich benutze.
Kapiere es doch mal: Mindestens ein Pin von PortB ist vom Takteingang
belegt.
MfG Spess
@ Karl Ich habe die Richtigkeit der Frequenz schon mit einem LED getestet. Das LED blinkt bei _delay_ms(1000) schön im Sekundentakt so wie es sollte. Ich bin mir deswegen eigentlich sicher, dass die Frequenz stimmt.
@ Spess Wenn ich dich richtig verstehe, dann darf ich nicht den gesammten PORTB für die Datenübertragung verwenden, da ein Pin für die Taktversorgung des Chips dient? Das heisst, ich benutze anstatt des PIN 6 vom Port B einen anderen?
Hi
>Das heisst, ich benutze anstatt des PIN 6 vom Port B einen anderen?
Ja. Ist natürlich etwas Bitschubsen nötig.
MfG Spess
Ok, vielen Dank, das werde ich mal versuchen. Ich sehe gerade, dass bei dem Atemga8515 der PIN B6 NICHT für den Taktgenerator reserviert ist und daraus schliesse ich jetzt, dass darum mit dem Atmega8515 alles geklappt hat. Schon wieder was neues gelernt... Danke an alle, die sich die Zeit zum Schreiben genommen haben und besonderen Dank an Spess ;-) lG Roman
Hi >Danke an alle, die sich die Zeit zum Schreiben genommen haben und >besonderen Dank an Spess ;-) Eigentlich war Holger schneller: Beitrag "Re: LCD funktioniert nach Wechsel von Atmega8515L auf Atmega8 nicht mehr" Hast du wahrscheinlich nicht gelesen. MfG Spess
Ok, das stimmt...Also besten Dank auch an Holger!!!
Jetzt habe ich trotzdem noch eine kleine Frage. Muss ich den die PINB6 und PINB7 mit irgendwas verbinden, oder wird das intern im STK 500 board durch den XTAL jumber schon erledigt. Irgendwie muss ja der Takt des Clock Generators an den Controller kommen. Ich schliesse allerdings aus dem erfolgreichen Laufen des LED- Blinkprogramms, dass der Takt intern eingespeist wird, da das Programm sonst nicht laufen könnte. Liege ich da richtig?
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.