Hi hätte da mal ein kleines Anfänger Problem. Habe mich für Bascom als Prog Sprache entschieden da ich damit sehr einfach meine sachen bis jetzt machen konnte. Nun wollte ich mich mal an das Thema LCD ran wagen und stehe jetzt vor einem Graben. Hab den LCD richtig angeschlossen aber sobald ich spannung auf die anlage gebe leuchtet zwar der lcd aber die erste zeile zeigt nix an und in der 2. Sind alle punke belegt. Kann mir wer sagen was da los ist? Ps: Mein Prog text ist als Dateianhang dabei.
"erste zeile zeigt nix an und in der 2. Sind alle punke belegt" Soweit ich weis, ist das die typische Situation eines nicht (nicht korrekt) initialisierten LCD Display. Kontrolliere die Schaltung (welche Portpins an Display angeschlossen sind).
Vielleicht betrachtest du ja das LCD auch verkehrt herum, denn bei einem noch nicht initialisierten Text-LCD ist üblicherweise die obere Zeile aktiviert. Fazit: Fehler in der Initialisierung (wie schon genannt). ...
Ich kann den Initialisierungsbefehl bei dir nicht finden... Nach "Config Lcdmode = Port" musst du noch ein "Initlcd" einfügen, damit das LCD erstmal initialiert wird. Meines Wissens sollte man vor dem Schreiben auf das LCD auch noch die Position angeben, also: Locate 1,1 Lcd "Hello World"
Nunja, Die Bascom LCD-Routine ist für den HD44780 Controller des LCD geschrieben. schau doch mal im Datenblatt deines LCD was da für einer drauf ist. "kompatibel 44780" hat dabei nicht viel zu heißen, die Initialisierung ist dann meist eben nicht kompatibel. Wenns kein 44780 ist brauchste ne entsprechende LIB um das Ding zum Laufen zu bekommen ...
Danke schonmal für die ganzen antworten. In der Beschreibung zu dem lcd steht irgendwas von "Pinbelegung EA W404B-NLW" ist das der Controller? Zur kontrolle ist die Beschreibung des Mircocontroller als Anhang beigefügt. Wenn das Ding nicht 44780 kompatibel ist wo bekomme ich dann die entsprechende lib her? Ist ein 0815 LCD. MFG Daniel
Ah ja, die EA-DIP-Serien Hab von EA auch eins verbaut, das 204, hat auch nix geklappt mit der HD44780 initialisierung. Das Ding soll zwar kompatibel sein, isses aber dann doch nicht so ganz, die Initialisierung ist anders irgendwo. Auch nicht zu vergessen, das Timing ist wichtig bei der Beschaltung. Hab mit ATMega16 und 32 getestet, wenn mit Bascom programmiert war bei 12MHz Takt des Mega Ende der Fahnenstange, darüber gab das Ding mitunter Mist aus. Aber das war ja nicht die Frage. hier hab ich mal beschrieben wie ich das Ding zum Laufen bekam. War aber wie gesagt ein anderes Display des Anbieters, aber die Lib kannste ja mit den Init-Befehlen Deines Displays modifizieren. http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=5810&highlight=
So hab mir mal 3 Stunden zeit genommen und so sieht jetzt der Programm Code aus: 'LCD Test '-------------------------------------------------------------- $regfile = "m8def.dat" 'ATMega 8L $crystal = 4000000 'Quarz: 4 MHz $lib "HomeCon_1.2.lib" Config Lcdpin = Pin , Db4 = Portd.5 , Db5 = Portd.4 , Db6 = Portd.3 , Db7 = Portd.2 , E = Portd.6 , Rs = Portd.7 Config Lcd = 16 * 2 Config Lcdbus = 4 Config Lcdmode = Port Initlcd ' LCD wird mit "_Init_Lcd" aus "HomeCon.lib" initialisieren Cls Display On Do Lcd "Test" Loop End die lib marko hab ich nach dem foren beitrag angepasst und als anhang hier daran nochmal mitgeschickt. Leider immer noch das gleiche problem. Jemand noch eine idee?
Keiner eine Idee na ja dann muss ich mir wohl nochmal ein lcd mit hd 44780 kompetible bestellen. Kennt jemand neen guten Hersteller?
Hi, wenn du die Lib verwendest solltest Du den Bus DB4 - DB7 herumdrehen, oder die Ausgaben in der Lib umdrehen, sonst passt das nicht. Der Port wird nämlich direkt beschrieben. Auch die Pinbelegung ist nicht so ganz wahlfrei, leider, es seidenn du bastelst ne komplett neue LIB
So hab den lcd jetzt zu laufen gebracht. Hab in Initalisiert und kann ihn auch per hand also nibbels einzeln auf die Ports legen ansteuern. Leider ist das sehr umständlich und ich brauche 4 Zeilen pro bustaben. Jetzt meine Frage: Wie kann ich jetzt den Bascom befehl "LCD" wieder benutzen. Wenn ich ihn benutze versucht er den HD478... zu initalisieren das geht naturlich nicht ist ja keiner drauf. Kann man das irgendwie lösen?
Ich hatte mir vor langer Zeit mal die BASCOM-Hilfe durchgelesen (ich dachte, ich könnte mich mit BASCOM anfreunden, kann ich aber nicht...). Ich glaube, mich zu erinnern, dass BASCOM mehrere LCD-Controller unterstützt. Vielleicht ist deiner ja dabei? Ansonsten hilft vielleicht eine Nachfrage beim Autor? ...
HanneS und was benutzt du jetzt? Denke immer mit bascom ist das ziel zum greifen nahe (AD-wandler ,lcd usw.) aber so einfach ist es mit bascom dann auch wieder nicht.
> HanneS und was benutzt du jetzt?... Ich benutze BASIC. Aber auf dem PC. Teils QB (eine QBASIC-Version mit Compiler), teils VB6. Auf dem AVR nutze ich AVR-Studio und schreibe in AVR-Assembler. Denn direkt an der Hardware ist das meiner Meinung nach übersichtlicher. Den Aufbau der Hardware und den jeweils gültigen Befehlssatz entnehme ich dem jeweiligen Datenblatt. Bei Unsicherheiten bei den Befehlen hilft das Instruction-Set (PDF) oder die Online-Hilfe des AVR-Studios (Cursor auf Befehl, dann F1, wie auch bei QBASIC und VB üblich). Einige Tricks kann man sich in den ATMEL-Appnotes, den Datenblättern und hier im Forum abgucken. Das Wichtigste an der Programmierung ist aber sicher nicht die Sprache, sondern der logische Aufbau des Programms. Wer z.B. Interrupts meidet, wie der Teufel das Weihwasser, der wird auch in ASM die meiste Zeit in irgendwelchen Warteschleifen herumhängen... Ich hatte mich mal mit BASCOM beschäftigt, einige Beispiele angesehen, einige eigene kleine Dinge programmiert und mir das Ergebnis disassembliert und in ASM angesehen. Was ich da sah, war grausam. Wenn ich dafür auch noch Geld bezahlen soll, um eine Vollversion zu bekommen, tut mir leid, da kann ich drauf verzichten. Nun waren meine ersten Projekte auch noch ohne LCD und RS232. Ich brauchte daher keine speziellen Bibliotheken. Inzwischen nutze ich auch LCDs, habe mir für bisher 4 verschiedene LCDs die Treiberroutinen zusammengestellt. 3 davon muss ich noch verbessern, das 8x24 mit Controller MS50530 funktioniert inzwischen recht gut. Die Ausgabe erfolgt über Ringbuffer im Hintergrund, synchronisiert durch einen Timer-Interrupt. Diese Variante belastet den Controller am wenigsten. Du erwähnst den ADC als besonderes Feature von BASCOM. Das sehe ich anders. In ASM gibt es keine speziellen ADC-Befehle. Man muss nur mit den üblichen Befehlen (in, out...) die dementsprechenden Bits in den Steuerregistern setzen und kann dann bei Bedarf (im Vorbeigehen) adcl und adch (oder nur adch) auslesen ("in Register,adch"). Das ist sehr einfach und alle erforderlichen Informationen findet man in nur einer Quelle: dem Datenblatt des AVRs. Man ärgert sich nicht mit irgendwelchen Config-Anweisungen herum, sondern schreibt die dem Datenblatt entnommenen Werte in die angegebenen Register. Und man kann immer nachvollziehen was man macht, denn jeder ASM-Befehl entspricht exakt einem Maschinenbefehl. Eine Basic-Zeile kann dagegen schon etliche Maschinenbefehle erzeugen. Mit BASCOM hat man aufgrund der mitgelieferten Bibliotheken für LCD und andere Hardware den "schnellen Erfolg", wenn es aber mal etwas anders kommt, dann kommt man schnell ins Trudeln. In ASM hat man etwas mehr Schreib-Arbeit, aber dafür behält man die Übersicht über die Ressourcen und ist bedeutend flexibler. ...
Salut Hannes, Du hast schon recht, mit ASM hat man den direkten Überblick und weniger Code und kürzere Laufzeiten. Wenns aber nicht aufs Timing ankommt und ich auf die Schnelle n System auf die Füße stellen will sind mit GCC oder Bascom die Entwicklungzeiten schon deutlich kürzer. Ein Compiler kann niemals nen kürzeren Code als der von nem fähigen Programmierer der den Durchblick hat erzeugen. Ich arbeite gern mit Bascom aus eben dem Grund, dass eine Bascom Zeile mitunter 10 ASM-Befehle ergibt. Verhältnis 1:10 an Arbeit ;o)
> Wenns aber nicht aufs Timing ankommt und ich auf die Schnelle > n System auf die Füße stellen will sind mit GCC oder Bascom > die Entwicklungzeiten schon deutlich kürzer. Das werde ich niemals abstreiten. Wenn man mit einer Hochsprache richtig umgehen kann, dann arbeitet man damit bedeutend effizienter (Arbeitszeit betreffend) als mit Assembler. Wer mit Programmierung seine Brötchen verdienen muss, der kommt ohne Hochsprache nicht aus. ASM-Kenntnisse haben aber noch Niemandem geschadet. So ziemlich jeder ernstzunehmende C-Programmierer ist in der Lage, einen ASM-Code zu lesen und zeitkritische Teile in ASM zu schreiben. Das "schlimme" an BASCOM ist ja nicht BASCOM, sondern die Tatsache, dass viele Einsteiger meinen, sich durch das Verwenden von BASCOM den Blick in das Datenblatt sparen zu können. So nach dem Motto: BASIC kann ich ja. Wer sich intensiv mit BASCOM befasst und in der Lage ist, an kritischen Stellen ASM einzubinden, der kann damit viel erreichen. Aber meist wird BASCOM nur als ein Baukasten benutzt. Die vorgefertigten Standardroutinen (Bibliotheken) ermöglichen ja schnelle Erfolge. Das Verstecken des ASM-Codes führt dazu, sich nicht weiter um das compilierte Ergebnis zu kümmern. Und ist dann eine Hardware (LCD) mal etwas anders, dann steht man auf dem Schlauch. Ich bin jedenfalls nicht bereit, dafür Geld auszugeben. Und mit einer "gestohlenen Version" möchte ich auch nicht arbeiten. Es kommt aber auch darauf an, ob die Projekte überhaupt BASCOM-tauglich sind. Meine ersten Projekte (mit AT90S1200, Tiny12, Tiny15) hatten hauptsächlich mit Impulsverarbeitung zu tun (Impulsbreiten messen, Software-PWM erzeugen, Schaltfunktionen auslösen...). Da hätten mir die BASCOM-Bausteine sowiso nix genützt. Zumindest hätte es Ressourcenkonflikte gegeben, da BASCOM die verfügbaren Hardwareressourcen recht eigenwillig benutzt. Hätten meine ersten Projekte den Schwerpunkt auf ADC, Wert umrechnen, Anzeige am LCD, Überwachen von Grenzwerten, Schalten von Alarm, Kommunikation mit dem PC, usw. gehabt, dann wäre die Chance, dass ich mit BASCOM beginne, vermutlich etwas höher gewesen. Aber so wie es ist, ist es schon gut. Und wenn jemand mit BASCOM seine Projekte realisieren kann, dann soll er es tun. Ich habe nix dagegen. Nur sollte er dann nicht rummaulen, wenn mal etwas nicht so geht... Bit- & Bytebruch... ...HanneS...
>Nur sollte er dann
nicht rummaulen, wenn mal etwas nicht so geht...
Hab nicht gemault wollte nur wissen ob es da nee lösung gibt. Die Lib
die ich von marko bekommen habe ist komplett in ASM hab damit kein
Prob. Ist halt wie schon gesagt wurde ein bissl mehr schreib arbeit.
ASM ist und bleibt die mutter aller hochsprachen.
Hab das jetzt auch im mom über ASM gelöst aber wenn ich halt mal den
Text auf dem LCD ändern will muss ich jedes mal gleich z.b. 50 Zeilen
umschreiben da wegen der Bit folge. Dachte halt das das andere leute
evtl. einfacher machen oder schreiben die dann auch immer den ganzen
code um?
Du musst den Code nicht ändern, wenn du nur den Text ändern willst. Auch in ASM kann man sich Routinen schreiben, die man dann wie BASIC aufrufen kann. Schau dir mal hier: http://www.mikrocontroller.net/forum/read-1-262112.html#262226 das Programm an, wie einfach die LCD-Ausgabe erfolgt. Im darauf folgenden Beitrag findest du die (vorläufige) Routinensammlung zur Ausgabe von Zahlen und Text, noch einen Beitrag weiter die Routinen zum Ansteuern des LCDs (Treiber). Die Print-Sammlung ist im Laufe der Zeit entstanden und wird ggf. an neue Bedürfnisse angepasst. So ist in der hier gezeigten Version die Führungsnull-Unterdrückung bei der 8-Bit-Zahlenausgabe deaktiviert (auskommentiert). Dann gibt es eine Zahlenausgabe (printzt), die im Kopf der Datei nicht aufgelistet ist, damit wird eine 16-Bit-Zahl (2 Register), die Sekunden hochzählt, als Zeitstring (hh:mm:ss) ausgegeben. Jedenfalls ist damit die Ausgabe in ASM recht einfach. Mit locate wählt man die Ausgabeposition, mit den verschiedenen print-Makros kann man Zahlen formatiert ausgeben sowie ganze Strings (Text) und sogar indizierte Strings (Menüpunkte, Wochentage) anhand der Indexnummer. Gut, beim Erstellen der Texte und Tabellen muss man etwas aufpassen, aber das funktioniert recht gut und braucht recht wenig Ressourcen. Das mit dem "rummaulen" sieh mal nicht so persönlich. Schau dir an, welche Probleme es hier im Forum innerhalb der letzten Jahre mit BASCOM gab, dann weißt du, wie ich das meine. Da wurde sogar schon "rumgemault", dass der (übertaktete) Mega128 seine Arbeit unter BASCOM nicht schafft. Nunja, mit WAITxyz schreibt man keine effizienten Programme, auch nicht in ASM. Also:Frohes Schaffen noch... - Und einen schönen zweiten Advent... ...
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.