Hallo zusammen ! Bin nicht zum ersten Mal hier zum Lesen, allerdings nun auch frisch angemeldet zum Fragen stellen ;-) Ich starte mit dieser: Bin noch relativ neu im Thema Mikrocontroller, habe aber schon ein paar Projekte mit Arduinos realisiert, z.B. einen zeitgesteuerten USB-Anschalter mit sieben Ports und eine Schrittmotorsteuerung mit einem Arduino Nano und zwei parallel laufenden Controllerboards für zwei Motoren, um ein Musikkeyboard unter meinem Studioarbeitstisch aus- und einfahren lassen zu können. Also (Kenntnis-)Stand der Dinge ist bei mir: Grundsätzliche Programmierkenntnisse in der Arduino-IDE sind vorhanden inklusive Abfrage von Schaltern auch OHNE Delays über Schleifen. Im Rahmen der Vorstufe eines anderen Projektes habe ich nun bereits einen FRAM über I2C an einen Nano angebunden und aktuelle Schaltzustände von LEDs über das Ausschalten des Arduinos hinaus gespeichert und abrufen können. Nun möchte ich aber zwei Dinge darüber hinaus erreichen: a) mittelfristig in die direkte Benutzung und Programmierung von ATmega328p Chips einsteigen bzw. sozusagen von Arduino darauf umsteigen. Hierzu habe ich schon ein interessantes Buch gefunden, das ich in nächster Zeit durcharbeiten werde: https://www.amazon.de/gp/product/1449355781/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1 b) Und das hier ist die eigentliche Frage: Unabhängig davon würde ich gerne bereits wissen, wie man EIN I2C FRAM Board mit mehreren Mikrocontrollern (zunächst zum Einstieg Arduinos, später dann eben direkt native AVRs) nutzen bzw. ansteuern kann ? Verbindet man einfach alle mit dem I2C Bus und fertig ? Oder muss man die Arduinos bzw. AVRs adressieren ? Ich weiß, dass dies im umgekehrten Fall so ist (Mehrere FRAMs mit einem Arduino), aber was ist mit einem Speicherbaustein und mehreren MC's/AVR's ? Freue mich über Hilfe beim Lernen...! ;-) Besten Gruß an die ganze MC.net Gemeinde ! Uli
Uli A. schrieb: > aber was ist mit einem Speicherbaustein und > mehreren MC's/AVR's ? Eigentlich kein Problem. Nennt sich Multi Master Betrieb, o.ä. Uli A. schrieb: > Verbindet man einfach > alle mit dem I2C Bus und fertig ? So soll es sein, laut I2C Spezifikation.
Hallo, du musst dir die Frage stellen wie du sicherstellst das zum Zeitpunkt x nur ein Controller auf den Baustein zugreift bzw. zugreifen möchte. Sollen alle Controller lesend wie schreibend auf den Baustein zugreifen können?
Veit D. schrieb: > du musst dir die Frage stellen wie du sicherstellst das zum Zeitpunkt x > nur ein Controller auf den Baustein zugreift bzw. zugreifen möchte. "TWI Bus Arbitration" Siehe zugehöriges Kapitel im jeweiligen Datenblatt.
Veit D. schrieb: > Hallo, > > du musst dir die Frage stellen wie du sicherstellst das zum Zeitpunkt x > nur ein Controller auf den Baustein zugreift bzw. zugreifen möchte. > Sollen alle Controller lesend wie schreibend auf den Baustein zugreifen > können? Ja, genau - alle Controller sollen auf dem Speicher schreiben und lesen können. Allerdings nur auf unterschiedliche Speicherbytes - falls das einen Unterschied machen sollte....also z.B. Controller 1 nur auf die ersten 100 Bytes, Controller 2 nur auf Bytes 101-200 etc. ...sie kämen sich also nicht in die Quere mit Zugriffen auf den exakt gleichen Speicherbereich, wohl aber könnte es sein, dass sie gleichzeitig auf dem FRAM lesen/schreiben...
Arduino Fanboy D. schrieb: > Veit D. schrieb: >> du musst dir die Frage stellen wie du sicherstellst das zum Zeitpunkt x >> nur ein Controller auf den Baustein zugreift bzw. zugreifen möchte. > > "TWI Bus Arbitration" > Siehe zugehöriges Kapitel im jeweiligen Datenblatt. Welches Datenblatt meinst Du ? Das des FRAM Boards ?
Uli A. schrieb: > Welches Datenblatt meinst Du ? > Das des FRAM Boards ? Das Fram spricht I2C. AVR Arduinos sprechen TWI. Das macht keinen großen Unterschied. Ich meine dennoch das Datenblatt deines AVR Wire handelt das schon recht gut ab... Du musst dich also nicht unbedingt um die Details kümmern, allerdings die Rückmeldungen auswerten.
@ Uli Der I²C-Bus erlaubt mehrere Master. Master sind Instanzen (also Deine uC) im Bus, die eine Kommunikation anstossen. Siehe https://de.wikipedia.org/wiki/I%C2%B2C#Arbitrierung_im_Multimaster-Betrieb Du benötigst natürlich eine Strategie bei evtl. Kollisionen auf dem Bus, den Vorganz zu wiederholen. Ebenso muss die jeweilige Anwendung auf den uCs damit zurecht kommen, dass Daten zeitweise nicht geschrieben oder gelesen werden können, also eine nicht vorhersagbare Verzögerung dabei eintritt.
Hallo, in die Runde gefragt. Wäre es nicht einfacher nur ein µC beackert den Baustein und er fragt immer der Reihe nach alle anderen ab was sie lesen und schreiben wollen? Also ein Master und "unendlich" viele Slaves. Uli A. schrieb: > Allerdings nur auf unterschiedliche Speicherbytes - falls das > einen Unterschied machen sollte....also z.B. Controller 1 nur auf die > ersten 100 Bytes, Controller 2 nur auf Bytes 101-200 etc. ...sie kämen > sich also nicht in die Quere mit Zugriffen auf den exakt gleichen > Speicherbereich, wohl aber könnte es sein, dass sie gleichzeitig auf dem > FRAM lesen/schreiben... Es spielt keine Rolle welche Speicherbereiche sie ansprechen. Es gibt nur einen Bus. Da darf nur einer zeitgleich drauf quatschen. Die Controller sind alle der Reihe nach dran.
Veit D. schrieb: > in die Runde gefragt. Wäre es nicht einfacher nur ein µC beackert den > Baustein und er fragt immer der Reihe nach alle anderen ab was sie lesen > und schreiben wollen? Also ein Master und "unendlich" viele Slaves. Nein, das wäre aufwendiger. Allerdings sehe ich nicht, warum ein einzelnes FRAM geteilt werden soll. Sofern das schnelle Beschreiben nicht zwingend ist, kann doch jeder µC die Daten im internen EEPROM ablegen. "Schnelles Beschreiben" ist eh fragwürdig, da bei Kollisionen Wartezeiten entstehen. Ich denke, die Planung sollte noch einmal überdacht werden.
Veit D. schrieb: > Wäre es nicht einfacher nur ein µC beackert den > Baustein und er fragt immer der Reihe nach alle anderen ab was sie lesen > und schreiben wollen? Wieso ist irgendwas einfacher, wenn man es komplizierter macht? Wenn ich das richtig verstanden habe, dann wird hier Arduino genutzt. Da ist es üblich die Wire Lib einzusetzen. Diese handelt das ganz prächtig ab. Im Singlemaster Betrieb kann man sie blind nutzen. Im Multimaster Betrieb, muss man in manchen Situationen eine Repeated Start statt einer Stop Kondition setzen. (z.B. zwischen Adresse schreiben und Daten lesen) Wire kennt die entsprechenden Parameter. Auch ein versagen der Arbitration wird erkannt und per Rückgabe gemeldet. Diese Rückgabe gilt es auszuwerten! Es würde mal gut tun, die Wire Doku aufmerksam zu lesen .... Da sie offensichtlich sehr schwer zu finden ist, hier mal ein Einstig: https://www.arduino.cc/en/Reference/WireEndTransmission
m.n. schrieb: > Veit D. schrieb: >> in die Runde gefragt. Wäre es nicht einfacher nur ein µC beackert den >> Baustein und er fragt immer der Reihe nach alle anderen ab was sie lesen >> und schreiben wollen? Also ein Master und "unendlich" viele Slaves. > > Nein, das wäre aufwendiger. > Allerdings sehe ich nicht, warum ein einzelnes FRAM geteilt werden soll. > Sofern das schnelle Beschreiben nicht zwingend ist, kann doch jeder µC > die Daten im internen EEPROM ablegen. "Schnelles Beschreiben" ist eh > fragwürdig, da bei Kollisionen Wartezeiten entstehen. > > Ich denke, die Planung sollte noch einmal überdacht werden. Danke für die Anregungen und fürs Mitdenken. Soweit ich das weiß bzw. gelesen habe ist das Schreiben auf das "interne" EEPROM aber doch nur zeitlich begrenzt bzw. nur einige Tausend mal möglich, bevor das Ding die Biege macht und daher auf Dauer nicht sinnvoll, weil es hier um die Entwicklung eines Studiogeräts geht, das ggfs. täglich hunderte Schaltvorgänge verwalten soll - da sind die meiner Erinnerung nach ca. 30.000 Speichervorgänge fix aufgebraucht...oder habe ich da was falsch verstanden ? Das Thema "Geschwindigkeit" ist für mich dagegen nicht wirklich relevant, da es nur um die simple Abspeicherung von den Ist-Schaltzuständen von Pins bzw. daran hängenden 5V Relais geht.... Grundsätzlich könnte ich natürlich auch pro Arduino / AVR einen eigenen FRAM verwenden und wäre damit schnell durch - die Dinger kosten aber ja immerhin 15€....
Uli A. schrieb: > Grundsätzlich könnte ich natürlich auch pro Arduino / AVR einen eigenen > FRAM verwenden und wäre damit schnell durch - die Dinger kosten aber ja > immerhin 15€.... Es kommt auf die Größe an, aber für € 15 finde ich keins: https://www.reichelt.de/index.html?ACTION=446&LA=446&nbc=1&q=eeprom;SID=93XgjuJawQATQAAF3xrIE45750cf7b37e36d8873c898e2537e5e3
Arduino Fanboy D. schrieb: > Veit D. schrieb: >> Wäre es nicht einfacher nur ein µC beackert den >> Baustein und er fragt immer der Reihe nach alle anderen ab was sie lesen >> und schreiben wollen? > > Wieso ist irgendwas einfacher, wenn man es komplizierter macht? > > Wenn ich das richtig verstanden habe, dann wird hier Arduino genutzt. > Da ist es üblich die Wire Lib einzusetzen. > Diese handelt das ganz prächtig ab. > > Im Singlemaster Betrieb kann man sie blind nutzen. > > Im Multimaster Betrieb, muss man in manchen Situationen eine Repeated > Start statt einer Stop Kondition setzen. (z.B. zwischen Adresse > schreiben und Daten lesen) Wire kennt die entsprechenden Parameter. > Auch ein versagen der Arbitration wird erkannt und per Rückgabe > gemeldet. > Diese Rückgabe gilt es auszuwerten! > > Es würde mal gut tun, die Wire Doku aufmerksam zu lesen .... > Da sie offensichtlich sehr schwer zu finden ist, hier mal ein Einstig: > https://www.arduino.cc/en/Reference/WireEndTransmission Danke für den Hinweis auf das genauere Ansehen der Wire.h. ! Finde den Ansatz mit Master und Slave Arduinos auch eher komplizierter...zumal ich wie erwähnt mittelfristig eher von den Arduinos weg und hin zu nativ(programmiert)en AVRs kommen möchte.... Mal allgemein gefragt, weil ich da noch gar nicht so richtig eingestiegen bin: Kann ich denn Code-Bausteine wie "Wire.h." ausschließlich in der Arduino IDE-Programmierung nutzen ? Oder ist das auch auf eine spätere direkte Verwendung der mega328p's portierbar ? Die wiederum kann man ja auch durch die Verwendung eines Arduino als Flash Programmer programmieren oder ? Freue mich da über ein paar Sätze zu den Grundlagen....;-)
Achtung: Unter "Modell" noch auf FRAM(5) klicken!
Uli A. schrieb: > die Dinger kosten aber ja > immerhin 15€.... 20 Stück FM24C256 gibts beim Chinamann für 5 bis 10 Euronen
m.n. schrieb: > Uli A. schrieb: >> Grundsätzlich könnte ich natürlich auch pro Arduino / AVR einen eigenen >> FRAM verwenden und wäre damit schnell durch - die Dinger kosten aber ja >> immerhin 15€.... > > Es kommt auf die Größe an, aber für € 15 finde ich keins: > https://www.reichelt.de/index.html?ACTION=446&LA=446&nbc=1&q=eeprom;SID=93XgjuJawQATQAAF3xrIE45750cf7b37e36d8873c898e2537e5e3 Hatte jetzt von den I2C FRAM Boards gesprochen (die leider kaum in kleineren Speichergrößen als 32KB erhältlich sind - mir würde für die paar Schaltbytes ja viel weniger reichen)... Bin leider auch noch nicht so weit, das ich wüsste wie man direkt EEPROMS anspricht statt des FRAM über I2C....;-///
Danke m.n und Fanboy ! Sorry, war zu blöd, das mit der FRAM Auswahl zu sehen...;-( Ich verstehe gerade, dass ich mich da offensichtlich ein bisschen besser entscheiden muss, wieviel der Arduino-mit-Shields-Komfortzone ich verlassen möchte bzw. ggfs. muss, um das ganze kostengünstiger und mehr "von der Pike auf" zu lösen....;-) Denn: Die "rohen" FRAM-SMD-Bausteine muss ich doch auch wieder noch anderweitig in das System integrieren, oder ? Will sagen, die fertigen Boards haben doch noch andere Bauteile drum herum, die ja wohl irgendwie nötig zu sein scheinen für die Kommunikation oder den elektronisch korrekten Anschluss des Chips, oder ? Gibt offensichtlich viel zu lernen....;-) z.B. SMD-Löten....;-)
:
Bearbeitet durch User
Uli A. schrieb: > Kann ich denn Code-Bausteine wie "Wire.h." ausschließlich in der Arduino > IDE-Programmierung nutzen ? Du kannst die IDE austauschen und Wire weiter verwenden. Es gibt sicherlich 1/2 Dutzend im Arduino Umfeld einsetzbare IDEs. Auch Kommandozeile ist möglich. Wire ist Teil des Arduino Frameworks. Solange du das mitschleppst, ist auch Wire dabei. Auch gibt es reichlich alternatibe Libs, wenn dir Wire nicht schmeckt, oder du auf das Arduino Framework verzichten willst. Uli A. schrieb: > Oder ist das auch auf eine spätere direkte > Verwendung der mega328p's portierbar ? Wire ist auch auf nackten AVR einsetzbar, ein Arduino Board ist nicht nötig. Uli A. schrieb: > Die wiederum kann man ja auch > durch die Verwendung eines Arduino als Flash Programmer programmieren > oder ? Ja, man kann Arduinos zu ISP Programmern machen.
Uli A. schrieb: > Denn: Die "rohen" FRAM-SMD-Bausteine muss ich doch auch wieder noch > anderweitig in das System integrieren, oder ? Will sagen, die fertigen > Boards haben doch noch andere Bauteile drum herum, die ja wohl irgendwie > nötig zu sein scheinen für die Kommunikation oder den elektronisch > korrekten Anschluss des Chips, oder ? Dummerweise haben die Boards meist Pullup fest drauf. Was dann beim Einsatz vieler solcher Boards an einem Bus Probleme machen kann. Denn es werden pro Bus nur 2 Pullup benötigt. Ein Abblockkondensator, ein paar Lötbrücken für die Adresse. Ansosnsten ist auf den FertigBoards nix drauf, Adafruit hat Schaltpläne für alle Boards öffentlich ausliegen. Da stecke die Nase mal rein!
> Ein Abblockkondensator, ein paar Lötbrücken für die Adresse. > Ansosnsten ist auf den FertigBoards nix drauf, > > Adafruit hat Schaltpläne für alle Boards öffentlich ausliegen. > Da stecke die Nase mal rein! Super Hinweise ! Danke !
Hallo, naja, was aufwendiger oder einfacher ist liegt im Auge des Betrachters. Es gibt nichts einfacheres wie ein Master-Slave Betrieb. Denn hier hat der Master die alleinige und damit volle Kontrolle über den Bus. Was mir bei der Wire Lib fehlt für den Multi-Master Betrieb ist die künstliche zeitliche Verzögerung für den nächsten Request wenn Kollisionen auftreten. Der Trick ist ja wenn es kollidiert das jeder Master unterschiedliche Miniwartezeiten hat bis zum nächsten Versuch, damit sich die Kollision schnell auflöst. Ein Zufallsgenerator im Wertebereich von paar Takten würde ungemein helfen.
Uli A. schrieb: > Grundsätzlich könnte ich natürlich auch pro Arduino / AVR einen eigenen > FRAM verwenden und wäre damit schnell durch - die Dinger kosten aber ja > immerhin 15€.... CY15B004J-SXA, 512 Byte, bei Mouser 2.06 € FM24CL16B-G, 2K Byte, bei Digikey 1.77 €
Veit D. schrieb: > Was mir bei der Wire Lib fehlt für den Multi-Master Betrieb ist die > künstliche zeitliche Verzögerung für den nächsten Request wenn > Kollisionen auftreten. Der Trick ist ja wenn es kollidiert das jeder > Master unterschiedliche Miniwartezeiten hat bis zum nächsten Versuch, > damit sich die Kollision schnell auflöst. Ein Zufallsgenerator im > Wertebereich von paar Takten würde ungemein helfen. Dann mach das doch so! Es ist die Aufgabe eines Programmierers die Rädchen da dran zu bauen, die man benötigt. Warum soll Wire das für dich tun? Wire liefert dir eine Erfolgsmeldung. Ist sie positiv, dann hat alles geklappt. Ist sie negativ, dann machste dein random Delay, und versuchst es danach nochmal. Das ist deine Aufgabe, nicht die von Wire.
Veit D. schrieb: > Hallo, > > naja, was aufwendiger oder einfacher ist liegt im Auge des Betrachters. > Es gibt nichts einfacheres wie ein Master-Slave Betrieb. Denn hier hat > der Master die alleinige und damit volle Kontrolle über den Bus. > > Was mir bei der Wire Lib fehlt für den Multi-Master Betrieb ist die > künstliche zeitliche Verzögerung für den nächsten Request wenn > Kollisionen auftreten. Der Trick ist ja wenn es kollidiert das jeder > Master unterschiedliche Miniwartezeiten hat bis zum nächsten Versuch, > damit sich die Kollision schnell auflöst. Ein Zufallsgenerator im > Wertebereich von paar Takten würde ungemein helfen. Danke für die Anregung - dennoch ist für mich die 1-Master Strategie für dieses Projekt nicht die Richtige, weil ich insgesamt deutlich mehr Pins verwalten muss als wiederum ein Master bewältigen kann...daher ja die vermutlich 6 AVR's mit JE 9 Eingabe und 9 Ausgabe-Pins... LG
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.