Hallo, ich habe ein LCD (16x2, HD44780-kompatibel) an einen Atmega 168, Port C, angeschlossen und ein winziges Bascom-Hello-World-Programm geladen. Es tut sich aber nichts. Aufällig war übrigens, daß ich zunächst vergessen hatte, die RS-Leitung an den µC anzuschließen. Auf diese Weise konnte ich wenigstens den Kontrast einstellen, d.h. wenn ich an dem 10-K-Trimmer die Spannung auf ca. 0,5 V absenkte sah ich eine (die obere) Zeile mit allen Punkten. Nachdem ich die fehlende RS-Leitung angeschlossen habe sehe ich garnichts mehr, weder Kontrast noch Text. Hat jemand eine Idee ? Ist etwas dagegen einzuwenden, das LCD an Port C des Atmega 168 anzuschließen ? Gruß Tilmann
Angehängte Dateien:
Es ist keine gute Idee, den Reset-Pin des AtMega zu belegen, wenn noch genug andere Pins frei sind...
Ähm - du hast den Display-Reset an den Atmega-Reset angeschlossen? Das ergibt keinerlei Sinn - das Display "will" darüber resettet werden, und nicht den Atmega selbst irgendwie resetten...
Tilmann schrieb: > Ist etwas dagegen einzuwenden, das LCD an Port C des Atmega 168 > anzuschließen ? Nein, dagegen ist nichts einzuwenden, nur -den RESET-Anschluß PC6 würde ich mir nicht verbauen. Du hast doch auch PC0 übrig. MfG Paul
Hi >Ähm - du hast den Display-Reset an den Atmega-Reset angeschlossen? Das >ergibt keinerlei Sinn - das Display "will" darüber resettet werden, und >nicht den Atmega selbst irgendwie resetten... Was für einen Displayreset? RS ist Registerselect. Lustig finde ich die Reihenfolge der Pins. Da kommt einiges an Arbeit auf dich zu. MfG Spess
Hi Leute, vielen Dank für die vielen Antworten. Den Pin C.0 wollte ich mir für eine AD-Wandler-Sache freihalten. Könnte ich einen Pin eines anderen Ports verwenden ? Ich sehe ein, daß ich Port D dafür hätte nehmen sollen. > Lustig finde ich die Reihenfolge der Pins. Da kommt einiges an Arbeit > auf dich zu. Wieso ? Gruß Tilmann
Hi
>Wieso ?
PC1 - LCD D7
PC2 - LCD D6
PC3 - LCD D5
PC4 - LCD D4
Fällt dir etwas auf? Man kann sich das Leben auch mit aller Macht schwer
machen.
MfG Spess
Tilmann schrieb: >> Lustig finde ich die Reihenfolge der Pins. Da kommt einiges an Arbeit >> auf dich zu. > > Wieso ? Siehe Spess53. Hier:
1 | unsigned char InvertDirection(unsigned char byte) |
2 | {
|
3 | byte = ((byte >> 4) & 0x0F) | ((byte << 4) & 0xF0); |
4 | byte = ((byte >> 2) & 0x33) | ((byte << 2) & 0xCC); |
5 | byte = ((byte >> 1) & 0x55) | ((byte << 1) & 0xAA); |
6 | |
7 | return byte; |
8 | }
|
Bevor dich das in den Wahnsinn treibt. mfg.
spess53 schrieb: > Man kann sich das Leben auch mit aller Macht schwer > machen. Dann stellt sich noch die Frage ob das (geheim gehaltene) Programm eine solche Bit-Anordnung überhaupt unterstützt ..... Bei Verwendung von Port C sollte man auch darauf achten das Avcc angeschlossen ist (was gerne mal unterschlagen wird).
Thomas E. schrieb: > Hier: > unsigned char InvertDirection(unsigned char byte) > { > byte = ((byte >> 4) & 0x0F) | ((byte << 4) & 0xF0); > byte = ((byte >> 2) & 0x33) | ((byte << 2) & 0xCC); > byte = ((byte >> 1) & 0x55) | ((byte << 1) & 0xAA); > > return byte; > } > > Bevor dich das in den Wahnsinn treibt. Tilmann schrieb: > angeschlossen und ein winziges Bascom -Hello-World-Programm geladen.
Mitlesa schrieb: > Tilmann schrieb: >> angeschlossen und ein winziges Bascom -Hello-World-Programm geladen. Und so ein bisschen Bitgeschiebe geht in Bascom nicht? Das Leben ist kein Ponyhof. mfg.
:
Bearbeitet durch User
> PC1 - LCD D7 > PC2 - LCD D6 > PC3 - LCD D5 > PC4 - LCD D4 > > Fällt dir etwas auf? Man kann sich das Leben auch mit aller Macht schwer > machen. Tut mir leid, mir fällt nichts auf. Es geht um die Verbindungsleitungen zwischen LCD und µC ? AVCC ist angeschlossen. Kann man die RS-Leitung des LCD an einen Pin eines anderen Ports legen ? Gruß Tilmann
spess53 schrieb: > Lustig finde ich die Reihenfolge der Pins. Da kommt einiges an Arbeit > auf dich zu. Ist in seinem Fall egal. Das erledigt BASCOM bzw. die Programmierer die die dortige LCD Ansteurung gemacht haben.
Tilmann schrieb: > Kann man die RS-Leitung des LCD an einen Pin eines anderen Ports legen ? Was denkst du, wozu es in BASCOM die CONFIG Anweisung gibt? Programm einfach kopiert ohne es auch nur im geringsten wenigstens einmal anzusehen, welche Befehle benutzt werden und in der Doku nachzusehen, was die eigentlich machen?
:
Bearbeitet durch User
> Was denkst du, wozu es in BASCOM die CONFIG Anweisung gibt?
Natürlich habe ich es angepaßt. Was ich nicht wußte war, daß es ein
Problem ist, es an den Reset-Pin des µC anzuschließen, denn der hat ja
sonst auch andere Funktionen neben seiner Reset-Funktion.
Und die andere Frage war die, ob ich in den CONFIG-Anweisungen auf den
Port beschränkt bin, an dem auch die anderen LCD-Anschlüsse sind.
Das scheint nicht der Fall zu sein. Richtig ?
Gruß
Tilmann
Tilmann schrieb: > Und die andere Frage war die, ob ich in den CONFIG-Anweisungen auf den > Port beschränkt bin, an dem auch die anderen LCD-Anschlüsse sind. > > Das scheint nicht der Fall zu sein. Richtig ? Der Hersteller macht das nur so zum Spass, dass man beim Config LCD bei der Pinzuordnung auch den Portnamen angeben muss. Aus der BASCOM Hilfe
1 | Config Lcdpin = Pin , Db4 = Porta.4 , Db5 = Porta.5 , Db6 = Porta.6 , Db7 = Porta.7 , E = Portc.7 , Rs = Portc.6 |
Oh, Herr ....
> Oh, Herr ....
Also um die Frage, ob man die Ansteuerung des LCD auf Pins verschiedener
Ports verteilen kann, drücken sich alle beharrlich, nicht wahr ?
Das man bei "Config Lcdpin = Pin , Db4 = Porta.4 , ..." Port und Pin
angibt dürfte sich wohl verstehen, aber ob alle Pins zum selben Port
gehören müssen ist halt die Frage.
Gruß Tilmann
Tilmann schrieb: >> Oh, Herr .... > > Also um die Frage, ob man die Ansteuerung des LCD auf Pins verschiedener > Ports verteilen kann, drücken sich alle beharrlich, nicht wahr ? Es 'drücken' sich alle, weil man da mit 2 Sekunden selbst nachdenken auch selbst drauf kommt. Und wenn nicht, dann probiert man es einfach aus. > Das man bei "Config Lcdpin = Pin , Db4 = Porta.4 , ..." Port und Pin > angibt dürfte sich wohl verstehen, aber ob alle Pins zum selben Port > gehören müssen ist halt die Frage. Genau. Deswegen schreibt man ja auch den Port nicht nur ein einziges mal hin, sondern bei jedem Pin immer wieder erneut. (Das war jetzt Sarkasmus)
Karl H. schrieb: > Das erledigt BASCOM bzw. die Programmierer die die dortige LCD > Ansteurung gemacht haben. Hmm, leider. Das befreit den "Programmierer" vom Denken und leistet dem Murks aktiv Vorschub.
>Das befreit den "Programmierer" vom Denken und leistet dem >Murks aktiv Vorschub. Das verstehe ich jetzt nicht. Eine frei konfigurierbare Belegungsmöglichkeit ist sehr flexibel und praktisch. Man kann die Pins für das LCD nehmen die noch frei sind. Ein entsprechender Code ist minimal größer und komplizierter als wenn alle Datenleitungen auf einem Port in aufsteigender Reihenfolge angeordnet werden müssen. Denn eigentlich ist dieser Zwang Murks. Viele Anfragen zu LCDs wären hier gar nicht aufgeschlagen wenn zum Beispiel der Code hier aus dem Tutorial eine freie Pinbelegung erlauben würde;)
holger schrieb: > Viele Anfragen zu LCDs wären hier gar nicht aufgeschlagen > wenn zum Beispiel der Code hier aus dem Tutorial eine > freie Pinbelegung erlauben würde;) Ich gehe noch einen Schritt weiter: Viele Fragen im Forum würden sich erübrigen, wenn die Leute, die nicht gezwungen sind, "C" zu benutzen, für ihre Aufgaben Bascom benutzen würden. ----------------------------------------------------------------------- Waidmann's heil! Die Jagd auf mich geht gleich los... MfG Paul
Paul B. schrieb: > Waidmann's heil! Die Jagd auf mich geht gleich los... Stimmt, auch die Arduino Fraktion kennt bei der LCD-Ansteuerung keinerlei Pin-Zwänge. Und wenn ich mich nicht irre, werden die Arduino-Programme, ähh Sketche vom GCC übersetzt, was irgendwie die Verwendung von C vermuten läßt ;-)
holger schrieb: > Das verstehe ich jetzt nicht. Gut, dann erklär ich es dir. > Eine frei konfigurierbare > Belegungsmöglichkeit ist sehr flexibel und praktisch. > Man kann die Pins für das LCD nehmen die noch frei sind. Für sich gesehen schon, aber... > Ein entsprechender Code ist minimal größer und komplizierter > als wenn alle Datenleitungen auf einem Port in aufsteigender > Reihenfolge angeordnet werden müssen. ...das sehe ich anders. Der Code wird vor allem unnötig größer. Er enthält eine Menge Operationen, die bei sinnvoller Pinbelegung komplett vermeidbar sind. > Denn eigentlich ist dieser Zwang Murks. Ganzheitlich betrachtet keineswegs. Nachlässigkeiten beim Hardwareaufbau per Software auszubügeln, ist kein guter Stil, auch wenn es oberflächlich funktioniert. Das ist das Gleiche, als wenn ein Automobilkonstrukteur das Fahrwerk irgendwie zusammenklaubt, nur Hauptsache es rollt, und dann mit ESP dessen Unzulänglichkeiten kompensiert, damit die Karre halbwegs stabil fährt. > Viele Anfragen zu LCDs wären hier gar nicht aufgeschlagen > wenn zum Beispiel der Code hier aus dem Tutorial eine > freie Pinbelegung erlauben würde; Die Anfragen würden m.E. noch zahlreicher, weil die Anfänger den Code erst recht nicht verstehen. Die Tutorials richten sich an Leute, die was lernen und nicht nur stupide kopieren wollen.
holger schrieb: > Viele Anfragen zu LCDs wären hier gar nicht aufgeschlagen > wenn zum Beispiel der Code hier aus dem Tutorial eine > freie Pinbelegung erlauben würde;) schlechtes Argument denn diese Anfrage ist hier aufgeschlagen obwohl (oder sogar weil?) eine freie Pinbelegung gegeben ist
Jetzt wird das hier schon wieder ein "BASCOM ist Mist" Thread... @Tilmann 1. Lass den ResetPin frei(wurde schon genannt) Wenn das Programm mit dem Pin wackelt dann interpretiert das die ResetLogik eben als Reset und schickt den µC durch ebendiesen, was das für den Programmablauf bedeutet kannst du dir ja denken. 2. Bei PortC fällt mir ein dass es da was gab mit JTAG-Fuse der muss ausgeschaltet sein wenn man den Port benutzen will Ich bin mir aber nicht sicher ob das bei dem 168 auch so ist.
Hi
>Ich bin mir aber nicht sicher ob das bei dem 168 auch so ist.
Nein. Der ATMega168 hat nur Debugwire.
MfG Spess
>holger schrieb: >> Das verstehe ich jetzt nicht. > >Gut, dann erklär ich es dir. Das musst du nicht. Ich hab durchaus genug Erfahrung zu verstehen was du sagen wolltest. Ich teile deine Meinung nur nicht. >> Eine frei konfigurierbare >> Belegungsmöglichkeit ist sehr flexibel und praktisch. >> Ein entsprechender Code ist minimal größer und komplizierter >> als wenn alle Datenleitungen auf einem Port in aufsteigender >> Reihenfolge angeordnet werden müssen. >...das sehe ich anders. Und ich sehe das halt anders als du. >Der Code wird vor allem unnötig größer. Was heisst unnötig? Wenn man jedes Byte im Flash dringend benötigt hast du Recht. Wenn man noch Platz hat ist es Quatsch. Für unbenutztes Flash gibt es kein Geld zurück;) >Er enthält eine Menge Operationen, die bei sinnvoller Pinbelegung komplett >vermeidbar sind. Ja, mein Gott es ist auch etwas langsamer. Macht meistens den Bock auch nicht mehr fett. >> Denn eigentlich ist dieser Zwang Murks. >Ganzheitlich betrachtet keineswegs. Nachlässigkeiten beim Hardwareaufbau >per Software auszubügeln, ist kein guter Stil, auch wenn es >oberflächlich funktioniert. Welche Nachlässigkeiten? Ich will mein LCD mit Pins ansteuern die auf drei Ports verteilt sind. Das sind die Pins die einfach über geblieben sind weil der Rest anderweitig belegt ist. Wo siehst du da eine Nachlässigkeit? Es gibt noch einen witzigen Nebeneffekt bei frei programmierbaren Pins für das LCD. Da man jedes Bit einzeln setzt wird das ganze oft in sbi und cbi übersetzt. Das sind atomare Operationen die bei der "alles auf einem Port" Lösung nicht atomar sind. Das heisst: Ich kann auf demselben Port wo ein Pin vom LCD angeschlossen ist gnadenlos in einem Interrupt einen anderen Pin toggeln ohne mir Gedanken zu machen.
Vielleicht wäre es an der Zeit, mal das Sparschwein zu schlachten und 8 € in einen kleinen Logik-Analyzer zu investieren, z.B. ebay 181795830268 o.ä.
holger schrieb: > Das heisst: Ich kann auf demselben Port wo ein Pin vom LCD angeschlossen > ist gnadenlos > in einem Interrupt einen anderen Pin toggeln ohne mir Gedanken zu > machen. Ist ein Argument. So hab ich das noch gar nicht betrachtet.
holger schrieb: > in einem Interrupt einen anderen Pin toggeln ohne mir Gedanken zu > machen. Auch wenn gleich wieder ein paar Leute auf mich eindreschen, aber das kannst du beim 168er grundsätzlich, indem du nicht ins PORT- sondern ins PIN-Register schreibst. mfg.
>Auch wenn gleich wieder ein paar Leute auf mich eindreschen,
Kannst du haben;) Ersetze toggeln durch auf 0 oder 1 setzen.
holger schrieb: > Kannst du haben;) Ersetze toggeln durch auf 0 oder 1 setzen. sbi,cbi Und wer immer noch auf dem Atmega8 rumjuckelt, ist selber schuld. mfg.
:
Bearbeitet durch User
Das ist übrigens kein Display Reset, sonder "Register Select", damit wird ausgewählt ob man ein Kommando oder ein Zeichen an das Display sendet. Der HD44780 kann diverse Konstellationen von Zeilen und Spalten treiben, und wird am Anfang initialisiert vom Controller. Wenn das Display im 4.bit Modus betrieben wird, wie es Bascom standartmässig macht, dann müssen die bits 4567 auf GND gelegt werden, und R/W sowieso.
DJShadowman schrieb: > Wenn das Display im 4.bit Modus betrieben wird, wie es Bascom > standartmässig macht, dann müssen die bits 4567 auf GND gelegt werden, > und R/W sowieso. Ahja, wieso das denn? Die Pins DB4-7 werden doch eh ignoriert im 4 bit Modus.
Hi >Wenn das Display im 4.bit Modus betrieben wird, wie es Bascom >standartmässig macht, dann müssen die bits 4567 auf GND gelegt werden, Unsinn. Die Datenleitungen haben interne PullUp-Widerstände . Da ist Masse kontraproduktiv. Wenn schon, dann auf VCC. Außerdem sind es die Pins 0/1/2/3. MfG Spess
Ich finde die unkomplizierte Möglichkeit prima, die LCD-Anschlüsse frei wählen zu können. Wenn man eine Leiterplatte entwirft, sieht man, daß es besser wäre, den Anschluß mit einem Anderen zu tauschen, um Kreuzungen zu vermeiden und "Knäuel" zu entwirren. Manchmal mache ich auch nur zur Inbetriebnahme ein Display dran, um mir irgendwelche Zwischenergebnisse und Variablen angucken zu können, da ist es auch nützlich. MfG Paul
Icke ®. schrieb: > Ganzheitlich betrachtet keineswegs. Nachlässigkeiten beim Hardwareaufbau > per Software auszubügeln, ist kein guter Stil, auch wenn es > oberflächlich funktioniert. So ein Display ist ja meist etwas größer, da dürfte genügend Platz sein, die Pins 'von der anderen Seite anzufahren', um Kreuzungen zu vermeiden. > Das ist das Gleiche, als wenn ein > Automobilkonstrukteur das Fahrwerk irgendwie zusammenklaubt, nur > Hauptsache es rollt, und dann mit ESP dessen Unzulänglichkeiten > kompensiert, damit die Karre halbwegs stabil fährt. Ist das gar nicht mehr Standard? Früher wurde das doch so gemacht! (A-Klasse, Audi TT, ...?)
holger schrieb: > Für unbenutztes Flash gibt es kein Geld zurück;) > Ja, mein Gott es ist auch etwas langsamer. Macht meistens den Bock auch > nicht mehr fett. > Welche Nachlässigkeiten? Ich will mein LCD mit Pins ansteuern die auf > drei Ports verteilt sind. In diesem speziellen Fall gebe ich dir Recht, da ist es nahezu egal. Und ebenso kann es manchmal sinnvoll sein, etwa aus Gründen des PCB-Layouts. Wenngleich es sicher kein überbordendes Problem darstellt, vier nebeneinander liegende Datenpins vom LCD auf vier nebeneinander liegende Portpins am µC zu routen. Aber darum geht es mir gar nicht. Ich sehe das Problem darin, daß allzu bequeme Funktionen den Programmierer zur Nachlässigkeit "erziehen". RAM und CPU-Leistung sparen? Ist doch reichlich vorhanden, also klotzen statt kleckern. In diesem Beispiel hat Ressourcenverschwendung freilich keine spürbaren Auswirkungen. Aber wenn sich die Einstellung manifestiert, wird der Programmierer auch später keinen Gedanken an Optimierung verschwenden. Und dann hat das sehr wohl praktische Auswirkungen. Schau dir mal an, wie aufgeblasen und ressourcenfressend aktuelle PC-Software daherkommt. Im Vergleich zu Programmen von vor zwei Jahrzehnten hat sich die Funktionalität nur mäßig weiterentwickelt, der Verbrauch an RAM, CPU-Leistung und Plattenplatz ist jedoch um mindestens eine Größenordnung angewachsen. Die Ursachen dafür liegen m.E. in der Verwendung vorgefertigter Frameworks, die jede Menge Ballast mit sich rumtragen und eben in der Einstellung der Programmierer, daß Ressourcenverbrauch egal ist. Dies wiederum hat zur Folge, daß sich vom Funktionsumfang her vergleichsweise primitive Software, wie etwa die Ergüsse aus den Häusern Lexware und Starfinanz, bei der Arbeit auch auf leistungsfähiger Hardware anfühlt wie Aquajogging. Deshalb, wehret den Anfängen ;-)
Hallo Leute, vielen Dank für Eure Hilfe, insbesondere den Tip den µC-Reset-Pin nicht zu verwenden, und die Info, das man das LCD auch von verschiedenen Ports aus ansteuern kann. Bin jetzt mit meiner LCD-RS-Leitung an PD0 gegangen und es geht. Zumindest die "Hallo-Welt!" - Ausgabe. Bis zum nächsten mal ! :-) Gruß Tilmann
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.