CAN Gateway mit AVR möglich?

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

Geht.

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

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.

Beitrag "2 Stk. MCP2515 an einem z.B. ATMega32"

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.

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

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

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

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

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

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