Hallo zusammen, Ich beschäftige mich seit kurzem für ein Projekt mit den PICs (PIC16F1823). Ich habe schon einige Erfahrung mit AVRs, bin was die PICs angeht aber noch blutiger Anfänger. Meine Fragen: 1. ist es möglich die IOs weiterhin direkt anzusteuern, auch wenn das I²C Modul aktiviert ist? 2. Wenn ja, wäre es möglich einen Master in Software zu implementieren, der direkt auf die I²C Leitungen "schreibt", während das Hardware-Modul empfängt? Das Ziel davon ist, dass bei einer Kollision auf dem Bus trotzdem keine Daten verloren gehen, auch nicht für den Master der die Arbitrierung "verloren" hat. Deshalb 3. Gibt es eine möglichkeit nur mit dem Hardware-Modul Daten zu senden, bei einer Kollision aber trotzdem den gesamten Datensatz zu erhalten? Ich freue mich auf jede Unterstützung. [Neuling] M1k3y
> Das Ziel davon ist, dass bei einer Kollision auf dem Bus > trotzdem keine Daten verloren gehen Gleichzeitig Master und Slave zu sein ist quatsch. Dann kann der Chip nur mit sich selbst reden. Wozu soll das gut sein? Wechselweise die Rolle von Master und Slave zu haben ist problemlos möglich. Ich bin sicher, dass du den Modus der HW jederzeit schnell umschalten kannst. Bei Kollision sind Datenverluste unvermeidbar. Das I2C Protokoll hat keinen Schutz dagegen. Du must da schon einen Software Layer oben drüber packen, der diese Kollisionen erkennt und repariert oder von vorne herein verhindert.
> Gleichzeitig Master und Slave zu sein ist quatsch. Dann kann der Chip > nur mit sich selbst reden. Wozu soll das gut sein? Nicht unbedingt. Der Punkt ist das in meiner Anwendung Kollisionen nicht nur möglich sondern sogar wahrscheinlich sind. Es werden potentiell bis zu 100 Teilnehmer auf dem Bus kommunizieren. Ich muss Sicherstellen, dass bei einer Kollision trotzdem alle Teilnehmer alle Daten erhalten, da häufiger Daten als "Broadcast" versendet werden. [edit] Ich möchte mit dem doppelten System den Master vom Slave trennen. Somit könnte ich gleichzeitig die Daten für den Fall einer Kollision empfangen. M1k3y [jetzt mit Account]
:
Bearbeitet durch User
Tobias E. schrieb: > Der Punkt ist das in meiner Anwendung Kollisionen nicht nur möglich > sondern sogar wahrscheinlich sind. Es werden potentiell bis zu 100 > Teilnehmer auf dem Bus kommunizieren. > > Ich muss Sicherstellen, dass bei einer Kollision trotzdem alle > Teilnehmer alle Daten erhalten, da häufiger Daten als "Broadcast" > versendet werden. Bist Du sicher, dass Du I2C nehmen willst?
Tobias E. schrieb: >> Gleichzeitig Master und Slave zu sein ist quatsch. Dann kann der > Chip >> nur mit sich selbst reden. Wozu soll das gut sein? > > Nicht unbedingt. > > Der Punkt ist das in meiner Anwendung Kollisionen nicht nur möglich > sondern sogar wahrscheinlich sind. Es werden potentiell bis zu 100 > Teilnehmer auf dem Bus kommunizieren. > > Ich muss Sicherstellen, dass bei einer Kollision trotzdem alle > Teilnehmer alle Daten erhalten, da häufiger Daten als "Broadcast" > versendet werden. > > [edit] > Ich möchte mit dem doppelten System den Master vom Slave trennen. Somit > könnte ich gleichzeitig die Daten für den Fall einer Kollision > empfangen. > > M1k3y [jetzt mit Account] 100 Teilnehmer und jeder kann wahlfrei senden? Da ist I2C aber gar keine so gute Idee. Was ich mich da gleich noch frage: Wie lang ist dein Bus?
Tobias E. schrieb: > Es werden potentiell bis zu 100 > Teilnehmer auf dem Bus kommunizieren. > > [...] da häufiger Daten als "Broadcast" > versendet werden. I2C funktioniert anders.
@google > Bist Du sicher, dass Du I2C nehmen willst? I²C ist der einzige Bus der alle vorraussetzungen erfüllt. Ich brauche keine hohen Datenraten. Aber Multimaster und die Möglichkeit zur Kollisionserkennung. @-.-.- > 100 Teilnehmer und jeder kann wahlfrei senden? Da ist I2C aber gar keine > so gute Idee. Die Teilnehmer senden nur bei Events. Allerdings können diese zeitlich sehr nah (bis zeitgleich) auftreten. Die Datenrate wird sicherlich kein Problem darstellen. Der Datenverlust für einen Master der bei einer Kollision die Arbitrierung verliert ist das einzige Problem das noch besteht. > Was ich mich da gleich noch frage: Wie lang ist dein Bus? In der Theorie mehrere Meter. Allerdings elektronisch in Abschnitte von <1m unterteilt. Reflektionen, Übersprechen und Buskapazität als Fehlerquellen sind gelöst.
Oliver R. schrieb: >> Es werden potentiell bis zu 100 >> Teilnehmer auf dem Bus kommunizieren. >> >> [...] da häufiger Daten als "Broadcast" >> versendet werden. > > I2C funktioniert anders. Jein. Ich benutze die General Call Adresse für einige Daten. Das entspricht in etwa einem broadcast.
Um mit der Forenempfehlung zu antworten: dafür nimmt man besser CAN. Ich weiß nicht, ob das auf dem PIC geht, was Du vorhast, aber es gibt jede Menge PIC, die CAN eingebaut haben. fchk oder Volker werden Dir bestimmt gleich schreiben, welche. ;-)
google schrieb: > Um mit der Forenempfehlung zu antworten: dafür nimmt man besser CAN. Ist in meinem Fall leider keine Option. Für CAN brauche ich (nach meinem Kenntnissstand) einen zusätzlichen Transceiver. Meine Anwendung zielt aber darauf ab, dass der einzelene Node so klein, einfach und vor allem günstig wie möglich ist. M1k3y
Tobias E. schrieb: > Der Datenverlust für einen Master der bei einer > Kollision die Arbitrierung verliert ist das einzige Problem das noch > besteht. Das merkt der Verlierer aber. Warum kann er dann nicht einfach seine Sendung wiederholen? Aber ganz allgemein halte auch ich den I2C Bus in deinem Fall für die falsche Wahl.
Tobias E. schrieb: > google schrieb: >> Um mit der Forenempfehlung zu antworten: dafür nimmt man besser CAN. > > Ist in meinem Fall leider keine Option. Für CAN brauche ich (nach meinem > Kenntnissstand) einen zusätzlichen Transceiver. Meine Anwendung zielt > aber darauf ab, dass der einzelene Node so klein, einfach und vor allem > günstig wie möglich ist. > > M1k3y Ich kenn mich zwar mit PICs nicht aus, bin aber sicher, dass es PICs gibt mit komplett fertigen CAN inkl. Transceiver etc. Da nur noch CAN_L und CAN_H anschließen und ballern. Für deinen beschriebenen Einsatz eignet sich I2C nicht sehr gut, da ist CAN so viel besser!
Georg G. schrieb: > Tobias E. schrieb: >> Der Datenverlust für einen Master der bei einer >> Kollision die Arbitrierung verliert ist das einzige Problem das noch >> besteht. > > Das merkt der Verlierer aber. Warum kann er dann nicht einfach seine > Sendung wiederholen? Das ist nicht der Punkt. Der Verlierer wiederholt selbstverständlich seine Nachricht. Es geht darum dass der Verlierer die aktuelle Übertragung des Gewinners vollständig erhält. > Aber ganz allgemein halte auch ich den I2C Bus in deinem Fall für die > falsche Wahl. Die alternative ist im Moment ein selbstentwickelter Bus, den ich basierend auf I²C gebastelt habe. Ich möchte aber wenn möglich lieber etwas bewährtes nehmen.
Du kannst natürlich die Logik-Pegel an den Pins per Software einlesen, auch, wenn sie auf Ausgang geschaltet sind oder durch das MSSP-Modul kontrolliert werden. So kannst Du ggf. einen "Software-Slave" parallel zum MSSP mitlaufen lassen, der die Kommunikation überwacht. Auch die Port-Change Interrupts müssten wie erwartet funktionieren, so daß die Software gezielt bei einer Flanke an CLK in Aktion treten kann und nicht ständig pollen muss. Wenn Dein Software-Slave allerdings auch Signale treiben können muss (Daten oder ACK senden), muss das Hardware-Modul dafür allerdings deaktiviert werden. Oder vielleicht hast Du noch zwei Portleitungen frei, dann könnten diese parallel zur Datenleitung angeschlossen werden. Dann kann das MSSP-Modul auch eingeschaltet bleiben und Du hast praktisch zwei unabhängige I2C-Module.
Thomas E. schrieb: > Du kannst natürlich die Logik-Pegel an den Pins per Software einlesen, > auch, wenn sie auf Ausgang geschaltet sind oder durch das MSSP-Modul > kontrolliert werden. So kannst Du ggf. einen "Software-Slave" parallel > zum MSSP mitlaufen lassen [...] Hätte ich auch selber drauf kommen können das ganze umzudrehen. Danke dafür. > Wenn Dein Software-Slave allerdings auch Signale treiben können muss > (Daten oder ACK senden) [...] Muss er zum Glück nicht. ACKs brauch ich nicht und es werden keine READ Aktionen auf dem Bus durchgeführt. Ich denke damit wäre dieses letzte Problem auch gelöst. Allen hier danke für die schnelle und äuserst kompetente Hilfe. M1k3y
Stefan U. schrieb: > Gleichzeitig Master und Slave zu sein ist quatsch. Dann kann der Chip > nur mit sich selbst reden. Wozu soll das gut sein? Kein Quatsch, nennt sich Multimaster, ist in der I2C-Spezifikation ausdrücklich vorgesehen. Bei den 8051/AVR ist dafür der Status 0x68 vorgesehen: "Arbitration lost in SLA+R/W as Master; own SLA+W has been received; ACK has been returned". Es kann allerdings sein, daß dieser PIC keine vollständige I2C-Implementation enthält.
Tobias E. schrieb: > Es geht darum dass der Verlierer die aktuelle Übertragung des Gewinners > vollständig erhält. Wo ist das Problem? Kollision wird erkannt und du schaltest auf Empfang um. Alles, was auf dem Bus bis zu diesem Zeitpunkt gelaufen ist, ist bekannt. Als kannst du nahtlos aufsetzen. Es sollte aber ein Soft-Empfänger sein. Das HW Modul ist dazu nicht flexibel genug (vermute ich).
> Alles, was auf dem Bus bis zu diesem Zeitpunkt gelaufen ist, > ist bekannt. Nein. Wenn mehrere Busteilnehmer zugleich die CLK Leitung ansteuern, wird ihr Signal verzerrt und dadurch werden auch die Daten verfälscht. Um einen cleveren Retry Mechanismus kommt man nicht herum. Übrigens sind 100 Teilnehmer für normale I2C Bausteine viel zu viel. Doch du willst ja sogar ohne Treiber auskommen!
Georg G. schrieb: > Kollision wird erkannt und du schaltest auf Empfang um. Mit dem Auftreten der Kollision ist der Datenblock eh zerstört und muß neu gesendet werden. Dann kann man sich den ganzen Kram sparen und arbeitet mit einem vernünftigen Handshake. Broadcasts kann man so nur nutzen, wenn man mit Datenverlusten leben kann.
Won K. schrieb: > Mit dem Auftreten der Kollision ist der Datenblock eh zerstört und muß > neu gesendet werden. Nö, nur der unterlegene Master muß erneut senden. Der gewinnende Master kann seinen Transfer fortsetzen. Er merkt nichtmal, daß ein 2. Master parallel gesendet hat.
Stefan U. schrieb: > Wenn mehrere Busteilnehmer zugleich die CLK Leitung ansteuern, > wird ihr Signal verzerrt und dadurch werden auch die Daten verfälscht. Auch das ist falsch. Jeder Teilnehmer darf den Clock stretchen, auch ein Slave. Der/die aktiven Master warten solange mit dem nächsten Bit, bis SCL = high ist.
Stefan U. schrieb: > Übrigens sind 100 Teilnehmer für normale I2C Bausteine viel zu viel. > Doch du willst ja sogar ohne Treiber auskommen! Wieso? Das gibt auch bloß eine Kapazität im einstelligen Nanofarad-Bereich, und die Eingänge sind alles Schmitt-Trigger. Er wird ja wohl nicht jeden Teilnehmer mit 1k Pull-Up ausstatten. Ich denke, das funktioniert schon...
Thomas E. schrieb: > Stefan U. schrieb: >> Übrigens sind 100 Teilnehmer für normale I2C Bausteine viel zu viel. >> Doch du willst ja sogar ohne Treiber auskommen! > > Wieso? Das gibt auch bloß eine Kapazität im einstelligen > Nanofarad-Bereich, und die Eingänge sind alles Schmitt-Trigger. Er wird > ja wohl nicht jeden Teilnehmer mit 1k Pull-Up ausstatten. Ich denke, das > funktioniert schon... Ja, das denkt man. Nicht denken, rechnen sollte man. 10nF 1k sind schon 10µs Zeitkonstante. Wie soll man da halbwegs ordentlich 100kHz Minimaltakt erreichen, hmm? Der arme Master, der zusätzlich zu dem Strom aus dem 1k noch die xnF zeitnahe entleeren muss muss ;-) Elektrisch klappt das nie gescheit. Aber Abhilfe ist mögich: http://www.nxp.com/products/interface-and-connectivity/interface-and-system-management/i2c/i2c-multiplexers-switches:MC_41851
Peter D. schrieb: > Auch das ist falsch. Jeder Teilnehmer darf den Clock stretchen, auch ein > Slave. Der/die aktiven Master warten solange mit dem nächsten Bit, bis > SCL = high ist. Macht der Herr Sonnenschein mal wieder eins auf Oberklug? lg Heiner
Die Aufgabe ist doch geradezu prädestiniert für den LPC11C24 mit integriertem CAN-Transceiver. Der kostet unter 2€, mit dem Transceiver auf Basis des TJF1051 kann der ca. 100 Teilnehmer - wobei die Anzahl von CAN Nodes schon grenzwertig ist. Wenn man es vernünftig aufbauen möchte nimmt man einen Master mit 2 CANs und teilt dann auf. Der I2C ist selbst mit der bei einer angenommenen Stecke von 30..50cm zwischen den Nodes absolut fehl am Platz, ganz zu schweigen von der zu treibenden kapazitiven Last. Weiterhin die nicht symmetrische Übertragung von Clock und Data auf dieser Strecke. Und dann noch die geplante Master/Slave Konzeption führen die Idee I2C ad absurdum. Mag sein, dass man es "irgendwie" mit I2C lauffähig bekommt. Eine "vernünftige" Elektronikentwicklung ist das aber nicht.
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.