www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik CAN-AVR vs AVR plus ext. CAN Tranceiver


Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
da ich mir üüberlege in näherer Zukunft auf einen CAN Bus umzusteigen 
(CANOpen), stellt sich die Frage ob es ein AVR mit integriertem CAN sein 
soll, oder ein externer CAN Tranceiver Baustein.
Was sind die Vor/Nachteile?

Kosten sind ja ca. gleich, Bestückung mit eingerechnet.
AVR inkl. CAN hat natürlich den Vorteil dass es kompakter, bzw 
platzsparender auf der Platine ist und man weniger I/Os opfern muss. AVR 
exkl. CAN hat den Vorteil dass man viel unabhängiger ist und so evtl 
auch einen XMega einsetzen könnte.

Aber sonst? Was sind die Unterschiede in Sachen Qualität, Performance? 
Weiniger Auslastung mit internem CAN? Einfachere Programmierung, oder 
sogar das Gegenteil?

gruß
Jens

Autor: Prof. Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, du meinst sicherlich ein AVR mit integriertem CAN-Controller. Den 
Trasceiver brauchst du so oder so. Es gibt zwar auch Microcontroller die 
selbst den Transceiver integriert haben, aber meines wissens nicht von 
Atmel.
Rein qualitativ kann ich nichts über die Unterschiede sagen. Ich 
persönlich fand es aber einfacher den integrierten CAN-Controller zum 
laufen zu bringen.

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jens,

das Problem stellte sich uns hier auch vor einem Jahr. Aus den von Dir 
genannten Flexibilitätsgründen (alle möglichen AVRs einsetzbar) 
tendierte ich zuerst zu externen Bausteinen (MCP2515), habe mich aber 
dann doch für die integrierte Lösung (AT90CAN...) entschieden.

Gründe:

- natürlich ist man flexibler, andererseits haben wir so kleine
  Stückzahlen, dass man da gerne auf einen Typ setzt. Die zwei, drei
  Euro mehr spielen bei uns keine Rolle
- Beschaffungsproblem/Wechsel auf andere Controllerfamilien:
  wäre mit dem MCP2515 natürlich möglich, aber auch bei den
  CAN-Controllern ist man auf einige wenige Hersteller angewiesen.
- Man spart Platz und das Ausfallrisiko ist kleiner
- Ansteuerung und Protokoll des CAN-Controllers benötigen auch Platz
  und sind natürlich auch eine potentielle Fehlerquelle.

Letztlich haben wir uns eine CAN-Bibliothek gebaut, die viel 
abstrahiert, so dass bei einem Controllerwechsel nur sehr wenig 
angepasst werden müsste.

Ich würde uC mit integriertem CAN-Controller einsetzen. Mittlerweile 
gibt es die schon recht günstig.

Wenn es natürlich auf Cent ankommt, mag das alles wieder anders 
aussehen.
Hier erhält jeder Knoten z.B. immer eine galvanische Trennung. Das 
kostet zwar, erspart aber Ärger und im Extremfall das Abrauchen mehrerer 
Baugruppen ;-)

Chris D.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gut, danke,

dann werd ich mich wohl auch am AT90CAN versuchen.

Autor: egal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gut wahl!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.