Portbelegung auf ATMega für LCD1602

[HeSt]

Hallo allerseits,

ich möchte nun endlich mit der Verwendung eines Displays an einem Mega8 oder/und Mega16 beginnen.
Einige Beiträge habe ich ja schon gesichtet und studiert ... bin aber noch nicht ganz schlau daraus geworden ...
Nun meine Fragen:
Kann ich für einen 4-Bit-Betrieb des LCDs nur EINEN Port nutzen, wie es mir vorschwebt (siehe unten), oder muss ich Steuer- und Datenleitungen an getrennten Ports ausgeben?
Wenn getrennt, hilft mir ja eine 4-Bit-Anwendung nichts, da ich mit den anderen 4-Port-Pins nichts steuern kann, weil ja bei der Ausgabe (einem OUT PORTx,ldc_data) ALLE PINs des PORTs angesprochen werden und somit andere Funktionen mit angesteuert würden!?.

ZB (M16):
; PC0 / 22 > + Transitor VCC to LCD
; PC1 / 23 LCD RS (register select)
; PC2 / 24 LCD RW (read/write)
; PC3 / 25 LCD E (enable)
; PC4 / 26 \
; PC5 / 27 \ > Datalines for LCD 1602
; PC6 / 28 /
; PC7 / 29 /

Gruß Heinz

[seite5]

Geht auf jeden Fall, wenn Du Deinen Treiber selber schreibst. Falls nicht, sollte in der Beschreibung des Treibers oder im Header-File
ein Hinweis auf Beschränkungen in der Pinbelegung zu finden sein.
(Ich würde allerdings die Daten ins lower nipple legen, spart ein paar Befehle.)
mfg
Achim

[HeSt]

Geht auf jeden Fall, wenn Du Deinen Treiber selber schreibst. Falls nicht, sollte in der Beschreibung des Treibers oder im Header-File
ein Hinweis auf Beschränkungen in der Pinbelegung zu finden sein.
(Ich würde allerdings die Daten ins lower nipple legen, spart ein paar Befehle.)
mfg
Achim

Danke, Achim!
Da ich bzgl. Display absoluter Neuling bin, kannst dir vorstellen, wieviel ich über Treiber weiß ... und geschweige denn was von "selber schreiben" verstehe!

Somit verstehe ich es so, dass ich Steuer- und Datenleitungen nicht auf EIN Port legen kann (auch wenn ich für die Daten die L-nipples verwende).
Dann kann ich ja gleich bei der 8-Bit Version bleiben, da ich mit den H-nipples nichts "eigenes/anderes" anfangen kann.
Aber warum verwenden dann nahezu alle die 4er Version, weil sie Pins "sparen"!?
Wie bzw. wozu kann ich dann die anderen 4 Pins verwenden, wenn jedes Mal, wenn ich auf dem Port was ausgebe, außer den Pins für das LCD auch die anderen - nicht für das LCD bestimmten Pins - Werte enthalten? Die steuern ja dann diese Funktionen ohne es in diesem Moment zu wollen!
Da hab ich ein grundsätzliches Verständnisproblem!
mfg
Heinz

[seite5]

Nö, da hast Du mich falsch verstanden.
Da Du den Treiber nicht selber schreiben willst/kannst, brauchst Du also eine Bibliothek/Treiber. Da gibt's dann einen Header (*.h).
Dort wird über #defines festgelegt, welcher Pin des Controllers welche Display-bezogene Funktion übernimmt.
Vielleicht ist es einfacher, wenn Du mal ansagst, welche IDE Du verwendest.
---
Habe gerade mal auf github nach LCD1602 gesucht - dort ist von I2C-Interface die Rede - dann brauchst Du eh nur 2 Leitungen ...
https://github.com/bitbank2/LCD1602

mfg
Achim

[HeSt]

Hab auch noch ein wenig gesucht und hab das hier gefunden:

Anschluss an den Controller
Jetzt, da wir wissen, welche Anschlüsse das LCD benötigt, können wir das LCD mit dem Mikrocontroller verbinden:
Pinnummer
LCD Bezeichnung Anschluss
1 VSS GND (beim TC1602E: VCC)
2 VCC +5 V (beim TC1602E: Gnd)
3 VEE GND , Poti oder PWM am AVR
4 RS PD4 am AVR
5 RW GND
6 E PD5 am AVR
7 DB0 nicht angeschlossen
8 DB1 nicht angeschlossen
9 DB2 nicht angeschlossen
10 DB3 nicht angeschlossen
11 DB4 PD0 am AVR
12 DB5 PD1 am AVR
13 DB6 PD2 am AVR
14 DB7 PD3 am AVR
15 A Vorsicht! Meistens nicht direkt an +5 V abschließbar,
sondern nur über einen Vorwiderstand, der an die Daten
der Hintergrundbeleuchtung angepasst werden muss.
16 K GND

Da in obigem Beispiel auch nur ein Port für alle Leitungen zum LDC verwendet wird, hab ich meine Pinbelegung umgedreht:
; PC0 / 22 \
; PC1 / 23 \ > Datalines for LCD 1602
; PC2 / 24 /
; PC3 / 25 /
; PC4 / 26 > LCD RS (register select)
; PC5 / 27 > LCD RW (read/write)
; PC6 / 28 > LCD E (enable)
; PC7 / 29 > + Transitor VCC to LC

Somit müsste es funktionieren.

IDE!? Ich hab keine IDE. Zudem versteh ich nix von C (wo dein link hinführt). Ich programmiere in Assembler.
Auch wenn es so aussieht, dass ich mehr mit AVRs mache, weil ich seit 2008 im Forum bin ...
Ich hab bislang nur ganz kleine Sachen mit dem T13 gemacht, 3 kleine mit dem M8 und eine einfache Heizungssteuerung mit dem M16 (ohne LCD!).
Jetzt möchte ich mit einem M16 einen Solartracker bauen. Der soll mit LCD ausgestattet sein, damit man Parameter, die im EEProm abgelegt werden, jederzeit über LCD anzeigen und anpassen kann.

Wo ich auch noch grüble ist, wie ich ADC-Werte in Volt umrechne und diese mit zumindest einer Kommastelle ausgeben kann - in Assembler!
Wie man für die Ausgabe Ziffern in Text umwandelt hab ich schon gefunden - allerdings auch nur in C

Bis ins Frühjahr, wenn die Sonne wieder kräftiger wird, sollte meine Steuerung - zumindest AVR-mäßig - fertig sein.

mfg Heinz

[HeSt]

Also,
nach einer Unmenge an Recherchen, abwägen und vergleichen, bin ich zur Ansicht gekommen, dass meine ursprüngliche Pinbelegung des LCD-Ports ganz normal funktionieren muss. Also kein "Treiber" selbst geschrieben werden muss. Wichtig ist nur die Reihenfolge der nibbles.
Bitte um Berichtigung, wenn ich falsch liege!

In einem englisch-sprachigen Forum habe ich (bis auf die Steuerpins) die gleiche Pinbelegung gefunden.
In meinem Fall ganz wichtig: solange mit dem Display gearbeitet wird, MUSS der Pin für die Stromversorgung IMMER 1 sein.
Daher überlege ich gerade, ob ich nicht einen Pin eines anderen Ports dazu verwende, um nicht bei jeder LCD-Routine darauf achten zu müssen.
Somit bleibt dann halt ein LCD-Port-Pin am µC unbelegt.

[edit]
; PC0 / 22 > LCD RS (register select)
; PC1 / 23 > LCD RW (read/write)
; PC2 / 24 > LCD E (enable)
; PC3 / 25 n/c
; PC4 / 26 <> LCD DB4
; PC5 / 27 <> LCD DB5
; PC6 / 28 <> LCD DB6
; PC7 / 29 <> LCD DB7
[endedit]

[avr_racer]

Hallo allerseits,

ich möchte nun endlich mit der Verwendung eines Displays an einem Mega8 oder/und Mega16 beginnen.
Einige Beiträge habe ich ja schon gesichtet und studiert ... bin aber noch nicht ganz schlau daraus geworden ...
Nun meine Fragen:
Kann ich für einen 4-Bit-Betrieb des LCDs nur EINEN Port nutzen, wie es mir vorschwebt (siehe unten), oder muss ich Steuer- und Datenleitungen an getrennten Ports ausgeben?
Wenn getrennt, hilft mir ja eine 4-Bit-Anwendung nichts, da ich mit den anderen 4-Port-Pins nichts steuern kann, weil ja bei der Ausgabe (einem OUT PORTx,ldc_data) ALLE PINs des PORTs angesprochen werden und somit andere Funktionen mit angesteuert würden!?.

ZB (M16):
; PC0 / 22 > + Transitor VCC to LCD
; PC1 / 23 LCD RS (register select)
; PC2 / 24 LCD RW (read/write)
; PC3 / 25 LCD E (enable)
; PC4 / 26 \
; PC5 / 27 \ > Datalines for LCD 1602
; PC6 / 28 /
; PC7 / 29 /

Gruß Heinz

Du kannst grundsätzlich es so machen wie es dir beliebt. Ein Port für alles, ein Port für Steuer und ein Port für Datenleitungen oder im schlimssten Falle, falls der Port nicht ganz ausreicht auch nur einen Pin auf einen anderen Port legen.
Bezug auf "weil ja bei der Ausgabe (einem OUT PORTx,ldc_data)":
ldc_data = ein Register und im 4bit- Modus müssen eben 2mal 4bit übertragen werden. Somit bleibt das Highnibble immer 0 bei der Vorverabeitung. Damit das LCD die Daten auch richtig verarbeitet kann zb das RW, RS oder das Enablebit einzelnd gesetzt werden.
RS, RW, Enable können als Bit/s deklariert werden
1 = RS
2 = RW
3 = Enable

zB:

out PORTx , LCD_DATA
sbi PORTx , RS
sbi PORTx , RW
sbi PORTx , Enable

übersetzt ohne Deklarationen

out PORTC , R16
sbi PORTC , 1
sbi PORTC , 2
sbi PORTC , 3

Letztendlich dienen die Deklarationen nur der Lesbarkeit in allen Programmiersprachen.
https://www.mikrocontroller.net/arti...-Tutorial:_LCD

Seriele 8bit-Ausgabe mit kleiner Hardwareerweiterung
https://www.roboternetz.de/community...Seriel-ATMega8

https://www.roboternetz.de/community...chnipsel/page2

Wo ich auch noch grüble ist, wie ich ADC-Werte in Volt umrechne und diese mit zumindest einer Kommastelle ausgeben kann - in Assembler!

Guck mal hier
https://www.roboternetz.de/community...ine-Bibliothek
beinhaltet mehrere 16bit Matheroutinen.

[HeSt]

Hi avr_racer,

danke für deine Erklärungen.

Das hab ich mittlerweile bereits so übernommen.

Und danke für die Links!!
Mit den Bibliotheken hab ich so mein Problem, weil ich den Programmierstil und Benamselung übernehmen müsste.
Und bevor ich meine Programme daran anpasse, bin ich schneller, wenn ich mir ansehe, verstehe wie Routinen geschrieben sind, um sie dann in "meiner Welt" umzusetzen.
Wahrscheinlich hab ich auch noch nicht kapiert, wie man "fremde" Bibliotheken verwendet. Aber bislang scheint es bei mir keinen Sinn zu machen (im Sinne von .include ...).
Wer weiß, vielleicht bringt mir noch wer bei, wie man es richtig macht.

[avr_racer]

Die Namensvergabe liegt ganz bei dir, das was für dich in deinem Programm für das jeweilige Projekt sinnhaft erscheint. Ein Ausblick für die Zukunft zeigt aber das man die entsprechenden Deklarationen beibehalten sollte, was eine enorme Verkürzung der Programmierung mit sich bringt. Hochsprachen sind auch nichts weiter als der sinnvolle Einsatz von Bibliotheken...

Diese Bibliotheken gibs halt auch in C, C++, C# usw auch diese mussten mal geschrieben werden... nur am Rande.

Bibiliotheken müssen nicht mal fremd sein es können auch deine eigenen sein aber es ist doch Schwachsinn sich jedesmal durchs Datenblatt des Controllers zu lesen.... Mensch wie wär did doch gleich... was ab und an Zeitaufwendig sein kann.

Zum einbinden der Includes gibs 2 Möglichkeiten:
1. alle Includedateien befinden sich in deinem Projektordner für das jeweilige Projekt. Das einbinden erfolgt dann ganz unten in deiner Hauptdatei.
Beispiel:
Hauptdatei = test.asm
.include "controller"
Dekalerationen Register/RAM
Interrauptvektoren mit Sprung vom Resetvektor von .org 0000 rjmp INIT
Init von Controller/Ports usw
Hauptprogramm
.include "weitere Unterprogramme"

Nachteil ist wenn man in Unterschiedlichen Projekten die gleichen Routinen/Unterprogramme braucht hat man vllt das Original verändert...

2. Wenn man sich seine eigenen Bibiliotheken schreibt werden alle Routinen, die allgemein sind, in einen Ordner aufbewahrt, selbiges trifft auch für controllergebundene Routinen zu die in zb in ATmega8 Ordner abgelegt werden. Bei einem neuen Projekt werden die entsprechenden Dateien einfach nur kopiert und siehe Punkt 1 als Include eingebunden.

Vorteil du kannst in dem jeweiligen Projekt die Dateien unter Umständen anpassen ohne das es sich auf andere Projekte auswirkt.

So wie du angefangen hast hab ich auch mal angefangen bis mir folgender Satz entgegen gebracht worden ist:
Lieber gut kopiert als schlecht selbstgeschrieben! Verfasser unbekannt. Lernen heißt kopieren gerade am Anfang.

Hast du denn mal Programmcode den man sich mal anschauen kann ?
Mit welcher Software prgrammierst du AtmelStudio 4/7 ?

http://www.avr-asm-tutorial.net/avr_...ner/warum.html
http://www.avr-asm-tutorial.net/avr_de/index.html

[HeSt]

Was mich abhält fertige (fremde) Bibliotheken zu verwenden ist die Tatsache, dass andere Definitionen von Registern und dergleichen verwendet werden. Sie passen absolut nicht in meine Namensgebung. Wie kann ich sie denn da einbinden!?

Lieber gut kopiert als schlecht selbstgeschrieben! Verfasser unbekannt. Lernen heißt kopieren gerade am Anfang.

Das mache ich ja, indem ich mir Bibliotheken schnappe, den Code kopiere und an meine Umgebung anpasse. Aber einfach mit .include einbinden ist nicht möglich.

Mit welcher Software prgrammierst du AtmelStudio 4/7 ?

Zum "Schreiben/Codieren" verwende ich einen ganz normalen Texteditor.
Zum Compilieren verwende ich AVR Studio4 (hab 6 auch auf dem Rechner, aber 4 bin beim debug gewöhnt). Und noch reicht 4, da all meine µCs enthalten sind.
Zum codieren ist mir AVR zu umständlich.

Hast du denn mal Programmcode den man sich mal anschauen kann ?

Sieh PN