Hallo, ich bin größtenteils ein Einsteiger auf dem Gebiet der Mikrocontroller, aber schon sehr erfahren mit Arduino. Ich versuche mit verschiedenen ATtinys (85/24) ein Netzwerk zu bauen, in dem einige ATtinys Analoge Daten weitergeben und alle an einen ATtiny weitergeben sollen, der diese Daten dann auswertet und anderen ATtinys sagen soll, was sie machen sollen. Erstmal die Frage: Ist das machbar? Zweitens: Kann ich die ATtinys alle an eine Datenleitung zu dem Endverbraucher hängen? Drittens: Kann ich mehrere solcher Netzwerke als "Eingabegeräte" für einen Arduino benutzen? Mein Ziel ist es, mit Werten von bis zu 40 Potis und bis zu 20 Knöpfen über einem Arduino Mega eine Lichtanlage zu steuern. Quasi ein Bühnenpult DiY.
Informiere dich mal über das Stichwort "Bus Systeme". Für kurze Leitungen geht vielleicht der I²C Bus. Ansonsten wäre RS485 ein gängiger Kandidat.
Das hat nichts mit dem Prozessor zu tun! Das ist nur eine Frage des Übertragungsprotokolls, der Entfernung und auch der Zeit, die für so etwas übrig ist. Praktisch alle Prozessoren dieser Reihe haben eine serielle Schnittstelle. Oder, falls der Speicher nicht proppenvoll ist, machst Du es mit Software.
PerLüß schrieb: > ich bin größtenteils ein Einsteiger auf dem Gebiet der Mikrocontroller, > aber schon sehr erfahren mit Arduino. D.h.: du kannst rein garnix selber. > Ich versuche mit verschiedenen ATtinys (85/24) ein Netzwerk zu bauen, > in dem einige ATtinys Analoge Daten weitergeben und alle an einen ATtiny > weitergeben sollen, der diese Daten dann auswertet und anderen ATtinys > sagen soll, was sie machen sollen. > Erstmal die Frage: Ist das machbar? Natürlich. > Zweitens: Kann ich die ATtinys alle an eine Datenleitung zu dem > Endverbraucher hängen? Kommt drauf' an. Datenrate, Leitungslänge und Anzahl. > Drittens: Kann ich mehrere solcher Netzwerke als "Eingabegeräte" für > einen Arduino benutzen? Klar. > Mein Ziel ist es, mit Werten von bis zu 40 Potis und bis zu 20 Knöpfen > über einem Arduino Mega eine Lichtanlage zu steuern. Quasi ein > Bühnenpult DiY. Dann vergiss diesen Arduino-Dreck (die Hardware kannst du durchaus weiter nutzen) und lerne selber zu denken und zu programmieren.
nein, eine Kommunikation ist technisch völlig unmöglich. Sonst hätte das sicher schon irgendwer gemacht
Hallo Peter, das was Du vor hast, lässt sich eventuell machen. Es wäre aber wichtig, sich erst mal Gedanken über die geforderte Datenrate zu machen. Autor: c-hater (Gast) >Dann vergiss diesen Arduino-Dreck (die Hardware kannst du durchaus >weiter nutzen) und lerne selber zu denken und zu programmieren. Starke Worte eines kleinen Geistes.
Für einen Anfänger ist es sehr schwer, eine zuverlässige Kommunikation mehrerer MCs aufzubauen. Deutlich einfacher ist es daher, alles mit einem MC zu machen. Mehrere ADC-Eingänge kann man leicht mit 74HC4051 multiplexen. Und mehrere Digitaleingänge mit 74HC165 kaskadiert einlesen.
Leute, warum immer gleich so superböse Kommentare? Der gute Mann hat euch doch nicht angegriffen... PerLüß schrieb: > > Mein Ziel ist es, mit Werten von bis zu 40 Potis und bis zu 20 Knöpfen > über einem Arduino Mega eine Lichtanlage zu steuern. Quasi ein > Bühnenpult DiY. Dann bleibt eigentlich nur DMX. Google mal danach. DMX ist der de facto Standard für so eine Aufgabe und du wärest auch kompatibel zu Standard-Produkten. Für Arduino/AVR gibt es Projekte wie Sand am Meer. DMX ist supersimpel im Aufbau, einzig die Synchronisation im Empfänger ist vielleicht manchmal etwas tricky. Aber dafür gibt es Beispiele.
Ich würde alles mit 3 bis 4 leistungsstarken Arduinos problemlos auf die Reihe bekommen, aber ich habe ein kleines Geldproblem, daher muss ich mit 20-30 ATtinys auskommen
Harald schrieb: > Dann bleibt eigentlich nur DMX. Google mal danach. > > DMX ist der de facto Standard für so eine Aufgabe und du wärest auch > kompatibel zu Standard-Produkten. Für Arduino/AVR gibt es Projekte wie > Sand am Meer. DMX ist supersimpel im Aufbau, einzig die Synchronisation > im Empfänger ist vielleicht manchmal etwas tricky. Aber dafür gibt es > Beispiele. Ja, ich ziele auf DMX ab ( da bin ich Profi ) aber ich muss das ganze für wenig Geld über Arduinos und ATtinys laufen lassen und ein Arduino hat bekanntlich nicht so viele analoge Inputs für die ganzen Fader.
PerLüß schrieb: > Ich würde alles mit 3 bis 4 leistungsstarken Arduinos ... So einen Arduino Due mit 32-Bit ARM kostet 11€, ein Arduino Pro Mini mit ATmega328 etwa 1,80€ und du meinst, dass du mit irgendwelchen selbstgestrickten ATtinys-Boards günstiger wirst? ADC Module lassen sich über I2C anhängen, z.B. ADS1115 mit 4 Kanälen gibt's für 2€ und ein 16 Kanal Analogmultiplexer (CD74HC4067) gibts für ähnliches Geld - fertig auf einem kleinen Board aus CN.
Wenn du jeden ADC Pin deines MC an einen CD4051 hängst, kannst du mit einem ADC Kanal 8 analoge Inputs abfragen, zum Umschalten der Multiplexer werden einmalig 3 Digitalausgänge benötigt. Mit einem CD4067, wie oben erwähnt, sind es pro ADC Kanal 16 Analogeingänge zum Preis von einmalig 4 Digitalausgängen. Das reicht für sehr viele Fader und anders machens die Profis auch nicht.
PerLüß schrieb: > für wenig Geld über Arduinos und ATtinys laufen lassen und ein Arduino > hat bekanntlich nicht so viele analoge Inputs für die ganzen Fader. Wo willst Du denn sparen? Ich denke, dass DMX schon sehr preiswert ist. Andere Methoden geben vermutlich keine Ersparnis, vorausgesetzt es soll auch stabil funktionieren.
Der Arduino Nano hat 8 analoge Eingänge und kostet 2 bis 3 €. Das "Blue-Pill" Board (STM32F103C8T6) ist Arduino kompatibel, hat 10 analoge Eingänge und kostet ebenfalls 2 bis 3 €. Der A/D Wandler MCP3208 hat 8 analoge Eingänge und wird sehr einfach per seriellem SPI Bus angesprochen. Davon kannst du ganz viele an einen einzigen µC anschließen. Kostet auch wieder nur 2 bis 3 € (wer hätte das gedacht?) Die bisherigen Empfehlungen zu Analogschaltern (CD4051 und ähnliche) möchte ich damit nicht abwerten. Die auch günstig und vorteilhaft. > für wenig Geld Konnten wir Dir damit helfen?
Stefan U. schrieb: > Die bisherigen Empfehlungen zu Analogschaltern (CD4051 und ähnliche) > möchte ich damit nicht abwerten. Tust du nicht. Der erste Block im MCP3208 ist ein Analog-Multiplexer. Der DAC dahinter ist einkanalig und so ein DAC wäre im µC genauso verfügbar ;-)
Harald schrieb: > Wo willst Du denn sparen? Ich denke, dass DMX schon sehr preiswert ist. > Andere Methoden geben vermutlich keine Ersparnis, vorausgesetzt es soll > auch stabil funktionieren. Definitiv ist DMX sehr preiswert und ich werde das nur darüber machen. Und sparen tue ich mit meinen ATinys sehr viel, weil ich die für ca. 60ct pro Stück gekauft habe.
Noch mal die Frage: Was für ein Protokoll bzw. System würdet ihr mir zur Kommunikation der MCs empfehlen und wie würde ich das Signal an einem Arduino empfangen? PS: Ich werde definitiv nicht auf irgendwelche erweiterungen oder fertige Adapter/Systeme für Arduino umsteigen, weil ich eine Menge ATtinys habe und nicht vorhabe mehr geld für solche Sachen auszugeben. Ich würde mich sehr über konstruktive Vorschläge freuen, destruktive Kommentare kann ich echt nicht gebrauchen.
Ich dachte die Entscheidung seit für DMX gefallen. Versuche es doch erstmal damit, wenn es nicht klappt, hast du konkrete Gründe und dann man schauen, wie man diesen begegnet.
PerLüß schrieb: > Harald schrieb: > >> Wo willst Du denn sparen? Ich denke, dass DMX schon sehr preiswert ist. >> Andere Methoden geben vermutlich keine Ersparnis, vorausgesetzt es soll >> auch stabil funktionieren. > > Definitiv ist DMX sehr preiswert und ich werde das nur darüber machen. > Und sparen tue ich mit meinen ATinys sehr viel, weil ich die für ca. > 60ct pro Stück gekauft habe. D.h. Du hast Hardware gekauft bevor Du wusstest wie Du es (gut) lösen kannst. Und jetzt willst Du / musst Du mit aller Gewalt bei den Tinys bleiben, obwohl einige deutlich bessere Vorschläge kamen. Das ist clever angefangen :-)
PerLüß schrieb: > Ich würde mich sehr über konstruktive Vorschläge freuen, destruktive > Kommentare kann ich echt nicht gebrauchen. Wenn sich jemand doof anstellt, dann muss er sich das gefallen lassen. Und das mit Dutzenden von Attinys zu lösen ist keine clevere Lösung. Schon alleine, dass man Dutzende Mal die Firmware flashen / pflegen muss ist schon eine Schnapsidee.
PerLüß schrieb: > Was für ein Protokoll bzw. System würdet ihr mir zur Kommunikation der > MCs empfehlen und wie würde ich das Signal an einem Arduino empfangen? Du musst doch wissen, was du für Anforderungen an das Kommunikationsprotokoll und die Übertragungsstrecke hast (Zeitauflösung, (quasi-)parallele Übertragung), Größe und Art der zu übertragenden Informationspakete, maximal Teilnehmeranzahl, Länge der Übertragungsstrecke, Störungen im Umfeld, Anforderungen Fehlertoleranz, ...). Das könntest du erstmal formulieren.
Conny G. schrieb: > Schon alleine, dass man Dutzende Mal die Firmware flashen / pflegen muss > ist schon eine Schnapsidee. Der mit Abstand größte Aufwand geht in die Software selber. Mit Arduino-Standardbaukasten-Wissen ist bei diesem Vorhaben wenig auszurichten. Da dürfte sich der TE maßlos verschätzen- aber man wächst ja bekanntlich an seinen Aufgaben :)
PerLüß schrieb: > Und sparen tue ich mit meinen ATinys sehr viel, weil ich die für ca. > 60ct pro Stück gekauft habe. Da wurde leider am falschen Ende gespart. Das wirst Du noch merken!
Vergiss mehrere Controller, nimm besser externe ADCs, oder Multiplexer.
Vor allem der ATtiny24 dürfte für ein ordentliches Übertragungsprotokoll extrem knapp (wenn nicht gar zu wenig) mit RAM und Flash ausgestattet sein. Und beim ATtiny85 drängt sich mir die Frage auf, warum man einen µC mit so wenig Pins verwendet, wenn man ganz viele Eingabe-Elemente abfragen will. Es ist ja nicht grundsätzlich verkehrt, alte Teile zu verbrauchen. Aber sie sollten wenigstens ungefähr zum Anwendungsfall passen, sonst programmierst du dir am Ende einen Wolf und hast dennoch kein zufriedenstellendes Ergebnis. Glaube mir, du wirst das Ding mindestens zwei mal bauen.
Stefan U. schrieb: > Glaube mir, du wirst das Ding mindestens zwei mal bauen. ... oder gar nicht mehr... Gruss Chregu
PerLüß schrieb: > Mein Ziel ist es, mit Werten von bis zu 40 Potis und bis zu 20 Knöpfen > über einem Arduino Mega eine Lichtanlage zu steuern. > Quasi ein Bühnenpult DiY. Und wofür sind da jetzt mehrere Prozessoren nötig? Bis du da eine eigene Multiprozessorkommunikation zuverlässig ans Laufen gebracht hast, bis dahin könntest du schon fertig sein, wenn du ein paar Vielkanal-ADC (wie zB. AD7490) und ein paar Schieberegister per SPI ausliest...
Multiprozessorkommunikation, und gleich mit RS422/RS485 oder aehnlich ... sportlich. Naja wenn's nachher laeuft hat der Poster etwas gelernt.
Lothar M. schrieb: > ... wenn du ein paar Vielkanal-ADC (wie zB. AD7490) Ein AD7490 mit seinen 1MSPS dürfte zum Abfragen von ein paar Potis allerdings mehr als großzügig dimensioniert sein. Insbesondere kostenmäßig liegen Analogmultiplexern vor dem µC aber wohl deutlich eher im Budget des TO.
Wolfgang schrieb: > Insbesondere kostenmäßig liegen Analogmultiplexern vor dem µC aber wohl > deutlich eher im Budget des TO. Dann nehme ich für 48 AD-Eingäge 4 von den MAX11605. Die über I2C eingelesen und fertig...
Es ist wirklich super, das sich so viele an dieser Diskussion beteiligen und ich bedanke mich für jeden Vorschlag(den ich überdenke), möchte aber nochmal klarstellen, dass ich weiß das ich mir mit meinem Vorhaben eine sehr schwirige und vlt. nicht so gute Aufgabe gestellt habe. Ich möchte aus diesem Projekt aber auch was lernen hinsichtlich der MCs, Arduino und Kommunikation. Ich fürchte ich muss nochmal klarstellen, dass ich kein Anfänger bin, sondern mit ähnlich schwirigen (vlt. noch schwirigeren) Projekten ohne Anleitung gelernt und trainirt habe. Also wenn ihr jetzt bitte aufhören würdet mir ADCs und Multiplexer schön zu reden... :-) Ich möchte lediglich etwas lernen, und zwar Kommunikation von einzelnen MCs wenn möglich in Reihe. Ich weiß, dass mein Lösungsansatz mit den ATtinys vlt. etwas wenig Leistung beinhaltet, aber ich möchte die Aufgaben verteilen und nicht ein Programm für einen großen MC basten (davon hab ich echt genug). Wenn keine besseren Vorschläge kommen werde ich es dann einfach mal mit RS422/RS485 probieren. :-) Vielen Dank für die vielen konstruktiven Beiträge.
> Ich fürchte ich muss nochmal klarstellen, dass ich kein Anfänger bin
Sorry, aber wie passt die Frage "Kann man ATtinys in Reihe miteinander
kommunizieren lassen?" dazu?
Wenn du kein Anfänger bist, dann weißt du, dass man jeden I/O Pin
einzeln per Software ansteuern und auslesen kann. Du hast also volle
Kontrolle über den Pin und kannst damit jede beliebige Kommunikation
umsetzen. Nur die Taktfrequenz des µC beschränkt dich dabei.
Sicher hast du auch schon von V-USB oder USBASP Programmieradaptern
gehört (wahrscheinlich besitzt du sogar mindestens einen), die das vor
machen. Wenn Leute das mit USB geschafft haben, dann geht es mit
einfacheren Protokollen erst Recht.
Stefan U. schrieb: > Du hast also volle > Kontrolle über den Pin und kannst damit jede beliebige Kommunikation > umsetzen. Nur die Taktfrequenz des µC beschränkt dich dabei. Also geht es mit RS422?!
> Also geht es mit RS422?!
Ja sicher!
geht auch ohne - wenn deine Leitungen kurz sind.
Lothar M. schrieb: > Dann nehme ich für 48 AD-Eingäge 4 von den MAX11605. Die über I2C > eingelesen und fertig... Bei 4 Stück muss man sich da wieder Gedanken über I2C-Multiplexer machen. Drei CD74HC4067 o.ä. 16:1 (alternativ 6 74HC4051 8:1) Analogmultiplexer vor einen µC mit seinerseits einem x:1 Multiplexer, dürfte genauso gut funktionieren, man hat gewöhnlich eine höhere Auflösung und spart den I2C-Mux. Kostenmäßig liegt man damit sowieso günstiger, sofern man auf jeden Cent gucken möchte.
Mein Opa hat vor 40 Jahren schon gesagt: "Wer billig kauft, kauft zweimal" Ab einem gewissen Punkt muss einem klar sein, dass man für eine Leistung auch etwas Geld ausgeben muss. Das fängt bei einer Zange an, geht bei der Lötstation weiter und endet am Prozessor. Anstatt zu überlegen, was will ich und was brauch ich dafür, werden erst einmal Prozessoren gekauft, weil die so schön billig sind.... Da überlegt man sich doch vorher, können die das überhaupt und was brauche ich für eine externe Beschaltung. Und dann ist auch klar, was das kostet. Aber so....
Wolfgang: erst lesen, dann antworten: PeterLüß schrieb: > Also wenn ihr jetzt bitte aufhören würdet mir ADCs und > Multiplexer schön zu reden... :-)
PittyJ schrieb: > Anstatt zu überlegen, was will ich und was brauch ich dafür, werden erst > einmal Prozessoren gekauft, weil die so schön billig sind.... Ich habe diese MCs auf Lager gehabt und habe nicht gebügend Geld um mir jetzt noch großarteig andere Geräte zu kaufen. Also warum nicht versuchen diese MCs zu recyclen?
Stefan U. schrieb: > Wolfgang: erst lesen, dann antworten: > > PeterLüß schrieb: >> Also wenn ihr jetzt bitte aufhören würdet mir ADCs und >> Multiplexer schön zu reden... :-) DANKE! PS: PerLüß (nicht Peter)
Stefan U. schrieb: >> Also geht es mit RS422?! > > Ja sicher! > geht auch ohne - wenn deine Leitungen kurz sind. Wie soll ich das verstehen, dass die Leitungen kurz sind? Ich werde zwischen 5-10cm kupferlitze verwenden, aber ohne was?
PerLüß schrieb: > Also geht es mit RS422?! Was würde dagegen sprechen? Aber wozu willst du in einem Gerät unbedingt mit differentieller Übertragung anfangen? Wie groß soll denn das Gerät werden? 1x2m? PerLüß schrieb: > wenn möglich in Reihe. Warum müssen die in deinem Konzept unbedingt "in Reihe" sein? Welche Gründe ausser "ich will!" hast du da? PerLüß schrieb: > 5-10cm kupferlitze Bei Leitungslängen in diesem Bereich geht das sogar mit TTL-RS232. Der "Master" adressiert über die TX-Leitung und ganz ohne Pegelwandler einen aus vielen Slaves. Und der antwortet dann über eine "vorteilhaft" verschaltete RX-Leitung, während die anderen Slaves die Füße still halten.
:
Bearbeitet durch Moderator
Für so kurze Leitungen brauchst du ganz sicher keine Treiberbausteine. Lies Dich mal zum Thema I²C Bus ein, da hast du dann nicht nur elektrische Vorgaben, sondern auch ein grundlegendes Übertragungsprotokoll auf das du aufsetzen kannst.
PerLüß schrieb: > ich bin größtenteils ein Einsteiger auf dem Gebiet der Mikrocontroller PerLüß schrieb: > Ich fürchte ich muss nochmal klarstellen, dass ich kein Anfänger bin Was soll man davon halten? PerLüß schrieb: > in dem einige ATtinys Analoge Daten weitergeben und alle an einen ATtiny > weitergeben sollen, der diese Daten dann auswertet und anderen ATtinys > sagen soll, was sie machen sollen Alle sind sich einig, daß diese Lösung suboptimal ist. Wenn es aber so gemacht werden muß daß nur die vorhandenen Tinys eine Verwertung finden dann dürfte Möglichkeit und Unmöglichkeit im Spektrum zunehmender Schwierigkeit entscheidend von der Anzahl zu übertragender Daten abhängen. Jeder Tiny hat einen digitalen Eingangs- und einen digitalen Ausgangspin und die werden in Reihe miteinander verknüpft- der Rest kann dann für lokale analoge/digitale I/O für Potis und Knöpfe Verwendung finden. Nun könnte durch die Kette ein einziges großes Datenfeld durchgeschoben werden an dem jeder Tiny seine Daten einträgt und aus einem Ausgabefeld seine Daten aus fixen Positionen empfängt. Letzteres bestückt der Master-Tiny nach Auswertung aller empfangenen Slave-Tiny Date der in dieser Kette voll eingebunden ist. Es ist offensichtlich daß hier die RAM-Kapazität einzelner Tinys der begrenzende Faktor für das Datenpaket insgesamt wäre da es jeweils der Übersicht wegen lokal in jedem Tiny vor dem Weitertransport zwischengespeichert würde. Der Vorteil ist bei diesem Vorgehen auch daß die Software der einzelnen Slaves weitestgehend identisch sein könnte und das Datenpaket im Rahmen der Speicherkapazität nach Bedarf einfacher in der Größe änderbar wäre - sprich einfacher Slaves hinzugefügt/entfernt werden könnten. Eine radikalere speicherplatzsparendere Lösung wäre einfach das Daten- Durchschleusen und Hinzufügen der eigenen Slave-Daten nach Übertragungsende, so daß das Datenpaket auf dem Transportweg der Kette laufend wächst. Am Anfang der Kette stünde der Master mit seinen Ausgabedaten. Die prüft jeder Slave Tiny für sich auf Relevanz. Das Ganze dürfte aber nicht mehr so flexibel und vor allem performance-hungriger sein weil sich das Hinzufügen eigener Daten nicht groß verzögern sollte. Im Grunde eine schöne Spielwiese auf der lange für Programmierspaß gesorgt ist... Soll man nun Lachen oder Weinen? :-)
Angehängte Dateien:
-
ArduinoATtinys.JPG
140 KB
> Alle sind sich einig, daß diese Lösung suboptimal ist.
Ich auch.
Das ist genau das, was ich wissen sollte.
Mein Entwurf für das Ziel ist im Anhang zu sehen.
Ich werde es mit rs232 probieren.
Vielen Dank.
PerLüß schrieb: > Ich werde es mit rs232 probieren. Solange die ganzen Schieber in einer Box eingebaut sind, ist RS232 für jeden einzelnen ATtiny absolut übertrieben. Über so kurze Strecken geht die Übertragung genauso gut mit 5V-Pegeln und man kann sich den ganzen Treiberkram sparen. Erst wenn es aus der Kiste raus und auf längere Leitungen geht, wäre ein solider Bustreiber angesagt, wobei RS232 da auch nicht die erste Wahl wäre, sondern eher RS422/RS485 o.ä.
PerLüß schrieb: > Ich werde es mit rs232 probieren Ganz oben sprichst du von ATTiny85/24, beide haben keinen echten UART. Also per Software UART? Beim Senden mag das ja noch einigermaßen abbildbar sein, beim Empfang ist das eine Krücke sondergleichen. Musst Du irgendwie noch Buße tun oder warum sollte man sich das freiwillig antun?
Wolfgang schrieb: > PerLüß schrieb: >> Ich werde es mit rs232 probieren. > > Solange die ganzen Schieber in einer Box eingebaut sind, ist RS232 für > jeden einzelnen ATtiny absolut übertrieben. Über so kurze Strecken geht > die Übertragung genauso gut mit 5V-Pegeln und man kann sich den ganzen > Treiberkram sparen. Was meinst du mit 5V pegeln? Treiber würde ich gerne sparen.
Harald schrieb: > Musst Du irgendwie noch Buße tun oder warum sollte man sich das > freiwillig antun? Ich eigne mir Wissen ganz gerne durch lösen solcher Probleme an. So habe ich schon so manchen Elektroschrott in ganz nette Sachen verwandelt und dabei mit Spaß gelernt.
PerLüß schrieb: > Ich fürchte ich muss nochmal klarstellen, dass ich kein Anfänger bin, > sondern mit ähnlich schwirigen (vlt. noch schwirigeren) Projekten ohne > Anleitung gelernt und trainirt habe. Das glaube ich dir nicht. Nicht angesichts der Formulierung deiner Fragen. > Also wenn ihr jetzt bitte aufhören würdet mir ADCs und Multiplexer > schön zu reden... :-) Ich möchte lediglich etwas lernen Und warum machst du es dann nicht? Spätestens beim Hinweis auf das Stichwort "Feldbus" war der Keks doch gegessen. Lernen ist etwas, das du schon selber tun mußt. Und dabei hast du es heutzutage viel leichter, als die Generationen vor dir. Du mußt einfach nur ein Stichwort in die Suchmaschine deiner Wahl eingeben und dann lesen. Wenn du unsicher bist: fang bei Wikipedia an. Folge den Verweisen. Eine Frage an ein Forum zu stellen, in der Hoffnung eine Lösung gesagt (oder gar gemacht) zu bekommen, ist das ziemlich genaue Gegenteil von "Lernen".
PerLüß schrieb: >>> Ich werde es mit rs232 probieren. >> Solange die ganzen Schieber in einer Box eingebaut sind, ist RS232 für >> jeden einzelnen ATtiny absolut übertrieben. Über so kurze Strecken geht >> die Übertragung genauso gut mit 5V-Pegeln und man kann sich den ganzen >> Treiberkram sparen. > > Was meinst du mit 5V pegeln? Treiber würde ich gerne sparen. Ja eben! Ach... Gruss Chregu
Vielleicht brauchst Du nichtmal RS232. Schau Dir mal das Protokoll der WS2812 LED Streifen an. Willis Beschreibung ziehlt genau darauf ab.
PerLüß schrieb: >> Alle sind sich einig, daß diese Lösung suboptimal ist. > Ich auch. > > Das ist genau das, was ich wissen sollte. > > Mein Entwurf für das Ziel ist im Anhang zu sehen. > > Ich werde es mit rs232 probieren. > > Vielen Dank. Das Bild zeigt ja dann endlich mal, was es werden soll. Wer da keine paar Multiplexer direkt an den Arduino hängt, der liebt es kompliziert. Wieviele Fader-swipes je Sekunde sollen es denn werden? Wenn man diese 100/s abtasten will, dann kann der Arduino locker 50 davon betreuen. Und 2-stufig kaskadierte 4051 sind für 64 Kanäle ausreichend. Auch die Software sollte kein Problem sein für jemanden, der ein Tinyx5 Netzwerk rein per Bitbang hinbekommt. Und notfalls kann man das sogar kaufen: https://www.sparkfun.com/products/11723 48 Kanäle, $25, incl. Library
Multiplexloesung mit 4067 Analogmultiplexer.
48 Eingaenge: 3 x 4067 = 3 x 65cent = 1.95
1 x Atmega88 1.99
Gesammt: 3.94 Euro + Chickenfood.
Software dazu in einer 1/2 h geschrieben. ADC Routine und darum eine
Schleife bis 48 gemacht und ins RAM ablegen.
Alles andere kostet wesentlich mehr Zeit. Alleine das loeten von den
ganzen ANtinys braucht wohl mehr an Stromkosten als es vernueftig zu
machen.
PerLüß schrieb: > Mein Entwurf für das Ziel ist im Anhang zu sehen. Worauf basiert dieser Entwurf? Warum machst du den "Bus" durch die µC durch? Da muss ja der µC vor dem "Master" alle Daten der vorangehenden fehlerfrei empfangen und wieder fehlerfrei senden. Unnötiger Overhead. Wie gesagt: der Bus gehört neben die µC (so wie Onewire/CAN/I²C/RS485...)? Conny G. schrieb: > Schau Dir mal das Protokoll der WS2812 LED Streifen an. Von der aderen Datenflussrichtung (Schreiben statt Lesen) dieser Bauteile mal abgesehen: deren Hardware ist auf das "Durchschieben und Aussortieren" ausgelegt. Jeder in der Kette nimmt sich die ersten paar Bytes und gibt den Rest "nach hinten" weiter.
Wenn denn der Weg das Ziel ist: Ich verstehe es so. Die Tinys sind 8-Pinner, wovon drei Pins für GND,VCC und Reset draufgehen. Einmal Daten rein, einmal raus, bleiben noch drei Eingänge für die Fadermessungen. Hab ich das so richtig gedeutet? Bleibt im Ring (ist das Daisy Chain?!?) ja nur ein asynchrones Protokoll, weil Taktleitung geht nicht mehr. Als Bus mit einem Master geht I2C aber immer noch, da hier die Datenleitung bidirektional verwendet wird. Ganz ehrlich? Im Ring mit ner Bitbanging-UART klingt hübsch, ist aber so ziemlich das fieseste, was geht, einfach, weil Du mit RC-Oszillator nicht einmal einen stabilen Takt hast. Spätestens, wenn Deine Daten das Konstrukt verlassen und mit Arduino, PC oder sonstewas kommunizieren, wird das kritisch, weil Quarze und RC gänzlich andere Temperaturkoeffizienten haben. Da fummelt man sich also mühsam Timerkonstanten raus, die bei 10° mehr oder weniger nicht mehr funktionieren. Auch das kannst Du softwareseitig herausarbeiten, indem Du in den Datenstream Synchronisationsbytes (0xAA auf 9Bit) einstreust und die Empfänger darauf als Kaskade synchronisierst (Geprüft wird u.A. auf das 9. Bit, das immer 0 sein muss, Synchronisiert wird auf den schnellsten Taktwechsel im 01010101-Pattern). Das KANN man machen, zur eigenen oder allgemeinen Bildung trägt es aber nicht bei. Den Hassel tust Du Dir mit I2C prinzipbedingt nicht an. Da wird die Kommunikation vom Master (Arduino MIT Quarz) per Taktleitung synchronisiert. Aber auch das nur, wenn der Weg das Ziel ist. Ansonsten kann man sich über Multiplexer&Co ne Menge Arbeit und auch Drahtverhau sparen.
> Musst Du irgendwie noch Buße tun oder warum sollte man sich > das freiwillig antun? Ich glaube, er hat noch keine Erfahrung mit der USI Schnittstelle gemacht. Die macht wirklich keinen Spaß.
Lothar M. schrieb: > Von der aderen Datenflussrichtung (Schreiben statt Lesen) dieser > Bauteile mal abgesehen: deren Hardware ist auf das "Durchschieben und > Aussortieren" ausgelegt. Jeder in der Kette nimmt sich die ersten paar > Bytes und gibt den Rest "nach hinten" weiter. Der Vorschlag war doch auch nicht, das WS2812-Protokoll 1:1 zu verwenden. Die Idee war, dass der erste µC seine(n) Wert(e) auf die Leitung schickt, der nächste empfängt, reicht weiter und fügt seine eigenen Werte an. Dadurch baut sich der gesamte Datenblock über die Kette immer weiter auf und kommt beim letzten µC der Kette fertig raus. Wenn jeder µC direkt nach der Aussendung seinen AD-Wandler anschmeißt und der erste einen angemessenen Takt für den Datenrefresh vorgibt (Messtaktperiode länger als Gesamtdatenblockdauer) braucht auch keiner der µCs den Datenblock zwischenzuspeichern.
Stefan U. schrieb: > Ich glaube, er hat noch keine Erfahrung mit der USI Schnittstelle > gemacht. Die macht wirklich keinen Spaß. Die ist so einfach gestrickt, dass man eigentlich fast nichts falsch machen kann. Wo genau siehst du da ein Problem? Tipp: Lag durch lausige Programmiersprachen zählt nicht als ernsthaftes Problem...
> Wo genau siehst du da ein Problem?
Man muss sehr viel "zu Fuß" programmieren.
Lothar M. schrieb: > Warum machst du den "Bus" durch die µC > durch? Da muss ja der µC vor dem "Master" alle Daten der vorangehenden > fehlerfrei empfangen und wieder fehlerfrei senden. Unnötiger Overhead. Steht keine spezialisierte Bus-Hardware zur Verfügung ist dafür die permanente Analyse des Busgeschehens fällig. Nicht unbedingt einfacher!
Es sind mit solch vielen Potis ein Haufen von Teile, die ausfallen koennen. Weshalb nicht ein Tablet mit Touch-Potis als Eingabgeraet, als Mobile Anwendung ? Verbindund zum Mischpult per Bluetooth.
Angehängte Dateien:
-
ws2812_protocol.png
12 KB
Das WS2812 Protokoll ist eigentlich ziemlich einfach. Man kann ja mit kleineren Geschwindigkeiten fahren. z.B. mit 100us pro Bit. Mal sehen: 18 Potis x 10 Bit = 180 Bit => ~18ms Datenstromlänge Wer machts?
Oha, das ist aber ein ausdauernder Karfreitagstroll gewesen... Oder soll man sowas beklopptes wirklich ernst nehmen? Wenn Paul Stoffregen das wüsste, würde er ihn gnadenhalber mit Teensy3.6 steinigen :p
Man könnte 3 Symbole definieren: 0: 25us low, 75us high 1: 75us low, 25 low Reset bzw Framestart: Zeiten größer 300us
Wie soll der Vogel sowas umsetzen, wenn er nicht mal rs232, 485 etc. und Protokolle auseinanderhalten kann bzw. will?
Mich interessiert es selber. Im Moment erscheint mir der Aufwand überschaubar ( Ich habe schon einige eigene Protokolle entwickelt ). Man kann ja mal auch ein wenig vom Mainstream abweichen, warum nicht? Mir ist aufgefallen, dass sich das Verfahren von dem der WS2812 unterscheiden muss. Bei den WS2812 nimmt jede LED 24 Bit aus dem Datenstrom heraus. Bei den Poti-MCs muss es umgekehrt sein: Jeder MC muss zum Datenstrom seine Bits hinzufügen. Die WS2812 haben den Vorteil, dass sie den längeren Puls als Signal zum "latchen" der RGB Werte verwenden können. Bei den Potis müsste es anders sein: Es muss erkannt werden, dass das letzte Bit gekommen ist und der MC jetzt anfangen kann, seine eigenen Bits anzuhängen.
Conny G. schrieb: > Vielleicht brauchst Du nichtmal RS232. > Schau Dir mal das Protokoll der WS2812 LED Streifen an. > Willis Beschreibung ziehlt genau darauf ab. Meinst du, ich könnte das für mein Projekt verwenden? Es wäre ja genau umkekehrt.
Autor: PerLüß (Gast) >Meinst du, ich könnte das für mein Projekt verwenden? Es wäre ja genau >umkekehrt. Hast Du meinen Post eins drüber gelesen? Da habe ich gerade erklärt, warum es nicht geht.
Natürlich geht das. 1. Soft uart bauen. 2. Bei sagen wir mal 8bit adc Auflösung 48bytes vom ersten Tiny zum 2. Schicken, dabei bekommt das erste Byte den adc Wert. Der zweite legt das in den RAM, packt seinen adc Wert dazu. Bei 2 potis eben je 2 Bytes. Das immer weiter bis die Werte hinten rauspurzeln und in den vernünftigen Controller gehen. Aaaaber: du wirst RAM Probleme bekommen. Ausserdem wird's echt blöd wenn der Takt durch temperaturschwankungen wegläuft. 3. Selber denken. Bist doch so ein erfahrener Arduinofuchs!
Wolfgang schrieb: > Die Idee war, dass der erste µC seine(n) Wert(e) auf die Leitung > schickt, der nächste empfängt, reicht weiter und fügt seine eigenen > Werte an. Dann kann beim 4-maligen Empfangen 4 mal was schief gehen. Meine Erklärung war dass der WS eben nicht alle Daten empfängt, sondern eben nur die seinen. Die anderen Nachfolgenden reicht er dank spezieller Hardware geradeaus durch ohne Empfang oder gar Interpretation.
Autor: Hauke Haien (Gast)
>1. Soft uart bauen.
Das ist fast ein wenig zu "unkreativ" und du läufst in die beschriebenen
Probleme.
Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite >Meine Erklärung war dass der WS eben nicht alle Daten empfängt, >sondern eben nur die seinen. Die anderen Nachfolgenden reicht er dank >spezieller Hardware geradeaus durch ohne Empfang oder gar >Interpretation. Die Logik der WS ist extrem einfach. Die einzelne LED muss sich nur die 24Bit raus schneiden und dann die Leitung einfach via Multiplexer durchrouten. Damit entfällt das Zwischenspeicherproblem. Die Pulskodierung der WS hat den Vorteil der hohen Oszillatortoleranz. Deshalb macht es Sinn, ebenfalls ein Pulslängenprotokoll zu verwenden.
chris schrieb: > Autor: Hauke Haien (Gast) >> 1. Soft uart bauen. > Das ist fast ein wenig zu "unkreativ" und du läufst in die beschriebenen > Probleme. Macht nix. Damit hat er einen halbwegs funktionierenden Ansatz und kann daraus lernen. Reicht der RAM nicht, kann er auch immer nur 2er oder 3er Ketten aus adresse und 1bzw. 2 adc werten im Kreis schicken. Geht auch. Er hat aber ka bisher nicht mal verraten, welche Sprache er zu verwenden gedenkt. Es sei denn, er hält DMX für eine Programmiersprache...
>Macht nix. Damit hat er einen halbwegs funktionierenden Ansatz und kann >daraus lernen. Hattest Du nicht die Temperaturprobleme beschrieben. Damit ist der halbwegs funktionierende Ansatz ein "nicht funktionierender" Ansatz. Ich habe einen besseren Vorschlag: Eine UART ist unnötig. Man kann die Betrachtung auf das einzelne Bit richten. Der Algorithmus könnte ungefähr folgendermaßen aussehen: 1. Erkennen, ob ein 0 oder 1 Bit empfangen wurde. 2. Falls Bit erkannt, Bit weiter senden 3. Wenn der Bitstrom endet, anfangen eigene Bits zu senden Die Bits werden als Pulslänge kodiert. 0: Signal kleiner 50us high 1: sonst
Die tinys sitzen wenige cm nebeneinander. Sie werden also einigermaßen gleichmäßig driften. Bei moderater Baudrate 9k6 oder noch viel weniger wird das sehr wohl funktionieren. Bzw. Funktioniert z.b. mit dem Bascom Softserial auf tinys ganz hervorragend. Im Prinzip würden wohl 1200baud locker reichen.
Zu umständlich. Es geht einfacher. Hier ein Vorschlag. Es werden 3 Symbole benötigt. 0,1, und ein Startsignal mit dem dem nachfolgenden Baustein angezeigt wird, dass er mit seinen Bits starten kann. die 3 Symbole: 0 : Pulslänge kleiner 50us 1 : 50us < Pulslänge < 100us Startsignal: Pulsänge >100us Der einzelne Baustein macht folgendes: 1. wenn 0 => weiter senden 2. wenn 1 => weiter senden 3. wenn Startsignal => eigene Bits senden Der erste Baustein in der Kette muss entweder vom Master das Startsignal bekommen ( dann wäre es eine Ringstruktur). Oder der erste Baustein in der Kette bekommt eine eigen Softwareversion und muss dann halt periodische z.B. alle 10ms seine Daten mit nachfolgendem Startsignal senden.
Hauke Haien schrieb: > Aaaaber: du wirst RAM Probleme bekommen. Ausserdem wird's echt blöd wenn > der Takt durch temperaturschwankungen wegläuft. Was willst du denn alles im RAM zwischenspeicher? - Für jeden selbst bereiten ADC-Wert ein Byte - Evtl. ein Byte für doppelt gepuffertes Empfangsbyte Das wars grob. Jedes empfangene Byte kann sofort an den Ausgang weitergereicht werten. Wenn kein weiteres Byte während der Aussendung kommt, werden die eigenen Bytes der Reihe nach gesendet und dann die nächste Wandlung angestoßen. Wo siehst du da erhöhten RAM-Bedarf? Mit den Temperaturschwankungen wird es wohl nicht so schlimm sein, wenn alle in der selben Box stecken. Bei einem Protokoll ähnlich dem WS2812 hätte man außerdem bei jedem Bit eine Synchonisationsflanke - wo soll da groß was weglaufen?
chris schrieb: > Zu umständlich. Es geht einfacher. > > Hier ein Vorschlag. Es werden 3 Symbole benötigt. 0,1, und ein > Startsignal mit dem dem nachfolgenden Baustein angezeigt wird, dass er > mit seinen Bits starten kann. Das bekommt der einfach nicht auf die Kette. Vergiss es. Kannste aber gerne noch 3 mal vorschlagen Wolfgang schrieb: > Was willst du denn alles im RAM zwischenspeicher? > - Für jeden selbst bereiten ADC-Wert ein Byte > - Evtl. ein Byte für doppelt gepuffertes Empfangsbyte Das wars grob. > Jedes empfangene Byte kann sofort an den Ausgang weitergereicht werten. Da hast du völlig recht, ist sinnvoller. Aber sowas darf der TE auch gern selbst auszutüfteln, dafür ja der Tipp mit der Softserial als Ausgangspunkt. Und Ja, nachdem klar ist dass alles in einem Schuhkarton spielt wird Temperaturdrift sein kleinstes Problem sein.
> Selber denken. Bist doch so ein erfahrener Arduinofuchs
Das eine schließt das andere aus, könne man meinen, wenn man die
Beiträge von den anderen Arduinofüchsen hier liest.
Mich interessieren neue Verfahren, das alte ist mir zu langweilig. Hier das A-Muster. Getestet auf zwei Arduinos ;-) Wer Muße hat, kann die digitalWrite und micros für andere System weg optimieren und die Übertragungsgeschwindigkeit erhöhen.
:
Bearbeitet durch User
Hauke Haien schrieb: > Und Ja, nachdem klar ist dass alles in einem Schuhkarton spielt wird > Temperaturdrift sein kleinstes Problem sein. Das oben gezeigte Bild misst Fader und schickt die Werte in die Runde. Aber wo sind die Aktoren? Spielt das wirklich alles in einem Schuhkarton? Spätestens beim Interface nach Außen bekommst Du so das nächste Sync-Problem, oder sehe ich das falsch?
Ich würde mal davon ausgehen, dass zumindest auf seinem Arduino dingens am Ende der Kette ein Quarz sitzt.
Hauke Haien schrieb: > Ich würde mal davon ausgehen, dass zumindest auf seinem Arduino dingens > am Ende der Kette ein Quarz sitzt. Jo, und dazu gilt es bei einer UART, die restlichen RC-Oszillatoren zu synchronisieren. Ich denke, es ist egal, ob der Übergang der Oszillatoren im Schuhkarton oder davor sitzt. Entweder verwenden ALLE Teilnehmer den RC-Takt und man hofft, dass sie alle auch gleich laufen. Oder man muss etwas unternehmen.
chris schrieb: > Hast Du meinen Post eins drüber gelesen? Da habe ich gerade erklärt, > warum es nicht geht. Ja, sorry hab ich übersehen. > Es sei denn, er hält DMX für eine Programmiersprache... Tu ich nicht. Aber der Arduino am Ende der Leitung (nicht in meiner Darstellung) soll das ganze letztenendes auf DMX ausgeben. Das Prinzip von DMX ist ja sowieso genau wie das der ws2812b Streifen genau falsch herum. Ich glaube wenn ein Knoten der Kette seine Werte (x[1.], y[2.],z[3.]) und dann ein 5us langes HIGH ausgibt müsste der nächste Knoten nach 4us spätestens erkennen, dass das Signal zu Ende ist und ein Signal mit den vorherigen Werten(x,y,z) und den eigenen Werten mit folgenden 5us HIGH ausgeben. Wenn der Knoten dann die Anzahl der Werte mitzählt (sollte nicht schwierig sein) kann er seine eigenen Werte als Wert[1]+x=xx ausgeben. Also: 1. x 2. y 3. z 4. xx 5. yy 6. zz 7. HIGH (8. delay(5);) Ich denke das müsste gehen. Aber wie kann ich das ausgeben? Kennt ihr eine Bibliothek, die quasi Serial für ATtiny macht.
> Kennt ihr eine Bibliothek, die quasi Serial für ATtiny macht. Du darfst gerne meinen Code kopieren: http://stefanfrings.de/avr_hello_world/index.html Er macht aber nur serielle Ausgabe. Wobei das für deinen Anwendungsfall vermutlich auch genügt, denn zum "Durchschleifen" der Daten musst du sie ja nicht decodieren oder interpretieren.
Angehängte Dateien:
-
ATtiny85.png
65 KB
Stefan U. schrieb: >> Kennt ihr eine Bibliothek, die quasi Serial für ATtiny macht. > > Du darfst gerne meinen Code kopieren: > http://stefanfrings.de/avr_hello_world/index.html > > Er macht aber nur serielle Ausgabe. Wobei das für deinen Anwendungsfall > vermutlich auch genügt, denn zum "Durchschleifen" der Daten musst du sie > ja nicht decodieren oder interpretieren. Danke das müsste gehen. Hier nochmal eine klare Skizze:
Wenn du den Takt mit dem Arduino vorgibst, entfallen sämtliche Probleme bezüglich der R/C Oszillatoren. Ich stelle mir das so vor: Der Ruhepegel ist High. Alle Impulse haben Low-Pegel. Zwischen den Impulsen ist eine Pause von weniger als 1ms. Eine Pause von mehr als 1ms wird als Übertragungsfehler gewertet. Startsignal: 1ms Impuls High-Bit: 1µs Impuls Low-Bit: 0.5µs Impuls Der Arduino sendet das Startsignal an den ersten ATtiny, gefolgt von genügend Low-Bits um alle Daten zu erfassen. Für jeden ATtiny sind ein paar Bits in diesem Strom reserviert. jeder ATtiny darf "seine" Bits verlängern High-Bits zu übertragen. Die anderen Bits reicht er 1:1 durch. Der Ausgang des letzten ATtiny führt wieder zum Arduino, welcher die Bits einsammelt und auswertet. Dazu muss jeder ATtiny seine Position in der Kette kennen und entsprechend mit zählen.
1 | Arduino |
2 | |
3 | Startsignal und Taktvorgabe: o--->---Tiny---Tiny---Tiny---Tiny---Tiny---+ |
4 | | |
5 | Empfang o----------<----------------------------------------------------+ |
Das Programm auf dem Arduino muss eine gewisses Maß an Verzögerung durch die Kette zulassen. Bei dem oben genannten Timing sollte das sehr einfach zu implementieren sein. Nur um Missverständnisse zu vermeiden: Meinen Code für soft-serial kannst du dazu nicht verwenden.
Aber gibt es eine Library bzw. ein fertiges Protokoll dafür oder ist dies selber zu schreiben? Man muss es sich ja nicht zu schwer machen...
> Aber gibt es eine Library bzw. ein fertiges Protokoll dafür
Deine Anforderung ist so speziell, dass du danach wahrscheinlich lange
suchen musst. Wie bereits gesagt wird so etwas häufig mit I²C Bus
realisiert. Aber das willst du ja nicht nutzen (oder doch?)
Auch da kommt die Taktvorgabe vom "Master" und R/C Oszillatoren stellen
kein Problem dar. Ebenfalls kennt bei I²C jeder "Slave" seine eigene
Nummer (heisst dort Adresse).
Bei I²C wird allerdings kein Ring gebildet, sondern alle Busteilnehmer
sind parallel geschaltet. Der Master spricht abwechselnd die Slaves
gezielt mit ihrer Adresse an und fordert sie auf, zu antworten.
Stefan U. schrieb: > Dazu muss jeder ATtiny seine Position in der Kette kennen und > entsprechend mit zählen. Ich finde das ausgesprochen lästig, wenn die alle verschieden sein sollen. Wozu das? Jeder kann doch seine Bits anhängen, sobald er erkennt, dass auf dem Eingang nichts mehr kommt. Da ist eine Kodierung wie beim WS2812, wo sich jeder ausrechnen kann, wann die nächste Startflanke kommen müsste, schon ganz praktisch.
> Wozu das?
Weil er es anders nicht versteht, das merkst du doch. Man kann sich
viele ausgefuchste Protokolle ausdenken oder wieder verwenden, aber er
hat ja bisher sämtliche bewährte Vorschläge abgelehnt.
Wieder mal ein Beispiel warum einfach wenn man es kompliziert machen kann. Oder um 4 Euro (s.o.) zu sparen mehrere Tage Lebenszeit zu opfern. Während Valaribo schon feiert spült Valabacho noch.
PerLüß schrieb: > Aber gibt es eine Library bzw. ein fertiges Protokoll dafür oder ist > dies selber zu schreiben? Man muss es sich ja nicht zu schwer machen... Für i2c gibt es fertige Libraries. Hab ich mal verwendet um von eben so einem Tiny, der eine spezielle Dekodieraufgabe hatte, die Daten abzuholen. Habe ihn dafür als I2C EEPROM funktionieren lassen. War in wenigen Stunden fertig.
Ich war mir wegen I2C nicht sicher, weil es hier nur kurz angesprochen wurde, aber die Ardbeit den MCs zu sagen wer sie sind kann ich mir glaube ich machen. :-) Und: > Weil er es anders nicht versteht, das merkst du doch. Man kann sich > viele ausgefuchste Protokolle ausdenken oder wieder verwenden, aber er > hat ja bisher sämtliche bewährte Vorschläge abgelehnt. Ich möchte für rs... nicht irgendwelche weiteren Bauteile investieren und habe bisher nur Pläne gefunden, die dieses erfordern. Vieles was gesagt wurde habe ich verstanden, aber auf dem Gebiet der direkten Programmierung von MCs (ATtinys) bin ich halt noch ein Semi-Anfänger... ich glaube es ist verständlich, wenn ich dann nicht alles verstehen kann. ;-)
PerLüß schrieb: > Ich möchte für rs... nicht irgendwelche weiteren Bauteile investieren > und habe bisher nur Pläne gefunden, die dieses erfordern. Wo willst du denn genau RSxxx einsetzen?
Ich hättes zwischen den MCs verwendet...
PerLüß schrieb: > Definitiv ist DMX sehr preiswert und ich werde das nur darüber machen. > Und sparen tue ich mit meinen ATinys sehr viel, weil ich die für ca. > 60ct pro Stück gekauft habe. Die wollen aber auch auf eine Platine und bisschen drum rum brauchen die auch. Bist du sicher, dass sich das rechnet? Bin ja erklärter Tiny10 Fan und auch da kann man einiges mit machen, wenn man nicht viel Pins braucht. Sicher ist auch ein einfaches "Steuern" über einen Pin möglich. Dazu muss aber jeder Tiny für seine Aufgabe programmiert sein. Dann bekommt er nur ein Start und evtl. ein Stoppbefehl.
Mein Protokoll oben lässt sich vermutlich auf dem Attiny10 implementieren. Das Ganze müsste dann in Assembler realisieren. Vermutlich könnte man dann mit 100kB/s fahren. https://www.mikrocontroller.net/attachment/highlight/361614
Der TO möchte aber ein bestehendes Standard Protokoll verwenden, dass seine ATttiny85 ohne zusätzliche Kosten unterstützen, maximal 2 Pins benötigt und keine Probleme mit R/C Oszillatoren hat. Da bleibt doch nur noch I²C!
PerLüß schrieb: > Ich hättes zwischen den MCs verwendet... Wozu RSxxx zwischen den µCs. Da reichen doch die 3.3..5V der µCs?
Die bisher gesammelten Anforderungen waren: * Es soll ein etabliertes Standard Protokoll sein * Dazu benötigt er Programmbeispiele * Es muss auf 5 ATTiny85 und einem Arduino Modul laufen * Es darf maximal 2 Pins belegen * Es soll ohne Zusatzkosten gehen, abgesehen von Hühnerfutter keine weiteren Bauteile Das schreit ganz laut nach I²C Bus! Die entsprechenden Treiber sind in seinen µC bereits integriert. Nun habe ich I²C schon im ersten Beitrag empfohlen und andere Leute haben diese Empfehlung bestätigt. Aber das will der TO nicht verwenden. Andere Lösungsansätze auf Basis des WS2812 sowie eigene Ideen wurden beigesteuert. Aber die will er auch nicht. Besser geeignete µC hat er aus Kostengründen ausgeschlossen, will andererseits aber RS485 oder RS422 Treiber benutzen. Das ist eindeutig Trollerei. Falls ich da im Irrtum liege, lieber PerLüß, dann nimm Dir heute nochmal die Zeit diesen ganzen Thread zu lesen und nach den Fachwörtern der einzelnen Vorschläge zu Googeln. Denn ab jetzt wirst du mit 99% Wahrscheinlichkeit keinen weiteren sinnvollen Vorschlag mehr bekommen. Zum einen, weil das Thema durchgekaut ist, zum anderen, weil du uns offensichtlich verarschen willst und wir das gar nicht gerne haben.
Stefan U. schrieb: > Das ist eindeutig Trollerei. Falls ich da im Irrtum liege, lieber > PerLüß, dann nimm Dir heute nochmal die Zeit diesen ganzen Thread zu > lesen und nach den Fachwörtern der einzelnen Vorschläge zu Googeln. Denn > ab jetzt wirst du mit 99% Wahrscheinlichkeit keinen weiteren sinnvollen > Vorschlag mehr bekommen. Zum einen, weil das Thema durchgekaut ist, zum > anderen, weil du uns offensichtlich verarschen willst und wir das gar > nicht gerne haben. Tja, schön dass du dich meinem ersten Post zum Thema so schnell angeschlossen hast!
Stefan U. schrieb: > Es muss auf 5 ATTiny85 und einem Arduino Modul laufen Ja fast: PerLüß schrieb: > bis zu 40 Potis und bis zu 20 Knöpfen :-) Gruss Chregu
Habe das zunächst auch immer mehr für einen Aprilscherz gehalten, aber scheint mal wieder jemand zu sein, der die "Weltmaschine" bauen will.
Autor: Stefan Us (stefanus) Datum: 02.04.2018 08:42 >Die bisher gesammelten Anforderungen waren: > > * Es soll ein etabliertes Standard Protokoll sein Warum immer Standard und nicht mal was Neues wagen? > * Dazu benötigt er Programmbeispiele > * Es muss auf 5 ATTiny85 und einem Arduino Modul laufen > * Es darf maximal 2 Pins belegen > * Es soll ohne Zusatzkosten gehen, abgesehen von Hühnerfutter keine >weiteren Bauteile Alle diese Punkte werden durch mein obiges Beispiel erfüllt. https://www.mikrocontroller.net/attachment/361614/bitChainProtokoll.ino Anwendung: 1. Attin85 Arduiono Framework installieren 2. Das Beispiel File auf den Attiny85 laden ( beim ersten in der Kette muss das "#define FIRST_IN_CHAIN" aktiviert werden ) 3. Das File auf den Arduino als letzten in der Kette laden 4. vorher meine Testwerte durch "analogRead" oder was auch immer ersetzen und bei den Attinys alle Serial.print raus werfen, die sind nur zum debuggen. 5. läuft
:
Bearbeitet durch User
Stefan U. schrieb: > Das schreit ganz laut nach I²C Bus! Die entsprechenden Treiber sind in > seinen µC bereits integriert. > > Nun habe ich I²C schon im ersten Beitrag empfohlen und andere Leute > haben diese Empfehlung bestätigt. Aber das will der TO nicht verwenden. > Andere Lösungsansätze auf Basis des WS2812 sowie eigene Ideen wurden > beigesteuert. Aber die will er auch nicht. Doch, will ich. War nur irgendwie kein großes Thema. > Denn > ab jetzt wirst du mit 99% Wahrscheinlichkeit keinen weiteren sinnvollen > Vorschlag mehr bekommen. Zum einen, weil das Thema durchgekaut ist, zum > anderen, weil du uns offensichtlich verarschen willst und wir das gar > nicht gerne haben. 1. Tut mir leid wenn ihr euch verarscht fühlt, nicht meine Absicht. 2. Die Vorschläge reichen mir auch. 3. Ich war nur etwas verwirrt durch die Diskussion über rsxxx und so. Sry wenn sich jmd. verarscht gefühlt hat. Meine Hauptfrage (Kommunikation) ist ja auch geklärt und ich werde es jetzt mit I2C machen.
Hi, jetzt kommt die Frage auf, ob die Targets auch geeignet sind. Kleine Zufallsauswahl: ATtiny48/88 echte HW und Masterfähigkeit. ATtiny441/841,1634 und 828 HW aber nur Slave. ATtiny 20/40 mit Slave... (ATiny4313 hat noch eine "Bufferung", der ATiny2313 nicht. Nur Umweg USI keine "echte" HW) "UPDI" Megas brauchen z.T. eine andere Lib. "...Unified Program and Debug Interface (UPDI) is an Atmel proprietary interface for external programming and on-chip debugging of a device. It is a successor to the PDI 2-wire physical interface,..." Google Die MEGAS haben das. ciao gustav
:
Bearbeitet durch User
Die müssen nur Slave sein und werden von Master reihum abgefragt.
> Ich war nur etwas verwirrt durch die Diskussion über rsxxx und so.
Das passiert, wenn man sein Projekt nur unzureichend beschreibt und die
Anforderungen nicht nennt. Dann bekommt man hier zahlreiche gut gemeinte
und sehr unterschiedliche Vorschläge und hat dann das Problem, den
sinnvollen Vorschlag heraus zu filtern.
Dein Kardinalfehler war, dass du Dir eine halbe Lösung ausgedacht hast
und dazu Fragen gestellt hast. Das Gesamtbild hast du uns lange
vorenthalten.
Ich muss hier den vorhergehenden Kommentaren Recht geben. Es ist etwas heavy für den Einstieg ohne Arduino ... Multi Master wäre CAN - aber das ist auch keine Einsteigersache Ich würde schrittweise vorgehen um vom C-Einsteiger zum fitteren C-Anwender zu werden 1. Zwei mC miteinander kommunizieren lassen, SPI und auch I2C und das ganze ohne die Arduino Libs... 2. Einen Master mit mehreren Slavs ... 3. Für den konkreten Fall ein Multi Master System erwägen Der Weg ist aber anstrengend, aber m.M. der einzig sinnvolle.
F. F. schrieb: > Habe das zunächst auch immer mehr für einen Aprilscherz gehalten, aber > scheint mal wieder jemand zu sein, der die "Weltmaschine" bauen will. Ist doch ein ganz normaler Vorgang. Wir bauen nach dem Ausschlussverfahren, bis es läuft - nennt sich Alchemie. Im Forum ist's dann Alchemie im Team. jeder kann sagen: "So wird's kein Gold, hab ich schon probiert." Alles im grünen Bereich - Wahnsinn ist anders.
Thread beobachten
Seitenaufteilung abschalten
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.