LCD an Atmega 168 anschließen

Ä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

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.

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.

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?

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 ....

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.

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

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.

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.

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.

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.

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