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.
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.
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 MCP3208ist 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!
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.
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...
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?!
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....
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.
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 MikrocontrollerPerLüß 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? :-)
> 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
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 WS2812LED 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...
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.
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
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 WS2812LED 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: 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.
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?
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.
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---+
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
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?
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.
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!
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
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
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
> 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.
