Forum: Mikrocontroller und Digitale Elektronik LCD 4x40 mit 2 Controllern


von rax (Gast)


Lesenswert?

Hallo,
hab ein 4x40 LCD Display und will dies nun mit 2 Controllern ansteuern. 
Den 1. Hab ich ganz normal angeschlossen. (Und Enable Pin 1 belegt) Wenn 
ich jetzt den 2. an das Display anschließe belege ich den 2. Enable Pin 
an dem, was aber ist mit den Datenleitungen? Kann ich die einfach 
Parallel zusammenstöpseln oder brauch ich da noch irgendwelche Dioden 
das die Ausgänge beider Controller nicht beschädigt werden?

MfG

von Klaus R. (klaus2)


Lesenswert?

ne, parallel - dafür ist ja der enable - alle datenleitungen etc gehen 
dann tristate.

Klaus.

von Johnny (Gast)


Lesenswert?

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.

von rax (Gast)


Lesenswert?

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?

von Peter D. (peda)


Lesenswert?

rax wrote:
> Hallo,
> hab ein 4x40 LCD Display und will dies nun mit 2 Controllern ansteuern.

Wozu soll das gut sein?

Du müßtest ein extra Handshakeprotokoll einrichten, damit nicht beide 
MCs zugleich auf das Display zugreifen.

Es sieht außerdem komisch aus, wenn ein MC Zeile 1 und 3 beschreibt und 
der andere Zeile 2 und 4.


Sinnvoller und einfacher ist es daher, ein MC steuert das Display und 
der andere MC schickt z.B. per UART seinen Text an den ersten.


Peter

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Ich glaube, daß der OP meint, daß er ein Display mit 2 Controllern 
(HD44780 oder kompatibel) vor sich liegen hat und dieses ansteuern will.

BTW: Es gibt doch sicher ein Datenblatt zu dem Display.

von rax (Gast)


Lesenswert?

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...

von Jens K. (jjk) Benutzerseite


Lesenswert?

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

Natürlich kannst Du das ...

Ein 4x40 Display ist "intern" aus 2 Displays aufgebaut, ergo hat man 2 
Controller (im Display). Diese mußt Du einfach nur nacheinander 
ansteuern. Also brauchst Du auch nur einen I/O-Pin mehr vom µC ... Klar, 
wenn der nicht da ist kann man das noch anders machen, aber man braucht 
bestimmt keine zwei µC ...

Schau mal da:
http://www.sprut.de/electronic/lcd/index.htm#4x40

Jens

von Peter D. (peda)


Lesenswert?

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

Dann bist Du aber der einzige.

Z.B.:
Beitrag "LCD Treiber Routine 4*40"


Peter

von rax (Gast)


Lesenswert?

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?!

von Michael U. (amiga)


Lesenswert?

Hallo,

nein, es wird so nicht gehen. Woher wissen Deine Controller, wann sie 
die Daten- und RS-Leitung benutzen dürfen?
Es darf nur ein Controller diese Leitungen auf Ausgang setzen und "sein" 
Duspkay ansteuern. Der andere muß die Leitungen um TriStae halten (beim 
AVR als Eingang dafinieren).
Wie sollen die sich darüber verständigen?
Wenn beide als Ausgang gesetzt haben und einer legt L an, der andere H 
gibt es eine nette Überlastung beider IO-Pins und das Display bekommt 
Schrottdaten...

Gruß aus Berlin
Michael

von Gast (Gast)


Lesenswert?

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

von holger (Gast)


Lesenswert?

>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.

von rax (Gast)


Lesenswert?

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.

von Michael U. (amiga)


Lesenswert?

Hallo,

>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

er will EIN Display mit 2 HD44780 in pblicher interner Verdrahtung an 
ZWEI GETRENNTE µC hängen und das geht so NICHT...

Oder habe ich jetzt die Leseschwäche? ;-)

Gruß aus Berlin
Michael

von Micha (Gast)


Lesenswert?

> 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

von rax (Gast)


Lesenswert?

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?

von holger (Gast)


Lesenswert?

>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.

von Michael U. (amiga)


Lesenswert?

Hallo,

rax wrote:
> 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?

Wie stellst Du sicher, daß NIE beide µC gleichzeitig zugreifen?

Gruß aus Berlin
Michael

von rax (Gast)


Lesenswert?

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

von rax (Gast)


Lesenswert?

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.

von gassssssssst (Gast)


Lesenswert?

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

von holger (Gast)


Lesenswert?

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

Ja.

von rax (Gast)


Lesenswert?

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?

von Peter D. (peda)


Lesenswert?

rax wrote:
> 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)

Wie schon gesagt wurde, Du kannst das LCD technisch nur mit einem MC 
betreiben, da beide LCD-Chips intern parallel geschaltet sind, außer dem 
E-Pin.

Was soll denn das sein, daß Du es logisch an 2 MCs hängen mußt?

Und warum soll ein MC nur Zeile 1 und 3 beschreiben können und der 
andere nur Zeile 2 und 4?


Wenn es denn sein muß, dann geht es eben nur, daß ein MC dem anderen 
seine Texthälfte sendet und der andere dann beide Hälften auf das LCD 
schreibt.


Peter

von Peter D. (peda)


Lesenswert?

rax wrote:
> 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


Das dürfte nicht gehen, es sei denn Du hast ne Spezialanfertigung.

Alle 4*40 LCD, die ich kenne, kontrollieren mit E1 Zeile 1+3 und mit E2 
Zeile 2+4.


Peter

von holger (Gast)


Lesenswert?

>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.

von Jadeclaw D. (jadeclaw)


Lesenswert?

@rax: Wobei, die E-Leitung vom jeweils anderen Controller zu beobachten, 
geht leider auch nicht, da die Daten bereitstehen müssen, bevor die 
E-Leitung aktiv geschaltet wird. (Siehe HD44780-Datenblatt). Es bleibt 
dir also nichts anderes übrig, als einen der beiden Controller zum 
'Master' zu deklarieren, der über eine Steuerleitung dann dem zweiten 
Controller Bescheid gibt, daß er jetzt auf den Displaybus zugreifen 
kann. Selbstverständlich muß vor der Freigabe der Master seine 
Displayleitungen hochohmig schalten ( DDR-Register für die PortPins auf 
0 setzen ). Ist der Slave fertig, gibt er den Displaybus wieder frei ( 
Portpins hochohmig ) und gibt über eine Rückmeldeleitung Bescheid, daß 
der Master wieder ran darf. Klingt kompliziert, dürfte in der Praxis 
recht einfach zu implementieren sein. Die Alternative wäre es, einen 
Controller die Displaysteuerung komplett zu übertragen und die Daten vom 
zweiten Controller über den UART oder SPI an den ersten Controller zu 
übertragen.

Gruß
Jadeclaw.

von Jadeclaw D. (jadeclaw)


Lesenswert?

Peter Dannegger wrote:
> Das dürfte nicht gehen, es sei denn Du hast ne Spezialanfertigung.
> Alle 4*40 LCD, die ich kenne, kontrollieren mit E1 Zeile 1+3 und mit E2
> Zeile 2+4.
Das allseits beliebte Wintek 2740 Display von Pollin ist steuertechnisch 
ein 4x40 LCD, auch wenn es nur 27 Zeichen pro Zeile hat, und hier ist es 
in der Tat so, E1 = Zeile 1&2, E2 = Zeile 3&4. Genau so läuft es gerade 
bei mir an einem Steckbrettaufbau. Bei anderen Displays kann es 
natürlich anders aussehen.

Gruß
Jadeclaw.

von Peter D. (peda)


Lesenswert?

Jadeclaw Dinosaur wrote:
> dir also nichts anderes übrig, als einen der beiden Controller zum
> 'Master' zu deklarieren, der über eine Steuerleitung dann dem zweiten
> Controller Bescheid gibt, daß er jetzt auf den Displaybus zugreifen
> kann. Selbstverständlich muß vor der Freigabe der Master seine
> Displayleitungen hochohmig schalten ( DDR-Register für die PortPins auf
> 0 setzen ). Ist der Slave fertig, gibt er den Displaybus wieder frei (
> Portpins hochohmig ) und gibt über eine Rückmeldeleitung Bescheid, daß
> der Master wieder ran darf. Klingt kompliziert ...

... und ist es auch.

Der Master muß jedesmal erst das LCD anfordern und der Slave muß 
schnellstmöglichst das LCD freigeben und es dann dem Master 
zurückmelden.
Es sollte also eine Interruptleitung sein und der Slave sollte nicht 
lange seine Interrupts sperren.

Auch müssen beide MCs die gleiche VCC haben, sonst fließen 
Ausgleichsströme uber die internen Schutzdioden. Du kannst also nicht 
einen MC abschalten oder resetten.


Peter

von holger (Gast)


Lesenswert?

>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.

von rax (Gast)


Lesenswert?

@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.

von Jadeclaw D. (jadeclaw)


Lesenswert?

Peter Dannegger wrote:
> Jadeclaw Dinosaur wrote:
>> dir also nichts anderes übrig, als einen der beiden Controller zum
>> 'Master' zu deklarieren, der über eine Steuerleitung dann dem zweiten
>> Controller Bescheid gibt, daß er jetzt auf den Displaybus zugreifen
>> kann. Selbstverständlich muß vor der Freigabe der Master seine
>> Displayleitungen hochohmig schalten ( DDR-Register für die PortPins auf
>> 0 setzen ). Ist der Slave fertig, gibt er den Displaybus wieder frei (
>> Portpins hochohmig ) und gibt über eine Rückmeldeleitung Bescheid, daß
>> der Master wieder ran darf. Klingt kompliziert ...
>
> ... und ist es auch.
Nö.

> Der Master muß jedesmal erst das LCD anfordern und der Slave muß
> schnellstmöglichst das LCD freigeben und es dann dem Master
> zurückmelden.
Der Master fordert nichts an. Der Master heißt so, weil er bestimmt, 
wann der Slave mal ran darf. Ich weiß nicht, wie Rax das realisiert, 
aber ich habe in meinen Teilen eine Ablaufsteuerung per Timerinterrupt 
drin, da ist es kein Problem, zwischenzeitlich auch einen Pin periodisch 
abzufragen.

> Es sollte also eine Interruptleitung sein und der Slave sollte nicht
> lange seine Interrupts sperren.
Ein Extra-Hardwareinterrupt ist deshalb dazu nicht notwendig.
Nochmal zum Verständnis: Master schaltet Displayport hochohmig und setzt 
die Freigabeleitung auf 1, Slave fragt diese im Timerinterrupt 
regelmäßig ab, geht diese Leitung auf 1, schaltet der Slave die 
Antwortleitung ebenfalls auf 1, führt die Ausgabe durch, schaltet seinen 
Displayport hochohmig und setzt die Antwortleitung wieder auf 0. Ist die 
Antwortleitung auf 0, übernimmt der Master wieder, indem er die 
Freigabeleitung wieder auf 0 setzt. Während der eine auf den anderen 
wartet, können natürlich beide per Timerinterrupt problemlos weitere 
Dinge erledigen, die jeweils gerade keine Ausgabe erzwingen.
Für Polling und Warten nimmt man heutzutage keine Schleifen mehr. Oder?

> Auch müssen beide MCs die gleiche VCC haben, sonst fließen
> Ausgleichsströme uber die internen Schutzdioden. Du kannst also nicht
> einen MC abschalten oder resetten.
Resetten schon, zumindest beim AVR geht es, da in dem Moment die 
Portleitungen hochohmig werden (Ausnahme ISP-Pins). Einen Controller 
abschalten geht auch, zwar nicht spannungsmäßig, aber SLEEP geht schon, 
dann ist der Stromverbrauch je nach Sleepmodus vernachlässigbar gering.

Gruß
Jadeclaw.

von Jadeclaw D. (jadeclaw)


Lesenswert?

rax wrote:
> @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?
Richtig.

> 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.
Da aber die Daten am Display anliegen müssen, bevor die E-Leitung aktiv 
wird, genügt es eben nicht, nur die E-Leitung zu beobachten, die 
jeweilige Freigabe muß separat gesteuert werden, da sonst die Ports 
aufeinander arbeiten. Siehe auch meine Antwort zu Peter Danneger ( Zum 
Verständnis nochmal... ). Übrigens wäre es auf diese Weise auch möglich, 
2 Controller auf ein Display mit einer E-Leitung arbeiten zu lassen.

> Achja, laut Datenblatt ist E1 Zeile 1+2 und E2 Zeile 3+4.
Jup, wie beim Wintek-Display.

Gruß
Jadeclaw.

von ben90 (Gast)


Lesenswert?

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 ;)

von Peter D. (peda)


Lesenswert?

Jadeclaw Dinosaur wrote:
> Nochmal zum Verständnis: Master schaltet Displayport hochohmig und setzt
> die Freigabeleitung auf 1, Slave fragt diese im Timerinterrupt
> regelmäßig ab, geht diese Leitung auf 1, schaltet der Slave die
> Antwortleitung ebenfalls auf 1, führt die Ausgabe durch, schaltet seinen
> Displayport hochohmig und setzt die Antwortleitung wieder auf 0.

Dann hast Du ne Race-Condition:
Slave fragt Masterleitung ab und setzt dann seine Leitung, das dauert 
aber einige Zyklen.
Macht der Master gleichzeitig das gleiche, senden beide ans LCD und es 
entsteht Datensalat.


Peter

von Peter D. (peda)


Lesenswert?

Jadeclaw Dinosaur wrote:

> Übrigens wäre es auf diese Weise auch möglich,
> 2 Controller auf ein Display mit einer E-Leitung arbeiten zu lassen.

Das wäre definitiv unsinnig, Du kriegst dann nämlich nen gemischten 
Text.

Ich hab mal versehentlich 2 Tasks auf die UART zugreifen lassen, sah 
wirklich lustig aus, war völlig unleserlich.


Peter

von ben90 (Gast)


Lesenswert?

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...

von Henning (Gast)


Lesenswert?

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

von rax (Gast)


Lesenswert?

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 :)

von Micha (Gast)


Lesenswert?

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?
;-)

von ben90 (Gast)


Lesenswert?

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^^)

von Henning (Gast)


Lesenswert?

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

von Henning (Gast)


Lesenswert?

...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

von ben90 (Gast)


Lesenswert?

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^^

von Roland P. (pram)


Lesenswert?

Nimm doch noch nen dritten, der sich NUR um die Displayansteuerung 
kümmert. Am Besten einen mit 2 UART's, dann kann der erste und zweite 
mit dem dritten jeweils über eine eigene UART kommunizieren und dem 
dritten µC mitteilen,  was er gerne am Display stehen hätte :-)
da der dritte µC beide UARTS quasi parallel bedienen kann, entstehen 
auch keine Konflikte wenn mal beide gleichzeitig aufs Display schreiben 
wollen.

Gruß
Roland

von ben90 (Gast)


Lesenswert?

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

von Roland P. (pram)


Lesenswert?

ehrlich gesagt, hab ich mich das bei der Ursprungsfrage ja auch schon 
gefragt, aber da es (angeblich) technisch und logisch nicht geht, einen 
Controller zu verwenden, ist das wohl noch die einfachste Lösung SCNR
Der Vergleich mit dem Sandwichmaker is schon gut :-)

von ben90 (Gast)


Lesenswert?

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...

von Peter D. (peda)


Lesenswert?

Roland Praml wrote:
> Nimm doch noch nen dritten, der sich NUR um die Displayansteuerung
> kümmert.

Die Idee ist garnicht mal schlecht:

Beitrag "LCD über nur einen IO-Pin ansteuern"

Allerdings reicht der ATtiny25 nicht mehr, es muß schon ein ATtiny24 
sein, wegen den 2 E-Pins.

Dann kann man auch auswählen, ob man das LCD oben/unten aufteilen will 
oder doch besser rechts/links.


Peter

von ben90 (Gast)


Lesenswert?

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^^

von Jadeclaw D. (jadeclaw)


Lesenswert?

Peter Dannegger wrote:
> Dann hast Du ne Race-Condition:
> Slave fragt Masterleitung ab und setzt dann seine Leitung, das dauert
> aber einige Zyklen.
> Macht der Master gleichzeitig das gleiche, senden beide ans LCD und es
> entsteht Datensalat.
Nein, weil die Freigabeleitung erst vom Master auf 1 geht, wenn der Bus 
frei ist und der Master abwartet, bis der Slave die Antwortleitung auf 1 
und dann wieder auf 0 setzt. Typischer Handshake eben. ben90 hat das 
schon richtig erkannt.


Peter Dannegger wrote:
> Jadeclaw Dinosaur wrote:
>
>> Übrigens wäre es auf diese Weise auch möglich,
>> 2 Controller auf ein Display mit einer E-Leitung arbeiten zu lassen.
>
> Das wäre definitiv unsinnig, Du kriegst dann nämlich nen gemischten
> Text.
Nicht, wenn man vor der Ausgabe den Cursor (DDRAM-Adresse) korrekt 
positioniert. Jeder Controller bearbeitet 'seinen' Displaybereich.

Angesichts der Rechenleistung moderner Mikrocontroller würde ich das 
Ganze mit einem Controller machen, selbst wenn man das Ding vollmacht, 
ist er die ganze Zeit mit Nichtstun beschäftigt.

Gruß
Jadeclaw

von Michael A. (micha54)


Lesenswert?

Hallo,

also ich verstehe den ganzen Thread nicht. Die IMHO einzige sinnvolle 
Implementierung wäre doch

1) Ein uC steuert das Display, quasi als I2C-Interface zum Display

2) Die beiden anderen senden geeignete Displaybefehle über den I2C, z.B. 
auch im Multimasterbetrieb.

Gruss,
Michael (auch aus Berlin)

von Micha (Gast)


Lesenswert?

Oder eben:
Ein uC macht alles.

von tex (Gast)


Lesenswert?

@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.

von rax (Gast)


Lesenswert?

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

von tex (Gast)


Lesenswert?

@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.

von Micha (Gast)


Lesenswert?

> 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...

von stepp64 (Gast)


Lesenswert?

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

von Johnny (Gast)


Lesenswert?

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. ;-)

von Henning (Gast)


Lesenswert?

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

von rax (Gast)


Lesenswert?

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 :-)

von Johnny (Gast)


Lesenswert?

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 ;-)

von Micha (Gast)


Lesenswert?

> 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...

von Johnny (Gast)


Lesenswert?

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.

von rax (Gast)


Lesenswert?

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

von Falk B. (falk)


Lesenswert?

@Johnny (Gast)

>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.

Und wozu der Mumpitz? Damit ist EIN AVR schon gelangweilt, geschweige 
denn zwei.Und der OP soll mal erst mit EINEM Mikrocontroller umgehen 
lernen, ehe er coooole Multiprozessoranwendungen angeht.

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

Sehe ich nicht so, siehe Sleep Mode.

MfG
Falk

von Johnny (Gast)


Lesenswert?

>>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.

von Micha (Gast)


Lesenswert?

@ 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...

von rax (Gast)


Lesenswert?

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 :)

Bitte 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
Noch kein Account? Hier anmelden.