Portbelegung auf ATMega für LCD1602

[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]

[seite5]

Hallo HeSt,
letztendlich musst Du irgendeinen Mittler zwischen Deinem Programm und der Hardware schaffen, ob man das nun Treiber nennt oder Bibliothek oder ...
Alles in Assembler - Chapeau!
Auch mit einer IDE (ich nutze AS7.0) kann man alles in Assembler machen.
Ich hab bei solchen 4-bit-"Sachen" gern die zusammenhängenden Bits (i.d.F. die Daten) ganz "unten" (Bit 0 beginnend), spart Befehle und wenn Du eh alles
selber schreibst ist es sowieso egal.
mfg
Achim

[HeSt]

Hi Achim,
danke für den "Hut"
Ich kenne nichts außer Assembler. Hab noch nie was mit IDE, Bibliotheken oder sonstigem was gemacht.
Weiß gar nicht, wie man damit umgeht und was man alles damit machen kann.
Ich lese immer wieder was von einer Bibliothek von Fleuri.
Was kann die, wozu dient sie ...?
Ich weiß nicht, wozu ich sie brauchen könnte. Hab etwas gestöbert, kann aber damit nix anfangen.
Sie muss jedoch hilfreich sein, weil sie viele nutzen. Ich bin nur noch nicht drauf gekommen.
Aber mal weiter sehen.
LG Heinz

[wkrug]

Ich weiß nicht, wozu ich sie brauchen könnte. Hab etwas gestöbert, kann aber damit nix anfangen.

So ein LCD kann eine relativ komplizierte Initialisierung benötigen, die dazu auch noch in einem gewissen Zeitfenster gemacht werden muss.
Ausserdem müssen bestimmte Grundeinstellungen gemacht werden.
Alle dafür benötigten Befehle sind dann in so einer Bibliothek enthalten.
Man braucht also eigentlich nur die gewünschte Funktion z.B. initlcd aufrufen und die Bibliothek initialisiert das Display, damit es verwendet werden kann.

Ohne solche Bibliotheken müsstest Du alles was zum Funktionieren des LCD's gebraucht wird selbst programmieren, stellenweise auf Bitebene.
Aber warum was selbst programmieren, wenn es so etwas bereits debuggt zum Download gibt?

[HeSt]

Danke für die Unterstützung!

Dass die Ansteuerung eines LCDs eine mühsame Sache ist, hab ich schon bemerkt.
Allerdings hab ich die Init-Sequenzen bereits programmiert. Ist gut beschrieben.

Als ich vor etwa 3 Jahren mit LCD anfangen wollte, hab mir den Schmöker "Mikrocomputertechnik mit Controllern der Atmel AVR-RISC-Familie" von Günter Schmitt gekauft (530 Seiten). Für mich leider nicht wirklich hilfreich, da er "UNI"-mäßig geschrieben ist und viel voraussetzt. Behandelt zwar auch etwas Basis, aber eben sehr wissenschaftlich. Und das ist mir zu hoch und zu umständlich.
Ich benötige kurze verständliche Beispiele. Zudem sind die Programmbeispiele sehr verschachtelt und greifen immer wieder auf irgendwelche Routinen aus Bibliotheken zu. Es ist einfach zu unübersichtlich und zu mühsam sich da durchzuarbeiten und es zu verstehen.
Ich finde z.B. nirgendwo einen Hinweis darauf, ob und wie man den "auto cursor" - also die automatische Weiterschaltung des Cursors - während einer Routine ab- und wieder einschalten kann.
In meinem Gedankengang brauche ich es dazu, wenn ich Ziffern verändern will.
Also z.B. einen 3-stellig Wert. Diesen will ich mit einer Taste verändern. Da es aber mühsam ist, sich z.B. von 50 auf 210 hoch zu tippen. Da ist es einfacher, immer nur eine Stelle (H,Z,E) verändern zu können. Dazu soll "auto cursor" off sein. Danach wieder ein. Ob das in diese Form sinnvoll ist, weiß ich noch nicht. Derzeit sieht es danach aus.

So gibt es noch viele Dinge, die ich erst finden und behirnen muss, wie das geht.
Z.B. wie man Ziffern und Zahlen in Text umwandelt, damit man diese auf dem LCD ausgeben kann. Einige Routinen hab ich gefunden, aber noch nicht kapiert.
Das braucht halt auch seine Zeit. Und wenn ich nicht weiß, wie die Routinen in den Bibliotheken ticken, wie Werte übergeben werden müssen usw. hab ich einfach ein Problem damit.
Wenn ich selber codiere, weiß ich wie was funktioniert - und vor allem - dann hab ich's kapiert.

[HaWe]

ich will dich ja nicht missionieren, aber gerade als asm Programmierer müsste doch C(99) ideal für dich sein: C wird ja oft als asm mit lesbareren Wrappern beschrieben, welches durch den C Compiler in Maschinencode übersetzt wird, der compiliertem asm Code ebenbürtig ist in Kompaktheit, Effizienz und Schnelligkeit.
Aber C ist ja noch viel mächtiger als asm:
Warum wird/wurde das Multiuser-Multitasking-Betriebssystem UNIX nicht weiterhin (wie anfangs versucht) in asm programmiert, und auch nicht in irgendeiner anderen damals verfügbaren Programmiersprache, sondern warum wurde eigens dafür zunächst C entwickelt, um mit diesem "Tool" dann das Unix OS effizient entwickeln zu können?
Vorteil: Plattformübergreifende Portierbarkeit, und gerade bei MCUs wie AVRs oder ARMs oder sogar auch SoCs: Millionen von Libs, die das Arbeiten damit simplifizieren, wenn man will - oder man erfindet für sich das Rad damit auf effiziente Weise neu, wenn man es so lieber möchte.

[HeSt]

Aber C ist ja noch viel mächtiger als asm

Du hast schon recht!
Tatsächlich ist es bei mir aber so, dass ich immer nur dann an diese "Käfer" denke, wenn Bedarf besteht. Eine Problemlösung, die mit µC am einfachsten bewerkstelligt werden kann.
Und das kommt bei mir sehr selten vor.
Ich will mir C (noch) nicht antun, nur weil ich mit LCD grad auf Neuland gestoßen bin. Es geht nurmehr ums Display - Anzeigen und Ändern von Parametern. Alles andere (die gesamte Steuerung des Solartrackers) ist bereits soweit fertig. Somit müsste ich das in C auch neu codieren.

[wkrug]

Also z.B. einen 3-stellig Wert. Diesen will ich mit einer Taste verändern. Da es aber mühsam ist, sich z.B. von 50 auf 210 hoch zu tippen. Da ist es einfacher, immer nur eine Stelle (H,Z,E) verändern zu können. Dazu soll "auto cursor" off sein. Danach wieder ein. Ob das in diese Form sinnvoll ist, weiß ich noch nicht. Derzeit sieht es danach aus.

Ich halte diese Vorgehensweise nicht für Zielführend.
Mit den veränderten Werten willst Du ja sicher auch rechnen.
Also müssen die Zahlenwerte als Integer oder Float vorhanden sein.
Ich mach das immer so, das ich immer komplette Zeilen eines LCD beschreibe.
Ich bin auch der Meinung, das man komplexere Projekte eigentlich nur noch mit viel Aufwand in Assembler schreiben kann.
C ist da wirklich besser. Was mich am Anfang bei C immer gestört hat sind tatsächlich die Bibliotheken.
Gerade bei AVR - GCC ( ist im Prinzip in AVR Studio 7 implementiert ) ist das schon etwas Gerödel.
Um einen AVR mit Interrupts und direkten Flash und EEProm Zugriffen anzusprechen bindet man schon mal 4 Standard Bibliotheken ein.
Sind die dann aber mal eingebunden wird das Ganze dann sehr einfach.
Gut ist, das der Compiler von Studio 7 schon gleich meckert, was er denn für eine Library gerne hätte.
Ausserdem ist AVR - GCC im Internet super dokumentiert auch aus verschiedenen Quellen.
Ein weiterer " Schwachpunkt " von C ist, das Quasi jedes verfügbare Sonderzeichen der Tastatur für die Syntax genutzt wird.

Wenn man mal verstanden hat, das ein C-Compiler von oben nach unten arbeitet und keine defines bzw. Variablen benutzt werden können, die nicht vorher definiert wurden hat man schon viele potetielle Fehlerquellen ausgemerzt.

Fertige Bibliotheken für C gibt's da fast für jedes IC und jedes Display, das so ein Controller ansteuern kann.
Sogar eine FAT Library für SD Karten gibt's.

Ich hab als letztes Projekt gerade ein MiDi Clock Metronom mit Soundausgabe gebastelt.
Das Erstellen und Debuggen hat in C gerade mal 1 1/2 Tage gedauert. Das hätte Ich in Assembler nicht machen wollen.

Das Einbinden von Assembler Code in ein C-Programm ist nicht gerade trivial und auch stark vom verwendeten Compiler abhängig.
Ich hab früher immer mit CodeVision AVR gearbeitet. Da war die Assembler Einbindung und die Grundeinstellungen für den Controller relativ einfach.
Das Prog würde Ich als Einstieg in C durchaus empfehlen ( Version mit beschränkten Optionen ist kostenlos ) weil wesentlich einfacher zu handeln als AVR Studio.
Ich nutze heute noch den Automatic Programm Generator um die Grundeinstellungen für den verwendeten Chip zu generieren.
Den erzeugten Code kopiere Ich dann einfach in AVR - Studio.

Meine Empfehlung ist einfach mal ausprobieren und nicht von den ersten Hürden abschrecken lassen.

[HaWe]

es sollte hier keine Diskussion über Arduino-User werden...

ich bezweifle, dass auch nur 1% der Arduino-freaks in der Lage ist, z.B. einen ATSAM3X8E (DUE) ohne Arduino-libs zu programmieren.
mfg
Achim

Der Sinn der Arduino-IDE besteht gerade darin, alle von Arduino unterstützten Boards nicht ohne, sondern MIT der Arduino-IDE weitestgehend Plattform-unabhängig v.a. auch von nicht-IT-Profis programmieren zu können, u.a. mit Hilfe der zur Verfügung stehenden Libraries. Genau dafür wurde das Arduino (ursprünglich "Wiring") Konzept entwickelt.
Auf diese Weise lassen sich z.B. das LCD 1602 oder 2004 oder auch OLEDs oder andere TFTs mit jedem beliebigen Arduino inkl. weiteren 3rd party Boards (Uno, Mega, Nano, Zero, Due, aber auch M4, ESP8266 oder ESP32 u.a.m.), alle grundsätzlich mit identischem Sourcecode programmieren (Arduino verwendet C/C++11), und auch externe Editoren können in diese IDE eingebunden werden.
Durch Nutzung der Libs vereinfacht sich der nötige eigene Code für verschiedenste Devices erfreulicherweise auf nur sehr wenige Zeilen, und Arduino-Uno-AVR-Code sieht dabei überhaupt nicht anders aus als Arduino-Due-ARM-ATSAM3X8E-Code - und genau das sind die erwünschten Riesen-Vorteile.
Generell ist aber C/C++ immer Library-basiert, das fängt schon bei libc, stdio, stdlib oder stdint an und ist beliebig endlos erweiterbar, das ist das C-Konzept, das per Sprachdefinition nur rund 20 reservierte keywords oder statements vordefiniert hat: der Rest steht immer in Libs.
Eine Arduino-Programmierung völlig außerhalb der Arduino IDE samt API Libs entspricht gerade NICHT dem Arduino-Konzept, und dein Arduino-User-Bashing ist also völlig offtopic und irrelevant.

[seite5]

Du solltest vielleicht mal den Fortlauf des Threads im Auge behalten, meine Argumentation bezieht sich auf Dein "falsch: man kann schon -
muss es aber gar nicht" - man kann eben nicht!
mfg
Achim