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
@ 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-Tutorial#LCD-Ansteuerung MfG Falk
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
Servus, Anpassen ist dann wohl kein Problem. Gut soweit... Dank dir. MfG Matthias
>> muss ich zwangsweise von Bascom auf C ausweichen.
Sehe es positiv, ist doch ein Fortschritt
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
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
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 */
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.
@ 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-Tutorial#Programmierung 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
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
@ 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
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
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
>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.
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
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
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
Karl heinz Buchegger wrote:
> Wie lautet die Fehlermeldung
"Mecker in File unbekannt an Zeile unbekannt wegen sag ich nicht"
:-)
Peter
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...
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
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)
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.
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:1 | #define LCD_LINES 0x7B // PA0,PA1,PA3..PA6
|
2 | #define LCD_PORT PORTA
|
3 | #define LCD_DDR DDRA
|
4 | |
5 | #define LCD_D4 SBIT( LCD_PORT, 4 )
|
6 | #define LCD_D5 SBIT( LCD_PORT, 3 )
|
7 | #define LCD_D6 SBIT( LCD_PORT, 1 )
|
8 | #define LCD_D7 SBIT( LCD_PORT, 0 )
|
9 | #define LCD_RS SBIT( LCD_PORT, 6 )
|
10 | #define LCD_E0 SBIT( LCD_PORT, 5 )
|
Und die Zeilen bezüglich LCD_E1 schmeiß raus Peter
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
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
#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.
Da du anscheind immer noch versuchst die Fleury Lib hinzukriegen, mal ein Vorschlag: Mach ein Testprojekt: Dein main sieht so aus
1 | int main(void) |
2 | {
|
3 | |
4 | /* initialize display, cursor off */
|
5 | lcd_init(LCD_DISP_ON); |
6 | |
7 | /* clear display and home cursor */
|
8 | lcd_clrscr(); |
9 | |
10 | /* put string to display (line 1) with linefeed */
|
11 | lcd_puts("LCD Test Line 1\n"); |
12 | }
|
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.
1 | static uint8_t lcd_waitbusy(void) |
2 | |
3 | {
|
4 | _delay_ms( 10 ); |
5 | |
6 | return 0; |
7 | }
|
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!
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)
P.S. Das Optimieren werd ich für meine Kameraansteuerung mal testen, denn da hab ich ein Timingproblem...vll hilfts
Thread beobachten
Seitenaufteilung abschaltenBitte 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.