MCP2515 Interrupt-Pin

[Thomas T. (runout)]

Hallo Gemeinde,

ich plane, den CAN-Controller "MCP2515" in einem Projektchen zu 
verwenden.

https://www.microchip.com/en-us/product/MCP2515

Ich werde aus den Angaben im Datenblatt nicht schlau.
Ist der Interruptausgang Push-Pull oder open-drain?
Normalweise sind /INT-Ausgänge immer PP.

Vol: 0.6 V IOL = +1.6 mA, VDD = 4.5V
Voh: VDD – 0.7 — V IOH = -1.0 mA, VDD = 4.5V

Für mich heist das, er kann in beide Richtungen Strom treiben, also PP.

Der /INT-Ausgänge soll einen Optokoppler (low current) ansteuern,
wei die CAN-Mimik und der Prozessor isoliert sein sollen.

Viele Grüße
Runout

[H.Joachim S. (crazyhorse)]

Thomas T. schrieb:
> Normalweise sind /INT-Ausgänge immer PP.

Durchaus nicht immer.

Thomas T. schrieb:
> Für mich heist das, er kann in beide Richtungen Strom treiben, also PP.
Ja.

Gerade wennn du einen Optokoppler anschliessen willst ist es doch völlig 
egal. Schalte den Optokoppler gegen +, L-Pegel aktiviert die LED.

[Thomas T. (runout)]

zu Befehl :-)

[Frank K. (fchk)]

Thomas T. schrieb:

> Der /INT-Ausgänge soll einen Optokoppler (low current) ansteuern,
> wei die CAN-Mimik und der Prozessor isoliert sein sollen.

Ich würde eher einen Prozessor mit internem CAN-COntroller nehmen, um 
nicht den SPI-Flaschenhals zu haben, und dann einen isolierten 
Transceiver wie den hier:

https://www.analog.com/media/en/technical-documentation/data-sheets/adm3053.pdf

fchk

[runout (Gast)]

Frank K. schrieb:
> https://www.analog.com/media/en/technical-documentation/data-sheets/adm3053.pdf

Danke für den Tipp.
Das Teil ist ja nicht gerade ein Schnäppchen...

Bei mir ist ein SPI und(!) CAN auf der ISO-Seite.
(getrennt mit Si8641BB)

µController ist der Raspi Pi pico.

Grüße
Runout

[Frank K. (fchk)]

runout schrieb:
> Frank K. schrieb:
>> https://www.analog.com/media/en/technical-documentation/data-sheets/adm3053.pdf
>
> Danke für den Tipp.
> Das Teil ist ja nicht gerade ein Schnäppchen...

Ist halt so. Hab ich schon in einigen kommerziellen Produkten 
eingesetzt. Es gibt auch eine Variante für CAN-FD.

> Bei mir ist ein SPI und(!) CAN auf der ISO-Seite.
> (getrennt mit Si8641BB)
Dann nimm den Si8662 mit 6 Kanälen. Dann kannst Du Reset und IRQ auch 
darüber laufen lassen.

> µController ist der Raspi Pi pico.

ok, der hat keinen CAN-MAC eingebaut.

fchk

[Μαtthias W. (matthias)]

Das Ding steht schon auf NRND. Nimm lieber was aktuelles wie den hier 
https://www.microchip.com/en-us/product/mcp2518fd. Der bringt dann auch 
gleich CAN-FD mit auch wenn du das nicht brauchst.

[runout (Gast)]

Sorry, der MCP2515 war das richtige Target... (nicht NRND)


MCP2518FD hatte ich schon geprüft.

-Nicht/schwer verfügbar
-Treiber

  -Github-Ergebnisse 2515: 312 repository results

  -Github-Ergebnisse 2518: 11 repository results

[Falk B. (falk)]

Frank K. schrieb:
>> Der /INT-Ausgänge soll einen Optokoppler (low current) ansteuern,
>> wei die CAN-Mimik und der Prozessor isoliert sein sollen.
>
> Ich würde eher einen Prozessor mit internem CAN-COntroller nehmen, um
> nicht den SPI-Flaschenhals zu haben,

Ich weiß, die Antwort ist 2 Jahre zu spät, aber.
Wo soll da ein Flaschenhals sein? Erstens arbeitet nicht jeder CAN-Bus 
mit 1 Mbit/s und 2. erreicht der MCP2515 bis zu 10 Mbit/s am SPI, also 
Faktor 10. Das reicht locker. Der IC ist sehr preiswert und eine gute 
Wahl für kleine CAN-Projekte, dessen Mikrocontroller keinen internen 
CAN-Controller hat.

> und dann einen isolierten
> Transceiver wie den hier:

Wozu? Die allgemeine Optokopplermanie? Die allermeisten CAN-Tranceiver 
sind NICHT galvanisch getrennt. Wozu auch? CAN funktioniert so 
wunderbar.

[Daniel G. (denial)]

Nimm nicht den MCP2518FD, wenn CAN-FD nicht gebraucht wird. Pro 
CAN-Nachricht brauchst du bei dem viel mehr SPI Transfers. Außerdem hast 
du nicht die Möglichkeit über RX?BF und TX?RTS Pins SPI Transfers 
einzusparen.

[H.Joachim S. (crazyhorse)]

Falk B. schrieb:
> Wo soll da ein Flaschenhals sein

Das Gerücht des "SPI-Flaschenhalses" hält sich auch heute noch :-)
Dazu kommt noch dass auf SPI-Seite pro message deutlich weniger bits als 
auf CAN-Seite übertragen werden müssen. Nutzt man dann noch die Filter 
wird es selbst bei rel. vollem CAN ganz entspannt.

[Daniel G. (denial)]

Für handgeklöppelte SPI Treiber mag das noch gelten, aber wenn du 
Treiber benutzt, die den SPI Controller nicht pollen, sondern über 
Interrupts darauf waren, dass ein Transfer zu Ende ist oder gar DMA 
machen, bekommt jeder SPI Transfer sehr schnell sehr viel Overhead.

[Falk B. (falk)]

Daniel G. schrieb:
> Für handgeklöppelte SPI Treiber mag das noch gelten, aber wenn du
> Treiber benutzt, die den SPI Controller nicht pollen, sondern über
> Interrupts darauf waren, dass ein Transfer zu Ende ist oder gar DMA
> machen, bekommt jeder SPI Transfer sehr schnell sehr viel Overhead.

Was für ein Gejammer! Und morgen fällt der Mond vom Himmel! Genau DIR 
auf den Kopf! ;-)