Mehrere Attiny's mit 1 Atmega kommunizieren lassen

Als erstes solltest du klären, ob dein Arduino (Master) überhaupt einen 
freien UART Port hat. Der erste ist nämlich normalerweise mit der USB 
Buchse verbunden.

Welche Arduino Board willst du denn benutzen? Bist du für alternative 
Vorschläge außerhalb der Arduino Welt offen?

> Danke für eure Tipps zu Hard- und Softwarelösungen, Schalpläne und Code
> für meine Aufgabe, passende Weblinks & Quellen wo ähnliches realisiert
> wurde etc. etc...

Das kann man so verstehen, dass du das gesamte Projekt in fremde Hände 
geben willst. Dabei mache ich nicht mit. Ich beantworte aber gerne 
konkrete Fragen zu einzelnen Teil-Aspekten.

Fangen wir mal mit der UART an. Weißt du wie sie (elektrisch) 
funktioniert und wie man dort Optokoppler einsetzen kann?

Parallel dazu können wir vielleicht klären, welche Programmierkenntnisse 
du hast.

Wenn es um eine zuverlässig funktionsfähige Anwendung gehen soll, und 
nicht um den Weg zum Ziel:

Es gibt unter anderem von TI (BQxxx), Analog Devices (LT68xx) und Maxim 
fertige Lösung für Batteriemanagementsysteme. Der Aufwand einer 
Eigententwicklung lohnt einfach nicht.
Diese ICs haben auch eine passende galvanische schnittstelle 
implementiert, außerdem FET-Treiber fürs Balancing.

Falls du das mit den Attinys umsetzen willst:
- Als Topologie würde sich eine Verkettung anbieten, das heißt die 
einzelenen Attinys sind nur mit jeweils einem Nachbarn verbunden, und 
der letzte dann mit dem Atmega.
- Dann kannst du einfach UART über die Optokoppler nutzen, müsstest aber 
noch ein passendes Protokoll auf Softwareebene zum übertragen der Daten 
sammeln.

-----------

Um wie viele serielle Zellen soll es denn gehen? Bis 16s liesse sich das 
mit einem IC lösen, von TI-ICs lassen sich bis zu 16 verketten, das 
würde für 256s reichen.

Lothar M. schrieb:
> Wenn die Submodule sowieso potentialfrei aus Batterien/Akkus versorgt
> werden, wozu brauchst du dann noch Optokoppler?

Wenn man sie in Serie schaltet (14S), gibt es mit einer gemeinsamen GND 
Probleme...
Bei einer Parallelschaltung braucht man eh nur einen COntroller, um die 
Spannung zu messen, aber mehrere um den Strom zu messen...

Bevor die Diskussion über Sinn und Unsinn von Schaltungen ausartet würde 
ich darum bitten, die Skizze des TO abzuwarten.

Jens M. schrieb:
> Lothar M. schrieb:
>> potentialfrei
>
> Niemand außer dir hat Potentialfrei gesagt.
Spoe N. schrieb:
> galvanisch getrennt

> @elkoo
> Grundsätzlich funktioniert das so.
> Allerdings ist die Geschichte relativ langsam, da Optokoppler eben nur
> begrenzt schnell sind. Einige hundert Baud sollten aber gehen.


> Was mir noch so einfällt:
> Du brauchst relativ kleine Takt-Toleranzen, was nicht unbedingt mit dem
> internen Oszillator klappt. Synchrone Schnittstellen oder Autobauding
> können da vielleicht weiterhelfen. Bessere Oszillatoren beißen sich oft
> mit der Startzeit oder dem Stromverbrauch.

Synchrone Schnittstelle bedeutet, dass da noch eine Leitung und 
galvanische Trennung nötig ist.

Die AVRs können beherrschen doch ein "Multi-Device" 
Kommunikationsprotokoll.
Ist schon lange her, dass ich das im Datenblatt gelesen habe, daher 
weiss ich den Namen nicht mehr so genau.
Dürfte in einem ATMegaXX Datenblatt in dem U(S)ART-Kapitel gewesen sein.

Im Prinzip funktioniert das so:
Jeder hat Zugriff auf RX/TX und jede Nachricht beginnt mit einer 
Adresse. Nur wer diese Adresse hat fühlt sich angesprochen. Und das 
auswerten übernimmt die Hardware. Als Programmierer benutzt man "einfach 
einen UART".

Ansonsten würde ich noch I²C empfehlen.

Ich möchte auf den Thread Beitrag "Spannungsmessung mit Galvanischer Trennung" 
verweisen, wo das Thema eigentlich begann. Ich glaube, die Idee mit den 
mehreren Mikrocontrollern hat er von Peter.

Spoe: Geht es um dein Elektrofahrrad?

Bevor ihr weiter I²C vorschlagt: Denkt über die Optokoppler nach. Wenn 
ihm die wichtig sind, wird es mit Optokopplern richtig kompliziert.

Spoe N. schrieb:

> Ich möchte mehrere Attiny's galvanisch getrennt mit einem Atmega
> kommunizieren lassen (Zwecks Bau eines Battery-Management Systems).
>
> So stelle ich mir das idealerweise vor:
> a) Schlussendlich mindestens 14 Attiny's werden mit jeweils einer LiIon
> Zelle versorgt (2.5-4.2v, bei den langsameren Versionen der Attiny's
> sind 1.8-5v Versorgungsspannung ok, das sollte also gehen).
>
> b) Am Arduino gibt es einen RX und einen TX. Die werden jeweils mit
> einer Leitung verbunden, welche via Optocoupler zu/von den Attiny's
> führt (jeweils 2 coupler pro Attiny). Idealvorstellung: die zwei
> gleichen Leitungen werden via optocoupler mit allen Attiny's verbunden
> und nur das softwaremässig adressierte Attiny antwortet auf Anfrage des
> Atmega.
>
> c) Auf befehl des Atmega (master) sollen die einzelnen Attiny's
> adressiert werden & eine Spannung messen (oder eine/mehrere definierte
> andere Aufgabe ausführen) & Resultate ans Atmega zurückmelden wo diese
> geloggt / ausgewertet werden können. Falls die Spannung zu hoch wird,
> soll z.B. (auf Befehl des Atmegas) am entspreechenden Attiny eine Last
> zugeschaltet werden (Passive Balancing).

> Dummerweise (wortwörtlich) weiss ich bis jetzt nur, dass ich über das
> ganze Thema im Moment noch zu wenig weiss und auch noch nicht so genau
> weiss, wo ich beginnen soll.

Erstmal: Grundsätzlich ist machbar, was dir vorschwebt.

Beschränkungen ergeben sich für den möglichen "Grad" des passiven 
Balancing, denn es muss jederzeit die Mindestversorgungsspannung für den 
für die Zelle zuständigen Tiny gewährleistet sein. Das ist aber relativ 
unkritisch, das läßt sich einfach berechnen, ausserdem bieten auch die 
kleinsten Tinys genug Pins, um neben der Kommunikation drei bis vier 
verschiedene "Ballastwiderstände" in beliebiger Kombination zu 
aktivieren. Ob das überhaupt nötig ist, wäre zu berechnen. Vermutlich 
genügen ein bis zwei Ballastwiderstände, um auch recht extreme 
Unterschiede in der Fitness der Zellen hinreichend innerhalb eines 
Zyklus ausgleichen zu können.

Unkritisch und einfach umzusetzen ist auch die Kommunikationsrichtung 
Master->Slaves. Das kann man tatsächlich sehr einfach mit einem 
Optokoppler pro Slave realisieren. Die LED's der Optokoppler werden 
einfach als lange Kette verschaltet, "oben" an Plus der obersten Zelle 
der Reihenschaltung gelegt und "unten" über einen Widerstand und einen 
FET nach Masse (=Minus der untersten Zelle). dieser FET wird dann von TX 
des Masters angesteuert, dessen GND-Potential mit Minus der untersten 
Zelle identisch ist.
Voraussetzungen, damit das funktioniert, sind lediglich: die 
Flußspannung der Optokoppler-LEDs muss merklich unterhalb der minimalen 
Zellenspannung liegen, die maximale Sperrspannung des FET muss oberhalb 
der Summe der maximalen Zellenspannungen liegen und der FET muss ein 
Logic-Level-FET sein, geeignet für das, was der Master halt als 
Logic-Level anzubieten hat.

Die Gegenrichtung hingegen ist etwas komplizierter. Das läuft auf eine 
Kette von FETs und Widerständen hinaus (jeweils einer pro Slave) und 
"unten" einen Optokoppler, durch dessen LED der Strom fließt, den die 
Kette aus FETs und LEDs durchläßt. Blöd an dieser Konstruktion ist, dass 
durch diese Kette immer ein Strom fließen muss, er wird nur 
unterbrochen, wenn ein Slave was zu labern hat. Sinnvollerweise würde 
man also einen weiteren FET ganz unten in die Kette einfügen, der vom 
Master gesteuert wird. Der kann dann den dauerhaften Stromfluss 
unterbrechen und nur dann freigeben, wenn er überhaupt irgendwas von den 
Slaves erwartet. Der Nachteil ist: die Slaves können dann nur noch auf 
Anfragen antworten, nicht selber aktiv eine Kommunikation initiieren. 
Wenn man das will oder braucht, führt es zu einer deutlich aufwendigeren 
Schaltung.

c-hater schrieb:

> Kette aus FETs und LEDs durchläßt.

Das ist natürlich Bullshit. Sollte eigentlich heißen: "Kette aus FETs 
und Widerständen durchläßt".

Hugo H. schrieb:

> USART ist der falsche Ansatz. SPI scheint mir hier angebracht.

Unsinn. Du hast offensichtlich überhaupt nicht begriffen, wo das Problem 
liegt. SPI-Ketten funktionieren recht gut, wenn alle Teilnehmer das 
gleiche GND-Potential haben. Genau das ist aber hier nicht der Fall...

Das GND-Potential des "obersten" Tiny liegt nach den Vorgaben des TO bis 
zu 13*4.2=54.6V oberhalb des GND-Potentials des Masters. Kannst du 
erklären, wie du das Problem mit deinem Ansatz zu lösen gedenkst?

A. H. schrieb:
> Auch Quarze sind unnötig, die internen Ozillatoren sind genau genug für
> die Kommunikation.

Für UART Kommunikation sind Oszillatoren mit mehr als 4% Abweichung 
ungeeignet. Ein Blick ins Datenblatt könnte helfen. Die meisten mir 
bekannten AVR erfüllen die Anforderungen nicht. In der Praxis hat man 
meisten Glück, dass es doch geht, aber eben nicht immer.

A. H. schrieb:

> Anstelle Optokoppler würden auch Kondensatoren funktionieren.

Jepp, das wäre die weitaus bessere Lösung, ist allerdings nicht mit 
einfacher UART-Funktionalität umsetzbar, sondern erfordert 
Modulation/Demodulation. Auch kein Hexenwerk, aber bezüglich des 
Schaltungsaufwands doch etwas aufwendiger. Allerdings sind die 
benötigten Bauteile in Summe billiger.

Aber ob der TO das hinbekommt? Ich würde sagen: keine Chance. Wäre es 
anders, gäbe es diesen Thread garnicht...

Stefanus F. schrieb:

> Für UART Kommunikation sind Oszillatoren mit mehr als 4% Abweichung
> ungeeignet.

Das stimmt so allgemein natürlich nicht. Das hängt davon ab, wie man den 
UART nutzt (Anzahl Datenbits und Anzahl Stopbits).

Mit der USART-Hardware der AVR8 ist 5N2 möglich. Wie man leicht 
ausrechnen kann, sind dann 8,33333...% Taktabweichung zwischen Sender 
und Empfänger gerade der Grenzfall und somit 4% locker im sicheren 
Bereich...

c-hater schrieb:
> Das stimmt so allgemein natürlich nicht.
> Mit der USART-Hardware der AVR8 ist 5N2 möglich.

Das war klar, das so etwas von dir kommen würde. Wie Wahrscheinlich ist 
wohl dass der TO ein anderes Datenformat als 8 bits benutzen möchte?

Stefanus F. schrieb:

> Das war klar, das so etwas von dir kommen würde. Wie Wahrscheinlich ist
> wohl dass der TO ein anderes Datenformat als 8 bits benutzen möchte?

Kommt drauf an, ob er Arduidiot oder vernünftig denkender Mensch ist. 
Ich hoffe letzteres. Arduidioten gibt es ja eh' viel zu viele...

c-hater schrieb:
> Arduidioten

Diese Beleidigung ist unangebracht. Warum versaust du deine fachlich 
guten Beiträge immer mit so etwas?

M. K. schrieb:
> I2C mit Optokopplern ist genauso einfach/kompliziert
> wie UART mit Optokopplern.

Du scheinst da irgendeine einfache Schaltung zu kennen, die ich kennen 
sollte. Helfe mir mal auf die Sprünge, wie man das mit I²C macht.

M. K. schrieb:

> Seit wann denn das? I2C mit Optokopplern ist genauso einfach/kompliziert
> wie UART mit Optokopplern.

Nein, denn die Signale sind bidirektional. Das ist kein Problem, solange 
alle Peers dasselbe GND-Potential haben. Haben sie aber in dieser 
Anwendung nicht. Also dieselbe Soße wie bei dem Vorschlag mit SPI.

Erst denken, dann posten...

M. K. schrieb:

> Ich dachte ich mir grad ich schau mal kurz. Wie komplex ich doch denke,
> dabei hat z.B. TI extra Chips um I2C potentialfrei zu machen, ISO1540
> ist so ein IC dafür.

Und was kostet der pro Stück? (Hihihi!) Damit dürfte dieser Pfad der 
Diskussion schon erledigt sein...

M. K. schrieb:

> Umsonst ist nicht mal der Tod, der kostet das Leben.

Das ist unbesteitbare Wahrheit.

> Ein preisliches
> Limit konnte ich bisher nicht entdecken.

Nunja, das gab es tatsächlich nicht explizit. Aber allein der gesunde 
Menschenverstand dürfte nahelegen, dass ein solche Lösung kaum in Frage 
kommt, solange es Lösungen gibt, die weniger als 5% davon kosten...

Und übrigens: hast du mal darüber nachgedacht, warum das Teil dermaßen 
teuer ist? Wenn du dir das nicht selber erklären kannst, kann ich dir 
das gerne erklären. Ohne das im Detail auszuführen, läuft es jedenfalls 
darauf hinaus: das gegebene Szenario ist nix, was man mit I2C löst, 
jedenfalls nicht, solange man auch nur irgendeine eine andere Wahl 
hat...

M. K. schrieb:
> Du brauchst halt zwei OK bei I2C
> für die Signalleitung. Mehr ists aber nicht.

Wie verhindert du eine Rückkoppelung/Blockierung bei den bidirektionalen 
Koppelungen?

Spoe N. schrieb:
> Kann das so funktionieren?

Wenn du die Slaves zumindest mit Keramikresonatoren ausstattest, kann es 
funktionieren.

Hast du die Stromaufnahme der Slaves berücksichtigt, wie sich das auf 
die Akkus auswirkt?

Google mal nach "Abblockkondensator" dann findest du die Erklärung, 
warum sie wichtig sind. Oder guck hier: 
https://rn-wissen.de/wiki/index.php/Abblockkondensator

> Anbei ein erster Hardware-Entwurf zum zerpflücken.

Check mal deine RX/TX-Verbindungen - ich habe den Eindruck, dass du 
jeweils TX mit Tx und RX mit RX verbunden hast statt über Kreuz.

Der ATTiny13 scheint besonders schlecht für die Aufgabe zu sein. Der 
kann nur PB2-PB5 vermessen. D.h. dein Analogeingang ist derzeit noch 
unbeschaltet. Ein einfach schmucker Spannungsteiler macht dir alle 
Stromaufnahmen im Sleep zunichte. Besser wäre es, einen uC zu nehmen, 
welcher selbst seine BG vermessen kann.

Zudem ist der Bereich der Referenz von 1.0 ... 1.2 V angegeben. Viel 
Spaß mit der Kalibration über Temperatur und Versorgungsspannung. 
Schlussendlich willst du bezüglich Auflösung und Genauigkeit 4.2 V 
sicher von 4.25 V unterscheiden. Eine gute Referenz kostet halt Geld, 
was den Preis der o.g. Batterie-Spezialchips relativiert.

Der ATtiny45 könnte seine Versorgungsspannung mit der Bandgap-Referenz 
vergleichen, dann braucht man keinen externen Spannungsteiler.

Ums Kalibrieren kommt man jedoch wohl nicht herum.

Hi

Für einen solchen Fall hatte Atmel mal den ATMega406 erfunden:

• Battery Management Features
– Two, Three, or Four Cells in Series
– Deep Under-voltage Protection
– Over-current Protection (Charge and Discharge)
– Short-circuit Protection (Discharge)
– Integrated Cell Balancing FETs
– High Voltage Outputs to Drive Charge/Precharge/Discharge FETs

MfG Spess

M. K. schrieb:

> Das finde ich immer so toll an dir. Du hast immer ne bessere Lösung auf
> dem Kasten, der konkrete Lösungsvorschlag bleibt aber leider immer aus.

Bist du doof oder blind? Ich hatte ein recht vollständiges Konzept lange 
zuvor bereits beschrieben. Das war hier:

Beitrag "Re: Mehrere Attiny's mit 1 Atmega kommunizieren lassen"

spess53 schrieb:

> – Two, Three, or Four Cells in Series

Blöde Scheisse ist halt nur, dass der TO satte 14 Zellen braucht...

Stefanus F. schrieb:

> Ums Kalibrieren kommt man jedoch wohl nicht herum.

Das ist leider wahr, da führt nix dran vorbei.

Die integrierten Referenzen sind einfach über die Exemplare hinweg nicht 
genau genug für diese Anwendung. Nach meiner Erfahrung nichtmal 
innerhalb einer Charge. Also: keine Abkürzung möglich, Kalibrieren ist 
Pflicht, wenn die Sache funktionieren soll.

neuer PIC Freund schrieb im Beitrag #5992687:

> Der ATTiny13 scheint besonders schlecht für die Aufgabe zu sein.

Der Attiny13 scheint besonders schlecht für jede beliebige Aufgabe 
geeignet zu sein. Ich habe seit vielen Jahren ein Exemplar hier 
rumzuliegen, und versuche seitdem immer, das Teil irgendwo 
unterzubringen. Ist mir nicht gelungen. Die einzigen Aufgaben, für die 
es geeignet gewesen wäre, liessen sich immer auch locker mit den noch 
kleineren Tinys erschlagen.

Scheinbar wurde der Tiny13(A) ausschliesslich für C-only-Programmierer 
geschaffen, die nicht in der Lage waren, die noch kleineren Dinger in 
Assembler zu programmieren...

Irgendwie lustig, aber auch sehr bedenklich...

Für sportliche Übungen taugt er gut. Wenn du mit dem klar kommst, dann 
auch mit allen anderen Mikrocontrollern.

Für mich er das digitale Pendant zu LM741. Ich liebe ihn - im ernst. Den 
habe ich von allem µC am häufigsten verwendet.

Stefanus F. schrieb:

> Für sportliche Übungen taugt er gut. Wenn du mit dem klar kommst, dann
> auch mit allen anderen Mikrocontrollern.

Du prgrammierst nicht in Asembler, stimmt's? Das erklärt, dass du 
Verwendungen für den Tiny13(A) gefunden hast...

Ich bin sicher: jede einzelne davon hätte man auch mit einem Tiny10 
abhandeln können, wenn man den halt in Assembler programmiert...

c-hater schrieb:
> Du prgrammierst nicht in Asembler, stimmt's

Ja, stimmt. Schon lange nicht mehr.

> jede einzelne davon hätte man auch mit einem Tiny10
> abhandeln können, wenn man den halt in Assembler programmiert...

Gut möglich.

Der Tiny10 ist standalone ja noch schlechter als der Tiny13. Hat nicht 
mal eine Referenz, kann nur ratiometrisch. Das führt dann allerdings 
direkt zu einer zweiten Strategie, die im Widerspruch zu

> Ums Kalibrieren kommt man jedoch wohl nicht herum.

steht: Man kauft ein "kalibriertes" Bauelement. Vielleicht 2-3€ als 
externe Referenz an den Tiny drantüddeln. Ansonsten bräuchte man 
hochpräzise Messgeräte, und welcher Anfänger hat die schon. Dann aber 
bitte keinen Tiny10, der hat nur 8-bit ADC und keinen Referenzeingang.

Und ja, man kann den Tiny10 auch in c programmieren.

Stefanus F. schrieb:
> M. K. schrieb:
>> Du brauchst halt zwei OK bei I2C
>> für die Signalleitung. Mehr ists aber nicht.
>
> Wie verhindert du eine Rückkoppelung/Blockierung bei den bidirektionalen
> Koppelungen?

Das Timing von i2c ist doch bekannt, es darf nur ein SDA-OptoKoppler 
zeitgleich aktiv sein und nur der addressierte Slave schaltet beim 9.Clk 
(ACK) auf Senden, der Master natürlich auf Empfang.
Oder eben beim Lesen für die entsprechende Sequence.

Braucht halt etwas Logik, aber ist nachher transparent.

NichtWichtig schrieb:
> Braucht halt etwas Logik,

Allerdings. Damit sind wir weit entfernt von:

M. K. schrieb:
> I2C mit Optokopplern ist genauso einfach/kompliziert
> wie UART mit Optokopplern.

Es könnte sogar mit dem Tiny selbst gehen, die Logik wird dann in SW 
gegossen.

UART ist nunmal kein Bus, i2c schon.

Was braucht es denn?
Der selektierte Slave muß zu einer bestimmten Zeit ein GPIO umschalten 
damit die beiden Optokoppler "invers" arbeiten und der Slave senden 
kann.

Programmiert man den i2cSlave zu Fuß ist das doch Kleinkram.
Wenn HighSpeed nicht gefordert ist eine lockere Übung zum warm werden.

Beim Master das gleiche: Er weis ja wann er lesen möchte, ein GPIO langt 
zur Umschaltung.

NichtWichtig schrieb:
> UART ist nunmal kein Bus

Mit entsprechenden Treibern (z.B. RS485) oder eben Optokoppler und 
Übertragungsprotokoll wird daraus ein Bus.

Wie sonst würdest du denn einen RS485 Bus realisieren, wenn nicht mit 
UART oder USI?

> Programmiert man den i2cSlave zu Fuß ist das doch Kleinkram.

Ja, doch wie die Hardware um die Optokoppler herum aussehen kann, ist 
immer noch ungeklärt. So einfach, wie gedacht, ist es dann wohl doch 
nicht.

Diese IC's hatten wir schon in Diskussion (ab 
Beitrag "Re: Mehrere Attiny's mit 1 Atmega kommunizieren lassen"). Sie sind teuer 
und für Endverbraucher schwer zu bekommen.

Bei Aliexpress habe ich unter "I2C Isolator" ein paar verlockende 
Angebote gesehen, aber keins davon konnte ich öffnen. (Page not found).

Es gab mal eine Version Anzeiger in Bussen, also Front- Seiten- 
Heckanzeiger, die nicht mit eigenen CPUs via IBIS angesteuert wurden 
sondern nur eine in der Front und i2c durch das ganze Fahrzeug zu den 
anderen "dummen" Anzeigemodulen, die mit den Klappplättchen 
Schwarz/Gelb.

Etwa sowas hier: Beitrag "[V] Flip-Dot Module"

Was dann erstmal nicht ging war die Abfrage ob alle Anzeiger "anwesend" 
sind weil man i2c eben nur zum Senden implementiert hatte.

Und dort haben wir dann genau das gemacht das man mit wenig Zusatzlogik 
eben doch die Richtung umschalten konnte.
Ich meine dort wurde RS-422 verwendet welche eh bi-directional hätten 
können können wenn man den direction-Input entsprechend beschaltet.


Und i2c ZuFuss ist nun wirklich kein Hexenwerk.
Hier lohnt sich doch etwaige Mühe weil gleich mehrer Clients identisch 
benötigt werden.

Solange ich für die Trennung ein spezielles IC brauche, ist das viel 
komplizierter also ohne. Jedenfalls für mich.

M. K. schrieb:

> Man könnte sich natürlich fragen:
> Wenn der Tiny13 so unnütz ist, warum hat c-hater ihn sich gekauft?

Das ist einfach: der hat damals ziemlich genau den Bestellwert 
vollgemacht, der nötig war, um bei einer Pollin-Bestellung den Gutschein 
nutzen zu können.

Und es besteht ja immer noch eine gewisse Hoffnung, dass er wirklich mal 
für irgendwas passt...