Hallo Allerseits, 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. Deshalb bin ich froh um Tipps & Hinweise, wo ich am besten mit Lesen anfange, um mir das nötige Wissen anzueignen, welches für diese Art von Aufgabe geeignet ist. Meine Wissensbasis bisher: Habe ein zwei einfache Arduino-Projekte realisiert & habe schon gelesen, dass es wohl möglichkeiten gibt, Atmel-µController miteinander «sprechen» zu lassen... 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... Gruss elkoo
Spoe N. schrieb: > So stelle ich mir das idealerweise vor: Kannst du das nicht einfach mal als Schaltplan aufskizzieren? Das ist nämlich schlicht&einfach die Sprache der Elektrotechnik. Darin kann man auch ganz leicht irgendwelche Systemfehler (Potentiale, Pegel...) erkennen. > Die werden jeweils mit einer Leitung verbunden Wie lang ist diese Leitung? > via Optocoupler Wenn die Submodule sowieso potentialfrei aus Batterien/Akkus versorgt werden, wozu brauchst du dann noch Optokoppler?
:
Bearbeitet durch Moderator
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: > potentialfrei Niemand außer dir hat Potentialfrei gesagt. Das die 14 Zellen in einem BMS in Reihe geschaltet sind und so eben nicht potentialfrei sind darf als Grundwissen angenommen werden, sofern jemand etwas mehr kann als Batterien tauschen. Lothar M. schrieb: > Das ist > nämlich schlicht&einfach die Sprache der Elektrotechnik. Grundsätzlich hast du Recht, aber wenn alle "Prosaschreiber" so detailliert ausdrücken würden was sie vorhaben, ginge es durchaus auch ohne. Man versteht was er vorhat, und man merkt das er mehr weiß als er meint zu wissen. @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. Ob nicht evtl. I²C oder andere Isolationsmöglichkeiten wie spezielle Chips besser sind müsste man probieren. Grundsätzlich ist es aber problemlos möglich, ein serielles Protokoll mit (Sync/)Start/Adresse/Daten/(Checksumme/)Stop zu machen, viele Bastel-Servo-Controller machen das ähnlich. Testen kann man das ja erstmal ohne das gefährliche Ströme kommen, einfach alle Balancer parallel an ein Netzteil und gut. Jedes Platinchen hat an einem Ende GNDISO, RXISO und TXISO und am anderen Ende davon getrennte VCC und VEE und alles ist grün, sofern due die Isolationsabstände usw. beachtest. Die Teile sollten trotzdem eine Sicherung haben, denn ein defektes Modul kann den Akku durchaus imposant zerstören, da ist es besser wenn der Master merkt das einer seiner Kumpels fehlt und eine rote Lampe anmacht. 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.
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?
Stefanus F. schrieb: > 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. Man kann beim Arduino Uno z.B. aber dennoch den einzigen UART, den das System hat, sehr wohl auch zu eigenen Anwendungen benutzen, auch wenn der an USB angebunden ist. Die Arduinos sind halt schon ganz gut durchdacht was ja u.a. ihren Erfolg begründet hat ;) Zum Thema selbst: Schon mal drüber nachgedacht die Attinys als I2C-Slaves zu konfigurieren und der Arduino mimt dann den Master? Wäre doch IMO ein prädestiniertes System dafür.
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: > 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). Ein Teil davon kannst du auch ohne die Tinys machen. Aber in jedem Fall würde 1-Wire da schon in Frage kommen. https://de.wikipedia.org/wiki/1-Wire Erstmal ist auch wichtig zu wissen welche Tinys du verwenden willst. Nicht alle unterstützen alle Protokolle. Das mit der galvanischen Trennung wird wohl dein größeres Problem sein. Wobei ich noch darauf hinweisen möchte, dass das mit dem "Parasite Power" in meinen Augen Mist ist. Bei mir bekommen die immer Versorgungsspannung. Dann ist der Bus auch schneller. Diese Seite ist ganz nützlich: https://www.msxfaq.de/sonst/bastelbude/1wirebus.htm
:
Bearbeitet durch User
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: So funktioniert das auch, es ist auch eine der einfachsten Lösungen. Auf jeden Fall geht es per UART viel einfacher als per I2C oder OneWire. Die meisten neueren AVR haben auch ein echtes UART mit ein paar Bonus-Features. Was ihnen fehlt, ist ein stabiler Oszillator und eine einfache Möglichkeit, 14 Stück ohne gemeinsame Masse zu programmieren. Es gibt aber den ADS112U04, der macht genau das, was im ersten Beitrag beschrieben ist. Und ein wenig mehr (Ballast-Strom einstellbar, 4 Kanäle, Temperatursensor), genauer (Takt, Referenz und ADC) und einfacher (muss nicht programmiert werden). http://www.ti.com/document-viewer/ADS112U04/datasheet/features-sbas751340#SBAS751340 Die 4 Kanäle könnte man nutzen, um einen Chip für zwei oder drei Zellen zu verwenden. Da der ADC und die interne Referenz ziemlich gut sind, könnte man sich den Fehler des Spannungsteilers wohl erlauben. Man braucht ja auch bei einem Chip pro Zelle einen Spannungsteiler am Eingang. Mit der halben Chip-Anzahl, dem halb so großen Multiplexer und der gesparten ISP-Schnittstelle relativiert sich auch der Preis. Als Bonus braucht man keinen extra Aufwand für Takt oder Synchronisierung. Ja, das wäre viel zu einfach, wahrscheinlich habe ich etwas übersehen. Stefanus F. schrieb: > 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. Oder eben einen verwenden, der einen freien UART Port hat :)
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".
Anstelle Optokoppler würden auch Kondensatoren funktionieren. Die Gegenrichtung wird problemlos wenn alle Tinnys ihren Ausgang hochohmig schalten solange sie nichts zu sagen haben. Bei Optokoplern einfach die Led an Vcc. Da sie Open kolletor sind können sie alle parallel einen Pullup am Master RX Eingang runterziehen. Auch Quarze sind unnötig, die internen Ozillatoren sind genau genug für die Kommunikation. Das Protokoll der Kommunikation ist frei wählbar. Bei mir arbeitet es mit Klartext z. B. Master "id1 get wert" Antwort "id1 wert 125" Dadurch läßt es sich mit jedem Terminalprogramm überwachen/steueren
A. H. schrieb: > Da sie Open kolletor sind können sie alle parallel einen > Pullup am Master RX Eingang runterziehen. Bei 14 Stück funktioniert das nur noch bei Zimmertemperatur. Optokoppler haben bei höheren Temperaturen schon mal 100uA Leckstrom. Ja, man kann mehr LED-Strom spendieren, aber der kommt aus dem Akku...
USART ist der falsche Ansatz. SPI scheint mir hier angebracht.
Bauform B. schrieb: > schon mal 100uA Leckstrom. Nicht so schön. Als Ladegerät egal, aber als dauerhafter Bestandteil echt blöd. Hochwertigere Koppler? oder Kondensatoren? Ein Trafo scheint mir zu aufwendig. Oder den Pullup ausschalten solange keine Antwort erwachtet wird.
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...
Spoe N. schrieb: > Ich möchte mehrere Attiny's galvanisch getrennt mit einem Atmega > kommunizieren lassen (Zwecks Bau eines Battery-Management Systems). Dafür gibts spezialisierte Bausteine, z.B. LTC6810...6813: https://www.analog.com/media/en/technical-documentation/data-sheets/LTC6810-1-6810-2.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/68111fb.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/LTC6812-1.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/LTC6813-1.pdf Das sind funktionierende Lösungen, die Du mit Attinys nicht besser hinbekommen wirst. fchk
Zwischen -10 und 35° hatte ich da noch keine Probleme. Tinny 13 eignen sich gut dafür, dann widerrum fehlen die Pinns für noch einen (14) Quarze. Sollte er dennoch daneben liegen könnte er sich mit Osccal nachjustiern.
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?
Stefanus F. schrieb: > Bevor ihr weiter I²C vorschlagt: Denkt über die Optokoppler nach. > Wenn > ihm die wichtig sind, wird es mit Optokopplern richtig kompliziert. Seit wann denn das? I2C mit Optokopplern ist genauso einfach/kompliziert wie UART mit Optokopplern. UART aber mit 15 Geräten...da muss man etwas an Gehirnschmalz reinstecken damit man auch immer den richtigen Erwischt. Mit den TWI-Funktionen, die in jedem AVR stecken, braucht man das schon mal nicht, da hat ja Atmel schon den Gehirnschmalz investiert. Hugo H. schrieb: > USART ist der falsche Ansatz. SPI scheint mir hier angebracht. Bei 14 Slaves ist SPI vielleicht nicht unbedingt die gute Wahl. Sternsystem braucht dann 14 IOs, Kaskadierung macht die Übertragung langsam.
Stefanus F. schrieb: > c-hater schrieb: >> Arduidioten > > Diese Beleidigung ist unangebracht. Warum versaust du deine fachlich > guten Beiträge immer mit so etwas? Kann ich nur zustimmen. Weis auch nicht was sowas immer soll.
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...
c-hater schrieb: > Erst denken, dann posten... Dann geh mal mit guten Beispiel vorran. Du brauchst halt zwei OK bei I2C für die Signalleitung. Mehr ists aber nicht. Von daher: Stefanus hat schon recht, es ist etwas komlizierter als UART. EDIT: 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.
:
Bearbeitet durch User
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...
c-hater schrieb: > Und was kostet der pro Stück? (Hihihi!) Damit dürfte dieser Pfad der > Diskussion schon erledigt sein... Umsonst ist nicht mal der Tod, der kostet das Leben. Ein preisliches Limit konnte ich bisher nicht entdecken.
c-hater schrieb: > SPI-Ketten funktionieren recht gut, wenn alle Teilnehmer das > gleiche GND-Potential haben. Genau das ist aber hier nicht der Fall... Warum? Nur weil der TO nicht weiß, was er eigentlich will? Spoe N. schrieb: > 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. Warum soll das Ganze denn "galvanisch getrennt" 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...
Stefanus F. schrieb: > 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? Und wie unwahrscheinlich ist es? 2 Bytes a 5bit ergibt 10 bit. Genauer sind die Tiny ADCs auch nicht. Ausserdem hatten alle unsere Tiny25-85 unter 2% Fehler.
:
Bearbeitet durch User
Angehängte Dateien:
-
balancerV3attiny13.png
160 KB
Moin Danke für die zahlreichen guten Antworten und Ratschläge. Ich habe mitgelesen und nun mal ein wenig gezeichnet. Anbei ein erster Hardware-Entwurf zum zerpflücken. Kann das so funktionieren? Gerne nehme ich eure inputs entgegen (bin sicher, dass ich zahlreiche Fehlüberlegungen gemacht habe.. aber bin gespannt wo :) Danke für eure Hinweise & Tipps!!
Der blaue R ist über, die grünen vom Tiny zum Opto auch. Dafür fehlt da ein Pulldown, auch am Master. Und an die Tinys müssen noch Pufferkondensatoren.
Spoe N. schrieb: > Danke für die zahlreichen guten Antworten und Ratschläge. Ich habe > mitgelesen und nun mal ein wenig gezeichnet. Anbei ein erster > Hardware-Entwurf zum zerpflücken. Kann das so funktionieren? Gerne nehme > ich eure inputs entgegen (bin sicher, dass ich zahlreiche > Fehlüberlegungen gemacht habe.. aber bin gespannt wo :) Hättest Du mein Posting gelesen, wäre Dir klar, dass das mit den von mir vorgeschlagenen ICs eine 1-IC-Lösung gewesen wäre. fchk
Frank K. schrieb: > Hättest Du mein Posting gelesen Hab ich sehr wohl gelesen & danke für den netten Vorschlag. Dies ist jedoch nicht der Weg den ich beschreiten will. Es gibt ja sowohl chips bis 16s (wurde auch vorgeschlagen) sowohl als fixfertige BMSs (z.B. https://www.batrium.com die mindestens genau das und noch mehr können was ich bauen will... Ist aber einerseits nicht mit derselben Lernkurve verbunden und andererseits eine Kostenfrage.)
Angehängte Dateien:
-
balancerV3-1attiny13.png
160 KB
Jens M. schrieb: > Der blaue R ist über, die grünen vom Tiny zum Opto auch. Dafür fehlt da > ein Pulldown, auch am Master. > Und an die Tinys müssen noch Pufferkondensatoren. OK, Punkt 1-3 ist klar, die Pufferkondensatoren noch nicht. Wozu und wo genau brauche ich die?
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.
Im Normalfall sind Ein und Ausgänge High solange keiner spricht.Nach der Schaltung müßten alle inaktiv Low sein. Eine Reihenschaltung am Master TX würde viel Strom und 13 Widerstände sparen.
:
Bearbeitet durch User
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.
c-hater schrieb: > 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... 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. Schade eigentlich. Dem TE hilft sowas leider nicht, sonst würde er ja nicht fragen ;)
Der Spannungsteiler fällt kaum ins Gewicht. Könnte aber auch ausgeschaltet werden da noch genügend Pins übrig sind. Ganz ohne Pinverbrauch wäre den Reset als Adc Eingang (Problemlos bis runter auf 0,7Vcc) und den Rx als Spannungteiler gnd zu benutzen.
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.
Den Wunsch an den Zellen noch einen Controller zu haben, den kann ich ja noch nachvollziehen, aber für jede Zelle einen und dann noch aus diesen Zellen versorgt? Viel einfacher wäre es doch einen zu nehmen und alle Zellen damit zu überwachen. Wenn es unbedingt ein kleiner sein soll, dann kann man den Mangel an Pins auch mit Portextender oder Multiplexing erledigen. Der Controller langweilt sich eh die meiste Zeit. Bin gespannt, ob es fertig wird und wir das zu sehen bekommen.
:
Bearbeitet durch User
Stefanus F. schrieb: > Wenn du die Slaves zumindest mit Keramikresonatoren ausstattest, kann es > funktionieren. Es geht auch mit dem internen RC-Oszillator problemlos, wenn man mit Bitsynchronisation arbeitet, zumal die 8-Pinner eh keine HW-UART haben. Siehe mein Link oben.
Peter D. schrieb: > zumal die 8-Pinner eh keine HW-UART haben. Deswegen hatte ich 1-wire vorgeschlagen. DS2438 (habe ich zwar auch noch nicht benutzt) wäre doch schon etwas im die Richtung. Bin mir bewusst, dass man den Wunsch hegt ein eigenes System dem einem vorgegeben, starren System vorzuziehen. Ich glaube deshalb machen die meisten das alles hier, aber sich fertigen Lösungen zu bedienen heißt nicht, dass man alles abgenommen bekommt. Wenn es nur um den Lernerfolg geht, sollte man erstmal schauen die Kommunikation zwischen zwei Controllern, auch galvanisch getrennt, hinzubekommen. Danach dann mehrere Controller abfragen. Wenn das alles klappt, kann man an die Controller auch langsam was anderes als einen Taster zum testen anschließen. Ich glaube jeder von uns hat noch solche Projekte irgendwo rumliegen, deren Komplexität man aus mangelndem Wissen und vor allem aus mangelnder Erfahrung dann am Ende verworfen hat.
:
Bearbeitet durch User
F. F. schrieb: > Deswegen hatte ich 1-wire vorgeschlagen. 1-wire ist bezüglich Timing extrem kritisch. Andere Interrupts sind dabei nicht erlaubt. Bei meinem 124-Bus benutze ich beide Flanken, d.h. die Interruptlast halbiert sich.
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.
c-hater schrieb: > Ich bin sicher: jede einzelne davon hätte man auch mit einem Tiny10 > abhandeln können ... und mehr.
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.
neuer PIC Freund schrieb im Beitrag #5993698: > Der Tiny10 ist standalone ja noch schlechter als der Tiny13. Hat nicht > mal eine Referenz, kann nur ratiometrisch. Psst, du kannst doch jetzt nicht c-hater noch die Vorteile des Tiny13 gegenüber dem Tiny10 verraten. Und verrate ihm auch nicht, dass der Tiny13 z.B. mehr SRAM hat oder auch EEPROM was man im Tiny10 auch vergeblich sucht. Hat schon jemand erwähnt, dass der Tiny13 bis 20 MHz getaktet werden kann, der Tiny10 aber nur bis 12 MHz? Es ist ja so schwer die Vorteile des Tiny13 gegenüber den Tiny10 zu finden. In einem jedoch hat c-hater schon recht: Es dürfte recht selten sein eine Anwendung zu finden, in der der Tiny10 nicht ausreichend ist, die der Tiny13 aber mit bravur besteht. Man könnte sich natürlich fragen: Wenn der Tiny13 so unnütz ist, warum hat c-hater ihn sich gekauft?
Stefanus F. schrieb: >> jede einzelne davon hätte man auch mit einem Tiny10 >> abhandeln können, wenn man den halt in Assembler programmiert... > > Gut möglich. Möglich schon, aber warum sollte man Lebenszeit unnötig verschwenden? Assembler ist nur was für die Leute, bei denen das Programmieren selber das Ziel ist und nicht möglichst schnell, fehlerarm, zuverlässig und erweiterbar die fertige Applikation. Es ist auch ein gutes Gefühl, wenn der nächste Mitarbeiter das Projekt weiter führen kann und nicht alles komplett wegschmeißt.
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.
Stefanus F. schrieb: > 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. Hier etwas Lektüre für dich. Also ich finde das einfach.
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).
Deine Frage war nur, wie man die Rückkopplung verhindert. Das ist eine Lösung, eine weitere war mit dem ISO1540. Eine dritte Lösung liese sich mit dem SN75161 umsetzen. All diese Lösungen bzgl. galvanischer Trennung finde ich recht einfach, egal ob für UART oder I2C. Das Argument war ja, dass die galvanische Trennung für I2C viel zu kompliziert sei als für UART. Wie gesagt, das sehe ich nicht so.
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...
c-hater schrieb: > Und es besteht ja immer noch eine gewisse Hoffnung, dass er wirklich mal > für irgendwas passt... Wie gesagt: Sobald der Tiny10 z.B. etwas zu wenig RAM hat oder ein EEPROM sinnvoll wäre greift man zum Tiny13. Auch bei etwas mehr Rechenleistung ist der Tiny13 im Vorteil. Die beiden sind halt schon sehr dicht zusammen, das stimmt. Der Tiny10 ist natürlich genial, vor allem im tollen SO-23 Package. Da kann man richtig kleine Intelligenzen mit realisieren.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.