Hallo, ich bastel derzeit mal wieder an einem etwas größerem Roboter und mache mir schon seit einiger Zeit Gedanken über das Bus-System. Ich brauche auf jeden Fall eins, momentan stehe ich bei TWI, jedoch ist das alles andere als perfekt ;) Der CAN Bus hat es mir extrem angetan (so vom Prinzip her) aber ist der Hard- und/oder Softwareaufwand sehr groß. Zumal es auch nicht so ganz billig ist. Auf allen Sensoren/Aktoren wollte ich AtMega verbauen. Zu meinem Problem: Der TWI hat zwei unschlagbare Vorteile: Ich habe schon mit ihm gearbeitet und auch mehrfach zum laufen bekommen und es gibt ihn auf (fast??) jedem AtMega. Das Problem ist jedoch, dass ich dann halt einen Master brauche, der quasi als Router fungiert und das ist verdammt aufwändig zu implementieren. Das ist ja soweit ich das verstanden habe beim CAN anders, da sendet Quasi jeder an alle und wer möchte kann dies empfangen/auswerten. Kann ich den TWI irgendwie so benutzen, dass das auch gehen würde? Es gibt ja die möglichkeit ein Multi-Master System zu bauen. Kann ich nicht einfach alle auf Slave schalten, will einer was senden wechselt er in den Master Modus und sendet an den Broadcast. Sollte denke ich gehen aber wie sieht es dann mit den Kollisionen aus? Wenn nun zwei senden wollen, beide wechseln in Master-Mode, der eine merkt, dass da noch ein anderer Master ist, kann er dann wieder schnell in den Slave Modus schalten um die Übertragung noch mitzubekommen? Vermutlich nicht :( Oder kennt jemand noch eine andere Möglichkeit? Evtl. was selber gebautes? Der Bus muss nicht sehr schnell sein (1kb/s reicht vollkommen aus denke ich) und ein Paket kann auch auf eine bestimmte Anzahl begrenzt sein (8 Daten Byte sollten reichen). Wenn einer sendet sollen es alle anderen empfangen können und wissen von wem es kam. Sorry wegen dem langen Text, aber ich weiß nicht wie ich es besser beschreiben soll :(
Fabian S. wrote: > Hallo, > ich bastel derzeit mal wieder an einem etwas größerem Roboter Ok. Ich nehme an, du meinst mit 'größer' so etwa Kantenlänge um die 50 Meter oder? Weil sonst isses ziemlich wurscht, welches Verfahren du benutzt -- Störeinstrahlungen lassen sich noch mit Hausmitteln einfach bekämpfen... > Der CAN Bus hat es mir extrem angetan (so vom Prinzip her) aber ist der > Hard- und/oder Softwareaufwand sehr groß. Zumal es auch nicht so ganz > billig ist. Jo, ist schon schick, ist störsicher und bringt reichlich Overhead mit (Treiber, Drossel, Kabel, Protokolloverhead, Software...). > Zu meinem Problem: Der TWI hat zwei unschlagbare Vorteile: Ich habe > schon mit ihm gearbeitet und auch mehrfach zum laufen bekommen und es > gibt ihn auf (fast??) jedem AtMega. Nujo, TWI an sich ist schon ok. Es hat allerdings ein paar unschöne Haken: - TWI-Interface beim AVR ist äußerst komplex, wenn man nicht immer und überall sämtliche Zustände berücksichtigt, kommts gerne zu Aufhängern. - TWI lässt sich nur bedingt mit 'Repeatern' verstärken, da ein Takt ja bidirektional ist, man die Richtung aber nicht anhand des Protokolles erkennen kann (müsste man schon für jeden Slave nachgucken, nach welchen Steuersequenzen der auf Sendebetrieb geht -- Pegel überwachen is auch nix, denn da wird passiv hochgezogen). - Passiver Bus (wird mit R hochgezogen), das ist u.U. störanfällig. Besser wären aktive Treiber (lässt sich mit Konstantstromquelle oder sowas ja nachrüsten). > Das Problem ist jedoch, dass ich > dann halt einen Master brauche, der quasi als Router fungiert und das > ist verdammt aufwändig zu implementieren. Das ist ja soweit ich das > verstanden habe beim CAN anders, da sendet Quasi jeder an alle und wer > möchte kann dies empfangen/auswerten. Ok... ich glaub, du verwechselst da was mit SPI. > Kann ich den TWI irgendwie so benutzen, dass das auch gehen würde? Es > gibt ja die möglichkeit ein Multi-Master System zu bauen. Kann ich nicht > einfach alle auf Slave schalten, will einer was senden wechselt er in > den Master Modus und sendet an den Broadcast. Nennt sich dann halt I2C-Bus :-) und der ist sogar Multimaster-fähig. Genau so kann man das machen. > Sollte denke ich gehen > aber wie sieht es dann mit den Kollisionen aus? Wenn nun zwei senden > wollen, beide wechseln in Master-Mode, der eine merkt, dass da noch ein > anderer Master ist, kann er dann wieder schnell in den Slave Modus > schalten um die Übertragung noch mitzubekommen? Vermutlich nicht :( Doch, bei einem passiven Bus geht das. Im AVR-Datenblatt ist das als 'Bus-arbitration' beschrieben (...Bus-Schiedsgericht). Überlegung: - Kurzschlüsse kanns nicht geben, da alle nur aktiv nach Masse ziehen, rauf gehts per Widerstand. - Wenn einer sendet, kann er nur zwischen 'ich will runter' oder 'lass mal hochgehen' wechseln (=Transistor nach Masse oder R nach Vcc) - Wenn einer einen positiven Pegel senden will, macht er folglich einfach garnichts - Wenn einer nun einen positiven Pegel sendet, aber feststellt, dass der Bus trotzdem einen negativen Pegel besitzt (weil ein anderer angefangen hat, zu labern), kann er sofort abbrechen und stört niemanden. > Oder kennt jemand noch eine andere Möglichkeit? Evtl. was selber > gebautes? Selbes Spiel mit kurzschlussfesten RS485-Treibern.
Ahh ok, das im Datenblatt werde ich mir mal reinziehen.
> Ok... ich glaub, du verwechselst da was mit SPI.
Worauf beziehst du das jetzt? Dass ich einen Master brauche oder, dass
es bei CAN anders ist?
Wenn ich bei TWI mit nur einem Master von Slave A zu Slave B etwas
senden will, muss der Master den Slave A fragen "hast du was für mich?",
der Slave A sendet den Kram dem Master, der Muss das Paket
interpretieren und schauen an wen es gehen soll und es dann an Slave B
senden.
Mag ja sein, dass das mit diesem 'Bus-arbitration' auch ohne geht ;)
Fabian S. wrote: > Ahh ok, das im Datenblatt werde ich mir mal reinziehen. > >> Ok... ich glaub, du verwechselst da was mit SPI. > Worauf beziehst du das jetzt? Bezieht sich auf deine Idee mit dem 'Master-Router', der die Slaves nacheinander abklappert. Bei SPI hast du eine Punkt-zu-Punkt-Verbindung, also keinen Bus. Beim TWI aber schon :-) > Wenn ich bei TWI mit nur einem Master von Slave A zu Slave B etwas > senden will, muss der Master den Slave A fragen "hast du was für mich?", > der Slave A sendet den Kram dem Master, der Muss das Paket > interpretieren und schauen an wen es gehen soll und es dann an Slave B > senden. Richtig. > Mag ja sein, dass das mit diesem 'Bus-arbitration' auch ohne geht ;) Jo, nämlich genau dazu ist diese Bus-Arbitration ja auch da g
Mhh ok... Hab mir mal eben den Krams im Datenblatt durchgelesen, verstehen tuh ichs nicht so ganz :( OK, nur um nochmal sicher zu gehen. Ich habe alle Geräte auf Slave stehen. Nun entscheiden sich zwei davon zu senden, beide wechseln in den Master-Mode, senden die Adresse 0x00, um an alle zu senden, dann geht das senden der Daten los und erst jetzt bemerkt doch einer der Master, dass da noch ein 2. ist. Wenn ich den dann in den Slave-Mode schalte, ist es doch viel zu spät? Oder rekonstruiert er quasi das empfangene mit dem was er gesendet hat (es muss ja das gleich sein)?
Mhh... hört sich erstmal deutlich einfacher an als TWI ;) Habe mir den Wiki Artikel durchgelesen, da steht aber leider nichts über Kollisionen etc. Scheinbar muss man das alles selber machen. Aber sollte doch nicht so schwer sein oder? Das kann man dann ja auch alles mit dem Hardware UART machen. Das Problem ist nur, dass ich zwar nicht viel Datenaufkommen habe, aber regelmäßiges, eben Sensoren, Motor-Steuerung, ... Alles sachen die in kurzen Abständen erneut gesendet werden, was die Warscheinlichkeit einer Kollision nach oben treibt. Und wenn ich es mit dem Hardware uart mache wird es vermutlich meistens der Fall sein, dass dann beide Sender den anderen bemerken und beide abbrechen. Habe hier noch einen kleinen Tipp gefunden, dass man an Stelle der RS485 Treiber lieber einen CAN Treiber nehmen soll, weil der irgendwas mit der Kollision besser kann: Beitrag "Kollisionserkennung bei RS485"
Mir kommt gerade folgende Idee, vielleicht funktioniert das ja sogar?
Du verwendest SPI, aber alle uC's funktionieren als Slave und sind zu
einem Kreis zusammen geschlossen, wobei jeder uC eine eindeutige Nummer
n hat:
Der MOSI-Pin eines jeden uC's (n) ist mit dem MISO des vorherigen uC's
(n-1) verbunden. Alle SS sind direkt mit GND verbunden. SCK hängt direkt
an einem Taktgeber (Quarzoszillator oder so). Jeder uC sendet dabei
immer Datenpakete mit z.B. 9 Bytes - das 1. Byte ist die Nummer des
Ziel-uC's, der Rest die Daten. Lege fest, dass z.B. die Nummer 255 auf
dem Bus nie vorkommt, sodass Pakete an die Adresse 255 nirgendwo
ankommen.
Wenn ein uC ein Paket empfängt, gibt es folgende Möglichkeiten:
- Die Zieladresse ist weder die eigene noch 255
=> Das Paket wird weitergeschickt.
- Die Zieladresse ist 255 ODER die Zieladresse stimmt mit der eigenen
überein => Auswertung der Daten.
- Der uC hat Daten zu senden => Werden abgeschickt.
- Der uC hat keine Daten zu senden => Ein Paket an 255 wird
verschickt.
Außerdem solltest du vielleicht ein Bit des Address-Bytes (oder eines
gesonderten Flag-Bytes) "reservieren" und beim Abschicken neuer
Datenpakete (also nicht beim weiterleiten) auf 0 setzen. Einer der uC's
wird als "Watchdog" definiert. Er setzt dieses Bit beim durchreichen
immer auf 1. Empfängt dieser ein Datenpaket, in dem dieses Bit gesetzt
ist, bedeutet dies, dass die Ziel-Addresse auf dem Bus nicht existiert,
und der Watchdog löscht dieses Paket und sendet stattdessen ein
255er-Paket, um zu verhindern, dass der Bus mit fehlerhaften Paketen
zugestopft wird.
Ein solches Bussystem hätte eine relativ hohe Latenzzeit, aber einen
recht hohen Datendurchsatz, und jeder uC kann an jeden Daten schicken.
Der Hardware-Aufwand wäre minimal, und der Software-Aufwand müsste sich
auch in Grenzen halten.
Habe ich hier das Rad neu erfunden oder es ist völliger Unsinn oder ist
das tatsächlich sinnvoll :) ?
Edit: Schematisch so:
+-----------+ +-----------+ +-----------+
| uC | | uC | | uC |
+-->--+ MOSI MISO +-->--+ MOSI MISO +-->--+ MOSI MISO +-->--+
| | | | | | | |
| +-----------+ +-----------+ +-----------+ |
+-----------------<-----------------<-----------------------+
Bei RS485 wirst du nix zu Kollisionen finden, denn RS485 ist kein Protokoll, sondern nur eine Schnittstelle. SPI und dann einmal rundrum nemmt man 'Daisy-Chain', klar, schnarchlahm und wenn irgendwo ein Loch ist, hasten Problem g JTAG beispielsweise macht das, oder früher die Glasfasernetzwerke. Fabian S. wrote: > OK, nur um nochmal sicher zu gehen. Ich habe alle Geräte auf Slave > stehen. Nun entscheiden sich zwei davon zu senden, beide wechseln in den > Master-Mode, senden die Adresse 0x00, um an alle zu senden, dann geht > das senden der Daten los und erst jetzt bemerkt doch einer der Master, > dass da noch ein 2. ist. Jo. > Wenn ich den dann in den Slave-Mode schalte, ist es doch viel zu spät? Wieso? Beispiel: - Wenn beide gleichzeitig anfangen, zu reden, und wenn dann noch beide dasselbe zu erzählen haben, fällt die Kollision garnicht auf und alle sind glücklich. - Wenn zwei gleichzeitig reden, gibts nur eine Möglichkeit, sodass 'A' den 'B' stören kann: Indem 'B' ein (passives) 'Hoch' sendet, wohingegen 'A' gleichzeitig ein 'Tief' will und die Leitung runterzieht. In diesem Zustand liegen ja immernoch gültige und fehlerfreie Daten an, nämlich die des 'A' (der ja gerade runtergezogen hat). Das wiederum merkt 'B' und klinkt sich aus -- genau jetzt ist die Arbitration geschehen. 'B' muss halt warten, bis der Bus wieder frei ist, um nochmal von vorne zu senden. Schlussfolgerung ist dann natürlich, dass wenns denn zur Arbitration kommt, immer derjenige gewinnt, der als erstes ein 'Tief' sendet.
> 'B' muss halt warten, bis der Bus wieder frei ist, um nochmal von vorne > zu senden. Schlussfolgerung ist dann natürlich, dass wenns denn zur > Arbitration kommt, immer derjenige gewinnt, der als erstes ein 'Tief' > sendet. Jo, aber kann B dann was A schon gesendet hat noch mit empfangen? Ich habe ja z.B. den Fall der Motor-Treiber. Die bekommen vom PC die Nenndrehzahl vorgegeben, der Motor-Treiber liefert die Temperatur der Mosfets und die aktuelle Drehzahl zurück. Wenn die beiden nun gleichzeig senden wollen und der Motor-Treiber "gibt auf", bekommt er dann noch die neue Nenndrehzahl?
@Niklas: Es wird permanent übertragen und bei einfachen ungepufferten SPI-Modulen wie in den AVRs bleibt nicht viel Zeit zum nachdenken wenn im Slave-Mode ein Byte im Kasten liegt. Schon bei mässig hoher Bitrate kann das interessant werden. Du musst dir immer noch Gedanken darüber machen, wer wann sein Frame los werden darf. Da landest du schnell bei Token Passing und bei einer dank 8 Bit Breite nicht transparenten Übertragung, d.h. das Token darf in den Daten nicht vorkommen. Und wenn es mal weg ist, muss jemand (wer?) es wieder einspeisen. Es fehlt die Synchronisierung auf das Byte. Du hast einen konstanten Bitstrom ohne jede Information wo ein Byte anfängt. Sowas klappt besser wenn man den Ring statt dessen mit UART aufbaut.
Ok, Ring kommt denke ich so oder so nicht in Frage, weil das viel zu viel Kabel wäre was ich im Bot verteilen müsste :P Ne mal im Ernst, irgnedwie gefallen mir Ringe nicht. Vorallem wegen dem Ausfall-Problem.
A. K. wrote: > Du musst dir immer noch Gedanken darüber machen, wer wann sein Frame los > werden darf. Da landest du schnell bei Token Passing und bei einer dank > 8 Bit Breite nicht transparenten Übertragung, d.h. das Token darf in den > Daten nicht vorkommen. Und wenn es mal weg ist, muss jemand (wer?) es > wieder einspeisen. Hm, ich hätte jetzt gedacht, dass jeder immer dann senden darf, wenn er ein 255er-Paket empfangen hat, und sonst durchreichen muss. > Es fehlt die Synchronisierung auf das Byte. Du hast einen konstanten > Bitstrom ohne jede Information wo ein Byte anfängt. Zählte nicht das SPI-Modul in den ATmega's die SCK-Takte mit und signalisiert nach 8 Takten ein fertiges Byte an das Programm? Oder hab ich das falsch in Erinnerung - Dann bräuchte man einen Master, der nach 8 SCK-Takten jeweils SS auf HIGH zieht, um ein Byte-Ende zu signalisieren, und eventuell SCK kurze Zeit anhält, damit die anderen uC's genug Zeit zum Nachdenken haben... Was der Geschwindigkeit ungemein zuträglich wäre... Hmm, gut, es war einen Versuch wert :) > Ne mal im Ernst, irgnedwie gefallen mir Ringe nicht. Vorallem wegen dem > Ausfall-Problem. Hast Recht, wenn bei der Menge an Kabeln eines kaputt geht/abgeht geht gar nichts mehr...
Fabian S. wrote: >> 'B' muss halt warten, bis der Bus wieder frei ist, um nochmal von vorne >> zu senden. Schlussfolgerung ist dann natürlich, dass wenns denn zur >> Arbitration kommt, immer derjenige gewinnt, der als erstes ein 'Tief' >> sendet. > Jo, aber kann B dann was A schon gesendet hat noch mit empfangen? Prinzipiell schon, ob das das TWI-Modul im AVR kann, weiß ich nicht. > Ich habe ja z.B. den Fall der Motor-Treiber. Die bekommen vom PC die > Nenndrehzahl vorgegeben, der Motor-Treiber liefert die Temperatur der > Mosfets und die aktuelle Drehzahl zurück. > Wenn die beiden nun gleichzeig senden wollen und der Motor-Treiber "gibt > auf", bekommt er dann noch die neue Nenndrehzahl? Du musst halt aufpassen, dass sich zwei Knoten nicht gleichzeitig gegenseitig anlabern wollen, das geht vermutlich in die Hose :-)
> Du musst halt aufpassen, dass sich zwei Knoten nicht gleichzeitig > gegenseitig anlabern wollen, das geht vermutlich in die Hose :-) Jo eben und um das zu managen brauche ich wieder ein Master :D Von daher ist das ganze fürn Ar***. Wenn das nicht geht fällt TWI flach. Als nächstes würde bei mir die Idee mit UART/RS485 anstehen. Auch hier wieder die Frage mit den Kollisionen.
Sven P. wrote: > Jo, ist schon schick, ist störsicher und bringt reichlich Overhead mit > (Treiber, Drossel, Kabel, Protokolloverhead, Software...). Der in Software zu implementierende Overhead von CAN ist geringer als der anderer hardwareseitig einfacherer Multimaster-Lösungen, da der ganze Multimaster-Kram fix und fertig im CAN Controller steckt. Es zwingt ja einen niemand dazu, CanOpen zu verwenden. Und im hier skizzierten Umfeld dürfte die Begrenzung auf 8 Bytes Daten pro Frame auch kein Problem sein. Ein Paket per CAN zu versenden heisst, es dem CAN Controller zum Frass vorzuwerfen. Den Rest macht der dann. Keine Arbitrierung, kein Weiterleiten fremder Frames, keine Timeouts verlorener Token, kein Prüfsummencheck, usw. Und Empfangen tut man genau das was korrekt reinkam und einen auch angeht, nichts sonst. Wenn du das Kabel als Overhead siehst, hast du alternativ wohl Funk im Auge. Oder was ist damit gemeint? Dass CAN eine Drossel voraussetzt ist mir neu. Sicherlich ist die Hardware etwas aufwendiger. Weil man sich dafür einen MCP2515 pro Node ans Bein binden oder teurere Controller mit internem CAN verwenden muss (z.B. PIC18 28pin). Wenn das zu teuer ist, sollte man ernsthaft überlegen, ob man mit einem zentralen Master nicht auch leben kann. Das ist sehr viel einfacher als Multimaster "zu Fuss". Selbst wenn man dann einen kleinen Controller ausschliesslich als Paket-Poller/Router definieren muss, wenn sich von Haus aus sonst keiner als Master anbietet.
A. K. (prx): Ist alles richtig was du sagst :-) Nur gegenüber zwei Leitungen beim TWI ist das erheblich mehr Overhead. Immerhin macht der AVR ja auch fast alles alleine (Arbitrierung, Versand, Empfang, Adresse überwachen und entsprechend aufwachen, wenn er sich angesprochen fühlt). Fabian S. wrote: >> Du musst halt aufpassen, dass sich zwei Knoten nicht gleichzeitig >> gegenseitig anlabern wollen, das geht vermutlich in die Hose :-) > Jo eben und um das zu managen brauche ich wieder ein Master :D Von daher > ist das ganze fürn Ar***. > Wenn das nicht geht fällt TWI flach. Wieso das? Du hast ein saublödes Konzept, das ist alles grins Warum sollte einer der Treiber mal eben aufwachen, um seine Temperatur an den PC zu funken? Hat der so ein Mitteilungsbedürfnis...? Sowas fällt ganz klar unter 'Slave', der hat nur zu reden, wenn er angesprochen wird. So bleibt auch die Datenlast auf den Mastern berechenbar. Wenns wirklich mal was dringendes gibt, kann man pro Master und Aufgabenbereich eine Interrupt-Request-Leitung dazunehmen. Damit können dann die Slaves ihrem Master mitteilen, dass sie etwas zu vermelden haben. Ansonsten: Da das erste übertragene Byte immer die Adresse ist, kann man durch die Adresswahl auch eine Rangfolge der Master festlegen. Dann könnte man z.B. unter '0x01' (angenommen, das wäre die höchste Priorität, mit den meisten 'Tiefs' eben, sodass die Arbitrierung gewonnen wird) auch einen Notruf absetzen. > Als nächstes würde bei mir die Idee mit UART/RS485 anstehen. Auch hier > wieder die Frage mit den Kollisionen. RS485 musst du von Hand auswerten.
Niklas G. wrote: > Hm, ich hätte jetzt gedacht, dass jeder immer dann senden darf, wenn er > ein 255er-Paket empfangen hat, und sonst durchreichen muss. Wenn du es schaffst, einen SPI-Slave rechtzeitig daran zu hindern, diesen Code (Token) weiter durchzureichen ja. > Zählte nicht das SPI-Modul in den ATmega's die SCK-Takte mit und > signalisiert nach 8 Takten ein fertiges Byte an das Programm? Das schon. Aber nicht alle fangen zum gleichen Zeitpunkt mit Zählen an. Und SS synchronisiert m.W. nicht, sondern hält nur an. Wenn da mal einer ausser Tritt kommt, hilft nur ein globaler Reset oder eine ausgefuchste Datencodierung oben drauf, die in den Interframe-Gaps klar macht, wo der nächste Frame anfängt, und es der Node eine Reset des SPI-Moduls ermöglicht. Sowas ähnliches wie ein UART-Startbit "zu Fuss".
Sven P. wrote:
> Nur gegenüber zwei Leitungen beim TWI ist das erheblich mehr Overhead.
Hardwareseitig eindeutig ja, weil Controller und Driver nötig
(Kabelaufwand ist bei typischer I2C-Distanz gleich), softwareseitig
jedoch nicht.
Es war auch nicht primär gegenüber TWI adressiert, sondern gegenüber
schrägen Ideen mit SPI und insbesondere Multimaster-RS485.
Mit TWI in Multimaster habe ich keine Erfahrung, das ist wohl eine
gangbare Alternative wenn Tempo und Signalqualität ausreichen.
> Wieso das? Du hast ein saublödes Konzept, das ist alles *grins* > Warum sollte einer der Treiber mal eben aufwachen, um seine Temperatur > an den PC zu funken? Hat der so ein Mitteilungsbedürfnis...? Sowas fällt > ganz klar unter 'Slave', der hat nur zu reden, wenn er angesprochen > wird. So bleibt auch die Datenlast auf den Mastern berechenbar. Joa naja, ist das nicht im Auto bei CAN auch so, dass jeder Sensor in regelmäßigen Abständen seinem Mitteilungsbedürfnis nachkommt? Wenn ich wieder beim Auffordern bin, ist es wieder ein Router. War vielleicht ein schlechtes Beispiel. Es kann ja auch vorkommen, dass zwei Sensoren/Aktoren (den Master ausgeschlossen) Datan austauschen müssen. Z.B. wird es eine extra Platine geben mit lauter Shunts drauf, um den Stromverbrauch der einzelnen Motoren etc zu messen. Steigt nun einer der Verbräuche ins Unermessliche sollte man dem Treiber sagen er solle doch bitte abschalten. Das müsste dann alles über den Router/PC laufen.
Ach ja, was die Signal-Qualität angeht hab ich da auch noch son Problem. Unten im Bot sind 4 Motoren, die JEWEILS bis zu 15A bei 12V zeiehen! Ich befürchte mal, dass die eine ganz gute Streuung haben, und vorallem die PWM der Teile. Kann/Muss ich die irgendwie abschirmen gegen TWI? Das größte Problem ist da sicher die Treiberplatine auf der die TWI Leitungen nur einige cm von den Motor-Leitungen auf einer Platine entfernt sind.
Fabian S. wrote: > Mhh ok... > Hab mir mal eben den Krams im Datenblatt durchgelesen, verstehen tuh > ichs nicht so ganz :( > OK, nur um nochmal sicher zu gehen. Ich habe alle Geräte auf Slave > stehen. Nun entscheiden sich zwei davon zu senden, beide wechseln in den > Master-Mode, senden die Adresse 0x00, um an alle zu senden, dann geht > das senden der Daten los und erst jetzt bemerkt doch einer der Master, > dass da noch ein 2. ist. > Wenn ich den dann in den Slave-Mode schalte, ist es doch viel zu spät? Nein, der I2C ist voll multimaster fähig. Wenn 2 senden, verliert einer die Arbitration und kriegt nen entsprechenden Interrupt. Erfolgt das im Adreßbyte, dann kann es sogar passieren, daß er selber adressiert wird. Schau Dir mal die entsprechenden Zustände an, Du kriegst immer nen Interrupt, was gerade passiert ist und kannst daher entsprechend reagieren. Das einzige ist, Du mußt nach Arbitrationsverlust nochmal die Daten senden, das passiert nicht automatisch wie beim CAN. Und dann gibt es noch nen Bug im I2C der AVRs, Du mußt immer einige µs warten nach nem Stop, ehe Du ein Start senden kannst: http://www.robotroom.com/Atmel-AVR-TWI-I2C-Multi-Master-Problem.html Prinzipiell funktioniert es aber. Natürlich ist die Software beim CAN bedeutend einfacher, da dort alles automatisch passiert. Peter
Mhhh.... ich habe mal mit einem Typen darüber gesprochen, der sich auch intensiv mit dem CAN beschäftigt hat und er meinte nur ist soll nach möglichkeit die Finger davon lassen, er hat einige Wochen gebraucht um da ein wenig was auf die Beine zu stellen und ihr könnt mir glauben, dass der Typ was drauf hat. Seit dem bin ich da etwas vorsichtig. Vorallem das Register hin und herschieben ist wohl wenn ich das richtig verstanden habe alles andere als einfach. > Wenn 2 senden, verliert einer die Arbitration und kriegt nen > entsprechenden Interrupt. Erfolgt das im Adreßbyte, dann kann es sogar > passieren, daß er selber adressiert wird. Schau Dir mal die > entsprechenden Zustände an, Du kriegst immer nen Interrupt, was gerade > passiert ist und kannst daher entsprechend reagieren. Im Adressbyte wird es aber nie passieren, weil das immer 0 ist. Nur damit ihr bescheid wissen: Ich denke ich tendiere momentan zu einem Single-Master TWI System, wobei der Master als so eine Art vereinfachter Router fungiert. Er hat zwei Structs wo jeweils alle Sensor-Daten und alle Steuerungs-Daten drin sind. Die Sensor Daten aktualisiert er regemäßig durch nachfragen bei den Slaves. Die Steuerungs-Daten bekommt er im ganzen Paket vom PC. Und jetzt sendet er einfach zyklisch die beiden Pakete sowohl an alle Slaves und die Sensor-Daten auch an den PC (über UART). Das ganze erzeugt zwar etwas Datenmüll, weil nicht jeder Slave alle Sensor- und Steuer-Daten braucht, es vereinfacht jedoch das ganze enorm und jeder hat immer alle Informationen zur Verfügung. Die beiden Structs dann beim Senden noch mit einer Checksumme versehen und gut. Die Übertragung vom Master zum PC wird denke ich etwas komplexer, weil ich da ja keinen Paket-Start oder sowas übertragen kann wie beim TWI.
Fabian S. wrote: > intensiv mit dem CAN beschäftigt hat und er meinte nur ist soll nach > möglichkeit die Finger davon lassen, er hat einige Wochen gebraucht um > da ein wenig was auf die Beine zu stellen und ihr könnt mir glauben, > dass der Typ was drauf hat. Nix für ungut, aber ich würde eher sagen, dass er damit das Gegenteil bewiesen hat. Man muss das Rad auch nicht neu erfinden, Beispielcode für eine AVR+MCP2515 Kombination findet sich leicht (z.B. http://www.kreatives-chaos.com/artikel/ansteuerung-eines-mcp2515). Was anfangs etwas irritiert ist die Spezifikation vom Bit-Timing. Aber ein bischen googeln bringt da weiter und man findet fertige Webrechner dafür. Registergeschiebe gibt es höchstens deshalb, weil sich eine 29bit ID nicht immer am Stück in den Interface-Registern wiederfindet. Mit den klassischen 11bit IDs bleibt das erspart.
> Nix für ungut, aber ich würde eher sagen, dass er damit das Gegenteil > bewiesen hat. Das mag wohl sein ;) Er meinte das Hauptproblem war, dass es irgendwie zwei verschiedene CAN "Versionen" gibt und dass die sich nur minimal in irgend einer Byte/Bit Reinfolge unterscheiden und da ist er irgendwie nicht hintergestiegen. > Man muss das Rad auch nicht neu erfinden, Beispielcode für > eine Mega8+MCP2515 Kombination findet sich leicht. Mhhh das ja cool. Wie wäre das denn beim AtMega8, muss ich den Kram Pollen? Einen Timer Opfern? Oder die Interrupt-Pins?
Fabian S. wrote: > Mhhh das ja cool. Wie wäre das denn beim AtMega8, muss ich den Kram > Pollen? Einen Timer Opfern? Oder die Interrupt-Pins? http://www.kreatives-chaos.com/artikel/ansteuerung-eines-mcp2515
A. K. wrote: > Fabian S. wrote: > >> Mhhh das ja cool. Wie wäre das denn beim AtMega8, muss ich den Kram >> Pollen? Einen Timer Opfern? Oder die Interrupt-Pins? > > http://www.kreatives-chaos.com/artikel/ansteuerung-eines-mcp2515 Lölz! > Entgegen weitläufiger Meinungen in den Roboterforen ist dies ganz einfach > zu realisieren. Es kann natürlich keine vollständige Beschreibung werden, > da der MCP2515 doch eine ganze Menge an Funktionalität bietet. Mal ganz abgesehen, dass das schon der reinste Wiederspruch ist, hat das Tutorial auch nur 23 Seiten :D Ich denke ich bleib bei TWI. Werde mir das aber wohl trotzdem mal reinziehen, vielleicht steige ich ja doch noch dahinter.
Fabian S. wrote: > Mal ganz abgesehen, dass das schon der reinste Wiederspruch ist, Nein, denn man muss nicht alles verwenden was das Teil bietet. Vergiss Priorisierung und Adressfilter, mindestens für den Anfang, und es wird ziemlich einfach. > hat das Tutorial auch nur 23 Seiten :D Der oben von Peter verlinkte Artikel über die Multimaster-Probleme vom Atmels TWI hat auch schon 7 Seiten ;-). > Ich denke ich bleib bei TWI. Werde mir das aber wohl trotzdem mal > reinziehen, vielleicht steige ich ja doch noch dahinter. Ich will dich nicht zu etwas überreden, TWI mag völlig ausreichend sein. Ich habe nur genau wie der Autor der 23 Seiten festgestellen können, dass viele Leute schon bei der Erwähnung von "CAN" nasse Hosen kriegen - was ich nicht nachvollziehen kann. PS: Von diesen bei mir 21 Seiten sind 10 für Leserkommentare und 3 für SPI. Bleiben grad mal 8 Seiten für CAN. Vergleiche das mit den 7 für ein spezielles TWI-Problem ;-).
Fabian S. wrote: >> Wenn 2 senden, verliert einer die Arbitration und kriegt nen >> entsprechenden Interrupt. Erfolgt das im Adreßbyte, dann kann es sogar >> passieren, daß er selber adressiert wird. Schau Dir mal die >> entsprechenden Zustände an, Du kriegst immer nen Interrupt, was gerade >> passiert ist und kannst daher entsprechend reagieren. > Im Adressbyte wird es aber nie passieren, weil das immer 0 ist. Ich sags ja, du hast ein saublödes Konzept. Warum willst du überhaupt einen Bus, wenn du dann nachher doch alles zusammenwirfst? Warum sollen alle Busteilnehmer permanent den Bus ihrem geistigen Dünnschiss zuknallen? Es reicht doch, wenn sie sich melden, wenn sie gefragt werden, oder halt in Ausnahmezuständen. Auf diese Weise kann sich jeder genau das zukommen lassen, was er gerade benötigt. Die PC-Schnittstelle z.B. schickt regelmäßig eine Aufforderung an die Fahrtregler und fragt nach Temperatur. Entgegengesetzt schickt die Schnittstelle bei einer Änderung der Betriebsparameter (andres Tempo z.B.) eine Meldung an die Treiber. Die Treiber quatschen die Shunts an, um zu regeln (eigentlich Käse, da viel zu langsam).
> Ich sags ja, du hast ein saublödes Konzept. > Warum willst du überhaupt einen Bus, wenn du dann nachher doch alles > zusammenwirfst? > > ... > > Die Treiber quatschen die Shunts an, um zu regeln (eigentlich Käse, da > viel zu langsam). Also du meinst mit TWI, Multimaster und jeder fragt jeden, wenn er was neues braucht? Ob das nun unbedingt das Datenaufkommen verringert weiß ich ja nun nicht. Denn einige Informationen werden von mehreren Geräten benötigt, zumal der Master (bzw PC) sowieso alles wissen sollte, um es nett darstellen zu können :P
Ich denke auch, dass gerade bei vielen intelligenten Sensoren solche Konzepte wie die Event-basierten Nachrichten in CAN sinnvoll sind. (Ich denke so hat Fabian es am Anfang auch gemeint und es nicht mit SPI versechselt). Auf diese Weise kann man einmal den Sensor bauen und jedes Modul kann auf die Daten zugreifen ohne, dass man in der Sensor Software daran denken muss wer die Daten haben will und diese somit auch nicht ständig erweitern muss. Wieviele Knoten hast Du denn? Ich denke CAN ist da schon nahezu ideal.
Wenn du mit "Knoten" Sensoren und Aktoren meinst... uff so 10-20 vermute ich mal. Ist alles noch in der Planung, abgesehen vom Motor-Treiber, da hab ich schon eine erste Version fertig um mal die reine Ansteuerung der Motoren zu testen. Die wird dann aber nochmal neu gemacht. Ansonsten steht bislang nur der Unterbau mit den Motoren samt Gerüst. Aber CAN ist doch grade nicht Event-Basiert oder? Da ist es doch normal, dass jeder seinen Dreck einfach raus haut, egal obs jemand braucht oder nicht? Nur die Abstände sind quasi variabel.
Ähm... was verstehst du denn unter "event-basiert"? Ich verstehe darunter, dass ein Zustand und insbesondere dessen Änderung vom Sensor ungefragt mitgeteilt wird. Genau das ist doch mit CAN problemlos möglich, wenn nicht geradezu typisch. Das Gegenteil davon ist ein ein reines Abfrageschema, was eher typisch für Single-Master Systeme ist.
Ich finde CAN für diese App auch ideal, mit der Einschränkung, dass Du ein zusätzliches IC brauchst, wenn Du den ATmega benutzt. Die Benutzung ist eigendlich kinderleicht, solche Probleme wie 11-Bit und 29-Bit ID betreffen Dich ja nicht, da Du innerhalb Deines Systems nur eine der beiden Möglichkeiten implementieren wirst. Und solange die Mitglieder Deines Bus-Systems genügend Rechenpower haben, kannst Du Dir das Einstellen der Message-Filter auch sparen. Und falls sie das nicht haben, kommt eh kein anderes Bus-System infrage ;-) Deine Shunt-Platine wwürde ich nochmal überdenken. Die Kontrolle des Stroms würde ich innerhalb der Motoransteuerung unterbringen: der ATmega, der den Motortreiber schaltet, überprüft gleichzeitig uch den Strom. Ggf. benutzt Du einen Motortreiber mit geregeltem Strom-Ausgang. Viele Grüße, Stefan
Mhh ja hast Recht. Jetzt würde sich nur noch die Frage stellen wie ich mit möglichst wenig Hardware ein CAN Bus zum laufen bekomme. Wenn ich jetzt einen Atmega nehmen würde mit integriertem CAN Bus, benötige ich dann noch dieses eine kleine IC? Und wenn ich es ohne den Spezial Atmega mache brauche ich vermutlich den MCP2515, noch das Treiber IC und jede Menge Geduld?
Fabian S. wrote: > Wenn ich jetzt einen Atmega nehmen würde mit integriertem CAN Bus, > benötige ich dann noch dieses eine kleine IC? Lass das lieber. Der MCP2515 ist ziemlich einfach gebaut und dementsprechend einfach im Umgang. Der CAN Controller in den AT90CANxxx (vgl Mega128+CAN) ist wesentlich komplexer. Den Tranceiver (8pin) benötigst du immer, egal ob der CAN Controller drin ist oder draussen. > Und wenn ich es ohne den Spezial Atmega mache brauche ich vermutlich den > MCP2515, noch das Treiber IC [...]? Korrekt. Siehe Beispielschaltung im Artikel.
Hallo zusammen ! CAN ist 'ne feine Sache, allerdings was die Kosten angeht auch nicht gerade günstig. Wie schon gesagt braucht man entweder einen Mega mit integriertem CAN oder den externen MPC2515. Auf jeden Fall braucht jeder CAN-Knoten noch ein Drosselpaar um an den Bus angeschlossen zu werden. Bei RS485 reicht ein spezielles Bustreiber IC (z.b. MAX 495), die RX/TX Leitung des UARTS und ein bis zwei I/O Pins. Es gibt für RS485 das Bit-Bus Protokoll (Intel). Normalerweise werden 8Bit Daten übertragen. Das erste 'Byte' einer Übertragung ist aber 9Bit lang und kennzeichnet die Adresse. Ein Multimaster System könnte man auch so aufbauen, daß man den Bus Zeitmultiplext betreibt. D.h. der Bus hat eine Zykluszeit von sagen wir mal 10ms. Diese Zykluszeit wird auf die Anzahl der Knoten verteilt. Bei 10 Knoten darf der 1.Knoten nach 1ms, der 2.Knoten nach 2ms usw. senden. Dann bräuchte man noch einen Knoten, der alle 10ms einen neuen Zyklus startet, indem er eine bestimmte Sync-Nachricht an alle Knoten sendet. Da RS485 nur den physical Layer um mal beim Schichtenmodel zu bleiben, beschreibt, kannst Du Dir beliebige 'Schweinereien' im übergeordneten Protokoll überlegen. Gruß BeGe
Bernd Geyer wrote: > CAN ist 'ne feine Sache, allerdings was die Kosten angeht auch nicht > gerade günstig. MCP2515: <3€ PCA82C251: <1€. Yep, das ist teurer als I2C. Aber lustigerweise ist Mega8+MCP2515 günstiger als PIC18F258 oder AT90CAN128 mit internem CAN. > integriertem CAN oder den externen MPC2515. Auf jeden Fall braucht jeder > CAN-Knoten noch ein Drosselpaar um an den Bus angeschlossen zu werden. Wozu? Wegen produzierter oder wegen eingefangener Störungen? Wenn man ohne Dosseln nur Störungen empfängt, dann kommt man sowieso nicht ohne aus und kann I2C gleich ganz abschreiben. Und gängige Transceiver-Bausteine wie der PCA82C251 haben einen Anschluss zur Kontrolle der Flankensteilheit. Wenn man da nicht in die Vollen geht, ist die Störemission gering und Drosseln sind überflüssig. > Es gibt für RS485 das Bit-Bus Protokoll (Intel). Normalerweise werden > 8Bit Daten übertragen. Das erste 'Byte' einer Übertragung ist aber 9Bit > lang und kennzeichnet die Adresse. Bei RS485/UART Multimaster steckt man eine ganze Menge Aufwand in die Software, bis die wirklich stabil(!) läuft. Und das um 3€ pro Node einzusparen. Das macht man m.E. heute nur noch wenn die 3€ wehtun (hohe Stückzahl), grosse Datenmengen auftreten oder die in RS485-MM investierte Zeit eher der Sinn der Sache ist als das Ergebnis davon. RS485 ist prima für Single-Master. Aber warum sich das noch so viele als Multi-Master antun wollen ist mir ein Rätsel.
Fabian S. wrote: > Mhhh.... ich habe mal mit einem Typen darüber gesprochen, der sich auch > intensiv mit dem CAN beschäftigt hat und er meinte nur ist soll nach > möglichkeit die Finger davon lassen, er hat einige Wochen gebraucht um > da ein wenig was auf die Beine zu stellen und ihr könnt mir glauben, > dass der Typ was drauf hat. Ich kenns nur andersrum: Wer einmal CAN gemacht, will nichts anderes mehr, weils so einfach und zuverlässig ist. Das einzig "Schwierige" ist das Einstellen der Baudrate, da gibt es verschiedene Phasen pro Bit. Aber da nimmt man einfach irgendne Einstellung aus nem Beispielcode und gut is. Bei krummen Quarzen oder langen Leitungen ließe sich da wohl noch was optimieren. Um nun was zu senden, schreibt man ne Nachricht in nen Sendepuffer, das wars. Und wenn das Senden geklappt hat (inklusive Retry bei Fehlern) kriegt man nen Interrupt. Das Empfangen ist ähnlich einfach. Man bereitet nen Empfangspuffer vor, d.h. man legt den Identifier (Adresse) fest, auf den man hören will. Man kann jedes einzelne Bit maskieren, d.h. man kann auch Gruppen oder alle Identifier empfangen. Und dann kriegt man nen Interrupt, wenn was drin ist. Man kann oft auch mehrere Empfangspuffer kaskadieren. Z.B. beim AT89C51CC01 kannst Du bis 15 Empfangspuffer einstellen, d.h. bis zu 120 Datenbyte hintereinander empfangen, ohne das die CPU sie abgeholt hat. Dagegen ist ein einzelnes Byte Empfangspuffer beim I2C nur ein Witz. > Seit dem bin ich da etwas vorsichtig. Vorallem das Register hin und > herschieben ist wohl wenn ich das richtig verstanden habe alles andere > als einfach. Was fürn Schieben denn ??? Du hast bis zu 8 Byte Daten pro Paket, da wird nix geschoben. Die Hardware macht alles alleine. Ich hab den AT89C51CC01 und den SJA1000 programmiert, liefen fast auf Anhieb. Ein Kollege hat auch noch den MCP2515 und den LPC2292 programmiert. Wenn man einen CAN kann, sind andere kein Problem. Der LPC hat allerdings nen Bug, da läßt sich nur ein rudimentäres CAN benutzen, 99% der vorgesehenen CAN-Funktionalität sind unbenutzbar. Peter
Ähhh du redest jetzt davon, dass das alles so einfach ist. Das finde ich ja gut, aber redest du jetzt von einem der CAN Controller, die in einem der genannten µCs integriert ist oder diesem extrenen Teil?
Fabian S. wrote: > Ähhh du redest jetzt davon, dass das alles so einfach ist. Das finde ich > ja gut, aber redest du jetzt von einem der CAN Controller, die in einem > der genannten µCs integriert ist oder diesem extrenen Teil? Der SJA1000 ist extern, lohnt sich aber nur für MCs mit externem Memory-Interface (z.B. 8051-er, ATmega8515). Der MCP2515 muß über das SPI angebunden werden, d.h. per SPI muß man die Bytes aus dem Empfangspuffer rausholen bzw. in den Sendepuffer packen. Soweit ich weiß hat er 3 Empfangspuffer. Einen Interruptausgang hat er auch, d.h. man kriegt nen Interrupt, wenn Senden oder Empfang fertig ist. Peter
Fabian S. wrote: > Ähhh du redest jetzt davon, dass das alles so einfach ist. Das finde ich > ja gut, aber redest du jetzt von einem der CAN Controller, die in einem > der genannten µCs integriert ist oder diesem extrenen Teil? Das ist doch völlig schnuppe. Der programmseitige Unterschied zwischen CAN Controller drin und CAN Controller draussen ist grad mal CANREG1 = wert; //intern versus setreg(CANREG1, wert); //extern und sonst ist alles gleich. Ich kann bloss nicht empfehlen, sich als ersten CAN Controller ausgerechnet sowas wie den AT90CAN128 anzusehen. Dass der erst einmal abschreckt kann ich nachvollziehen. Beim MCP2515 (oder SJA1000) sieht das anders aus, die sind viel einfacher aufgebaut. Was aber garantiert ausreicht. Also: Intern ist hier nicht einfacher als extern. Eher umgekehrt.
> Das ist doch völlig schnuppe. Der programmseitige Unterschied zwischen > CAN Controller drin und CAN Controller draussen ist grad mal > CANREG1 = wert; //intern > versus > setreg(CANREG1, wert); //extern > und sonst ist alles gleich. Naja aber die ganzen Sachen die dahinter stehen müssen ja erstmal laufen. Siehe Tutorial: http://www.kreatives-chaos.com/artikel/ansteuerung-eines-mcp2515 In sofern ist das ein heftiger Unterschied. Und vorallem was den Platz angeht ;) Ich fürchte sogar daran könnte es scheitern, oder ich kauf mir noch die Studenten Version von Eagle für 125 oder was das noch war. Naja danke erstmal für eure ganzen Tipps! Ich werde erstmal noch ne Nacht drüber schalfen.
Die Modelleisenbahner haben sich Gedanken zu so einem abgespecktem Bussystem für Steuerungsaufgaben gemacht: http://www.america-n.de/Norm/rp-sig_tech_spec.pdf Ein ähnliches Prinzip hatte die Firma Phytec unter dem Namen µ-Net mal auf den Markt gebracht und in einer Heise Zeitschrift veröffentlicht, die es nicht mehr gibt (ich glaube elrad). Das war noch zu einer Zeit als CAN noch sauteuer und kaum in einem µC gleich drin war (so um 1995).
Noch eine kleine Anmerkung am Rande. Die AVRs haben afaik nur eine TWI Schnittstelle. Falls man die auch für interne Anwendungen verwenden will, sollte man es aus nahe liegenden Gründen vermeiden die auch gleichzeitig als externen Bus zu verwenden. Eine externe CAN Schnittstelle hat dieses Problem so gut wie nie. Alternativ kann man fehlende Schnittstellen auch in SW implementieren, was aber auch nicht immer die beste Lösung ist.
Wieso sollte ich eine TWI Schnitstelle für interne Sachen verwenden? Kann mir ja schlecht über TWI selber was senden.
Ich habe da eher an Bauteile mit einer I2C Schnittstelle a la 24Cxx oder LM75 gedacht. Die haben oft am externen Bus nichts verloren.
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.