CAN-Bus als freie Implementation

Sven Schulz schrieb:

Hallo!

Ich weiß nicht genau was du meinst, aber schau mal hier:

Wenn es von Reichelt sein soll, dann dazu den PCA 82C251 als Treiber.

HTH, Heiko.

"Heiko Lechner" schrieb im Newsbeitrag news: snipped-for-privacy@mid.dfncis.de...

Der Link beschreibt eine einzelne Hardware.

Ich meine aber einen nahezu x-beliebigen Prozessor, der mit den benötigten Pins auf dem CAN-Bus hängt, auf dem dann die Kommunikation mit dem CAN-Bus abläuft. Ohne zusätzlich Hardware, ohne spezielle CAN-Interfaces die schon vom Prozessorhersteller mit in den Prozessor eingebaut werden.

Sven

Sven Schulz schrieb:

Hallo!

Ach so.

Zu einer reinen Softwarelösung wüsste ich jetzt nichts, nur eines: schon das Ansteuern des MCP2515 in C frisst ordentlich Flashspeicher. Weiterhin ist man ja durch den MCP2515 (und auch µCs mit eingebautem CAN) nicht gezwungen "Objektorientiert" ;) zu arbeiten.

Den Treiber brauchst du aber wohl trotzdem (Pegelanpassung, Isolation).

HTH, Heiko.

Jepp. Ohne Treiber wird das gar nix. CAN ist differentiell, und der uC normalerweise single-sided gegen Masse. Und genau dazu gibt es die kleinen (typ.8Beiner), die das erledigen. Oft mit Standby usw. inklusive. Hier werkelt z.B. ein SJA1000 mit nachgeschaltenem PCA82C251.

Heinz

Sven Schulz schrieb:

Natürlich könnte man das CAN-Protokoll komplett in Software implementieren. Die genaue Spezifikation von CAN 2.0 findest Du hier:

Bedenke aber: Das Bit-Timing willst Du nicht wirklich in Software machen. Entweder verwendest Du einen Mikrocontroller mit Zykluszeiten im Bereich von einzelnen Nanosekunden, oder Du erreichst nur ein paar kBit/s. Es hat schon seinen Grund, warum es dafür spezielle Hardware gibt - sowohl als separate (externe) CAN-Controller, als auch als interne Peripherie bei manchen Controllern.

Zu den erforderlichen Leitungstreibern wurde ja schon geschrieben. Man könnte natürlich eine andere physikalische Schnittstelle (z.B. TTL Open Collector) verwenden und dann ohne spezielle Treiber auskommen.

Sinn ergibt beides wohl nur, wenn man nicht mit standardkonformen Teilnehmern an einem gemeinsamen Bus kommunizieren muß.

Tilmann

Sven Schulz schrieb:

Vor einiger Zeit ist mir eine pure Softwarelösung für einen PIC o.ä. im Netz untergekommen, hab ich leider nicht archiviert. Ich würde aber davon ausgehen das dort Assembler im Spiel war und man auch kaum grosse Ansprüche an Reaktionszeiten und verbleibende Möglichkeiten des µC stellen kann. Aber grundsätzlich: Wieso sollte man sich mit so einer Krückenlösung befassen, es gibt genug CAN-fähigen Kram der das in Hardware macht, warum die Quälerei?

Wie andere schon erwähnten: Ohne Treiberbaustein läuft auch damit nichts.

Jörg.

Jörg Schneide schrub:

Freescale MPC5200 ist da was feines... gibt's auch den Peak CAN Treiber unter Linux dafür. Oder man nimmt die 80C167-Klopper...

Die kommen noch dazu, ja.

Ansgar

Wenns denn unbedingt in einem Chip ohne HW-CAN sein soll (wo es doch jede Menge davon gibt, Atmel, SiLabs & ähnliche Verdächtige) geht das sicher auch in einem Spartan. Implementierung in VHDL und zum Rechnen gibts dann immer noch eine ARM-Cpu. Aber das Problem liegt ja nicht darin, dass die CAN-Implementierung so teuer ist, sondern die Lizenz dafür. Und die ist genaugenommen so oder so fällig.

Heinz

Einerseits soll Platz gespart werden (nebensächlich), andererseits soll tatsächlich die Anzahl der kostentreibenden ICs gesenkt werden. Für den Fall, das ein Prozessor auf einem Datenerfassungsboard (das mit anderen Boards via CAN gekoppelt ist) noch genügend Rechenkraft und Speicher besitzen sollte, könnte einer der schwach ausgelasteten Prozessoren die Arbeit des CAN-Controllers übernehmen.

Für die Pegelanpassung muß es unbedingt ein einzelner Treiberbaustein sein? Was würdest du einsetzen?

Sven

Ehrlich? Warum wird denn dafür eine Gebühr fällig? Ich dachte die Lizenzen laufen nach einigen Jahren aus, und der CAN gurgt schon seit 1983 in der Welt herum.

Sven

Das Timing wäre dann von der verwendeten Zielhardware abhänig. Schwer abzuschätzen wieviel kBit/s ich da durchbekommen würde.

Das wäre auch eine Alternative, gute Idee.

Sven

Controller und Transceiver sind grundsätzlich getrennt. Grund: unterschiedliche Fertigungstechnologien.

Standard ist der 82C250/251, aber es gibt auch noch diverse andere, je nach Anforderung.

Mit freundlichen Grüßen

Frank-Christian Krügel

Sven Schulz schrieb:

Heißt das, Du brauchst diese Kommunikation nur intern, zwischen "eigenen" Teilnehmern? Und ein paar kBit/s würden Dir schon reichen?

In dem Fall würde ich gar nicht versuchen, CAN per SW und mit anderer physikalischer Schnittstelle nachzubilden (standardkonform wird das eh nie werden), sondern gleich einen anderen Schnittstellentyp verwenden - z.B. I2C, der für sowas gedacht ist.

Tilmann

Hmmm. Nicht sehr intensiv darüber nachgegrübelt. Ich dachte schon, dass der "Erfinder" des CAN (Bosch?) noch die Hand dafür aufhält.

Was willst Du eigentlich damit genau machen? Anfänglich hörte sich das ganze danach an, als ob Du CAN-Msg von einem existierenden Bus abgreifen willst.

Etwas später klang es dann eher nach einfachem Datenaustausch zwischen "homebrewed" Equipment. Bei zweiterem würde ich doch RS485 überlegen. RS232 (ist ja hw-protokoll-kompatibel) hat praktisch jede CPU mit an Bord, ist auch ein Bus und Treiber für RS485 sind erfunden.

Und die Realisierung in SW ist auch eine bessere Fingerübung.

Heinz

Hallo Sven,

Hab ich was verpasst, oder hastn Du uns noch nicht verraten, warum es ausgerechnet CAN sein muss und nicht I2C oder LIN oder sonst was einfacheres sein kann?

Marte

Heinz Liebhart schrieb:

Hallo!

So wie sich das anhört will er mehrere Master (es geht scheinbar um mehrere "Datenerfassungsboards", die wohl autonom arbeiten sollen) an einem Bus betreiben, dann bräuchte er noch eine Kollisionserkennung/vermeidung.

Da kann man dann auch gleich wieder CAN nehmen :)

Falls er einen (extra) Master spendiert und die "Datenerfassungsboards" als Slaves baut, dann wird es durch "TIA/EIA-485-A-98" ;) bestimmt einfacher.

MfG, Heiko.

Hallo Heiko,

Na dann doch eher LIN, nicht wahr? I2C kennt angeblich auch einen Multimastermodus, hab ich aber noch nie damit zu tun gehabt. Autonome Netzwerke sind ohnehin eine Sache für sich.

Marte

"Marte Schwarz" schrieb im Newsbeitrag news:45cae72a$0$5724$ snipped-for-privacy@newsspool3.arcor-online.net...

Weil ich nur den CAN-Bus (gut) kenne. Andere Bussysteme kenne ich nur vom Namen her oder habe andere (unbegründete)Vorbehalte, z.B. I2C.

Sven

Sven Schulz schrieb:

Das hat Dir schon gereicht?

I2C Spezifikation:

Oft reicht in der Praxis eine Teilmenge davon: Simpler Master/Slave Betrieb ohne Clock-Stretching. Ist einfach per Software mit zwei Ports realisierbar, außerdem gibt es auch viele Mikrocontroller mit eingebautem I2C-Controller.

Tilmann