mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Alternative zu CAN-Bus?


Autor: Fabian S. (jacky2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :(

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fabian S. (jacky2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fabian S. (jacky2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)?

Autor: kopfschüttler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RS-485 kann ich empfehlen

Autor: Fabian S. (jacky2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Niklas Gürtler (erlkoenig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 +-->--+
|     |           |     |           |     |           |     |
|     +-----------+     +-----------+     +-----------+     |
+-----------------<-----------------<-----------------------+

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fabian S. (jacky2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> '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?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Fabian S. (jacky2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Niklas Gürtler (erlkoenig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Fabian S. (jacky2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fabian S. (jacky2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Fabian S. (jacky2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-M...

Prinzipiell funktioniert es aber.
Natürlich ist die Software beim CAN bedeutend einfacher, da dort alles 
automatisch passiert.


Peter

Autor: Fabian S. (jacky2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...).

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.

Autor: Fabian S. (jacky2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Fabian S. (jacky2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-).

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Fabian S. (jacky2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Phil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fabian S. (jacky2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ä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.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fabian S. (jacky2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd Geyer (bege)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fabian S. (jacky2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ä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?

Autor: PJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter
Klasse, super Hinweise. Danke.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fabian S. (jacky2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...
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.

Autor: Route_66 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Reinhard R. (reinhardr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fabian S. (jacky2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso sollte ich eine TWI Schnitstelle für interne Sachen verwenden? 
Kann mir ja schlecht über TWI selber was senden.

Autor: Reinhard R. (reinhardr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe da eher an Bauteile mit einer I2C Schnittstelle a la 24Cxx oder 
LM75 gedacht. Die haben oft am externen Bus nichts verloren.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.