Hallo zusammen, nachdem ich jetzt schon längere Zeit im Netz erfolglos gesucht habe, möchte ich mein Problem/Frage hier kurz vorstellen. Ich bin relativ neu, bzw. noch unkundig in dieser Materie, würde aber gerne mich einarbeiten. Konkret geht es um folgendes: Ich möchte gerne 128 LCD Displays mit unterschiedlichem Text ansteuern. Die einzigen Vorgaben: es sollten möglichst kleine Displays sein...die kleinsten LCD-Displays sind 16x2, oder? Alternative wäre - falls möglich - Oled wie sie in der Bucht angeboten werden (0,96´´ Diagonale). Das Ganze soll dann mit dem PC verbunden werden; ein Arduino Mega habe ich hier rumliegen (evtl. ist aber ein anderes Board besser geeignet?). Dann wäre noch die (wahrscheinlich wichtigste) Frage nach einem geeigneten Portexpander, falls eine solche Realisierung die optimale wäre. Ich habe ja am I2C Bus nur die Möglichkeit, 8 verschiedene Adressen anzusteuern (mcp23017, PCF8574, etc.)...wie kann ich da auf 128 individuelle Adressen kommen? Die besagten Oled-Displays haben ja auch nur die Möglichkeit rückseitig per Jumper zwischen zwei Adressen zu wechseln. Letzteres scheint mir das Hauptproblem zu sein. Leider habe ich bei meiner Suche kein Projekt, etc. gefunden, das auf 128 Displays kommt...oder ich habe falsch gesucht, bzw. zu wenig Sachkenntnis. Daher die Bitte um einen Tip oder Weiterhilfe bei diesem Problem. Besten Dank und liebe Grüße, Markus
Pro Display ein eigener Controller! Dann kannst du diese zB über Rs485 miteinander verbinden. Je nach gewünschter Update-Rate musst du ggf. Das ganze in mehrere Busse unterteilen. Alles in allem kein Hexenwerk.
Markus B. schrieb: > Daher die Bitte um einen Tip oder Weiterhilfe bei diesem Problem. Es gibt I2C Multiplexer (s. NXP AN262). Auch kann man mehrere Displays zu Gruppen zusammenfassen und jeder Gruppe einen eigenen µC (z.B. Arduino Pro Mini) spendieren. http://cache.nxp.com/documents/application_note/AN262.pdf
Vom PCF8574 gibt es zwei Varianten mit unterschiedlichen Adressbereichen - macht zusammen 16 IC's. Du könntest an ein IC drei Displays (parallel) anschließen. Nur die "E" Anschlüsse müssen separat sein. Kommt also gerade hin: 4 Datenleitungen für 3 Displays parallel 1 R/S Leitung dür 3 Displays parallel 1 Enable Leitung für Display a 1 Enable Leitung für Display b 1 Enable Leitung für Display c ==== 8 16 IC's mit jeweils 3 Displays macht zusammen 48 Displays. Jetzt noch einen I2C Multiplexer dazwischen, der die Adressbereiche auf drei Busse aufsplittet, und schon hast du genug. Aber: Mach Dir mal Gedanken über die Leitungslängen und die erreichbaren Bitraten. Ich denke, dass du von "simultaner" Ansteuerung weit entfernt bist. Insofern finde ich den Ratschlag bezüglich RS485 durchaus sinnvoll.
Stefan U. schrieb: > Aber: Mach Dir mal Gedanken über die Leitungslängen @TO Wie weit sind die einzelnen LCDs voneinander entfernt?
John schrieb: > Wie weit sind die einzelnen LCDs voneinander entfernt? Das ist wohl das Entscheidende. Erst wenn man das genau weiss kann man sich ein Konzept dazu überlegen.
Stefan U. schrieb: > Aber: Mach Dir mal Gedanken über die Leitungslängen und die erreichbaren > Bitraten. Ich denke, dass du von "simultaner" Ansteuerung weit entfernt > bist. NXP spricht in seiner AN10658 von 100m Kabel bei gut 200 bzw. 400kHz Takt - wenn man sich ein bisschen Mühe gibt. So groß wird die Anzeige doch nicht sein. www.nxp.com/documents/application_note/AN10658.pdf
Stefan U. schrieb: > Ich denke, dass du von "simultaner" Ansteuerung weit entfernt > bist. Tja, da hat jemand die Eigenschaft "simultan" im Kopf aber wir wissen nicht was genau er sich damit vorgestellt hat. Heisst simultan jetzt auf die Mikrosekunde genau, oder sind es nur Millisekunden, oder Sekunden, oder Minuten ....
Was NXP verspricht, hilft dir in der Praxis wenig. Denn die gehen sicher auch von "idealen" Treibern und Kabeln aus und haben nicht damit gerechnet, dass das Kabel alle paar Meter unterbrochen wird, um eine Last drauf zu klemmen.
Hallo, vielen Dank für die vielen Antworten. Also konkret soll das Ganze eine Beschriftung an einem Orgelspieltisch (ist eine virtuelle Orgel, System "Hauptwerk") für die verschiedenen Register werden. Da diese aber immer durch die unterschiedliche Belegung der Registerschalter (verschiedene Samples, die geladen werden) wechselt, kann ich keine fixe Beschriftung anbringen. Konkret sind das Entfernungen (unabhängig, wie die Displays schlußendlich untereinander verschaltet werden), die m. E. 2-2,5 Meter nicht überschreiten. Und es soll darauf eben jeweils ein zwei- bis dreizeiliger Text dauerhaft angezeigt werden, der dann von geladenem Sample zu geladenem Sample wechselt. Wegen der Größe hatte ich eben an so etwas gedacht: http://www.ebay.de/itm/Blue-0-96-inch-128x64-IIC-I2C-OLED-LCD-LCM-Display-Module-fuer-Arduino-STM32-51-/231745935646?_trksid=p2141725.m3641.l6368 Stefan U. schrieb: > Was NXP verspricht, hilft dir in der Praxis wenig. Denn die gehen sicher > auch von "idealen" Treibern und Kabeln aus und haben nicht damit > gerechnet, dass das Kabel alle paar Meter unterbrochen wird, um eine > Last drauf zu klemmen. Ok, das klingt einleuchtend...ansonsten hatte ich eigentlich genau an sowas gedacht. Ob das gut funktioniert, kann man wahrscheinlich nur ausprobieren, oder? Wenn ich diese Idee weiter verfolgen würde, kannst Du was über den Programmieraufwand, bzw. die Schwierigkeit dessen sagen? Ich bin wie gesagt Anfänger, und damit evtl. etwas überfordert...was ich an üblichen sketches zur LCD-Ansteuerung, etc. mit dem Arduino im Netz gefunden habe, kann ich glaub noch ganz gut nachvollziehen. Allerdings wird es bei so vielen Displays und den zugehörigen Adressen ja ungleich komplizierter... TestX schrieb: > Pro Display ein eigener Controller! Dann kannst du diese zB über > Rs485 > miteinander verbinden. Je nach gewünschter Update-Rate musst du ggf. Das > ganze in mehrere Busse unterteilen. Alles in allem kein Hexenwerk. Nach RS485 hatte ich bisher noch gar nicht gesucht...was ich aber auf die Schnelle gefunden habe ist, daß es durchaus bereits vorliegendes Material (auch für den Arduino) im Netz gibt. Was für einen Controller würde man denn in diesem Fall nehmen? Gruß, Markus
:
Bearbeitet durch User
vielleicht sowas (Zumindest Anregungen von derartigen Systemen einholen) http://www.woutex.de/ (elektronische Preisauszeichnung)
:
Bearbeitet durch User
Markus B. schrieb: > Konkret geht es um folgendes: > Ich möchte gerne 128 LCD Displays mit unterschiedlichem Text ansteuern. > Die einzigen Vorgaben: es sollten möglichst kleine Displays sein...die > kleinsten LCD-Displays sind 16x2, oder? Alternative wäre - falls möglich > - Oled wie sie in der Bucht angeboten werden (0,96´´ Diagonale). 8Digits x 2 Zeilen http://beck-oled-lcd-tft-display.de/fileadmin/lcd/AC-082A.pdf oder http://beck-oled-lcd-tft-display.de/fileadmin/lcd/GTC-08021.pdf Ansonsten: es gibt kleine grafische LCDs mit 128x64 oder ähnelichen x/y Pixel mit ~6x3cm sichtbarem Bereich und einem aktiven LCD-Controller, eine einfache Ansteuerung sollte daher kein Problem sein. keine Ahnung ob es die Ampire AC 082A noch gibt, habe die einmal in einem "ähnlichen" Projekt verbaut. Damals (1997) ging es darum Muskiern zu den Noten auch "lokale" Realtime-Infos zu geben. Ich hab als Protokoll MIDI verwendet, das war für den, der das Programmiert hat am einfachsten.... Allerdings hatte ich nicht mehr als 16 Gruppen mit x Displays zu bedienen. Du solltest Dir vor allem überlegen mit welcher SW Deine Anzeigen angesteuert werden sollen. Und davon kannst Du dann ableiten welches Hardware-Protokoll Du verwenden willst. Denn es wird mühsam sein aus einer vielleicht schon bestehenden Software mit einem für diese SW ungewohnten Protokoll zu arbeiten. Grüße MiWi
> Ob das gut funktioniert, kann man wahrscheinlich nur ausprobieren, oder? Du befindest dich da in einer Grauzone, für die I2C nicht gedacht ist, aber es könnte klappen. Kann auch sein, dass es heute klappt und in ein paar Jahren spontan ausfällt. Ich würde es nicht tun, für wackelige Basteleien scheint mir das Projekt insgesamt zu wertvoll. > Was für einen Controller würde man denn in diesem Fall nehmen? Egal, jeder µC mit seriellem Port kann auch RS485. Vielleicht darf's auch ein Raspberry Pi sein.
Vielleicht so was hier, wenn Geld nicht die Rolle spielt... https://sebastianfoerster86.wordpress.com/2016/01/23/powermeter-display-zu-dmx-display/ RS485 und bekanntes Protokoll... Firmware muss etwas angepasst werden...
Schau mal hier nach: http://www.creativeapplications.net/featured/discovery-wall-screen-made-from-thousands-of-ipod-nanos/ Der Hardware-Mensch: https://www.youtube.com/playlist?list=PL0KZLmPyL6Ak1bArDuLo77yhx95yMsjHL http://www.electricstuff.co.uk/nanohack.html
Markus B. schrieb: > Also konkret soll das Ganze eine Beschriftung ........ Und wo bleibt das schwergewichtige "simultan" im Titel? Alles für die Katz, Themaverfehlung!
Wegstaben V. schrieb: > vielleicht sowas (Zumindest Anregungen von derartigen Systemen > einholen) > > http://www.woutex.de/ > > (elektronische Preisauszeichnung) daran hatte ich auch schonmal gedacht. Leider findet man keine Preise dazu, bzw. was zu finden ist, ist echt teuer. Mitlesa schrieb: > Markus B. schrieb: >> Also konkret soll das Ganze eine Beschriftung ........ > > Und wo bleibt das schwergewichtige "simultan" im Titel? > Alles für die Katz, Themaverfehlung! mit "simultan" meinte ich, daß ich für alle 128 Displays 128 verschiedene Textanzeigen lade, und daß der dann möglichst gleichzeitig von allen Displays auch angezeigt wird. ->Stefan: Ich glaube, die Lösung RS485 scheint mir am besten geeignet. Mit dem Treiberbaustein MAX487 kann ich ja 128 Slaves an einem Bus betreiben. Nun eine (wahrscheinlich recht laienhafte Frage): wie werden die einzelnen Treiber adressiert? Wird die Adresse im MAX hinterlegt? Und eine weitere Frage: wäre dieses Oled per serieller Schnittstelle geeignet: http://www.ebay.de/itm/0-96-I2C-IIC-SPI-Serial-128X64-White-OLED-LCD-LED-Display-Module-for-Arduino-/281949402216?hash=item41a57e7468:g:zmYAAOSwCypWoI2N Wenn ich erstmal weiß, in welcher Richtung das Ganze geht (Schnittstelle, etc.), kann ich mich dann voll reinknien... Danke und Gruß, Markus
Markus B. schrieb: > wie werden die einzelnen Treiber adressiert? Das musst du in SW lösen, die RS485 ist eine reine physikalische Schicht. Das heißt dein Protokoll muss irgendwo das Adressbyte haben und alle Slaves (Displays) empfangen gleichzeitig. RS485 ist ja ein Bus. Nur der Slave, der diese Adresse hat, verarbeitet das empfangene Paket.
:
Bearbeitet durch User
Mit den meisten RS485 Treibern kannst du aber keine 128 Busteilnehmer haben, sondern nur halb so viele. Ich empfehle mehrere Displays an einen µC anzuschließen, und die dann per RS485 zu vernetzen.
TestX schrieb: > Pro Display ein eigener Controller! Dann kannst du diese zB über Rs485 > miteinander verbinden. Je nach gewünschter Update-Rate musst du ggf. Das > ganze in mehrere Busse unterteilen. Alles in allem kein Hexenwerk. So ist es! Pro Display reicht ein Tiny2313, der per USART die Daten empfängt und zur Anzeige bringt. Bloß kein I2C! Das Multiprozessor-Protokoll erlaubt 256 Adressen. Da die Displays nichts zurückliefern müssen, reicht unidirektionale Übertragung: Treiberbausteine (freie Auswahl) können einfach kaskadiert werden, um Teilbusse zu entkoppeln. Zur Einschätzung der Übertragungsrate gehe ich für eine 16x2-Anzeige von 40 Byte mit je 11 Bit = 440 Bit aus. Bei einer Baudrate von 115,2 kB dauert die Auffrischung aller 128 Displays rund 0,5 s. Das sollte für die "visuelle Gleichzeitigkeit" reichen. Andernfalls müßte die Baudrate erhöht werden: 250 - 500 kB. Wichtig ist, sich einen passenden "Hauptrechner" auszusuchen und zu programmieren. Markus B. schrieb: > Ich bin relativ neu, > bzw. noch unkundig in dieser Materie, würde aber gerne mich einarbeiten. Ich bin mir nicht sicher, ob Dich das nicht doch überfordert. Kümmer Dich zunächst um konkrete Displays und deren Stromversorgung und rechne dann erst einmal die Materialkosten zusammen.
Kunz schrieb: > Zur Einschätzung der Übertragungsrate gehe ich für eine 16x2-Anzeige von > 40 Byte mit je 11 Bit = 440 Bit aus. Bei einer Baudrate von 115,2 kB > dauert die Auffrischung aller 128 Displays rund 0,5 s. Das sollte für > die "visuelle Gleichzeitigkeit" reichen. Andernfalls müßte die Baudrate > erhöht werden: 250 - 500 kB. Braucht er doch dann nicht, das Update der Displays vom Rechner aus braucht doch bloß einmalig bei wechsel der Tasten zu dem neuen Ton / Sample zu geschehen. Das Display hat ja keine Daten welche sich dynamisch schnell ändern müssen. Wie ne Anzeige des Anschlages oder sowas... Da reicht eine "relativ" langsame Übertragung eigentlich völlig aus.
Draco schrieb: > das Update der Displays vom Rechner aus > braucht doch bloß einmalig bei wechsel der Tasten zu dem neuen Ton / > Sample zu geschehen. Das ist bekannt. > Da reicht eine "relativ" langsame Übertragung eigentlich völlig > aus. 115,2 kB ist relativ langsam!
Mit einem Controller am Display man könnte die neuen Daten auch erst mal zwischenspeichern und die Akualisierung aller Anzeigen mit einem Kommando syncron auslösen. Sascha
Mit der gezeigten Variante ( https://sebastianfoerster86.wordpress.com/2016/01/23/powermeter-display-zu-dmx-display/ ) hast du ein Display für ca. 15 €. 2x16 Zeichen, passen also 16 Displays in eine DMX Universe. Sind somit 8 Universen nötig. PC Hardware für 8 DMX-Universen gibts auch sehr günstig. Stromverbrauch sollte pro Display gering sein (15 mA ?!), wenn man keine Hintergrundbeleuchtung braucht! Vorteil: Bekanntes Verfahren, viel Hardware verfügbar und einiges an Software!
Stefan U. schrieb: > Mit den meisten RS485 Treibern kannst du aber keine 128 Busteilnehmer > haben, sondern nur halb so viele. MAX487 könnte das dann.
Stefan U. schrieb: > Mit den meisten RS485 Treibern kannst du aber keine 128 Busteilnehmer > haben, sondern nur halb so viele. Na, da kann ich abhelfen. Man nehme beispielsweise den ADM3072: http://www.analog.com/media/en/technical-documentation/data-sheets/ADM3070E_3071E_3072E_3073E_3074E_3075E_3076E_3077E_3078E.pdf Ein sehr gängiger Typ, gibts bei Conrad auch. Kann 256 Nodes. Gleichwertig, aber billiger wäre eventuell der XR3072X von EXAR. Weitere Typen gitbts auch von TI und Maxim, aber deren Namen sind mir gerade entfallen. >100 Nodes sind jedenfalls weder selten noch exotisch. Sonst ist RS485 eine recht gute Wahl - robust und bewährt.
Martin W. schrieb: > MAX487 könnte das dann. Das wäre der allerletzte Typ, den ich verwenden würde. Der ist ja teurer als der µC. Warum soll man ein teueres Spezialteil einsetzen? Man kann billige Treiber nehmen (RS485, RS423, CAN-Bus) und diese einfach wie oben geschrieben hintereinanderschalten, sodaß die einzelnen Äste des Busses <= 16 bzw. 32 Endpunkte haben.
Hier gibts kleine Grafikdisplays für 3€: ebay #322050426562 Als Bussystem würde ich CAN nehmen, wenn ich das machen würde. PICs mit eingebautem CAN sind billig und einfach zu bekommen, auch in DIL, zB PIC18F25K80 reicht völlig, dazu noch ein MCP2561 CAN-Transceiver, ein 16 MHz Quarz und etwas Kleinkram, und fertig ist das Displaymodul für 6-7€. Man kann das noch mehr im Preis drücken, indem man LIN verwendet. LIN kommt wie CAN aus der Automobiltechnik und wird dort eingesetzt, wo CAN zu teuer ist, zB. bei Fensterhebermodulen. LIN-Slaves brauchen keinen Quarz, weil sie Ihr Timing vom LIN-Master bekommen, der einen Quarz braucht. Da würde es dann schon ein PIC16F1618 plus ein MCP2003B Transceiver für zusammen etwa 1€ als Slave ausreichen - Quarz entfällt hier. In der AVR-Welt gibts ähnliches, aber die meisten AVR-UARTS haben keinen LIN-Support. Im direkten Vergleich ist die PIC-Peripherie leistungsfähiger und vielseitiger. Der Griff zu automobilen Standards ist eine sichere Bank, weil dieses Zeugs millionenfach tagtäglich im Einsatz ist und demzufolge in großer Stückzahl verbaut wird und damit billig ist. OLEDs würde ich wegen Einbrenngefahr und begrenzter Lebensdauer nicht wählen, obwohl sie sehr schön aussehen. Ein Weg zur Kostenreduzierung ist der Griff zu segmentierten LCD-Gläsern ohne Controller - quasi Taschenrechnerdisplays mit 7 oder 14 Segmenten. Es gibt viele PICs, die direkt solche Displays ansteuern können (die brauchen Wechselspannung, und die gemultiplexten Displays brauchen spezielle Signalformen, die besser in Hardware erzeugt werden). Das sieht dann zwar nicht so schön aus, ist aber vor allem in größeren Stückzahlen sehr billig, wenn man sie bekommt. Katalogdistributoren haben sie selten, weil sie oft kundenspezifisch gefertigt werden. Das hier ist so ein Modul, aber in diesem Fall preislich nicht sehr interessant: http://www.digikey.de/product-detail/de/varitronix/VIM-878-DP-FC-S-LV/153-1113-ND/1118603 Es geht deutlich billiger. Das vielleicht einfach mal so als Ideenspender. fchk
Textdisplay mit 2 Zeilen à 8 Zeichen für 95 Cent: http://www.pollin.de/shop/dt/NzczOTc4OTk- (enthält einen üblichen HD44780-kompatiblen Controller) Graphikdisplay mit 128x72 rechteckigen Pixeln für 75 Cent: http://www.pollin.de/shop/dt/MTYwOTc4OTk- Ansteuerung hier: Beitrag "Re: Display von Pollin - Datenblatt - Ansteuerung"
Rufus Τ. F. schrieb: > Textdisplay mit 2 Zeilen à 8 Zeichen für 95 Cent: > > http://www.pollin.de/shop/dt/NzczOTc4OTk- Klein+fein, guter Preis aber ohne Hintergrundbeleuchtung. Bei dem Anbieter würde ich auch vorher die Verfügbarkeit der benötigten Stückzahl klären.
Kunz schrieb: > Bei dem Anbieter würde ich auch vorher die Verfügbarkeit der benötigten > Stückzahl klären. Das Textdisplay ist seit Jahren im Angebot, das dürfte kein Restposten sein. Beim Graphikdisplay sieht das anders aus. Aber das ist nichts, was nicht bei telephonischer Bestellung zu klären sein dürfte.
Ich würde mir vor allem Gedanken machen wie ich die Daten aus Hauptwerk herausbekomme MIDI ist da viel zu langsam (31250 Bit/s /440Bit = 71s).Wenn es denn überhaupt möglich ist die Register Beschriftungen seriell auszugeben. Im Idealfall müsste Hauptwerk irgendetwas Netzwerkbasiertes oder eine sehr schnelle (virtuelle) Serielleschnittstelle bieten.
Midi schrieb: > Ich würde mir vor allem Gedanken machen wie ich die Daten aus Hauptwerk > herausbekomme Ich wollte die ganze Registerbeschriftung aus Hauptwerk auslagern (ohne MIDI->xxx). Daher dachte ich an eine (in meiner Vorstellung möglichst vereinfachte) Lösung mittels eines Boards wie Arduino, Raspberry, etc. und der entsprechenden Hardware-Peripherie wie Treiberbausteinen oder Controllern. Der anzuzeigende Text sollte in den sketch eingepflegt werden, und dann je nach Wunsch angezeigt werden. Dabei hatte ich bisher immer Zweifel, ob ich die Software dazu programmieren kann. Wenn ich aber die o. g. Beiträge (übrigens vielen Dank an alle!!!) so lese, bekomme ich da auch so meine Zweifel, ob ich das überhaupt schaffe. Scheint doch komplizierter zu sein als gedacht...Egal ob CAN oder RS485 mit einem wie auch immer gearteten Protokoll, ich muß ja auch die jeweiligen Controller programmieren... Ich hatte mir auch mittlerweile überlegt, von den Oleds (Stichwort Einbrenngefahr...) wegzugehen, und ganz normale 16x2 Displays zu verwenden, obwohl die eigentlich von den Abmessungen her zu groß sind und zu wenig Textfeld bieten. Vielleicht sind die auch besser in den Kontext einzubinden als die Oleds... Vom Kostenrahmen sieht es halt so aus, daß ich für 20€ ein LCD bekommen kann (das aber eigentlich auch etwas zu groß ist, aber genau für diesen Zweck mit Hauptwerk und MIDI konzipiert ist). Das ist preislich bestimmt ok, aber wenn ich 128 Stück davon brauche, sieht die Rechnung eben schon wieder anders aus. Was auch immer ich mache, ich würde dann bestimmt mit vielen Fragen nerven...;) Wenn ich es anginge, dann müßte ich mich zuerst auf ein Konzept bzgl. der Hardware/Schnittstelle, bzw. Bussystem, etc. festlegen, und dann mit einigen wenigen Teilen üben, ob es so funktioniert. Und dann erst alles anschaffen...
:
Bearbeitet durch User
Midi schrieb: > Ich würde mir vor allem Gedanken machen wie ich die Daten aus Hauptwerk > herausbekomme Hast Du Dich im Thread vertan? Das hier ist nicht der Orgel-Thread.
Mach auf jedes Display einen Controller mit 2 UARTs und jedes hat eine bestimmte, einmalige Adresse. Wenn nun ein Datensatz für Display #irgendwas kommt wird das immer empfangen und so lange weiter geschickt, bis das adressierte Display den Datensatz bekommt. Du hast also immer nur eine 2-2.5m lange Verbindung und da jede Verbindung autark ist und du dein Protokoll selber bestimmen kannst, kannst du beliebig viele Displays kaskadieren. z.B. ATXmega8E5
:
Bearbeitet durch User
Dazu brauch man keine zwei UARTs. Mit RS485 braucht auch nur jeder Teilnehmer seine Adresse kennen.
Basti schrieb: > Dazu brauch man keine zwei UARTs. > Mit RS485 braucht auch nur jeder Teilnehmer seine Adresse kennen. Aber einen RS485-Treiber. 2 uCs mit UART verbinde ich direkt ohne Treiber.
Dann brauch ich immer noch keine zwei UARTs, da ich TX und RX der einen UART völlig unabhängig steuern kann.
Basti schrieb: > Dann brauch ich immer noch keine zwei UARTs, da ich TX und RX der einen > UART völlig unabhängig steuern kann. Da reicht es aber schon, das Signal hinter dem RX-Puffer weiterzuleiten. Das geht schon mit einem billigen RS232 Bauteil (1/2 MAX232 reicht), ist schneller und belastet nicht alle µCs.
Für 1-2m reicht I2C immer noch aus, selbst ohne I2C Extender. Mit dem PCF8574(A) kann man 16 LCDs ansprechen. Das Ganze 8x macht 128 LCDs. Also braucht man noch 2x 4:1 I2C Mux ala PCA9544A oder 1x PCA9547. https://www.mikrocontroller.net/articles/Port-Expander_PCF8574 Das Ganze kann man spielend mit einem kleinen Arduino ansteuern, der ggf. über USB am PC hängt und von dort weitere Anweisungen erhält.
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.