LCD im 4-Bit Modus an nur einem Port betreiben

[Wolle G. (wolleg)]

Ich habe ein LCD C0802 mit HD44780, welches im 4 Bit-Modus betrieben 
wird.
Mit dem Programm im Anhang funktioniert das auch, wenn man 2 Ports 
verwendet.
Nun zu meinem eigentlichen Anliegen: Ich möchte das LCD nur an einem 
Port betreiben.
Aktuell verwende ich vom MSP430
P1.7 bis P1.4 für DB7 bis DB4 und P6.6 bis P6.4 für E, R/W und RS.
Nun möchte ich nur P1  für DB7- DB4 und für  E, R/W,RS verwenden.
Etwa so:
P1.7   P1.6   P1.5   P1.4   P1.3   P1.2   P1.1   P1.0
DB7    DB6    DB5    DB4     -       E     R/W    RS

Bis jetzt ist es mir auch nach vielen Stunden nicht gelungen, das 
funktionstüchtige Programm so umzubauen, dass es nur an EINEM Port 
läuft.
noch etwas: meine Programmierkünste sind unterentwickelt
Deshalb lasse ich meine umgebauten Programmentwürfe erst einmal weg und 
hänge nur das funktionstüchtige Programm an.
Vielleicht kann mir jemand helfen bzw. hat schon so was fertig 
rumfliegen.
Vielen Dank

[Route_66 H. (route_66)]

Wolle G. schrieb:
> Deshalb lasse ich meine umgebauten Programmentwürfe erst einmal weg und

So funktioniert das hier nicht!
Hänge Deinen Code an und wir können weiter diskutieren.
Eine von Dir nicht geschriebene (geklaute?) Software macht Dir hier 
niemand passgerecht!

[Peter D. (peda)]

Es ist einfacher, wenn man die LCD-Lib so schreibt, daß sie mit 
beliebigen Portpins funktioniert, z.B.:

https://www.avrfreaks.net/forum/tutc-lcd-tutorial-1001

Wichtig ist allerdings die vollständige Sequenz, um aus einem 
unbekannten Zustand garantiert in den 4-Bit Mode zu kommen.

[W.S. (Gast)]

Wolle G. schrieb:
> noch etwas: meine Programmierkünste sind unterentwickelt

Ah so.

Beim Draufschauen auf deinen Code fällt mir auf, daß so etwas dort 
eigentlich garnichts zu suchen hat:

#define E_H   P6OUT |= BIT6;
#define E_L   P6OUT &= ~BIT6;
#define RW_H  P6OUT |=  BIT5;
#define RW_L  P6OUT &= ~BIT5;
#define RS_H  P6OUT |=  BIT4;
#define RS_L  P6OUT &= ~BIT4;

Also mache es anders, nämlich so, daß du einen Treiber schreibst, der so 
etwas folgende Dienste bietet:
void Enable_ein (void);
void Enable_aus (void);
void RW_high (void);
void RW_low (void);
void RS_high (void);
void RS_low (void);

Damit hältst du erstmal alle physischen Details fern von den höheren 
Schichten und du kannst alle Funktionen separat ausprobieren.

Noch ein Tip:
Im Treiber solltest du dir ein Byte hernehmen, was den momentanen 
Soll-Inhalt deines Ports speichert. Das setzt du beim Initialisieren 
deines LCD-Anschlusses auf einen passenden Wert. Und später zum 
eigentlichen Betrieb des LCD machst du alle Änderungen NUR und ZUERST in 
diesem Byte, was du dann nach jeder Änderung auf den Port ausgibst. 
Damit brauchst du dann nämlich nicht mehr den Port auszulesen (P6Out |= 
BitXYZ;), sondern nur noch zu beschreiben. Kennt dein Port nicht nur 
P6OUT ssondern evtl. auch P6IN oder so ähnlich?

W.S.

[Stefan F. (Gast)]

Ist das dein Ernst, ganze Funktionen in eine Header-Datei zu packen? 
Damit brockst du dir früher oder später eine Menge Probleme ein. Lerne 
wozu Header Dateien gedacht sind.

Dein aktuelles Problem ist, dass du bei sämtlichen Zugriffen mit "P1OUT" 
alle 8 Bits des Ports veränderst. Dort solltest du nur die oberen 4 Bits 
ändern, die mit den Datenleitungen des Displays verbunden sind.

Zu Beispiel: P1OUT = (P1OUT & 0x0F) | (value << 4);

Mache das am besten wie von W.S. vorgeschlagen mit Funktionen statt 
Makros. Das ist viel geradliniger und vermeidet unerwartete 
Seiteneffekte. Der Compiler wird den Code schon gut optimieren, egal ob 
mit Makros oder mit Funktionen.

Wenn du das gelöst hast, ist es ganz einfach, die restlichen 4 Bits für 
die Steuerleitungen zu benutzen. Denn da hast du es mit &= und |= 
bereits richtig gemacht.

[Thomas (kosmos)]

ich hatte das damals mit ATTiny28 und einem Latch gemacht, dieses hängt 
dann parallel an einem Port du legst dein Bitmuster an dann gibts du dem 
Latch den Befehl das es die Daten übernehmen und ausgeben soll. Nun 
kannst du deinen kompletten Port wieder für andere Sachen(als Ein- als 
auch als Ausgänge) benutzen, da man die Eingänge des Latches hochohmig 
schalten kann. So das dein Port faktisch vom Latch getrennt  ist das 
Latch gibt aber weiterhin dein gefordertes Bitmuster aus, nun muss du 
nur noch dem LCD sagen übernehme die 8 Bits vom Latch. Brauchst eben ein 
paar Steuerleitungen für das Latch und welche für das LCD dir bleibt 
aber ein kompletter Port frei und wenn man es übertreiben will kann man 
an einen Port 2 Latches hängen und hat dann statt 8 Pins gleich mal 24.

Hier mal eine kleine Erklärung aber das Datenblatt ist auch sehr 
verständlich
https://www.mikrocontroller.net/attachment/18129/THEMENBLATT_PORTERWEITERUNG.PDF

[Conrad (Gast)]

@Stefan und W.S.
Weshalb hackt ihr eigentlich so auf den armen TO ein, es ist doch aus 
seinem ersten Beitrag klar erkennbar, daß das gezeigte Programm nicht 
von ihm ist.

[Isabella Fürstenstein (Gast)]

Weil es ein Forum voller Leute ist die selber nicht auf die Kette 
bekommen und ihren Frust dann an anderen auslassen
"Eine von Dir nicht geschriebene (geklaute?) Software macht Dir hier
niemand passgerecht!"

Komisch, in anderen Foren klappt das sehr wohl!!

An den TO
Versuch es mal in einem vernünftigen Forum
Es gibt auch ein deutsches Unterforum dort
https://www.edaboard.com/

[Peter D. (peda)]

Thomas O. schrieb:
> ich hatte das damals mit ATTiny28 und einem Latch gemacht

Wozu noch ein weiteres Latch?
Das LCD latcht bereits selber mit E = 1.

[Thomas (kosmos)]

und wieso nimmt man dann nur den 4 bit Modus, wenn da schon ein Latch 
drin ist?

[Stefan F. (Gast)]

Thomas O. schrieb:
> und wieso nimmt man dann nur den 4 bit Modus, wenn da schon ein Latch
> drin ist?

Um Leitungen einzusparen. Die Ausgabe wird dadurch kaum langsamer und 
der zusätzliche Programmieraufwand ist auch gering.

[Reinhard R. (reirawb)]

Thomas O. schrieb:
> und wieso nimmt man dann nur den 4 bit Modus, wenn da schon ein Latch
> drin ist?
Weil aus dem vom OP genannten Display "LCD C0802 mit HD44780" nur 4 Bit 
auf das Anschlußkabel herausgeführt sind (ich habe die auch schon 
benutzt).

Reinhard

[Teo D. (teoderix)]

Thomas O. schrieb:
> und wieso nimmt man dann nur den 4 bit Modus, wenn da schon ein Latch
> drin ist?

Weil das eine mit dem Anderen, mal so garnicht zu tun hat.
Mir scheint, du verwechselst da was!

[W.S. (Gast)]

Stefan ⛄ F. schrieb:
> Ist das dein Ernst, ganze Funktionen in eine Header-Datei zu packen?

Hä?
Also, ich hätte es wohl doch eher genau SO schreiben sollen, wie ich 
das selber halte:
extern void Enable_ein (void);
extern void Enable_aus (void);
extern void RW_high (void);
extern void RW_low (void);
extern void RS_high (void);
extern void RS_low (void);

So. Ich ärgere mich ohnehin seit langem über den Pfusch, den viele 
C-Programmierer dadurch machen, daß sie jeden Krempel in die .h 
hineinschreiben.

In eine .h gehört nur das hinein, was zum Interface des Units gehört, 
so daß übergeordnete Programmteile dessen Funktionen korrekt aufrufen 
können. Deshalb sind Interna wie
#define E_H ...
in der .h völlig fehl am Platz. Über diese Details brauchen die 
aufrufenden  Programmteile nichts zu wissen, sondern das hat die 
zugehörige Funktion Enable_ein() usw. zu erledigen.

Insofern hast du die Prototypen mit den Funktionen verwechselt.

Conrad schrieb:
> @Stefan und W.S.
> Weshalb hackt ihr eigentlich so auf den armen TO ein, es ist doch aus
> seinem ersten Beitrag klar erkennbar, daß das gezeigte Programm nicht
> von ihm ist.

Nein, wir hacken nicht auf dem TO herum, sondern versuchen (ein jeder 
auf seine Art) ihm beim Lösen seines Problems zu helfen.

Es ist klar, daß der Code, den er von irgendwo her bekommen hat, nicht 
auf exakt sein Bedürfnis paßt. Ebenso klar ist, daß gar vieler Code 
miserabel geschrieben ist, obskure Abhängigkeiten aufweisen mag und so 
weiter. Obendrein ist klar, daß ein Neuling mit "unterentwickelten 
Programmierkünsten" eben noch dazulernen muß - und da sind schlecht 
geschriebene Quellen kein guter Lehrstoff.

Eben deshalb braucht es sinnvolle Ratschläge - sinnvoll in dem Sinn, daß 
der TO keinen vorgekauten Fertig-Brei kriegt, sondern ihm die 
Herangehensweisen zum Selbermachen erklärt werden.

W.S.

[W.S. (Gast)]

Thomas O. schrieb:
> und wieso nimmt man dann nur den 4 bit Modus, wenn da schon ein Latch
> drin ist?

Ist dir eigentlich klar, daß das besagte Display eben genau SO IST, wie 
es ist? Also eben nur mit den Leitungen, die da auf dem Folienleiter 
herausgeführt sind.

Pollin:
https://www.pollin.de/p/lcd-modul-c0802-04-120622

Da ist das Wort "wieso nimmt man" völlig fehl am Platze.

W.S.

[Wolle G. (wolleg)]

Stefan ⛄ F. schrieb:
> Ist das dein Ernst, ganze Funktionen in eine Header-Datei zu packen?
> Damit brockst du dir früher oder später eine Menge Probleme ein. Lerne
> wozu Header Dateien gedacht sind.
Na ja. Ein Programmierlaie und dazu noch ein alter Knacker wird solch 
grundlegenden Sachen kaum (schwer) noch packen.

> Dein aktuelles Problem ist, dass du bei sämtlichen Zugriffen mit "P1OUT"
> alle 8 Bits des Ports veränderst. Dort solltest du nur die oberen 4 Bits
> ändern, die mit den Datenleitungen des Displays verbunden sind.
>
> Zu Beispiel: P1OUT = (P1OUT & 0x0F) | (value << 4);

Sehe ich ähnlich. Es ist mir aber nicht gelungen, dies 
programmiertechnisch zu lösen.

Das im ersten Beitrag genannte Programm wollte ich NUR so umstricken, 
dass das Ganze auch an Port P1 läuft. (Datenleitungen und 
Steuerleitungen am gleichen Port)
Ob dieses Programm irgendwo „geklaut“ wurde, kann ich nicht mehr sagen. 
Bestimmt habe ich mal etwas in einem Datenblatt zum HD44780 im 8 
Bit-Modus gefunden und danach für Flüssigkristallanzeigen (FKA) mit 
HD44780 verwendet. (das sollte doch der Sinn eines  Datenblattes sein!)
Dieses Programm habe ich für die FKA C0802 auf den 4 Bit Modus 
umgestrickt und lasse es auf meiner Experimentierleiterplatte testweise 
unter der Verwendung von P1 und P6 erfolgreich laufen.
Für eine Anwendung (Thermostatventilregler) habe ich eine Leiterplatte 
geätzt, wo die FKA
am Port P1 angeschlossen werden soll.
Dabei hatte ich gedacht, dass die Umstellung auf nur einen Port so 
leicht sein könnte, wie die Umstellung vom 8Bit auf 4Bit-Modus.
Da dies mir bisher nicht gelungen ist, bat ich hier um Hilfe.
Früher gab mal die Forenteilnehmer Buchegger oder Rufus, die mir 
weiterhelfen konnten.
Vielleicht findet sich jemand, der zunächst einige Zeilen so umbaut, 
dass man das Prinzip erkennen kann. Z. B. , wie und an welcher Stelle 
könnte man das Beispiel:
> Beispiel: P1OUT = (P1OUT & 0x0F) | (value << 4);
 konkret einfügen?

[Stefan F. (Gast)]

>> > Ist das dein Ernst, ganze Funktionen in eine Header-Datei zu packen?

W.S. schrieb:
> Hä? ...
> Insofern hast du die Prototypen mit den Funktionen verwechselt.

Schau bitte nochmal in die Header-Datei im Eröffnungsbeitrag. Ich bin 
nicht so dumm, wie du es gerne darstellst.

Die Datei enthält zu 90% Funktions-Bodies, die dort nicht hin gehören.

[Stefan F. (Gast)]

Wolle G. schrieb:
> Vielleicht findet sich jemand, der zunächst einige Zeilen so umbaut,
> dass man das Prinzip erkennen kann. Z. B. , wie und an welcher Stelle
> könnte man das Beispiel:
>> Beispiel: P1OUT = (P1OUT & 0x0F) | (value << 4);
>  konkret einfügen?

Ich verstehe nicht, das ist doch schon ein Beispiel auf dem 
Silbertablett. Jetzt mal ehrlich: Wenn du das nicht umsetzen kannst, 
dann musst jemanden Beauftragen, das Projekt für dich zu Ende zu 
bringen.

Das ist nämlich ungefähr so wie Auto fahren zu wollen, aber ohne die 
Hände ans Lenkrad zu legen. Das geht nur mit Chauffeur.

[Peter D. (peda)]

Wolle G. schrieb:
> Deshalb lasse ich meine umgebauten Programmentwürfe erst einmal weg

Dir wurde doch schon gesagt, daß genau das aber nötig ist, um Deinen 
Fehler zu finden. Wir können doch nicht hellsehen.

[Wolle G. (wolleg)]

Peter D. schrieb:
> Wolle G. schrieb:
>> Deshalb lasse ich meine umgebauten Programmentwürfe erst einmal weg
>
> Dir wurde doch schon gesagt, daß genau das aber nötig ist, um Deinen
> Fehler zu finden. Wir können doch nicht hellsehen.
Kein Problem, meine umgebauten Dateien anzuhängen.
Ich dachte allerdings, dass es einfacher ist, ein noch 
funktionstüchtiges Programm umzubauen, als Fehler zu suchen.
Ich muss noch darauf hinweisen, dass die Kommentare nicht unbedingt zu 
den Befehlen passen müssen.

[W.S. (Gast)]

Wolle G. schrieb:
> Ich dachte allerdings, dass es einfacher ist, ein noch
> funktionstüchtiges Programm umzubauen, als Fehler zu suchen.

Das kommt darauf an, was du da von woanders her bekommen hast.
Wenn man irgend etwas 'umbaubar', also portabel schreiben will, dann muß 
man zusehen, die verschiedenen Ebenen zu trennen, um zum Portieren nur 
eine davon anpassen zu müssen.

ich mach mal ein Beispiel aus dem Handgelenk:

unterste Ebene, das Wackeln mit den Portpins, Headerdatei wie folgt:

#ifndef PORTACCESSDEFINED
#define PORTACCESSDEFINED
extern void Init_Port (void);
extern void Enable_ein (void);
extern void Enable_aus (void);
extern void RW_high (void);
extern void RW_low (void);
extern void RS_high (void);
extern void RS_low (void);
extern void Nibble_Out (char N);
extern char Nibble_In (void);
#endif

Dieser Teil erledigt den physischen Datenverkehr. Das obige ist nur 
die Headerdatei, die zugehörige .c mußt du selber schreiben. Und der 
Universalität zu

obere Ebene, das Betreiben des Displays, Headerdatei dazu:

#ifndef POLLINDISPLAYINCLUDED
#define POLLINDISPLAYINCLUDED
extern void Init_Display (void);
extern void Set_WrPointer (unsigned int Position);
extern void Set_VariableChar (char C, char* GlyphArray);
extern void Char_Out (char C);
#endif

Dieser Teil erledigt das Aufsetzen des Displays, das setzen des 
Schreib-Punktes, das Eintragen der variablen Zeichen und das Ausgeben 
von Zeichen.
Auch dafür mußt du die zugehörige .c selber schreiben.

So ungefähr teilt man sinnvollerweise derartige Peripherie-Ansteuerungen 
auf, damit man zum Portieren möglichst wenig an Arbeit hat. 
Wahrscheilich wäre sogar bei dem Lowlevel-Teil noch eine Reduzierung 
nötig, die darin besteht, daß man das Aufteilen der Bytes in 2x Nibble 
dort erledigt und nicht im zweiten Teil tut. Der wäre dann völlig 
hardwareunabhängig. Aber dazu wäre dann nur das nötig:

#ifndef PORTACCESSDEFINED
#define PORTACCESSDEFINED
extern void Init_Port (void);
extern void RS_high (void);
extern void RS_low (void);
extern void Byte_Out (char B);
extern char Byte_In (void);
#endif

So.
Und die von dir gepostete Datei
TS_iP158_C0802_4BIT_44780_P1f-2.h
ist ein Graus ohnegleichen. Mache du lieber nicht den Fehler, so etwas 
dir anzugewöhnen.
Immer dran denken:
In eine .h Datei kommt nur Zeugs, was KEINEN Speicherplatz braucht, also 
Verweise, Typdeklarationen (sofern woanders benötigt) und Prototypen. 
Ich schreibe auch vor letztere 'extern' davor, der klaren Lesbarkeit 
zuliebe.
Und alles, was irgend welchen Platz braucht (im RAM oder im Flash), das 
kommt in eine .c Datei.

W.S.

[Wolle G. (wolleg)]

W.S. schrieb:
> ist ein Graus ohnegleichen. Mache du lieber nicht den Fehler, so etwas
> dir anzugewöhnen.
Willst Du aus einem 80jährigen (alter Knacker s.o.) Bastler noch einen 
Programmierer machen?
Meine Literatur, mit der ich in die µC-Programmierung eingestiegen bin, 
war:
„C Mit einfachen Beispielen programmieren; leicht + klar + sofort“ von 
Jürgen Wolf
Eigentlich ist es schade um die Mühe und den vielen Text, der für mich 
überhaupt nicht hilfreich ist.

Aber vielleicht findet sich doch jemand, der mir mit konkreten 
Änderungsvorschlägen helfen möchte.
Wie schon mal gesagt, es soll mein Programm, welches  P1 und P6 
verwendet, so umgebaut werden, dass nur P1 verwendet wird.

[Peter D. (peda)]

Schau Dir mal mein Beispiel an. Da gibt es eine Funktion lcd_nibble(), 
auf der alles andere aufbaut. Dein Code besteht dagegen aus nem Haufen 
ähnlicher C&P-Sequenzen, da reicht ein einziger Fehler und nichts geht 
mehr.

[Teo D. (teoderix)]

Wolle G. schrieb:
> Wie schon mal gesagt, es soll mein Programm, welches  P1 und P6
> verwendet, so umgebaut werden, dass nur P1 verwendet wird.

Puhhh.. Es wäre einfacher und sicher auch schneller, den ganzen Mist neu 
zu schreiben! Ich würd ja fast gerne, aber ich hab halt mal so NULL 
Ahnung von dem verwendeten µC. :}

[Peter D. (peda)]

Teo D. schrieb:
> Ich würd ja fast gerne, aber ich hab halt mal so NULL
> Ahnung von dem verwendeten µC. :}

Ob es nun PORT1,2,3 heißt oder PORTA,B,C sollte doch kein großes Problem 
sein.
Und wenn man die HW-Zugriffe auf möglichst wenige Funktionen kapselt, 
bleibt der Großteil an Code ja gleich.

[Teo D. (teoderix)]

Peter D. schrieb:
> Ob es nun PORT1,2,3 heißt oder PORTA,B,C sollte doch kein großes Problem
> sein.

Na dann mach halt!
Und, so'n Schiet kommt bei mir im Code nicht vor!

Peter D. schrieb:
> fast gerne

Muß ich das wirklich übersetzen!?

[Ein Freund (Gast)]

Oh - mein Beitrag ist wohl gelöscht worden. Macht aber nichts - einfach 
mal nach "Wolle G." suchen - erklärt manches :-)

[W.S. (Gast)]

Wolle G. schrieb:
> Willst Du aus einem 80jährigen (alter Knacker s.o.) Bastler noch einen
> Programmierer machen?

Ähem...

Also wenn du nun schon so ein Display an einen MSP430 etc. anschließen 
willst, dann unterstelle ich mal ganz einfach, daß du damit auch etwas 
anzeigen willst. Ergo mußt du - wohl oder übel - dich mit Programmierung 
befassen.

Das ist schlichtweg dein Schicksal, auf das es nur 2 Alternativen gibt:
1. es alles bleiben lassen
2. den Enkel anspitzen, daß er es dir macht

Im Grunde ist das alles nicht so schwer, allerdings ist gerade die 
Programmiersprache C eine Spielwiese für Leute, die sich am liebsten in 
möglichst schwer verständlicher Art betätigen wollen. Pech für dich, daß 
für deinen Mikrocontroller keine bessere Sprache verfügbar ist.

Aber nochmal: Wenn man keinen Spaghetti-Klumpen wie in dem von dir 
gezeigten Beispiel verfaßt, sondern das Ganze in passende 
Funktions-Stücke aufteilt und diese schön bieder formuliert, dann ist 
das auch mit 80 Jahren noch kein Problem. Kannste glauben.

W.S.

[c-hater (Gast)]

W.S. schrieb:

> Im Grunde ist das alles nicht so schwer, allerdings ist gerade die
> Programmiersprache C eine Spielwiese für Leute, die sich am liebsten in
> möglichst schwer verständlicher Art betätigen wollen.

C ist doch noch verhältnismäßig harmlos. Ja klar, man kann schon böse 
Fallstricke bauen (machen die meisten C-Programmierer schon 
unfreiwillig) und man kann absichtlich fast unleserlichen Code 
schreiben.

Aber gegen das, was mit C++ an Source-Obfuskation möglich wird, ist das 
wirklich ein Fliegenschiss. Da hat man nämlich alle Möglichkeiten von C 
und noch eine riesige Menge mehr...

[Ein Freund (Gast)]

c-hater schrieb:
> Da hat man nämlich alle Möglichkeiten von C
> und noch eine riesige Menge mehr...

Hat das auch nur entfernt noch eine Beziehung zum Thema?

[Stefan F. (Gast)]

Ein Freund schrieb:
> Hat das auch nur entfernt noch eine Beziehung zum Thema?

Nein, aber es gehört zu seiner Rolle die er hier spielt.

[Ein Freund (Gast)]

c-hater schrieb:
> Da hat man nämlich alle Möglichkeiten von C
> und noch eine riesige Menge mehr...

Stefan ⛄ F. schrieb:
> Nein, aber es gehört zu seiner Rolle die er hier spielt.

Hast Du nichts besseres zu tun? Holz hacken oder Kühe melken oder ... ?

[Stefan F. (Gast)]

Ein Freund schrieb:
> Hast Du nichts besseres zu tun? Holz hacken oder Kühe melken oder ... ?

Ich hätte gerne ein paar Nutztiere, aber nein, dazu fehlt mir das nötige 
Stück Land. Ich habe gerade wirklich nichts besseres zu tun. Urlaub im 
Corona-Dezember ist echt langweilig.

[Ralph S. (jjflash)]

Ein Freund schrieb:
> Hat das auch nur entfernt noch eine Beziehung zum Thema?

In letzter Zeit ist die Stimmung hier im Forum wirklich immer gereizter. 
Es geht nur noch ums Rechthaben, um darum wie man etwas programmiert 
oder nicht und unterm Strich vergrault man so die Leute: Schade.

Unterm Strich (der TO möges es mir verzeihen) sträuben sich mir auch die 
Nackenhaare ob des obigen Codes, aber es gibt halt nun mal höchst 
unterschiedliche Qualifikationen (und wie mir scheint wird mit der Höhe 
der Qualifikation auch der Streitlevel größer).

---------------------------------------------

Da im Moment mein Spielzeug ein Padauk Controller ist, habe ich aufgrund 
dieses Threads Funktionen für ein Textdisplay für einen PFS geportet. 
Nun wollte ich dem guten Mann hier helfen und habe mir eine kleine 
Challenge aufgebürdet: ich habe ein altes TI Launchpad MSP430G 
ausgegraben um dafür ein Display anzusprechen. Leider war auf keinem 
meiner Rechner mehr ein Setup dafür vorhanden und so habe ich mühselig 
eine Toolchain (mit alten Quellen) aufgesetzt: Puuuuh.

Dafür habe ich dann die Displayroutinen zu einem MSP geportet und die 
mit (sehr) ausführlichen Kommentaren versehen, damit man guten Einblick 
dafür hat, wie es gehen kann, dass man jeden x-beliebigen Portpin zur 
Ansteuerung verwenden kann, egal ob das portüberschreitend ist oder 
nicht. Die Geschwindigkeit spielt für dieses Display keine wirklich 
große Rolle, weil es eh wenig Datentransfer gibt.

Ob mein Programm direkt auf dem Controller des TO laufen kann, weiß ich 
nicht, sollte aber mit wirklich wenigen Änderungen funktionieren.

Dem TO wünsche ich viel Spaß bei der Durchsicht des Programms und den 
anderen viel Spaß beim zerlegen des Programms und beim Aufzählen der 
Stellen, warum man das so nicht macht.

JJ

[Wolle G. (wolleg)]

Ralph S. schrieb:
> Dem TO wünsche ich viel Spaß bei der Durchsicht des Programms und den
> anderen viel Spaß beim zerlegen des Programms und beim Aufzählen der
> Stellen, warum man das so nicht macht.

@Ralph S.
Recht vielen Dank dafür, dass Du mir helfen möchtest. Es tut richtig 
leid, dass ich Dir jetzt mitteilen muss, dass ich vor ca. 30min auch 
mein Programm zum Laufen gebracht habe.
Ich wollte gerade hier im Forum meine Erfolgsmeldung abgeben und habe 
gesehen, dass Du mir Deinen Programmentwurf zur Verfügung stellen 
wolltest.
Natürlich werde ich trotzdem mal versuchen, Dein Programm auf meinem µC 
zum Laufen zu bringen und auch versuchen, die Programmierungsweise zu 
verstehen.
In der Zwischenzeit habe ich noch eine gute Beschreibung (sogar in 
Deutsch) zum HD44780 + weiteren Ansteuerschaltungen im Netz gefunden. 
http://www.sprut.de/electronic/lcd/#init

Nochmals vielen Dank und bleib gesund.

[Ralph S. (jjflash)]

Wolle G. schrieb:
> Natürlich werde ich trotzdem mal versuchen, Dein Programm auf meinem µC
> zum Laufen zu bringen und auch versuchen, die Programmierungsweise zu
> verstehen.

Würd mich schon interessieren, ob das auf deinem µC läuft. An sich (da 
die Ansteuerung der GPIO dieselbe ist ==> P1DIR, P1OUT, P1IN) sollte das 
mit kleinen Anpassungen sofort gehen:

#include <msp430.h>
#include <legacymsp430.h>

Durch notwendige Includes für deinen µC ersetzen, mutmaßlich:

#include <MSP430x16x.h>      // für MSP430F1611

Dazu kommt dann die Verzögerungswarteschleife:

__delay_cycles(1250);

Das produziert auf dem MSP430G2231 ca. 1ms Verzögerung und muß bei dir 
dann durch etwas eigenes, das 1 ms wartet, ersetzt werden.

Dementsprechend muß die 60 µs Warteschleife:

  __delay_cycles(75);

ebenfalls durch etwas ersetzt werden, was 60 µs wartet.

Wäre nett wenn du das ausprobieren könntest (einfach um meine Neugier zu 
befriedigen).

[Maxim B. (max182)]

Wolle G. schrieb:
> Mit dem Programm im Anhang funktioniert das auch, wenn man 2 Ports
> verwendet.
> Nun zu meinem eigentlichen Anliegen: Ich möchte das LCD nur an einem
> Port betreiben.

Was ist Problem? In C gibt es Befehle wie

PORTX |= (1<<MIST0);
PORTX &= ~(1<<MIST0);

Und Compiler wird dann schon selber alles richtig machen.

[W.S. (Gast)]

Ralph S. schrieb:
> Dafür habe ich dann die Displayroutinen zu einem MSP geportet und die
> mit (sehr) ausführlichen Kommentaren versehen,

Hast du schön gemacht. Ist zwar nicht mein Stil (muß es ja auch nicht 
sein), aber ausführlich, ohne schlimmen Schnickschnack, nachvollziehbar.

W.S.

[Wolle G. (wolleg)]

Ralph S. schrieb:
> Wäre nett wenn du das ausprobieren könntest (einfach um meine Neugier zu
> befriedigen).
Da bitte ich um etwas Geduld. Wie weiter oben schon einmal angedeutet, 
ist die Anzeige C0802 für mein Spielzeug -digitaler 
Heizkörperthermostatregler- gedacht. Deshalb muss ich zunächst von 
meiner Experimentier"anlage" mit MSP430F1611 auf einen MSP430F2417 
umziehen.
Hier will ich als Thermometer einen DS18B20 direkt am µC betreiben und 
muss deshalb auch dafür noch das Programmteil bauen. Bisher habe ich 
immer den DS18B20 über eine DS2482-Brücke angeschlossen.
Bei meinen Programmierkünsten kann da schon etwas Zeit vergehen.

[Wolle G. (wolleg)]

Kleine Ergänzung zur "Ursachenforschung"
Nachdem ich mich etwas näher mit dem Datenblatt zur FKA und mit der 
Abhandlung: http://www.sprut.de/electronic/lcd/#init beschäftig habe, 
würde ich heute sagen, dass die Ansteuerung der Anzeige zunächst dadurch 
scheiterte, dass gewisse Wartezeiten zwischen den Befehlen nicht immer 
richtig eingehalten wurden. Bei der ursprünglichen Ansteuerung über
2 Ports entstand offensichtlich "automatisch" durch den Umschaltprozess 
zwischen den 2 Ports genügend Wartezeit.
Die Programmschnipsel lasse ich lieber erst einmal weg. (Programmierstil 
hat sich noch nicht geändert)

[Ralph S. (jjflash)]

Wolle G. schrieb:
> über
> 2 Ports entstand offensichtlich "automatisch" durch den Umschaltprozess
> zwischen den 2 Ports genügend Wartezeit.

Das glaube ich eher nicht. Das Timing deiner "Flüssigkristallanzeige" 
ist hoch unkritisch. Aber egal ist es auch, denn du hast ja auch eine 
Lösung gefunden gehabt.

---------------

Und ich hab e was gelernt: FKA . Ich bin schon sehr lange im 
Elektronikgeschäft und habe zig Abkürzungen mitbekommen (und ich bin 
auch kein Freund von "alles muß in Englisch"), aber FKA kannte ich 
nicht.

Manche werden auch vom Paulus zum Saulus (meine ich genauso): Früher 
bezeichnete ein dt. Unternehmen (irgendwas mit S und dann noch iemens 
teuer) seine Bausteine nicht als IC (integrated circuit) sondern als IS 
(wäre heute richtig übel, wegen eines Möchtegernstaates) das die 
Bezeichung für "integrierte Schaltung" war. Just dieselbe Firma: Du hast 
dort Werksbesichtigung und du liest schier kein deutsches Wort: Da gibt 
das das "Warehouse" ... und das "Device" muß ins "Logitc centre".. und 
am Measurement workplace wird gemessen.

-----------------------------

Und so hat sich eben auch LCD eingeführt gehabt (aber wie gesagt: FKA 
hab ich noch nie gehört)


Gruß zu den Feiertagen,

JJ

[STK500-Besitzer (Gast)]

Schon mal die Arbeit gemacht, das, was das Programm am Port ausgibt, 
aufzuschreiben?

Dazu solltest du  8 Spalten (für jedes Bit deines Bytes eine)
Den Spalten gibts du die Namen der Bits (z.B. "E", "R/W", D0", D1"...) 
in der Reihenfolge, wie du den Port berlegt hast (links das höchstwerige 
Bit, rechts das niederwertigste).
Dann überträgst du das, was die FKA-einrichten-Funktion macht 
zeilenweise in diese Tabelle (für die Pausen einfach eine Zeile 
freilassen).
Das kann man mit den anderen Funktionen genauso machen.

[Karl B. (gustav)]

Hi,
das Ganze kommt mir vor wie:
wohl wieder falsch "geswappt"?
Der HD44780 Controller verlangt im Vierbitmods nacheinander erst das 
höherwertige Nibble, dann das niederwertige. Das ist die "Konstante" in 
der Spezifikation.
Jetzt käme einer auf die Idee und meinte, wenn Portbit Bit4 bis Bit7 
genommen würden, wäre das schon gelungen. Genauso kann ich alles 
beliebig setzen an Portbits am µC, Hauptsache es korrespondiert mit dem 
tatsächlich verwendeten Pinout sowohl des LCD als auch des µC.
(Beispiel:
Der ATiny2313 hat einen Port mit einem Bit weniger, also nur 7 Bit statt 
8.)
Nein, im Programm muss das angepasst werden.
Und zwei Enable Impulse, eins pro Nibble.

ciao
gustav

P.S.: Seite 459 ISBN: 9783486587906

[Wolle G. (wolleg)]

Ralph S. schrieb:
> Das glaube ich eher nicht. Das Timing deiner "Flüssigkristallanzeige"
> ist hoch unkritisch. Aber egal ist es auch, denn du hast ja auch eine
> Lösung gefunden gehabt.
Ich hatte nur gemerkt, dass bei einer Umstellung der Taktgeschwindigkeit 
auf 8MHz viel Mist angezeigt wurde. Bei MSP430F2417 kann man dies rel. 
einfach umstellen.

Die Abkürzung "FKA" für Flüssigkristallanzeige ist eine 
"Eigenschöpfung".
In der DDR wurden in der Literatur (z.B. Funkamateur; Radio, Fernsehen, 
Elektronik) vorzugsweise deutsche Begriffe verwendet, die ich natürlich 
auch jetzt weiter verwenden werde.
Damals gab es den Arbeitsspeicher, den Programmspeicher, die 
Zentraleinheit usw. oder auch den Kellerspeicher. Für den Kellerspeicher 
gab es sogar eine griffige Erklärung folgender Art:
Für einen Kachelofen verwendete man in der Regel Briketts. Diese 
Briketts wurden im Keller im Sommer gestapelt. Im Winter wurden dann vom 
Stapel zuerst die oberen Briketts entnommen.
Das ist eine gute Bezeichnung, da dies der Arbeitsweise dieser 
Speicherart entspricht.
Was zuerst eingelagert wurde, wird zuletzt wieder herausgeholt.

Noch schlimmer finde ich 'denglisch' (z.B. Backshop)

[Carl D. (jcw2)]

Wolle G. schrieb:
> Ralph S. schrieb:
>> Das glaube ich eher nicht. Das Timing deiner "Flüssigkristallanzeige"
>> ist hoch unkritisch. Aber egal ist es auch, denn du hast ja auch eine
>> Lösung gefunden gehabt.
> Ich hatte nur gemerkt, dass bei einer Umstellung der Taktgeschwindigkeit
> auf 8MHz viel Mist angezeigt wurde. Bei MSP430F2417 kann man dies rel.
> einfach umstellen.
.
> Die Abkürzung "FKA" für Flüssigkristallanzeige ist eine
> "Eigenschöpfung".
> In der DDR wurden in der Literatur (z.B. Funkamateur; Radio, Fernsehen,
> Elektronik) vorzugsweise deutsche Begriffe verwendet, die ich natürlich
> auch jetzt weiter verwenden werde.
> Damals gab es den Arbeitsspeicher, den Programmspeicher, die
> Zentraleinheit usw. oder auch den Kellerspeicher. Für den Kellerspeicher
> gab es sogar eine griffige Erklärung folgender Art:
> Für einen Kachelofen verwendete man in der Regel Briketts. Diese
> Briketts wurden im Keller im Sommer gestapelt. Im Winter wurden dann vom
> Stapel zuerst die oberen Briketts entnommen.
> Das ist eine gute Bezeichnung, da dies der Arbeitsweise dieser
> Speicherart entspricht.
> Was zuerst eingelagert wurde, wird zuletzt wieder herausgeholt.
.
> Noch schlimmer finde ich 'denglisch' (z.B. Backshop)

Es gab auch in den Westzonen Handbücher der elektronischen 
Datenverarbeitung, in denen gekellert und entkellert wurde. Ich kenne 
die von Siemens aus den 80ern (oder nannten die sich da noch 
Siemens&Halske). Das war kaum besser zu lesen wie chinesische Angebote 
auf eBay, die ein Automat über Englisch nach Deutsch übersetzt hat. Ich 
hab z.B. ein "Ebenen Flugzeug". Oder eben "smoothing plane". Tatsächlich 
macht das Ding Holz glatt.