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
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!
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.
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.
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.
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
Beitrag #6510788 wurde von einem Moderator gelöscht.
@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.
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/
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.
und wieso nimmt man dann nur den 4 bit Modus, wenn da schon ein Latch drin ist?
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.
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
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!
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.
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.
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?
>> > 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.
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.
Beitrag #6511333 wurde von einem Moderator gelöscht.
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.
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.
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:
1 | #ifndef PORTACCESSDEFINED
|
2 | #define PORTACCESSDEFINED
|
3 | extern void Init_Port (void); |
4 | extern void Enable_ein (void); |
5 | extern void Enable_aus (void); |
6 | extern void RW_high (void); |
7 | extern void RW_low (void); |
8 | extern void RS_high (void); |
9 | extern void RS_low (void); |
10 | extern void Nibble_Out (char N); |
11 | extern char Nibble_In (void); |
12 | #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:
1 | #ifndef POLLINDISPLAYINCLUDED
|
2 | #define POLLINDISPLAYINCLUDED
|
3 | extern void Init_Display (void); |
4 | extern void Set_WrPointer (unsigned int Position); |
5 | extern void Set_VariableChar (char C, char* GlyphArray); |
6 | extern void Char_Out (char C); |
7 | #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:
1 | #ifndef PORTACCESSDEFINED
|
2 | #define PORTACCESSDEFINED
|
3 | extern void Init_Port (void); |
4 | extern void RS_high (void); |
5 | extern void RS_low (void); |
6 | extern void Byte_Out (char B); |
7 | extern char Byte_In (void); |
8 | #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.
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.
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.
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. :}
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.
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!?
Oh - mein Beitrag ist wohl gelöscht worden. Macht aber nichts - einfach mal nach "Wolle G." suchen - erklärt manches :-)
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.
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...
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?
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.
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 ... ?
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.
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
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.
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:
1 | #include <msp430.h> |
2 | #include <legacymsp430.h> |
Durch notwendige Includes für deinen µC ersetzen, mutmaßlich:
1 | #include <MSP430x16x.h> // für MSP430F1611 |
Dazu kommt dann die Verzögerungswarteschleife:
1 | __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:
1 | __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).
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
1 | PORTX |= (1<<MIST0); |
2 | PORTX &= ~(1<<MIST0); |
Und Compiler wird dann schon selber alles richtig machen.
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.
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.
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)
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
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.
Angehängte Dateien:
-
Swappen_.jpg
150 KB
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
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)
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.
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.