Hallo! Ich habe hier zwar schon einige Beiträge bezüglich CAN Gateway gefunden, aber es bleibt die Frage offen, ob es nicht doch mit einem 8-Bit AVR möglich wäre. Ziel ist es, in einem Auto welches mit 500kBit/s CAN arbeitet und rund 1000 Messages pro Sekunde aussendet ein Gateway zu bauen. Ist das noch mit einem 8-Bit AVR, also AT90CANxxx oder mit einem MCP2515 möglich? Schönen Abend. Herbert
Oh !! Sorry :) Ich brauche ein CAN - CAN Gateway, welches mir lediglich eine ID herausfiltert, ändert und wieder aussendet, alle anderen sollte es durchlassen. Verdammt, hatte ich tatsächlich vergessen zu schreiben! Danke. Herbert
Hallöchen Ich kenne nur den ATMEGA64M1. ( CAN sollte aber überall gleich sein ) Warum sollte es nicht geh'n. Das "Herausfilter" erledigt die Hardware durch eine Mask. Der Rest ist dann nur mehr eine Übung. hmg Mandi
Hallo! Naja, es geht darum, ob die Geschwindigkeit reicht. Der AT90CAN bekommt eine Nachricht, es gibt einen Interrupt, danach muss ich entscheiden, ob es eine Nachricht ist, die ich modifizieren muss oder nicht. Danach muss ich die Nachricht wieder aussenden, zb. über einen MCP2515. Deshalb die Frage ob er die Geschwindigkeit schafft! Am Besten wäre natürlich, wenn man es per Hardware durchleiten und Abfangen könnte, aber geht ja leider so nicht wirklich ohne anderen µC. Herbert
Für ein Gateway brauchst du aber 2 CAN Schnittstellen. Der 90CAN128 hat aber nur eine. Also du musst dann den 90CAN128 UND den mcp2515 nehmen. Ich würde nicht zwei 90CAN128 per SPI koppeln. Als SPI Slave sind die Megas nicht gerade geeignet. HTH.
Also mit zwei separaten CAN-Interfaces? Da würde ich was nehmen, was gleich zwei CAN MACs integriert hat, zB einen dsPIC33FJ128GP706A. Gleiches Package wie ein 90CAN128, dafür zwei ECAN Blöcke, mindestens doppelt so schnell, 16 Bit statt 8 Bit, und kostet dabei nicht mehr. Wenn Du unbedingt einen AVR nehmen musst, dann nimm einen mit externem Adress/Datenbus (z.B Mega 640 oder so) und zwei NXP SJA1000. Der SJA1000 kann den gemultiplexten Adress-/Datenbus des AVR direkt verarbeiten. Vom MCP2515 solltest Du absehen, das SPI dazwischen bremst. fchk
500kbit-CAN, also ist die SPI-Datenrate noch kleiner (nicht alle CAN-Bits werden auch über die SPI übertragen). Mit 16MHz-AVR kann die SPI mit 8Mbit betrieben werden -> genug Luft auch für 2 MCP2515 an einer SPI. Irgendwann habe ich hier mal genau zu dem Thema ein Schaltbild eingestellt, mal suchen.
Hallo crazy horse! Das sieht doch verdammt gut aus! Danke schonmal dafür. Und du meinst ein 16MHz AtMega schafft die 1000 Msg/s auch? Wäre mit einem At90CAN + MCP2515 eine Geschwindigkeitserhöhung gegeben oder nimmt sich das nichts? Problem wird wohl auch sein, dass es Bidirektional sein muss oder ? Herbert
Pro message gibt es maximal 12 byte, also 96bit auf der SPI, entspricht 12µs bei 8MHz SPI-Takt. Kommst also auf >8000 messages pro Sekunde. Du kommst nur auf 4000, reicht also. Hast du einen CAN-Controller on Chip, entfällt natürlich die Hälfte der SPI-Kommunikation. Aber, wie gesagt, es reicht auch so. Ich habe diesen Ansatz damals gewählt, weil ich mit dem CAN des AVR nicht so zurecht kam und auch schlecht lieferbar war. Inzwischen sieht es ja besser aus.
Hier gibts das mit einem SJA1000: http://www.kreatives-chaos.com/artikel/sja1000-testboard Einen zweiten hängst Du dann einfach parallel zum ersten und nimmst A9 als CS anstelle A8. Anstelle der beiden 16 MHz Quarze ist ein 16 MHz Quarzoszillator für die gesamte Schaltung sinnvoller. Der SJA1000 hat den Vorteil, dass Du nur einen einzigen Speicherzugriff brauchst, um auf ein Register zuzugreifen. Das geht natürlich viel schneller als über SPI und ist auch einfacher zu programmieren. Sprich: Du hast viel mehr Luft im Design. fchk
Hallo! Noch eine Frage an crazy horse. So wie ich das sehe funktioniert das ganze folgendermaßen. Ich bekomme einen Interrupt vom MCP2515 dass eine Nachricht zum abolen bereit ist. Wenn also nun der Interrupt ausgeführt wird, muss ich folgendes machen:
1 | can_get_message(&message,1); |
2 | |
3 | can_send_message(&message,0); |
Wenn der andere MCP einen Interrupt ausführt, gehört 1 und 0 getauscht, weil mir das nur den CS Pin auswählt. Aber wenn ich mir diese Funktionen nun ansehe, dauern die doch bestimmt an die 100 Taktzyklen, wenn nicht sogar mehr, dann scheidet doch ein Durchsatz von 1000 Messages / Sekunden von vornherein aus, oder sehe ich das falsch? Danke Herbert
Ich habe ehrlich gesagt keine Ahnung, wie lange diese Funktionen dauern. Wenn es 100 Takte (ich denke eher mehr) sein sollten: 16.000.000/100=160.000 :-) Ausserdem werden wohl nicht von beiden Seiten 1000 messages/s kommen, sondern insgesamt. Es reicht locker.
Ich werde einfach einmal 2 Stück kaufen, und es austesten! Hoffe du kannst mir helfen, wenn es zu Problemen kommt, wobei ich es erstmal nicht vermute :) Weißt du zufällig wie stark der MCP2551 eingreift? Also der CAN Transceiver, undzwar, wenn der MCP2515 oder AT90CAN128 fälschlicherweise mit dem Senden beginnt, obwohl gerade eine Nachricht läuft, ob der MCP2551 das unterdrückt, oder ob es eigentlich so wie der CAN Controller das haben möchte, an den Bus weitergegeben wird? Herbert
Ein CAN Controller sendet normalerweise nicht mitten in einen fremden Frame rein. Im Normalbetrieb geschieht das nur bei der Arbitrierung per ID, und da kontrolliert. Der Transceiver hat keinerlei Eigenintelligenz.
Hallo! Das dachte ich mir auch. Er kontrolliert ja ständig, ob sein Tx mit dem Rx übereinstimmt oder? Und wenn der die ID sendet, und am Rx liegt etwas anderes, sollte er ja das senden ABBRECHEN und nichtsmehr weiter schicken oder? Herbert
Herbert schrieb: > Er kontrolliert ja ständig, ob sein Tx mit dem Rx übereinstimmt oder? Das macht der CAN-Controller, nicht der Transceiver.
Hallo! Sorry, ja das meinte ich in diesem Fall ! Anders gesagt, es dürfte nie eine Komplette Message am Tx liegen, wenn schon alleine die ID nicht am Bus übernommen wurde, richtig? Herbert
Entweder, tut das mein AT90CAN128 nicht, oder mein Oszilloskop schafft die Synchronisation zwischen den beiden Kanälen nicht. Ich werde mir wohl einen Logik Analysator borgen müssen, damit ich das Objektiv beurteilen kann. Herbert
Herbert schrieb: > Entweder, tut das mein AT90CAN128 nicht, oder mein Oszilloskop schafft > die Synchronisation zwischen den beiden Kanälen nicht. Digital oder analog? Wenn analog, dann spiel mal mit chopped vs. alternated trigger. Analogscopes zeichnen beide Traces ja leider nicht gleichzeitig auf.
Nein es ist digital, ein älteres, ca. 15 Jahre alt, ein Kanal springt auch nach dem Stoppen der Aufzeichnung etwas. Ansonsten, werde ich mir alternativ ein moderneres digitales Oszi leihen müssen, einen Logik Analysator hat nicht jeder leider. Herbert
>Ziel ist es, in einem Auto welches mit 500kBit/s CAN arbeitet und rund >1000 Messages pro Sekunde aussendet ein Gateway zu bauen. Mal sehen was der TÜV dazu sagt;)
Glaubst doch ned ernsthaft, dass die das Auto zerlegen und nachschauen ;) Selbst wenn, wärs meines Erachtens komplett egal. Herbert
>Selbst wenn, wärs meines Erachtens komplett egal.
Es soll Menschen geben die das völlig anders sehen.
Es soll Menschen geben (mich) denen das völlig egal ist :) Also, einfacher Test, Kanal A und Kanal B an Tx angeschlossen und siehe da, absolut Asynchron :( Also ist das Oszilloskop schuld! Herbert
Hallo nochmal! Ich habe jetzt einen Logik Analysator, und siehe da, er sendet wie er sollte. Allerdings fällt mir eins auf, im Auto ist zwischen 2 Messages ca. 5µs Zeit, in der Zeit müsste ich also alle Daten aus dem MoB lesen, und ihn wieder freigeben, damit die nächste Nachricht hineinwandern kann. Ich denke das wird für den 8-Bit AVR eng. Gibt es eine Möglichkeit, dass ich zb. 2 MoBs verwende, bei denen ich bei beiden keinen Filter aktiviere, also alle IDs genommen werden, und das er automatisch, wenn 1 MoB noch nicht freigegeben ist, in den nächsten schreibt? Danke Herbert
Der MCP2515 hat 2 Empfangsbuffer. Ist RXB0 belegt und RXB0CTRL.BUKT=1, werden die ankommenden Daten automatisch nach RXB1 geschrieben... Und nun schreib ich nichts mehr in diesem trööt, du suchst ständig nach Problemen, die es gar nicht gibt.
Hallo! Es tut mir leid! Mir ist dies heute aufgefallen, als ich meinen Logik Analysator dran hatte und wollte wissen wie das ist. Das heißt ich brauche lediglich 1 MoB das mit dem Buffer erledigt der MCP sowieso selbst. Ich habe mir nämlich das Datenblatt des AT90CAN angeschaut und nachdem das steht: jedes MoB hat: "– 8 Bytes Data Buffer (Static Allocation)" und: "To preserve register allocation, the CAN data buffer is seen such as a FIFO (with address pointer accessible) into a MOb selection.This also allows to reduce the risks of un-controlled accesses. There is one FIFO per MOb. This FIFO is accessed into a MOb page thanks to the CAN message register." Bin ich davon ausgegangen, das er aufgrund des einen Buffers nicht fähig ist, eine weitere anstehende Message zu speichern. Herbert
Im MCP2515 kannst du auch schon Filter definieren. Wenn du nur eine einzige ID "beantworten" willst, muss dein AVR gar nicht mit allen Nachrichten zurecht kommen.
Hallo Sven! Wie schon desöfteren geschrieben, hilft mir das nichts, da alle Nachrichten durch das Gateway müssen, und nur eine verändert wird. Im Datenblatt des MCP2515 steht, wie du eben gesagt hast, dass er den RXB1 füllt, wenn der RXB0 voll ist. Im Danteblatt des AT90CAN finde ich eine ähnliche Funktion nicht. Eventuell verwende ich einfach 2x MCP2515. So wie ich das sehe, muss ich Abfragen ob ein Rollover statt gefunden hat, danach muss ich einfach aus dem RXB1 Buffer die Nachricht lesen. Soweit so klar :) Herbert
holger schrieb: >>Selbst wenn, wärs meines Erachtens komplett egal. > > Es soll Menschen geben die das völlig anders sehen. Mach dir da keine Gedanken, in dem Auto werden alle Lampen an sein. Das notwendige Zeitverhalten der CAN Botschaften untereinander und in Bezug auf die anderen Steuergeräte wird er so niemals einhalten können. Durch sein ein eingeschleiftes Gateway werden alle Zeitrelationen unter den CanBotschaften verändert. Jede Signalplausibilisierung in den Steuergeräten wird das erkennen und Abschalten. Ralph
Herbert schrieb: > Glaubst doch ned ernsthaft, dass die das Auto zerlegen und nachschauen > ;) > > Selbst wenn, wärs meines Erachtens komplett egal. > > Herbert Wenn nach einem Unfall, egal wer Schuld ist, die gegnerische Versicherung auch nur den Verdacht hat, das du an deinem Auto etwas gebastelt hast wird diese Versicherung jeden Hebel in Bewegung setzen. Durch deine Bastelei entfällt die ABE und damit werden beide Versicherungen, deine und die gegnerische, bei dir die Hand aufhalten und jeden Cent wieder haben wollen. Und das bekommen sie vor Gericht auch. Wenn dir das natürlich dein Basteln wert ist....... Ganz abgesehen von der Staatsanwaltschaft die bei Körperverletzung und noch schlimmerem ebenfalls bei dir stehen wird. Mit Fahrlässigkeit kommst du da nicht durch. Aber bastel du nur am Auto rum. Du kannst das ja besser als die Autohersteller und Zulieferer die da 100K € und mehr in die Entwicklung einzelner Steuergeräte und eines Can Bus systems investieren.
Ralph schrieb: > Aber bastel du nur am Auto rum. Du kannst das ja besser als die > Autohersteller und Zulieferer die da 100K € und mehr in die Entwicklung > einzelner Steuergeräte und eines Can Bus systems investieren. Danke Ralph für die Lorbeeren, werde ich machen :) Herbert
@Herbert Ich möchte dir ja nicht die Laune verderben oder den Spaß am Basteln nehmen, aber der PT-CAN eines Autos mit einem Gateway zu versehen ist eine wirklich unkluge Idee. Erstens sind alle Botscaften mit CRC und meistens auch Alive-Counter ausgestattet. Sobald du deinen Gateway dazwischen hängst und die Hauptklemme aktivierst,sprich das Auto aufweckst und den Can aktivierst, werden sich sämtliche Steuergeräte vom Bus trennen und in den Notfallmodus gehen. (Licht an, Scheibenwischer an...) Dann hast du einen bumvollen Fehlerspeicher und falls vorhanden den Infospeicher auch voll. Aber nehmen wir mal an du bekommst den Gateway ans Laufen, ohne das alles ausgeht, das Einzige was du sehen wirst sind die Botschaften im Zahlenformat. Ohne einen detaillierten Nachrichtenkatalog, in dem sowohl die Bezeichnung als auch die Umrechnung der vorhandenen Signal beschrieben ist kommst du da nicht weiter. Der nächste Punkt ist, das du keine Ahnung hat, wie die Botshaften in den Steuergeräten weitergerechnet werden da kann ein wahnsinniger Murks rauskommen. Und zum Schluss überleg mal, warum ein Gateway von einer Firma im Automotivebereich so ca 2 bis 5k kostet. Glaube mir das ist wirklich nicht böse gemeint, aber lass es besser, da kommt nichts Gutes bei raus.
Hannes schrieb: > Aber nehmen wir mal an du bekommst den Gateway ans Laufen, ohne das > alles ausgeht, das Einzige was du sehen wirst sind die Botschaften im > Zahlenformat. Ohne einen detaillierten Nachrichtenkatalog, in dem sowohl > die Bezeichnung als auch die Umrechnung der vorhandenen Signal > beschrieben ist kommst du da nicht weiter. > > Der nächste Punkt ist, das du keine Ahnung hat, wie die Botshaften in > den Steuergeräten weitergerechnet werden da kann ein wahnsinniger Murks > rauskommen. Hallo Haannes! Ich weiß welche Nachrichten ich zu verändern habe, auch die CRC Berechnung ist bekannt. Es geht lediglich um ein CAN Gateway zwischen dem Display und dem Rest. Ich verstehe nicht wozu ich wissen muss, was im Steuergerät weitergerechnet wird, alles was ich brauche ist bekannt, wie gesagt es geht nur um eine Veränderung am Display. Herbert
Du kannst auch zwei AT90CAN verwenden, die Datenübertragung zwischen beiden machst Du dann nicht wie vorgeschlagen per SPI sondern nutzt zwei 8Bit-Ports und überträgst die Daten parallel mit Hardware-Handshake. Sollte problemlos machbar sein und die Geschwindigkeit ist auch ausreichend. Seit es diese neumodischen seriellen Schnittstellen gibt, denkt fasst keiner mehr an die gute alte parallel Datenübertragung...
Ich weiß zwar nicht was für ein Auto du hast bzw. auf welchem CAN-Bus das Display (des Kombiinstruments?) liegt aber es ist trotzdem leicht möglich das du den Bus "ausser Takt" bringst und dann trennen sich wiederum die Steuergeräte vom Bus (je nach Protokoll). Was mich aber wirklich interessieren würde, ist wo du den Nachrichtenkatalog für den Bus her hast. Egal ob das Display/Kombiinstrument direkt von der Autofirma oder von einem Zulieferer kommt, liegen diese Katalog normalerweise auf gesicherten Laufwerken, Tresoren..... jedenfalls nicht öffentlich zugänglich. Hannes
Hallo! Für das Auto sind die Daten Online da viele daran gearbeitet haben, die Nachrichten zu entschlüsseln. Deshalb sind die meisten online. Herbert
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.