LCD 4x40 mit 2 Controllern

Du musst sicherstellen, dass nicht beide Controller gleichzeitig den 
gemeinsamen Bus zum Display ansteuern.
Ich würde einfach jeweils die Enable Leitung zum Display noch zum 
anderen Controller führen, damit dieser feststellen kann, dass er jetzt 
nichts auf dem Bus machen darf und warten muss. Am besten in einem IRQ, 
dass keine Zeit verloren geht.
Ist sicher nicht ganz einfach zu realisieren, damit dies sauber 
funktioniert und sich die beiden Controller nicht in die Quere kommen.

Ich würde eher die Displaysteuerung einem Controller überlassen und eine 
Kommunikation zwischen den beiden Controllern aufziehen, damit der eine 
Controller dem anderen sagen kann, was er anzeigen soll. z.B. per UART 
oder SPI oder so.

Mh, Also einfach:
Wenn
E1 == Highsignal
Datenbits von E2 sperren?

Und dem Controller macht es nichts aus, wenn auf die Ausgangsports 
gerade 0V anliegen und parallel über die Leitung strom zum Display 
fließt?

das problem ist doch, dass ich es nicht mit einem Steuern kann (schon 
allein von Funktionsgründen her)

Achja, datenblatt etc. kenn ich schon. Alles geplant und ich hoffe das 
funktioniert auch so. Nur ob das eben den Ausgängen was ausmacht war ich 
mir unsicher...

hä, in deinem Topic selber schreibst du aber, dass du 2 Controller 
verwendet hast?!

Irgendwie steh ich gerade voll auf der Leitung. Ich habs bisher so:

E1 an IO Port von MC1
E2 an IO Port von MC2
Datenbits 1-8 an IO Port von MC1 und MC2
RS an IO Port von MC1 und MC2

und dann eben noch Spannungsversorgung für das Display.

Kann das so nicht funktionieren oder wie?!

Die Controller müssen nicht miteinander kommunizieren, sind beider auf 
enabled, wird in der 1 und 3 sowie in der 2. und 4. zeile das gleiche 
angezeigt. Nämlich genau das, was er über den Bus an Daten bekommt.

setzt man jetzt enable 1 auf high und den 2. auf low, dann schreibt er 
das erste display voll (also die zeile 1 und 2)

danach setzt man enable 1 auf low, und den 2. auf high (der inhalt der 
1. displays wird dabei gehalten) und er schreibt auf zeile 3 und 4

>Die Controller müssen nicht miteinander kommunizieren, sind beider auf

Die Frage ist ob der OP das mit den Controllern falsch verstanden hat.
Das Display hat zwei LCD-Controller die bis auf die
Enable Leitungen parallel geschaltet sind.
Man kann diese beiden LCD-Controller mit einem
uC ansteuern.

Genau das hab ich gemeint @Gast.

Es ist also ein Programmierungstechnisches Problem, dass sie eben keine 
Daten gleichzeitig senden dürfen, aber das ist ja nicht wirklich 
dramatisch.

Also danke für eure Hilfe, ich denke ich habs verstanden.

> Oder habe ich jetzt die Leseschwäche? ;-)
Ich hab's auch noch nicht kapiert...

Irgendwie ist nach wie vor nicht so 100%ig raus was rax will... Dass es 
um ein LCD mit zwei HD44780 geht ist, glaube ich, sicher.
Aber der Rest noch nicht...

Also rax, falls meine obige Annahme betreffs des LCDs zutrifft:
- du kannst dieses LCD nicht ohne weiteres an zwei Mikro-Controllern 
anschliessen
- du kannst dieses LCD problemlos mit einem Mikro-Controller ansteuern

ich KANN es aber nicht mit einem. Es geht einfach nicht, wie ich schon 
gesagt habe (Technisch geht es klar, aber logisch, funktionell etc. 
gehts nicht)

Also: Wie dann, wenn mein Ansatz so falsch war?
Wo liegt das Problem, wenn MC1 Ausgänge TriState sind wenn ich mit MC2 
schreibe und andersrum?

>Wo liegt das Problem, wenn MC1 Ausgänge TriState sind wenn ich mit MC2
>schreibe und andersrum?

No Problem wenn du es richtig machst.
MC1 kann dann nur die Zeilen 1+2 und
MC2 die Zeilen 3+4 beschreiben.
Wobei mir im Moment nichts vernünftiges einfällt
dies überhaupt mit zwei uC tun zu wollen.
Da würde ich eher zwei 2x40 Displays nehmen.

Also nochmal gaaanz langsam ;-)

Ich will Zeilen 1+2 schreiben:
MC1:
E1 = High
Datenbits setzen und Displayzeilen 1+2 schreiben
E1 = Low
Datenbits = Low

MC2:
E2 = High
Datenbits setzen und Displayzeilen 3+4 schreiben
E2 = Low
Datenbits = Low

(mal von dem ganzen Read / Write zeugs abgesehn)

Würde das Display die 1. und 2. Zeilen immer noch anzeigen obwohl keine 
Daten mehr dazu ankommen bzw E1 = Low ist?
Ansonsten wärs ja nur noch - wie gesagt ein problem mit der 
Programmierung, aber das krieg ich hin. Davon bin ich überzeugt :-)

MfG

Sry 4 Doppelpost, hab aber gerade michaels Post gelesen:

Naja, ich geh mit E1 in ein IO Port von MC2 und anders herum. Wenn E1 = 
High ist (also gerade was geschrieben wird) Dann muss der 2. MC eben 
warten bis er fertig geschrieben hat.

wer kommt denn auf so was ein 4x40LCD mit 2µC anzusteuern
das wird doch nie und nimmer was

>Würde das Display die 1. und 2. Zeilen immer noch anzeigen obwohl keine
>Daten mehr dazu ankommen bzw E1 = Low ist?

Ja.

Gut! Und dann meine letzte Frage, dann nerv ich euch nichtmehr :-D

was mach ich mit RS und den 2 MCs?
Wenn E1 = High muss RS von MC1 auf High sein und von MC2 der RS 
Ausgangsport auf Low sein und andersrum?
(So hätt ichs mir jetzt zumindest vorgestellt)

Achja, wann muss man ein Befehl überhaupt interpretieren (RS Low) und 
Anzeigen (RS High)
wo ist da der unterschied?

>was mach ich mit RS und den 2 MCs?
>Wenn E1 = High muss RS von MC1 auf High sein und von MC2 der RS
>Ausgangsport auf Low sein und andersrum?
>(So hätt ichs mir jetzt zumindest vorgestellt)

Da sich die uC auch den RS Pin teilen muss auch dieser
je nachdem welcher uC gerade zugreifen soll beim
inaktiven uC auf Input geschaltet werden.

>Achja, wann muss man ein Befehl überhaupt interpretieren (RS Low) und
>Anzeigen (RS High)
>wo ist da der unterschied?

Datenblatt nicht gelesen. Ich glaub du solltest
das mit den zwei uC an einem Display besser sein lassen.

@Jadeclaw Dinosaur

OK, stimmt. So könnte ich es auch machen.
Also Eine Datenleitung zum 2. MC der dann das Signal gibt, dass der 1. 
Loslegen kann?
Das hab ich doch die ganze Zeit gemeint mit E1 und E2. Wenn ein IO Port 
von MC1(sagen wir PC0), E1 vom LCD ansteuert, dann müssen die 
Datenleitungen von  MC2 Tristate sein. Wenn MC2 loslegen will, muss PC0 
auf Low schalten und die Datenleitungen von MC1 Tristate sein! Da MC1 
Master ist, hat er natürlich immer vorrang beim Schreiben.

Achja, laut Datenblatt ist E1 Zeile 1+2 und E2 Zeile 3+4.

Was sind denn nun eigentlich diese logischen und funktionellen gründe 
wieso es nur mit 2µC geht?^^
Mit fällt auch kein anlass dazu ein...
Finde das vorhaben allerdings interessant ;)

Wieso?

Am Anfang ist M gesetzt und der Master fängt an...
M ist fertig und setzt seine Leitung auf 0...
Darf aber erst wieder Anfangen wenn Slave auf 1 war und wieder 0 ist...
Der Slave macht dann auch nix mehr bis die Master Leitung einmal 1 war 
und wieder 0 ist...

Mich würde mal interessieren, warum du unbedingt 2 Mikrocontroller dafür 
nehmen willst. Hat das irgendwelche bestimmten Gründe? Es würde viel 
einfacher mit einem gehen

Grüße

Ja. Der eine steuert Uhrzeit und Status, der andere wird nur atktiv wenn 
ein Gerät einschält (der 1. Soll das Gerät automatisch einschalten + 
ausschalten) über den 2. Kann man dann Konfigurationen vornehmen (Über 
Tastenfeld etc.) und die "Statüsse" von den einzelnen Abläufen ausgeben.

Ist alles ein bisschen kompliziert, die Schaltung, deshalb frag ich euch 
ja zum Verständnis.
Ich denke ich habs verstanden und geh nochmal alles durch, bevor ich die 
Platine ätze. Dannach werd ich dann eh erst mal den 1. MC an das LCD 
ansteuern und schauen ob das Funktioniert. Wenn das fertig ist, kommt 
erst der 2.

Also Gute Nacht :)

Wenn das deine Begründung ist, bleibt die Frage:
> Mich würde mal interessieren, warum du unbedingt 2 Mikrocontroller dafür
> nehmen willst. Hat das irgendwelche bestimmten Gründe?
;-)

Wie Micha schon meinte...das is keine Begründung zwei µController zu 
nehmen für die Ansteuerung...

Während der zweite Controller eingeschaltet ist sendet er seine Daten 
zum ersten und der gibt sie für ihn aus...
Wenn der zweite Controller schläft dann sendet er eben keine Daten und 
der erste freut sich über weniger Arbeit ;)
(außer er freut sich zu laut...dann wacht der zweite unbeabsichtigt 
auf^^)

Das nennt man dan wohl Dual-Core ;-)
ne mal im ernst, das kannste mit einem viel einfacher realisieren...

...ich bins nochmal. Also echt, irgendwie verstehe ich den Sinn dahinter 
nicht, wieso du 2 nehmen willst.

Das wäre so, wie wenn du 2 Rechner nehmen willst um ne DVD zu gucken; 
der eine liest die DVD, streamt es ins Netz und der ander Rechner gibt 
den Stream auf dem Monitor wieder. Wobei das schon wieder sinn ergeben 
könnte, wenn mehrere Rechner den Stream wiedergeben sollen.... (nur so 
als beispiel)

Grüße Henning

http://www.longcountdown.com/images/sandwichmaker.gif

...das is das wie EIN sandwichmaker an dem ZWEI leute stehen und 
versuchen gleichzeitig ihre sandwiches zu machen...
...nachdem der erste dat gerät aufgeklappt hat und sein sandwich 
reingeworfen hat macht er es wieder zu...
...der nächste kommt und klappt ihn nochma auf...macht dabei unter 
umständen das sandwich vom ersten kaputt und legt seins in das zweite 
fach...
...dann kommt wieder der erste um noch ne gurke draufzu machen...
...will den maker anschließend wieder zu machen...
...aber der zweite wollte grade nochma schaun ob er auch genug käse 
dabei hat und will ihn auf machen...

...UND ES GIBT KRIEG!^^

...und am schluss liegt ein sandwich aufm boden und is irgendwo verloren 
gegangen...die gurke liegt im falschen fach...und hinsichtlich käse und 
toast ist alles etwas in die falsche reihenfolge geraten xD

was lernen wir daraus?
a) vll hätte der zweite dem ersten einfach sagen sollen was er gerne 
hätte und der könnte dann in ruhe koordiniert an die zubereitung 
gehen...
b) microcontroller und essen liegt doch näher beieinader als wir immer 
dachten...zumindest ich persönlich brauche beides zum leben^^

und wo is da der sinn?^^
so nen rechenaufwand is das doch nicht, dass man für die kleine 
anwendung da 3 controller braucht o.O

wenn wir noch nen 4. nehm dann haben wir nen Quad-Core...

und es passt wieder genau auf die sandwich geschichte:

VIER Leute, jeder will ein sandwich machen, an EINEM sandwichmaker, aber 
es gibt nur EINE klappe um was rein zu tun und ZWEI fächer für 
sandwiches... ;-)

translation:

VIER Controller wollen jeder eine zeile von EINEM display haben, aber es 
gibt nur EINEN RS Pin und ZWEI EN Pins...

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

und zum thema...
ich glaube er macht bloß nen denkfehler...
er hat doch oben geschrieben warum er meint, dass es nicht geht...
aber wenn ich das richtig verstanden habe müsste es trotzdem gehen...

die frage is halt wie komplex das ganze werden soll...
klar macht evtl nen extra controller für das display sinn...
aber wenn auch ein einzelner oder zwei controller von denen einer fürs 
LCD zuständig ist damit klarkommen...
ich dachte wir suchen nach ner möglichst "einfachen" lösung...
ich find nen dritten controller nu auch nich komplizierte als zwei an 
einem display mit handshake^^

Oder eben:
Ein uC macht alles.

@rax
Du kannst das Problem recht einfach losen indem Du die Daten die an das 
Display gehen sollen nicht parallel an das Display führst sondern 
seriell über ein Schieberegister. Neben dem Umstand dass Du dabei 
diverse Ports an Deinem uC sparst kannst Du jeweils den zustand der 
Prozessorports abfragen, womit Du den ganzen Master/Slave Aufwand 
minimieren kannst.

Ich sagte doch, es ist kompliziert, weil der eine an das Gerät gebunden 
ist. (Und dareichen mir die Ports nicht) Und was bitteschön ist an dem 
Master - Slave prinzip kompliziert?

MfG

@rax
Ich bin mir nicht sicher ob Du meinen Post richtig verstanden hast.
Ich habe Dir vorgeschlagen, die DATEN dem Display nicht direkt von den 
Ports Deiner uCs zur Verfügung zu stellen, sondern sie über ein 
Schieberegister an das Display zu leiten. Du brauchst dafür keine 
zusätzlichen Prozessoren oÄ. und Dein Display ist weiterhin mit beiden 
uCs verbunden.
Außerdem behältst Du Ports Deiner uCs übrig, weil Du dann nicht 8 Pins 
Deines uCs für das Datenwort, dass an das Display zu senden ist, 
benötigst, sondern nur ein Pin. Du hast dann also pro Prozessor 7 PINs 
mehr zur freien Verfügung.
Der Vorteil besteht ganz einfach darin, dass Du nur den Enable Eingang 
des Schieberegisters abfragen musst, um zu erfahren, ob das Display 
gerade vom anderen Prozessor benutzt wird.

> Ich sagte doch, es ist kompliziert, weil der eine an das Gerät gebunden
> ist. (Und dareichen mir die Ports nicht) Und was bitteschön ist an dem
> Master - Slave prinzip kompliziert?
Und wieso bitteschön ist es kompliziert einen uC mit mehr Pins zu 
nehmen?

Du brauchst uns nicht um Erlaubnis zu fragen - es ist dein Problem wie 
du es löst. Es ist lediglich so, dass die meisten hier der Ansicht sind, 
dass es mit 2 uC komplizierter ist als mit einem - und das wird 
vermutlich auch so bleiben...

Eventuell könnte man das Display ja auch im 4bit Mode ansteuern. Dann 
wären ja Pins übrig für die 2. Enable Leitung...

In meinem Post (an dritter Stelle) war ja eigentlich schon alles 
beantwortet. Kaum zu glauben, wieviel Diskussionsstoff das Thema sonst 
noch hergibt :-)
Die dreichip Lösung mit separatem Controller nur für das Display gefällt 
mit. Vorallem im Zusammenhang mit dem trääääänend langsamen character 
Display mit HD44780 :-)
Es gäbe noch die Möglichkeit, auf dem Display selber die Verbindung der 
beiden Controller zu unterbrechen und separat auf jeden uC zu verbinden, 
das eigent sich auch vorzüglich für ein Serienprodukt. ;-)

ahh jetzt hab ich das kapiert wie rax das meint :-)

AHHH, ich glaub jetz weiß ich, was ihr die ganze Zeit gemeint habt :-D

MC2 sendet MC1 auf 4 oder 8 Bit (je nach dem) die Daten. MC1 schickt 
Datenbits für E1 (sagen wir PD 0-7) - E1 wird high und Bits werden 
dargestellt.
Nun hat MC1 inzwischen die Bits von MC2 eingelesen und sendet diese nun 
an das LCD durch die Pins PC 0-7 (PD Bits von vorher gehen auf 
Tristate). MC1 setzt Leitung E2 auf high, wodurch Zeilen 3+4 dargestellt 
werden.

Hab ich das so richtig verstanden oder sitze ich immer noch auf der 
Leitung?

So brauch ich nix mit Handschütteln etc. das kann ja der MC für sich 
intern regeln, dass immer nur entweder Zeiel 1+2 oder 3+4 beschrieben 
werden.

Wenn das so wäre dann nehm ich mein Kopf und hau ihn gegen die Wand... 
wos doch so einfach wäre :-)

Rax, sorry das sagen zu müssen, aber Du hats eigentlich gar nichts 
begriffen.
Die einzig vernünftige Lösung, die zuverlässig und serientauglich 
funktioniert ist die folgende, wie bereits mehrmals und von 
verschiedenen Personen hier beschrieben wurde. Hier noch ein wenig 
ausführlicher:

1. Das Display ist an EINEN Deiner zwei Mikrocontroller anzuschliessen. 
Nennen wir ihn Mikrocontroller A.
Auf diesem Mikrocontroller A ist die Displayansteuerung zu 
implementieren, und zwar für alle Zeilen des Displays, also genau so, 
wie es im Datenblatt vom Display empfohlen wird.

2. Du verbindest Deine beiden Mikrocontroller A und B mit irgendeiner 
Schnittstelle die Du möchtest, z.B. UART, SPI, I2C oder sonstwas.

3. Du denkst Dir ein kleines, einfaches Protokoll aus, mit dem 
Mikrocontroller B dem Mikrocontroller A einen Befehl mit dem 
darzustellenden Text schicken kann.
Am einfachsten sendest Du einfach den Klartext eins zu eins per UART, 
SPI, I2C, ... und schliesst ihn mit einem Nullzeichen oder Linefeed ab. 
Mikrocontroller A empfängt also solange Text, bis er im Text ein 
Nullzeichen oder Linefeed findet und stellt den bisher empfangenen Text 
dann auf dem Display dar.

Sollte also nicht soooo kompliziert zu realisieren sein ;-)

> Die einzig vernünftige Lösung, die zuverlässig und serientauglich
> funktioniert ist die folgende, wie bereits mehrmals und von
> verschiedenen Personen hier beschrieben wurde.
IMO gibt es noch eine zweite: alles zusammen mit einem Controller 
realisieren...

Er hat aber anscheinend zwei Mikrocontroller, vo denen einer eine RTC 
kontrolliert und den Betriebszustand und der andere nur eingeschaltet 
wird, wenn das Gerät aus dem Standby in den Aktivzustand geholt wird.
Dies kann unter Umständen schon Sinn machen für sehr Stromsparende 
Geräte, sofern der nicht immer aktive Mikrocontroller wirklich sehr viel 
Strom benötigt und der immer aktive für die RTC sehr sparsam ist.

@Johnny:
Genau das gleiche hab ich im Post vorher geschrierben.
MC2 sendet MC1 die Daten. MC1 stellt sie für beide dar.

>>Dies kann unter Umständen schon Sinn machen für sehr Stromsparende
>>Geräte,

>Sehe ich nicht so, siehe Sleep Mode.

Du scheinst ebenfalls keine Ahnung von Elektronik zu haben.
Es gibt Systeme, die trotz Batteriebetrieb einen fetten Prozessor 
benötigen, z.B. ARM 9 oder ein FPGA, welche keinen brauchbaren Sleepmode 
haben. Wenn das Ding aber meistens nicht benötigt wird, dann kann man es 
und ganze Teile in der Elektronik mit einem sehr kleinen, stromsparenden 
Mikrocontroller a la MSP430 abschalten und erst bei Bedarf wieder 
einschalten.
Es gibt also durchaus Anwendungen, wo dies Sinn macht.

@ Johnny (Gast)
Ich bin da auf jeden Fall Falk's Meinung. Aber du hast natürlich auch 
recht - ich glaube allerdings ehrlich gesagt nicht, dass rax ein System 
mit FPGA oder ARM9 aufbaut, sondern vielmehr plant 2 AVRs zu benutzen...

Ihr braucht nix zu spekulieren. Ich machs genau so wies Johnny 6 Posts 
weiter oben gesagt hat. Und so ist es ja auch logisch...

Ich sagte ja, ich stand auf der Leitung :)