Can bus ohne Can-fähige Controller

Vermutlich soll ein MC ja noch andere Sachen machen und nicht nur zu 99% 
im CAN-Protokoll rödeln.

Heizer schrieb:
> Warum braucht man dann ein CAN-Transceiver
Um die Signale physikalisch dem CAN Bus anzupassen. Pegel, 
differentielle Signale
> oder Can-Controller
Der nimmt dem µC einen Großteil der Arbeit ab. Wenn der µC schnell genug 
ist und du genug Ahnung hast kannst du es auch in Software 
implementieren.

Denke schon dass auch ein MegaAVR das CAN Protokoll in Software 
nachbilden kann. Bei UART klappts ja auch. Highspeed-CAN liegt mit 
500kBit ca. um Faktor 4 höher. Bei 20MHz hast du also 40 Takte pro Bit. 
In Assembler auf jeden Fall machbar, in C evtl auch.

Allerdings gibt es auch Mittelwege: CAN-Transceiver, die per SPI 
angebunden werden. Auch wenn ich da grade keinen CAN.
Und SPI kann der Atmel ja in Hardware, also praktisch "nebenbei".

Heizer schrieb:
> Can Transciever auch?
Nimm das Datenblatt deines µC und studiere ob die IOs den physikalischen 
Anforderungen das CAN Buses genügen.

Heizer schrieb:
> Can Controller kann man in Software realisieren. Can Transciever auch?

Dank der elektrischen Definition vom Interface gehts bei CAN schlecht 
ohne Transceiver. RS232 geht ja auch nicht ohne RS232-Bausteine wie 
MAX232.

Heizer schrieb:
> Can Controller kann man in Software realisieren. Can Transciever auch?

 Und warum sollte man so etwas machen ?
 Was ist mit Pegel, Kurzschluss ?
 CAN-Controller ist machbar, wenn auch wenig sinnvoll, aber uC ohne
 Transceiver an CAN Bus dranzuhängen ist Blödsinn.

Korrekt.

Wobei es uC und CAN-Controller schon in einem Chip gibt, etwa die 
AT90CAN oder STM32F1xx Chips und viele andere auch.

Gruß
Ulrich

le x. schrieb:
> Bei 20MHz hast du also 40 Takte pro Bit.

Das reicht bei CAN nicht, die Teilnehmer müssen sich auf den Bitanfang 
synchronisieren können. Dazu unterteilen sie ein Bit in mindestens 8, 
besser 16 Slots. Quasi wie eine UART auf das Startbit synchronisiert.

Ein CAN-Controller braucht für 1MBit mindestens einen 8MHz Quarz.
Eine SW-Lösung wird deshalb kaum unter 80MHz gehen.

Peter Dannegger schrieb:
> Ein CAN-Controller braucht für 1MBit mindestens einen 8MHz Quarz.
> Eine SW-Lösung wird deshalb kaum unter 80MHz gehen.

 Üblich sind aber 250Kb und 500Kb. Also hat man schon bei 20MHz etwa
 40Cy/bit und das bei der schnelleren Variante.
 Da kann höchstens die Adressdekodierung einen TINY4313 z.B. zum
 Schwitzen bringen, aber Bit-stuffing und anderes mit Sicherheit nicht.
 Ob der AVR dann auch noch was anderes und sinnvolles machen kann,
 ist eine andere Frage.

Für CAN in Software benötigt man letztlich einen recht schnellen Core, 
der nur für den CAN Bus arbeitet, ohne störende Interrupts. Damit der 
nicht durch Kommunikation mit dem Rest des Systems gestört wird muss das 
also eine Art I/O-Prozessor sein, der ins Gesamtsystem eingebettet ist.

Damit kommt als ein vorgelagerter AVR kaum in Frage. Denn wenngleich 
sich der vielleicht mit einem langsamen CAN Bus abmühen kann, würde er 
mit dem Hauptsystem nicht kommunizieren können ohne CAN zu 
vernachlässigen.

In Frage kommt das in Multiprozessorumgebungen, deren einzelne 
Prozessoren für I/O-Aufgaben optimiert sind. Die deshalb keine 
spezialisierten Hardwaremodule für allerlei I/O enthalten, wie CAN 
Controller, sondern genug I/O-Prozessoren, um solche Hardwaremodule 
durch Software zu ersetzen.

Eine solche Konstellation findet man beispielsweise im Parallax 
Propeller und bei XMOS. Auf diese Weise kann ein nicht zu kleiner XMOS 
Controller auch Ethernet in Software anbinden.

Aber natürlich stellt sich die Frage, ob sich das wirklich lohnt. Es 
gibt genug billige Mikrocontroller mit integriertem CAN, deren CAN schon 
fix und fertig funktioniert. Nicht erst nach langer Programmierarbeit.

CAN in Software zu Realisieren ist Mühselig und fehleranfällig. Steht 
auch in keinen Verhältnis zu dem Mehrpreis eines  µC der das von haus 
aus kann.

Die CAN Pegel sind bei einem 5V system 5V und 0V für Daten und 2,5V für 
Idle-mode. Wenn du das also ohne weitere Komponenten wie Tranciver 
machen willst brauchst du auch noch DACs und ADCs.

Außerdem schützt der Transciever den µC vor unschönen Sachen die auf der 
Busleitung kommen können. Die meisten Tranciever können Spannungsstöße 
in kV-Bereich ab. Da macht dein µC schon lange die Grätsche.

Es geht mehr um den Controller als um den Transceiver.
Ich persönlich würde da keine 5min dran verschwenden, dass irgendwie in 
Software zu realisieren - nicht alles was geht, ist auch sinnvoll. 
Dinge, die man für kleines Geld jederzeit kaufen kann und darf, macht 
man nicht selbst, nichtmal beim Hobby (wenn es um echtes Geld geht 
sowieso nicht). Ich habe bei mir zu Hause ein inzwischen gut gewachsenes 
CAN-Netz, das macht auch Spass, aber auf die Idee das auch mit 
Controllern ohne CAN zu machen wäre ich niemals gekommen. Ich finde es 
auch wenig spannend, zu versuchen das in Software nachzuklimpern. 
Vielleicht schafft man es, wahrscheinlich eher nicht, weil man 
irgendwann einsieht, das selbst der Erfolgsfall zu wenig Nutze ist 
(ausser fürs Ego vielleicht). Wir leben so schön und so komfortabel, 
weil wir die Sachen nutzen, die andere vor uns schon gemacht haben und 
netterweise zur Verfügung stellen. Also nehmen.

H.Joachim Seifert schrieb:
> Ich persönlich würde da keine 5min dran verschwenden, dass irgendwie in
> Software zu realisieren - nicht alles was geht, ist auch sinnvoll.

 Versteht sich von selbst, stimme ich dir zu.

A. K. schrieb:
> Aber natürlich stellt sich die Frage, ob sich das wirklich lohnt. Es
> gibt genug billige Mikrocontroller mit integriertem CAN, deren CAN schon
> fix und fertig funktioniert. Nicht erst nach langer Programmierarbeit.

 Versteht sich von selbst, stimme ich dir zu.

Fabian F. schrieb:
> Außerdem schützt der Transciever den µC vor unschönen Sachen die auf der
> Busleitung kommen können. Die meisten Tranciever können Spannungsstöße
> in kV-Bereich ab. Da macht dein µC schon lange die Grätsche.

 Versteht sich von selbst, stimme ich dir zu.

Wieso das denn? Ich kann mir gut vorstellen, dass das einige schon 
versucht haben und auch weiterhin versuchen werden.  Ne tatsächlich 
funktionsfähige Lösung habe ich noch nicht gesehen.
Wenn überhaupt, wäre es ja nur für die kleinen Controller nützlich. Bei 
den grösseren Teilen kann man eigentlich immer einen mit CAN on chip 
auswählen, kostet deswegen auch nicht mehr.
Und gerade bei den kleinen hat man dann wieder das Problem, dass das 
Kerlchen alleine damit ziemlich ausgereizt ist was die Rechenzeit 
betrifft. Kostet auch einiges an Programmspeicher, auch nicht gerade in 
Hülle und Fülle vorhanden.
Vielleicht macht es Sinn, nur Teillösungen zu programmieren (den listen 
only mode z.B.), das kann man sicher gut machen. Man braucht sich nicht 
um Arbitrierung, active/passiv-error frame, overload frame oder remote 
request zu kümmern. Man bekommt alle Daten und kann damit Aktoren 
steuern.

Und irgendwo ins CAN stopfst du ein einzelnes echtes Dummy-CAN, damit 
sich wenigstens einer die Mühe macht, die Frames des Masters zu 
acknowledgen.

Bloss: Wieso dann CAN? Das geht mit unidirektionalem RS422/485 leichter.

H.Joachim Seifert schrieb:
> Wieso das denn? Ich kann mir gut vorstellen, dass das einige schon
> versucht haben und auch weiterhin versuchen werden.  Ne tatsächlich
> funktionsfähige Lösung habe ich noch nicht gesehen.
> Wenn überhaupt, wäre es ja nur für die kleinen Controller nützlich. Bei
> den grösseren Teilen kann man eigentlich immer einen mit CAN on chip
> auswählen, kostet deswegen auch nicht mehr.
> Und gerade bei den kleinen hat man dann wieder das Problem, dass das
> Kerlchen alleine damit ziemlich ausgereizt ist was die Rechenzeit
> betrifft. Kostet auch einiges an Programmspeicher, auch nicht gerade in
> Hülle und Fülle vorhanden.
> Vielleicht macht es Sinn, nur Teillösungen zu programmieren (den listen
> only mode z.B.), das kann man sicher gut machen. Man braucht sich nicht
> um Arbitrierung, active/passiv-error frame, overload frame oder remote
> request zu kümmern. Man bekommt alle Daten und kann damit Aktoren
> steuern.

So was habe ich mal gemacht. Wir mussten bei einem Produkt im nachhinein 
auf CAN umsteigen, weil SPI durch EM-Dreck gestört war. Ein µC konnte 
von haus aus kein CAN und war auch nicht ersetzbar. Hier haben wir per 
Software eine Art Soft-CAN geschrieben, der sich einzelne Bytes vom Bus 
geholt hat. Gesendet hat der selber nix. Und dass war schon ein riesen 
Aufwand. Insbesondere QC.

Heizer schrieb:
> Mit einem stinknormalen uC mit DIO kann man doch auch High- und Low
> Signale senden (zumindest an die Leitung an legen)

Sehe ich das richtig, dass Daten nur gesendet werden sollen? Das geht 
meiner Einschätzung nach ohne größere Probleme mit einem ganz einfachen 
Mikrocontroller (z.B. tiny85) und ohne Transceiver.

Gleiches gilt, wenn Daten nur empfangen werden sollen, etwa um 
irgendein Gerät ein- oder auszuschalten.

Erich schrieb:
> @ Markus Weber
> Du hast das CAN Protokoll nicht verstanden.
> Gruss

Was bringt dich zu dieser Einschätzung? :-)

c-hater schrieb im Beitrag #3813510:
> Pit schrieb:

>
> Und, last but not least, weil es immer wieder ein innerlicher
> Vorbeimarsch ist, die unfähigen C-Frickler mal wieder daran zu erinnern,
> auf wie viel Hardwareleistung sie freiwillig verzichten, nur um ihrem
> üblen Kult in möglichst reiner Form zu frönen...

Du lebst wahrscheinlich auch in einem Erdloch und benutzt zum kochen, 
zähneputzen und Wäsche waschen Steine, weil ja jede Art von 
fortgeschritten Werkzeug Blasphemie im Angesicht des Assembler-gottes 
ist.

Tonx schrieb:
> Guten Tag allerseits
> ich habe eine kurze Frage:
> ich habe einen µc mit CAN-Controller von microchip ( pic32), im moment
> läuft CAN Transceiver MPC2551 mit.
> jetzt möchte ich den MPC2551  durch TJA1051 ersetzen, von pining her,
> sind gleich, also keine Layout-Änderung.
> soll ich noch software Anpassung auch machen( in CAN-Controller)?
>
> mfg
> Tonx

Geht ohne Software-Anpassung! Habe es jetzt für diese Beiden nicht 
geprüft, aber ein paar Varianten unterscheiden sich in der Funktion 
eines Pins, bitte daher nochmal genauestens prüfen.

Tonx schrieb:
> ich habe eine kurze Frage:
Du kannst für eine neue Frage, die ausser den drei Buchstaben "CAN" 
nichts mit irgendeinem Vorherigen zu tun hat, ganz problemlos einen 
neuen Thread starten.

> jetzt möchte ich den MPC2551  durch TJA1051 ersetzen, von pining her,
> sind gleich, also keine Layout-Änderung.
> soll ich noch software Anpassung auch machen( in CAN-Controller)?
Was steuert denn die Software an diesem Pegelwandler an? Hast du von 
der Software aus Zugriff auf den Pegelwandler?