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
ne, parallel - dafür ist ja der enable - alle datenleitungen etc gehen dann tristate. Klaus.
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?
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
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.
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...
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
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
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?!
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
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.
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
> 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.
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
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?
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
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
>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.
@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.
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.
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
>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.
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.
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.
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 ;)
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
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
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^^
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
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
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 :-)
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...
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
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^^
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
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)
@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. ;-)
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.
@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
>>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 :)
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.