www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik C und LCD Frage.


Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus Leutz,

da ich eine Cam ansprechen muss, muss ich zwangsweise von Bascom auf C 
ausweichen.
Nun gehts mir darum ich schau mir grad die LCD-Lib von Peter Fleury an.
Er hat, so wie auch viele Beispiele die ich gefunden hab, RW aufn 
Controller mit drauf. Leider hab ich platzmässig Probleme da die Kamera 
schon extrem viel Pins belegt. Deshalb will ich mir das RW sparen. 
Brauchst bei Bascom ja auch net...*g*
Kann statt der Abfrage fürs Busy-Flag einfach ne Pause von wegen meiner 
50µ Sekunden machen? Halt sowas in der Art...

MfG
Matthias

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Matthias (Gast)

>Kann statt der Abfrage fürs Busy-Flag einfach ne Pause von wegen meiner
>50µ Sekunden machen? Halt sowas in der Art...

Ja, dann musst du aber ntweder die Bibliothek anpassen oder eine andere 
nehmen. Z.B. die hier.

http://www.mikrocontroller.net/articles/AVR-GCC-Tu...

MfG
Falk

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> @ Matthias (Gast)
>
>>Kann statt der Abfrage fürs Busy-Flag einfach ne Pause von wegen meiner
>>50µ Sekunden machen? Halt sowas in der Art...
>
> Ja, dann musst du aber ntweder die Bibliothek anpassen

Die Anpassung ist aber nicht viel Arbeit.
Peter Fleury hat hier schon vorgearbeitet. Das warten auf
das Busy Flag ist in einer einzigen Funktion gekapselt.
Dort einfach die Abfrage gegen eine Warterei austauschen
und die Sache ist gegessen.

Peter: Wenn du mitliest. Das wär doch mal was für einen
Konfigurations #define

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus,

Anpassen ist dann wohl kein Problem. Gut soweit...

Dank dir.

MfG
Matthias

Autor: TOM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> muss ich zwangsweise von Bascom auf C ausweichen.

Sehe es positiv, ist doch ein Fortschritt

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus,

Fortschritt...naja ich weis mal nicht.
Musste grad feststellen, dass die Lib von Peter nicht damit klarkommt, 
das ich zwischen den Datenleitungen noch einen Eingang fürn AD Wandler 
hab...sprich zwischen DB4 und 5 liegt ein AD Eingang und dann kommt erst 
wieder DB6 und 7. Damit haut die Zuweisung mit den Bits im LCD_Write 
nicht hin.

Ich hab etz genau 2 Möglichkeiten...entweder die Schaltung wieder 
komplett zu zerreissen oder die ganze Routine Umbaun...fragt sich nur 
was schneller ist...

MfG

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo liegt denn der AD Eingang, auf DB viereinhalb?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias wrote:

> Musste grad feststellen, dass die Lib von Peter nicht damit klarkommt,
> das ich zwischen den Datenleitungen noch einen Eingang fürn AD Wandler
> hab...sprich zwischen DB4 und 5 liegt ein AD Eingang und dann kommt erst
> wieder DB6 und 7. Damit haut die Zuweisung mit den Bits im LCD_Write
> nicht hin.

Alles kein Problem.

Ich mache auch erst das Layout und dann muß die Software sehen, wie sie 
das wieder zurechtwurschtelt.

Hier ein LCD-Treiber, der jeden Pin benutzen kann:

Beitrag "LCD Treiber Routine 4*40"

Nur in der Initialisierung setze ich das DDR-Register zusammen für alle 
Pins.
Man muß dann eben die DDR-Bits einzeln setzen, wenn die Ausgänge auf 
verschiedenen Ports liegen.


Peter

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus,

nix 4,5.
db4 = Pin36
db5 = Pin37
db6 = Pin39
db7 = Pin40

E = Pin35
RS = Pin34

RW = GND

Pin38 fürn AD Wandler...also liegt er zwischen den Datenleitungen.

Vorhin hatte ich mal ne Anzeige von 1 und 2 in der jeweiligen Zeile.
Jetzt hab ich mal die Wartezeit in der lcd_waitbusy geändert...Ich 
versteh noch net 100 pro wie die ganze Lib funkt aber Teilweise.

Wie lange sollte ich warten, da ich RW nicht abfragen kann?

static uint8_t lcd_waitbusy(void)

{
  delay(16000);       /* wait 16ms*/
  delay(16000);
  delay(16000);
  delay(16000);

    register uint8_t c;

    /* wait until busy flag is cleared */
    c=lcd_read(0);

    /* the address counter is updated 4us after the busy flag is cleared 
*/
    delay(2);

    /* now read the address counter */
    return (lcd_read(0));  // return address counter

}/* lcd_waitbusy */

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias wrote:
>
> Wie lange sollte ich warten, da ich RW nicht abfragen kann?

Fang mit ein paar ms an, und versuch einfach wie weit du
die Zeit zurückdrehen kannst. Dann noch, vielleicht 10%
wieder länger machen und gut ists.

Wenn ich mich recht erinnere ist 'Display löschen' eine
Operation die ineterssanter Weise relativ lange dauert.
D.h. wenn das Display nicht mehr gelöscht wird, dann war
die Zeit zu kurz.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Peter Dannegger (peda)

>Ich mache auch erst das Layout und dann muß die Software sehen, wie sie
>das wieder zurechtwurschtelt.

Sehr intelligent. Scheuklappen auf, Kopf runter und durch die Wand.

Ich überlege mir vorher, wie es sowohl für Layout UND Software günstig 
ist, ggf. wird noch mal was gewechselt. Denn wenn man hinterher ein 8 
Bit-Port auf auf drei Ports verteilt hat wird das "lustig". Aufwand 
hoch, Performance runter.

@   Karl heinz Buchegger (kbuchegg)

>Wenn ich mich recht erinnere ist 'Display löschen' eine
>Operation die ineterssanter Weise relativ lange dauert.
>D.h. wenn das Display nicht mehr gelöscht wird, dann war
>die Zeit zu kurz.

Datenblätter sind auch schon erfunden worden.

http://www.mikrocontroller.net/articles/AVR-GCC-Tu...
AVR-Tutorial: LCD

CLEAR und HOME brauchen 1.64 ms laut Datenblatt der gängigen HD44780er 
LCD Controller. Alle anderen Befehle 40 us.

MFG
Falk

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:

> Ich überlege mir vorher, wie es sowohl für Layout UND Software günstig
> ist, ggf. wird noch mal was gewechselt. Denn wenn man hinterher ein 8
> Bit-Port auf auf drei Ports verteilt hat wird das "lustig". Aufwand
> hoch, Performance runter.


Oje, ob ein Byte schreiben nun 40 oder 41µs dauert, ist natürlich ein 
absolut unverantwortbarer Performanceeinbruch!
Und ein Clear würde sogar von 1.640ms auf riesige 1.641ms ansteigen!

Man muß auch mal auf dem Teppich bleiben.

Datenblatt lesen setze ich voraus, Pins ohne Sonderfunktion lassen sich 
in der Regel ohne merkbaren Performanceverlust vertauschen. Ein LCD ist 
ja doch sehr langsam.
Das Beispiel soll auch zeigen, daß man sowas trotzdem gut lesbar coden 
kann (mit Bitvariablen).

Einen Ethernetcontroller mit erheblich mehr Traffic schließt man 
natürlich richtig und memory mapped an.


Peter

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Peter Dannegger (peda)

>Oje, ob ein Byte schreiben nun 40 oder 41µs dauert, ist natürlich ein
>absolut unverantwortbarer Performanceeinbruch!
>Und ein Clear würde sogar von 1.640ms auf riesige 1.641ms ansteigen!

Falsch, deine Aussage war allgemein gefasst und damit kritikwürdig.

"Ich mache auch erst das Layout und dann muß die Software sehen, wie sie
das wieder zurechtwurschtelt."

>Man muß auch mal auf dem Teppich bleiben.

Bin ich ;-)

>Datenblatt lesen setze ich voraus, Pins ohne Sonderfunktion lassen sich
>in der Regel ohne merkbaren Performanceverlust vertauschen. Ein LCD ist
>ja doch sehr langsam.

In diesem Fall ja. Allgemein, nein.

>Einen Ethernetcontroller mit erheblich mehr Traffic schließt man
>natürlich richtig und memory mapped an.

Darauf wollte ich hinaus.

MFg
Falk

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus

erstens kommt es anders und zweitens als man denkt.

Von der Kamera war anfangs keine Rede und jetzt hab ich den 
Salat...sprich ich muss zum laufen kriegen.
Zeitplan ist bis Ende des Jahres müssen Schaltung und die Software 
Rechnerseitig laufen...koste es was es wolle an 
(Arbeitsstundentechnisch).

Geäzt wird erst wenn der Mist fertig ist, wenn überhaupt...

Jedenfalls funkt das Display momentan nur mit Bascom noch net mit C (OK 
das Clear geht aber mehr nicht).
Ich mach aber erstmal die anderen Sachen bevor ich ans Display gehe, vll 
fällt mir der Fehler dann gleich ins Auge...
Die digitalen Zustände krieg ich ja schon hin, aber etz kommt der 
AD-Wandler...

Ausserdem sollte ich noch sagen das ich bisher mit C auf Controllern 
noch nix am Hut hatte und jetzt ins sprichwörtliche kalte Wasser 
geworfen wurde. Beim Softwareproggen tut man sich halt sehr viel 
leichter als bei Controllern, da das Debuggen wegfällt. Entweder es geht 
oder geht nicht...

MfG
Matthias

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias wrote:

> Jedenfalls funkt das Display momentan nur mit Bascom noch net mit C (OK
> das Clear geht aber mehr nicht).

Dann würde ich Dir raten, ertmal die ganzen ifdefs für andere Displays 
und Zugriffsarten rauszuschmeißen, damit der Text lesbarer und 
verstehbarer wird.

Und die ganzen BV-Macros verursachen bei mir auch immer Kopfschmerzen. 
Die sollte man auf Bitzugriffe umschreiben.

Danach sollte sich Dein Problem wesentlich schneller finden lassen.


> Beim Softwareproggen tut man sich halt sehr viel
> leichter als bei Controllern, da das Debuggen wegfällt. Entweder es geht
> oder geht nicht...

Gerade deshalb sollten LCD oder UART als erstes laufen, damit man sich 
damit Statusmeldungen ausgeben lassen kann.
Sonst ist man ja richtig blind und der MC ein versiegelter Tresor


Peter

Autor: Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Musste grad feststellen, dass die Lib von Peter nicht damit klarkommt,
>das ich zwischen den Datenleitungen noch einen Eingang fürn AD Wandler
>hab...sprich zwischen DB4 und 5 liegt ein AD Eingang und dann kommt erst
>wieder DB6 und 7. Damit haut die Zuweisung mit den Bits im LCD_Write
>nicht hin.

und was sollte da nicht gehen?
die Bits lassen sich doch sogar auf verschiedene Ports verteilen.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus,

weil mein Compiler wegen den meisten Befehlen meckert...
z.B.
DDR(LCD_PORT)
Für meinen Compiler unbekannt.
AVR Studio mit AVR GCC.


@Peter
Uart läuft sogar schon über mein BT modul...er läuft auch durch die 
Funktionen, aber irgendwie krieg ichs net hin...
Problem ist das ich net 100 Pro weis was ich in den Defs verändern muss.
Die Pins auf meine legen is klar, LCD größe einstellen auch.
ABER was ist ein WRAP? Ich habs mal auf 0 gelassen, da von Zeilenumbruch 
nix in meinem Display stand.

#define LCD_LINE_LENGTH  0x40     /**< internal line length of the 
display    */
Ich habs mal so gelassen, da die Adress die danach kommen mit meinem 
übereinstimmen.

#define LCD_IO_MODE      1
Hab ich auch so gelassen da ich ja im 4bit modus ran will ans Display.

Auch fragt Peter öfters das Busyflag ab, aber ich hab halt keins...

MfG
Matthias

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus,

weil mein Compiler wegen den meisten Befehlen meckert...
z.B.
DDR(LCD_PORT)
Für meinen Compiler unbekannt.
AVR Studio mit AVR GCC.


@Peter
Uart läuft sogar schon über mein BT modul...er läuft auch durch die 
Funktionen, aber irgendwie krieg ichs net hin...
Problem ist das ich net 100 Pro weis was ich in den Defs verändern muss.
Die Pins auf meine legen is klar, LCD größe einstellen auch.
ABER was ist ein WRAP? Ich habs mal auf 0 gelassen, da von Zeilenumbruch 
nix in meinem Display stand.

#define LCD_LINE_LENGTH  0x40     /**< internal line length of the 
display    */
Ich habs mal so gelassen, da die Adress die danach kommen mit meinem 
übereinstimmen.

#define LCD_IO_MODE      1
Hab ich auch so gelassen da ich ja im 4bit modus ran will ans Display.

Auch fragt Peter öfters das Busyflag ab, aber ich hab halt keins...

Blöde Frage kann die überhaupt ein 4 Zeilen ansprechen wenn ich in da 
lcd.h  sowas lese?

#if LCD_LINES==1
#define LCD_FUNCTION_DEFAULT    LCD_FUNCTION_4BIT_1LINE
#else
#define LCD_FUNCTION_DEFAULT    LCD_FUNCTION_4BIT_2LINES
#endif
#else
#if LCD_LINES==1
#define LCD_FUNCTION_DEFAULT    LCD_FUNCTION_8BIT_1LINE
#else
#define LCD_FUNCTION_DEFAULT    LCD_FUNCTION_8BIT_2LINES
#endif

MfG
Matthias

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias wrote:
> Servus,
>
> weil mein Compiler wegen den meisten Befehlen meckert...
> z.B.
> DDR(LCD_PORT)
> Für meinen Compiler unbekannt.
> AVR Studio mit AVR GCC.

Wie lautet die Fehlermeldung

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger wrote:

> Wie lautet die Fehlermeldung

"Mecker in File unbekannt an Zeile unbekannt wegen sag ich nicht"

:-)


Peter

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Use DDR like a funktion...so ähnlich jedenfalls.
Was mich nur wundert beim original File gings Compilieren, aber seit ich 
was geändert hab eben nicht mehr...vll irgendwo ne Klammer vergessen zu 
löschen oder zu viel gelöscht...
Langsam weis ich auch nicht mehr weiter.

Ich klemm jetzt mal den RW noch mit an und schau obs damit geht...und 
lass das File von Peter mal so wies ist ausser das ich meine Pins und 
die Zeilenzahl des Display anpasse...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias wrote:
> Use DDR like a funktion...so ähnlich jedenfalls.

Quatsch, Function.
Das ist ein Makro, dem die Registeradresse übergeben wird.
Das ist alles.

> Was mich nur wundert beim original File gings Compilieren, aber seit ich
> was geändert hab eben nicht mehr...vll irgendwo ne Klammer vergessen zu
> löschen oder zu viel gelöscht...

Auch immer wieder beliebt: Ein ';' wo er nicht hingehört

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tjo ein Grund warum ich C nicht grad liebe, aber seis drum.

Selbst mit RW am Controller und Originalfile geht nüschts.
Die Pins, Taktrate und Größe des Displays sind eingegeben...

Langsam aber sicher verzweifle ich...*heul*

Hab den AD Wandler sogar zum Laufen gebracht aber ein sch*** LCD will 
mich net...*g*

Langsam aber sicher Raff ich ja das meiste von Peters Quellcode. Viel is 
drin ums Variabl zu gestalten...aber selbst wenn ich das was ich net 
brauch wie die Ansteuerung im Memorymode und den anderen Controller 
rausschmeiss...hilft auch nix. Auch wenn ich die If-Anweisungen auf die 
Möglichkeiten reduzier die mich betreffen...keine Reaktion.

Initialisieren tut er wohl richtig, da die Balken verschwinden...aber er 
schreibt einfach nix raus.

Gibts da noch irgendwelche Anfängerfehler wo ich z.B. noch was vergessen 
haben könnte einzustellen?

Ich hab auch irgendwo hier im GCC- Tutorial gesehen das man die 
Optimierung des Codes einschalten sollte. Aber wo schaltet man die im 
AVR-Studio ein...hab nämlich bisher noch nirgens was gefunden.

MfG
Matthias
(FlascheGlühweinaufmach)

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaub ich habs die Optimierung gefunden blos welche sollte ich 
nehmen?

The current levels of optimization are:

-O0 No optimization. This is the same as not specifying any 
optimization.

-01 Optimize. Reduces code size and execution time without performing 
any optimizations that take a great deal of compilation time.

-O2 Optimize even more. avr-gcc performs almost all optimizations that 
don't involve a space-time tradeoff.

-O3 Optimize yet more. This level performs all optimizations at -O2 
along with -finline-functions and -frename-registers.

-Os Optimize for size. Enables all -O2 optimizations that don't increase 
code size. It also performs further optimizations designed to reduce 
code size.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias wrote:
> Langsam aber sicher verzweifle ich...*heul*


Probier doch mal meinen Code, er ist so schön minimalistisch.

Die Defines müßten so stimmen:
#define LCD_LINES       0x7B            // PA0,PA1,PA3..PA6
#define LCD_PORT        PORTA
#define LCD_DDR         DDRA

#define LCD_D4  SBIT( LCD_PORT, 4 )
#define LCD_D5  SBIT( LCD_PORT, 3 )
#define LCD_D6  SBIT( LCD_PORT, 1 )
#define LCD_D7  SBIT( LCD_PORT, 0 )
#define LCD_RS  SBIT( LCD_PORT, 6 )
#define LCD_E0  SBIT( LCD_PORT, 5 )

Und die Zeilen bezüglich LCD_E1 schmeiß raus


Peter

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja also bei mir siehts im Header so aus...
*---------------------------------------------------------------------
#define LCD_PORT         PORTA        /**< port for the LCD lines   */
#define LCD_DATA0_PORT   LCD_PORT     /**< port for 4bit data bit 0 */
#define LCD_DATA1_PORT   LCD_PORT     /**< port for 4bit data bit 1 */
#define LCD_DATA2_PORT   LCD_PORT     /**< port for 4bit data bit 2 */
#define LCD_DATA3_PORT   LCD_PORT     /**< port for 4bit data bit 3 */
#define LCD_DATA0_PIN    4            /**< pin for 4bit data bit 0  */
#define LCD_DATA1_PIN    5            /**< pin for 4bit data bit 1  */
#define LCD_DATA2_PIN    1            /**< pin for 4bit data bit 2  */
#define LCD_DATA3_PIN    0            /**< pin for 4bit data bit 3  */
#define LCD_RS_PORT      LCD_PORT     /**< port for RS line         */
#define LCD_RS_PIN       6            /**< pin  for RS line         */
#define LCD_RW_PORT      LCD_PORT     /**< port for RW line         */
#define LCD_RW_PIN       7            /**< pin  for RW line         */
#define LCD_E_PORT       LCD_PORT     /**< port for Enable line     */
#define LCD_E_PIN        5            /**< pin  for Enable line     */
*----------------------------------------------------------------------

LCD_E1 gibts bei mir nicht...

Kann es sein das wir unterschiedliche Versionen von der Lib haben?
Denn später greift Peter ständig auf die defines zu...wie z.B.

*----------------------------------------------------------------------
/* configure all port bits as output (LCD data and control lines on 
different ports */
        DDR(LCD_RS_PORT)    |= _BV(LCD_RS_PIN);
        DDR(LCD_RW_PORT)    |= _BV(LCD_RW_PIN);
        DDR(LCD_E_PORT)     |= _BV(LCD_E_PIN);
        DDR(LCD_DATA0_PORT) |= _BV(LCD_DATA0_PIN);
        DDR(LCD_DATA1_PORT) |= _BV(LCD_DATA1_PIN);
        DDR(LCD_DATA2_PORT) |= _BV(LCD_DATA2_PIN);
        DDR(LCD_DATA3_PORT) |= _BV(LCD_DATA3_PIN);
*----------------------------------------------------------------------

Und es stimmt deiner is minimalistisch...*g*

Danke soweit jedenfalls.
Matthias

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias wrote:

> Kann es sein das wir unterschiedliche Versionen von der Lib haben?
> Denn später greift Peter ständig auf die defines zu...wie z.B.

Ich meinte diese Lib:

Beitrag "LCD Treiber Routine 4*40"


Peter

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#define LCD_DATA1_PIN    5            /**< pin for 4bit data bit 1  */
#define LCD_E_PIN        5            /**< pin  for Enable line     */


Das wird wohl nicht so gut kommen, wenn du die Enable Leitung
und den Data Pin 1 auf den selben Output legst.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da du anscheind immer noch versuchst die Fleury Lib hinzukriegen,
mal ein Vorschlag:

Mach ein Testprojekt:

Dein main sieht so aus
int main(void)
{

    /* initialize display, cursor off */
    lcd_init(LCD_DISP_ON);

    /* clear display and home cursor */
    lcd_clrscr();
    
    /* put string to display (line 1) with linefeed */
    lcd_puts("LCD Test Line 1\n");
}

dann nimmst du die Originale vom Fleury und änderst vorsichtig
im Headerfile deine Konfiguration. Allem anschein nach, kannst du
RW vom LCD benutzbar machen (wenn auch nur temporär). Tu es!
Benutze RW, damit du erst mal nicht am Code ändern musst. Zur Zeit
ist es wichtiger das LCD mal überhaupt zum Laufen zu bekommen.

Du stellst ein
LCD_LINES
LCD_DISP_LENGTH
LCD_PORT + die ganzen Leitungsdefinitionen

LCD_CONTROLLER_KS0073 kontrollierst du, ob es auf 0 steht
LCD_WRAP_LINES        kontrollierst du, ob es auf 0 steht
LCD_IO_MODE           kontrollierst du, ob es auf 1 steht

Compilieren, linken und laufen lassen.
Das LCD müsste laufen.

Und erst jetzt fängst du an, die lcd_waitbusy umzuändern.
Du musst dabei nicht übertreiben. Eine Wartezeit von 10ms ist mehr
als ausreichend, so dass du keinerlei Probleme kriegen wirst.
static uint8_t lcd_waitbusy(void)

{
  _delay_ms( 10 );

  return 0;
}

Den Header für die delay Routinen einbinden nicht vergessen.
Den Optimizer Switsch stellst du auf -Os.


Das Testprogramm neu kompilieren und nochmal testen. Muss immer
noch funktionieren.

Und erst jetzt baust du den ganzen Schmuss in dein eigentliches
Programm ein!

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ZONK!

#define LCD_DATA1_PIN    5            /**< pin for 4bit data bit 1  */
#define LCD_E_PIN        5            /**< pin  for Enable line     */

Klarer Bullshit von meiner Seite aus...O mann warum passiert immer mir 
so ein Bullshit!?!

So so siehts jetzt aus...

#define LCD_PORT         PORTA        /**< port for the LCD lines   */
#define LCD_DATA0_PORT   LCD_PORT     /**< port for 4bit data bit 0 */
#define LCD_DATA1_PORT   LCD_PORT     /**< port for 4bit data bit 1 */
#define LCD_DATA2_PORT   LCD_PORT     /**< port for 4bit data bit 2 */
#define LCD_DATA3_PORT   LCD_PORT     /**< port for 4bit data bit 3 */
#define LCD_DATA0_PIN    4            /**< pin for 4bit data bit 0  */
#define LCD_DATA1_PIN    3            /**< pin for 4bit data bit 1  */
#define LCD_DATA2_PIN    1            /**< pin for 4bit data bit 2  */
#define LCD_DATA3_PIN    0            /**< pin for 4bit data bit 3  */
#define LCD_RS_PORT      LCD_PORT     /**< port for RS line         */
#define LCD_RS_PIN       6            /**< pin  for RS line         */
#define LCD_RW_PORT      LCD_PORT     /**< port for RW line         */
#define LCD_RW_PIN       7            /**< pin  for RW line         */
#define LCD_E_PORT       LCD_PORT     /**< port for Enable line     */
#define LCD_E_PIN        5            /**< pin  for Enable line     */


Und O wunder entlich seh ich was am Display...

Ich glaub ich lass es jetzt mal so wies ist...ersteinmal...
Mit RW.

Hab die letzten 3 Tage schon beschissen geschlafen wegen dem ganzen und 
was weis ich noch was wie oft die Dateien umgeschrieben. Selbst im Traum 
dummkuck

Also dank dir nochmal Karl Heinz...warst ne grosse Hilfe!!!
Bin Heil froh das solche Foren und darin kompetente Leute gibt, denn 
sonst wäre ich aufgeschmissen.

Danke Nochmals...ich glaub wenn das Projekt Fertig ist schreib ich ein 
Buch und stells hier rein...samt Quellcode und Schaltplan...für die 
nächsten Dau`s.

MfG
Matthias (der sich etz a Flasche Wein aufmacht)

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P.S. Das Optimieren werd ich für meine Kameraansteuerung mal testen, 
denn da hab ich ein Timingproblem...vll hilfts

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.