Forum: Mikrocontroller und Digitale Elektronik CAN auch schneller als MCP2515 ?


von Karsten K. (karsten42)



Lesenswert?

Moin Moin CAN Wissende :-)

Ich habe ein MCP2515 an einem ATMEGA 1284 via SPI mit 2Mhz. Der MCP und 
die MCU laufen mit 16Mhz.
Die Problematik ist, dass ich auf eine CAN Nachricht innerhalb von < 
80µs antworten möchte ( Request <-- Response ). Mit oben beschriebenen 
Setup benötigt der MCP2515 schon ganze 26,6 µs um nach dem Empfang der 
CAN Nachricht einen INTerrupt auszulösen. Das Auslesen des Buffers via 
SPI dauert dann 69,8 µs. Bis die Daten also im Programm sichtbar sind, 
dauert es schon 96,4 µs.
Das erhöhen der SPI Geschwindigkeit wird im Grunde das Problem nicht 
lösen, denn ich muss ja auch noch die Daten verarbeiten und wieder per 
SPI an den MCP2515 senden.

Ist es überhaupt realistisch mit "C" und einem anderen Controller, z.B. 
SJA1000 oder AT90CAN128 solche Antwortzeiten zu erreichen?

Beste Grüße
Karsten

von Wilhelm F. (Gast)


Lesenswert?

Karsten K. schrieb:

> Ist es überhaupt realistisch mit "C" und einem anderen Controller, z.B.
> SJA1000 oder AT90CAN128 solche Antwortzeiten zu erreichen?

Nun ja, bei einem ARM z.B. LPC2000 mit CAN müssen nur intern Register 
gelesen und geschrieben werden, das erspart den Bus. Ich fand das schon 
komfortabler zu programmieren, weil man nicht erst auf einen Bus 
zugreifen muß.

EIne andere Frage ist der Bus-Traffic auf dem CAN-Bus, ob man den 
restlos zupacken möchte.

von Daniel H. (Firma: keine) (commander)


Lesenswert?

Karsten K. schrieb:
> Ist es überhaupt realistisch mit "C" und einem anderen Controller, z.B.
> SJA1000 oder AT90CAN128 solche Antwortzeiten zu erreichen?

Definitiv. Am C soll es ohnehin nicht scheitern, solange man sauber 
programmiert und der Compiler keinen Murks macht. Bei Controllern mit 
CAN-Interface sind die Daten ja quasi direkt im Zugriff, d.h. der 
Controller kann auch direkt anfanzen zu werkeln. In deinem Fall werden 
ja allein schon fast 30µs verbraten bis du die Daten überhaupt auslesen 
kannst.

Das Verarbeiten der Daten auf dem Controller dürfte hier das geringste 
problem sein, in deinem Fall ist einfach das Interface zu langsam. 80µs 
sind ja eigentlich schon eine ganze Menge, kommt natürlich darauf an, 
was für Operationen der Controller durchführen muss, aber bei 16 MHz 
sind das immerhin schon 1280 Takte. Wenn man die vollständig nutzen 
kann, weil der Controller die Daten direkt lesen kann, dann sollte das 
also kein Thema sein.

: Bearbeitet durch User
von Falk B. (falk)


Lesenswert?

Bei 16 MHz kann die SPI mit 8 MHz laufen, das ist schonmal Faktor VIER 
schneller!

von Chris (Gast)


Lesenswert?

die 26µS bis zum Interrupt hat er aber trotzdem, dann Daten verarbeiten 
usw. wird trotzdem knapp..

von Daniel H. (Firma: keine) (commander)


Lesenswert?

Falk Brunner schrieb:
> Bei 16 MHz kann die SPI mit 8 MHz laufen, das ist schonmal Faktor VIER
> schneller!

Wenn es linear skaliert und lesen und schreiben gleich lange brauchen 
dann benötigt er aber immer noch mindestens 26,6µs + (2 * 69,8µs/4) = 
61,5µs (vorausgesetzt der MCP hat keine weitere Vorzögerung um die Daten 
auf den CAN-Bus auszugeben). Damit bleiben auf dem Controller weniger 
als 18,5µs um zu reagieren. Könnte aber je nach Anforderung reichen.

von Karsten K. (karsten42)


Lesenswert?

Humm, 8 Mhz SPI:
lesen würde bei linearem Verhalten dann 14,6µ dauern. Schreiben von 
8Byte + CAN Header dauern dann 21,68 µs. Plus MCP Interrupt auslösen von 
26µs und 5µ für das aufbereiten zum senden sind alles zusammen 67,28µs. 
Das wäre mir ehrlich gesagt zu knapp, denn die MCU wird ja auch noch 
einige Zeit benötigen.
Wenn es stimmt, das ein AT90CAN128 wirklich viel schneller ist werde ich 
das in Angriff nehmen. Ein SJA1000 ist zwar auch nett, aber nur in SMD 
und kostet eine "Unmenge" an Pins.
Der CAN Bus ist im Übrigen leer. Es sind nur maximal drei teilnehmer am 
Bus. Ach, und die Übertragung läuft mit 250K Baud. Es ist zumindest 
beruhigend, das es keine utopischen zeiten sind und ich nicht unbedingt 
in Assembler schreiben muss. Das wäre für mich nicht wirklich 
realisierbar :-)

Gruß
Karsten

von Gerd B. (bertr2d2) Benutzerseite



Lesenswert?

Karsten K. schrieb:
> Die Problematik ist, dass ich auf eine CAN Nachricht innerhalb von <
> 80µs antworten möchte ( Request <-- Response ). Mit oben beschriebenen
> Setup benötigt der MCP2515 schon ganze 26,6 µs um nach dem Empfang der
> CAN Nachricht einen INTerrupt auszulösen.

Ist das wirklich so ? Wenn ich die decodierten CAN Daten vom 
Logicanalyzer anschaue (2.Bild), werden die End of Frame Daten + IFS 
nicht berücksichtigt. Wenn ich das mal grob interpoliere antwortet der 
MCP2515 nahezu sofort ...

Gruß

Gerd

von Karsten K. (karsten42)


Angehängte Dateien:

Lesenswert?

Hallo Gerd,

Danke für deine Aufmerksamkeit. Ich war mir sicher, aber Kontrolle ist 
besser. Der Analyser zeigt nicht nur die Netto-Daten sondern das 
gesammte CAN-Paket. Ein etwas besserer Ausschnit zeigt, das nach dem CRC 
noch ein paar Impulse ( hier ein ACK ) kommen. Dann dauert es 
tatsächlich 26,6 µs bis der MCP2515 einen INTerrupt auslöst.

gruß
Karsten

von H.Joachim S. (crazyhorse)


Lesenswert?

Hier habe ich es mal vorgerechnet:
Beitrag "Re: 2 Stk. MCP2515 an einem z.B. ATMega32"

von Gerd B. (bertr2d2) Benutzerseite


Lesenswert?

Wenn ich mich nicht irre ist das letze, vom Logic Analyzer dekodierte 
Bit das ACK-Bit. Die IFS Bits gehören aber IMHO zu einem kompletten 
Frame dazu ...

Mit welcher CAN-Rate arbeitest Du denn ? Standard oder Extended Frame ?

Gruß

Gerd

von Frank K. (fchk)


Lesenswert?

Karsten K. schrieb:

> Wenn es stimmt, das ein AT90CAN128 wirklich viel schneller ist werde ich
> das in Angriff nehmen. Ein SJA1000 ist zwar auch nett, aber nur in SMD
> und kostet eine "Unmenge" an Pins.

Du könntest auch einen dsPIC33EP512MC502 in Betracht ziehen. Gibts auch 
bastelfreundlich in DIL28, 70MHz, 48k RAM, 512k Flash (es gibt auch 
welche mit weniger), ECAN im Chip drin (quasi eine deutlich verbesserte 
Version dessen, was Du im 2515 hast, mehr Buffer, etc etc).

fchk

von Gerd B. (bertr2d2) Benutzerseite


Lesenswert?

Gerd B. schrieb:
> Wenn ich mich nicht irre ist das letze, vom Logic Analyzer dekodierte
> Bit das ACK-Bit. Die IFS Bits gehören aber IMHO zu einem kompletten
> Frame dazu ...


sed s/IFS Bits/EOF Bits/

: Bearbeitet durch User
von Karsten K. (karsten42)


Lesenswert?

Gerd B. schrieb:

> sed s/IFS Bits/EOF Bits/

Hei freu: jemand der sed kennt :-)

Gerd du hast Recht. Wenn die EOF bits alle 1 sind, wird man die so nicht 
sehen. Baudrate ist 250K; ein Bit ist dann 4µs lang. es passen also noch 
ganze 6 EOF bit in den Frame und es bleiben dann nur 2,625µs als 
Verzögerung vom MCP2515 übrig.

Ich habe hier ein AT90CAN128 auf einem development board von Olimex. Ich 
werde mich dann an die Arbeit machen das ganze interrupt gesteuert mit 
dem eingebauten CAN-Controller zu realisieren. Wir eine heiden Arbeit; 
Aber wir wollen ja Herausforderungen haben.

Herzlichen Dank an alle für eure sehr nützlichen Tips! Eine Runde V-Bier 
bitte. ( In Paderborn konnte man vor vielen Jahren auch ein Byte oder 
gar ein Long in einer Kneipe bestellen und wurde nich schräg angesehen. 
Bit heisst da ja das Bier :-)

Gruß
Karsten

von Falk B. (falk)


Lesenswert?

@ Karsten K. (karsten42)

>Ich habe hier ein AT90CAN128 auf einem development board von Olimex. Ich
>werde mich dann an die Arbeit machen das ganze interrupt gesteuert mit
>dem eingebauten CAN-Controller zu realisieren. Wir eine heiden Arbeit;
>Aber wir wollen ja Herausforderungen haben.

Oder einfach bewährte Systeme nachnutzen. Das Rad immer wieder neu zu 
erfinden ist nicht sonderlich clever.

http://www.kreatives-chaos.com/artikel/universelle-can-bibliothek

Siehe auch CAN.

Bitte 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
Noch kein Account? Hier anmelden.