Hallo Leute, ich habe da ein Verständnisproblem. Ganz vereinfacht gesagt besteht ein Can-Protokoll ja aus High- bzw. Low Pegeln. (Signale). Mit einem stinknormalen uC mit DIO kann man doch auch High- und Low Signale senden (zumindest an die Leitung an legen) Warum braucht man dann ein CAN-Transceiver oder Can-Controller oder sonst wie die heissen. (Sorry ich kann die zwischenbausteine nicht richtig zuordnen)?? danke im Voraus
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.
Weil die High- und Low-Pegel beim CAN eben überhaupts mit den High- und Low-Pegeln am Mikrocontroller-Ein-Ausgang gemeinsam haben. Diese Anpassung ist die Aufgabe des CAN-Transceivers (Spannungen des Mikrocontrollers an die Spannung des gewählten CAN-Busses anpassen). Der CAN-Controller ist der Teil der die Logik macht. Also Bitreihenfolge, Arbitrierung, Stuff-Bits einfügen und wegnehmen, CRC, Timing, Synchronisation ...
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".
Max H. schrieb: > 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. Christopher schrieb: > Weil die High- und Low-Pegel beim CAN eben überhaupts mit den High- und > Low-Pegeln am Mikrocontroller-Ein-Ausgang gemeinsam haben. > > Diese Anpassung ist die Aufgabe des CAN-Transceivers (Spannungen des > Mikrocontrollers an die Spannung des gewählten CAN-Busses anpassen). > > Der CAN-Controller ist der Teil der die Logik macht. Also > Bitreihenfolge, Arbitrierung, Stuff-Bits einfügen und wegnehmen, CRC, > Timing, Synchronisation ... danke schön. das nenne ich Hilfe. Statt einfach einen WIki Artikel zu posten.
le x. schrieb: > In Assembler auf jeden Fall machbar, in C evtl auch. UART ist aber wesentlich einfacher. Bit Stuffing und CRC gibt es dort nicht. Klar könnte man das Paket vorher komplett berechnen und dann "nur" senden, was aber dann nicht mehr sehr schnell sein wird.
le x. schrieb: > 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". moment. vestehe ich das jetzt richtig? Can Controller kann man in Software realisieren. Can Transciever auch?
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.
Peter II schrieb: > UART ist aber wesentlich einfacher. Das ist unbestreitbar. > Bit Stuffing und CRC gibt es dort nicht. Stimmt. Aber z.B. bei USB (LowSpeed=1,5MBit/s), also dem Dreifachen von CAN. Und selbst da schafft es ein AVR, Bitstuffing und CRC in Echtzeit zu behandeln, nix mit vorberechneten Paketen. Jedenfalls ab ca. 18MHz Takt. Bei einem Drittel der Bitrate rutscht die Sache in Bereiche, die sogar in (fast) purem C machbar wären.
Ok jetzt ist mir die sache klar geworden(vermute ich) also so ist die Kommuniklation aufgebaut: uC[Master]--Can-Contr.--Can-Trans.-- ---Can-Leitung---Can-Trans.--Can.Contr.--uC [Master/Slave]
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.
:
Bearbeitet durch User
Marc Vesely schrieb: > 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. wäre ja im Falle nicht wichtig, wenn z.B. ein 328p als vorgelagerter CAN-Baustein funktioniert und sonst nicht viel zutun hätte. Ob das dann preislich viel Sinn macht steht auf einem anderen Blatt.
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.
:
Bearbeitet durch User
A.K., Du hast es wie immer gut und präzisse auf den Punkt gebracht. Wenn man sich sehr anstrengt, wären vielleicht dennoch etwas grenzwertige Sachen ähnlich diese Implementierung hier möglich: http://www.youtube.com/watch?v=m4f4OzEyueg
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.
Und natürlich ist jegliches weiteres Nachdenken über eine Software-CAN-Controlelr ab hier verboten. Wo kämen wir denn da hin, wenn jetzt jemand hier noch kreativ wird.
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.
:
Bearbeitet durch User
Also ich denke es gibt durchaus Anwendungen für solch einen Soft-Can: * Bewusst Busfehler erzeugen um Stabilität zu testen * Debugging auf Bit-Ebene * Fehler herausfinden, was dort passiert ist.
Sven schrieb: > Also ich denke es gibt durchaus Anwendungen für solch einen Soft-Can: > * Bewusst Busfehler erzeugen um Stabilität zu testen > * Debugging auf Bit-Ebene Um seine anderen Software-CAN-Implementationen zu testen? :D > * Fehler herausfinden, was dort passiert ist. Dafür gibts Logic-Analyzer, DSO's, und fertige CAN-Analyzer/Interfaces.
Das macht aus meiner Sicht auch keinen Sinn. Natürlich kann man CAN in Software realisieren aber warum? Will man eine Kommunikation zwischen verschiedenen Geräten aufbauen, kommt man um den CAN Tranceiver nicht herum. Egal ob als einzelner Chip oder im µC integriert. Zum Testen vom CAN würde ich auch auf ein fertiges Interface zurückgreifen. Wir haben mal einen rudimentären Klon vom CANalyzer und CANape gebaut. Für kleine Tests geht das mal aber für mehr auch nicht. Vor allem weil man dann immer mehr Features möchte und dann geht die Entwicklungszeit quasi ins Unendliche.... Es hat schon seine Berechtigung, dass es Firmen gibt, die sich nur mit Hard- und Software für CAN ( und natürlich auch andere Protokolle ) auseinandersetzen. Oberflächlich betrachtet ist CAN auch easy: 8 Datenbyte, Priorisierung durch ID, Übertragungsrate auswählen, Leitungslänge beachten und den Bus terminieren. Geht man ins Detail wird das ganze dann doch Umfangreicher durch Sachen wie Arbitrierung, Bit-Stuffing, CRC....
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.
@ Markus Weber Du hast das CAN Protokoll nicht verstanden. Gruss
Erich schrieb: > @ Markus Weber > Du hast das CAN Protokoll nicht verstanden. > Gruss Was bringt dich zu dieser Einschätzung? :-)
Beitrag #3813510 wurde von einem Moderator gelöscht.
Beitrag #3813523 wurde von einem Moderator gelöscht.
Beitrag #3813917 wurde von einem Moderator gelöscht.
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.
Und während c-hater seinem Fetisch nachgeht bewegt sich die restliche Welt langsam Richtug model-based-design und darauf basierender automatische Code-Generierug und lässt auch die C Welt hinter sich... Früher kontrollierte man den Output vom C-Compiler, das macht heute keiner mehr. Heute schaut man gelegentlich noch in den Output von genriertem Code, obwohl das auch schon fast vorbei ist.
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
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?
:
Bearbeitet durch Moderator
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.