mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bussystem im Kfz


Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Ich bastel gerade an einem Projekt im Auto, bei dem ich verschiedene
selbst entwickelte Schaltungen über ein Bussystem verbinden möchte. Die
einfachste Schaltung ist dabei vielleicht der Innenlichtdimmer und die
anspruchvollste die Ladedruckregelung.

Das Problem bei meinem Bussystem ist nun, das die einfachen Schaltungen
wie der Innenlichtdimmer nicht die wichtigen Informationen wie die der
Ladedruckregelung blockieren dürfen. Ich möchte auch gerne verschiedene
Sensorwerte "für alle" auf den Bus geben, so daß jede Baugruppe sie
abrufen und bei Bedarf verarbeiten kann.

Fällt Euch da spontan ein einfaches Bussystem für solche Zwecke ein?


Viele Grüße,
Jan

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CAN.

Autor: StephanW (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt, in neueren Fahrzeugen ist eh schon ein CAN-Bus drin, über den
alle Komponenten/Steuerteile kommunizieren.

Gruß Stephan

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nicht nur einer. meistens gleich 3

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
3? weiß nicht soviel darüber - würde mich aber interessieren wozu!

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Teilung ist oft Motor mit Hochgeschwindigkeit und Karosserie
sowie Innenraum/Komfort mit niedrigerer Geschwindigkeit.
Meistens laufen die Busse dann am Amramturenbrett (Tacho) zusammen
da dort oft Statusinformationen angezeigt werden.

Die Trennung ist sinnvoll da z.B. der motor und seine Komponenten
nur auf einem engen Raum mit kurzen Leitungen und hoher
Geschwindigkeit kommunizieren können und vom abgerissenen
Buskabel der Bremsleuchte hinten links nicht gestört wird.
Un dem Fahrer ist es Egal ob die Klimaanlage innerhalb von 10ms
oder 100 ms auf einen Tastdruck reagiert.

In moderneren Fahrzeugen werden aber mitlerweile auch andere
Busse eingesetzt, z.B. Motor mit Flexray, Multimedia mit MOST,
Türen mit LIN.....

Gruß
  Martin

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hier gibts was zu lesen zu dem thema:
http://www.heise.de/ct/03/14/170/default.shtml

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, an CAN hatte ich tatsächlich auch schon gedacht. Ich bin aber wieder
ein bißchen davon abgekommen, weil ich denke, dass es ein wenig
"overdressed" ist.

Ganz konkret wird es, wenn ich beispielsweise den Ladedruck auf den Bus
geben will: Ich brauche für den Fühler einen IC, nur um den Wert auf den
Bus zu geben. Ich kann das Protokoll nicht per Software abwickeln, weil
es zu komplex ist. Ich brauche also zur Bearbeitung dann noch
zusätzlich einen Controller (beispielsweise um die Abweichung des
Druckfühlers zu berechnen).

Wie würde das Bussystem denn ganz konkret aussehen?

Sensor->SLIO <-> CAN <-> CAN-Controler <-> Verarbeitung?

Danke für Eure Antworten!
Jan

Autor: ich kann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn CAN zuviel kann, nimm den AS Bus
ein Master fragt zyklisch bis zu 32 Slaves ab
Reaktionszeit ist < 5msec, übertragen werden pro Zyklus 4 Bit
einfache 2Drahtverbindung (incl. Versorgung), max 100 m (reicht im Auto
sicher ;)

ist eigentlich ein Industriebus für die unterste Ebene

Gruß Peter

Autor: Leopold (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AS-Bus ist mir kein Begriff!
Hat da jemand eine genaue Hardware- und Protokollbeschreibung?
mfg leo

Autor: ich kann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo

@Leopold
am besten du startest von da:
http://www.as-interface.com/

Gruß Peter

Autor: Jim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso nicht CAN?

Das dürfte das am weitesten verbreitete System für solche Zwecke sein,
dementsprechend billig ist auch die Hardware und es gibt jede Menge
Controller aus allen Grössenklassen, die so etwas schon eingebaut
haben.
Von der Software im Internet ganz zu schweigen.
Etwas anderes würde ich an Deiner Stelle nicht nehmen.

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also nachdem ich jetzt all Eure Meinungen gehört habe, denke ich auch,
dass CAN mölicherweise die beste Lösung ist. Ich bin ursprünglich auf
der Suche nach einem einfacheren System gewesen, aber mit einem
MCP2502X/5X kann ich ja doch recht einfach Sensorwerte auf den Bus
geben und diese dann mit dem 2510 wieder auslesen...

Danke für Eure Antworten :-)
Jan

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch wenn es viel Unterstützung für CAN gibt, sollte man die Komplexität
nicht unterschätzen. Man wird nicht umhin kommen, CAN in der Tiefe zu
verstehen. Und um CAN halbwegs zu verstehen, kann man durchaus sich ein
halbes Jahr Vollzeit mit beschäftigen...

Oder ist die Unterstützung mittlerweile wirklich so weit, dass ich mich
um Details wirklich nicht mehr kümmern muss? Für wie aufwändig haltet
ihr den Einstieg.

Meine Erfahrungen gehen 10 Jahre zurück, als wir in diese Technik
einsteigen wollten und ich mich etwa einen Monat damit beschäftigt
hatte. Wir haben dann doch etwas einfacheres genommen.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Meine Erfahrungen gehen 10 Jahre zurück, als wir in diese Technik
> einsteigen wollten und ich mich etwa einen Monat damit beschäftigt
> hatte. Wir haben dann doch etwas einfacheres genommen.

Definiere das ganze mal ... beim CAN handelt es sich doch eigentlich um
ein sehr verständliches Medium ... anders als bei jedem anderen
kommerziellen Bus-System wie Profibus oder Interbus, von Industrial
Ethernet ganz zu schweigen !

Also für uns war die Implementation von CAN wirklich das was am
wenigsten Entwicklungszeit benötigte, bei der Profibus Implementation
mussten wir sogar ne Woche einen Siemens-Ing. holen, da das damals mit
der gesicherten Datenübertragung nicht so einfach war ...

Bis dann
 Michael

Autor: Josef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Würde einen RS 485 nehmen. Auch CAN arbeitet damit. Software dazu gibt
es im Forum. Oder selber machen.
UART mit 9 Bit initialisieren, Baud 9600. Falls 9 Bit == 1 ist es die
Adressinformation. Alle Teilnehmer auf Empfang schalten. Zugriff auf
den Bus nur nach einer Wartezeit x eigener Adresse (falls 2
gleichzeitig senden wollen).
Jedes Adressbyte stellt den Buszugriffstimer der Teilnehmer auf den
Ausgangswert. So haben Teilnehmer mit niederer Adresse Vorrang.
Übertragung immer zB. mit 5 Byte.  Adresse, Befehl, Par1,Par2,
Absenderadresse.
Werde in geraumer Zeit Software posten.


Schöne Grüße Josef

Autor: Jim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Würde einen RS 485 nehmen. Auch CAN arbeitet damit."
Seit wann das denn?

Man kann RS485 als Übertragungsmedium nehmen. Wird aber so gut wie
nie gemacht, weil das viele Nachteile hat (keine dominanten /
rezessiven Pegel -> Nur Master-Slave Konfiguration).

Nimm CAN, dann musst Du Dir über das Protokoll keine Gedanken mehr
machen. Multimaster, was ja in Deinem Fall sinnvoll ist, kostet dann
keinen Gedanken mehr. Die ICs kosten auch fast nichts mehr, es gibt von
Microchip auch SPI-CAN-Controller, ideal für den Anschluss an einen
ATMega - Samples gibt es kostenlos.

Autor: Josef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Viel Spass mit der Einarbeitung auf die CAN Chips ;-) (Data Sheets ab
200 Seiten). CAN benützt gleich wie RS485 die
Differenzspannungsauswertung. Die dominaten rezessiven Pegel bei CAN
brauchste im Selbstbau nicht, da du Prüfsummen verwenden kannst.
Nebenbei würde ich von einem Eigenbau-Netzwerk im KFZ abraten. es sei
denn, du bist Mitglied beim ADAC oder so.
Im Profibereich geht fast kein Weg an einem genormten Bussystem
vorbei. Im Hobbybereich würe ich nicht so streng sein.


Josef

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

also CAN Systeme sind wirklich nicht mehr so komplieziert zu handhaben.
Wir arbeiten da aus der Automobilindustrie jeden Tag damit
und setzen ihn auch bei Prototypen gerne ein. Allerdings würde ich
dringend davon abraten in ein bestehendes CAN system im Auto
einzugreifen da sollte man wirklich den ADAC Fachmann in der
Verwandschaft haben. Mithorchen und einen eigenen Bus aufmachen ist da
angeraten.
Von Atmel gibt es mittlerweile ja den AT90CAN ist ein Mega128 mit CAN
dazu, gibts C Beispiele auf der Hompage. Also alles kein Hexenwerk.
Das einzige den gibt in Stückzahlen wohl erst im November.
Wenn man etwas mehr mit dem Bus machen will vieleicht noch einen CAN
Dongel von Peak für den PC anschaffen...

Gruss,

Markus

Autor: Josef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus, du hast natürlich recht. Aber du sagst selber, dass du jeden Tag
mit CAN arbeitest. Das ist nichts für Hobbybastler.
Damit du den AT90CAN einsetzen kannst, bedarf es schon guter
Kenntnisse, abgesehen davon, dass du ihn mal auf ein Board auflöten
mußt. Für uns vieleicht kein Problem, aber für jüngere Kollegen
ev.schon. Ein 485er Chip kostet gerade 40 Cent und funktioniert mit
jedem MC (auch welche ohne HW-UART).
Der CAN nimmt dir zwar Buszugriff und Senden ab, die Verwaltung der
Daten von zB. 30 Teilnehmern bleibt aber immer noch bei dir.


Ich persönlich habe mit CANDIP gute Erfahrungen gemacht, aber der
kostet (http://www.lawicel.com/candip/)

Josef

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich mußte mal ein Gerät über das CANopen Protokoll anbinden.

Ja, man muß erstmal die Doku vom CAN-Controller durcharbeiten. Nicht
alle 200 Seiten, aber Spaß macht es nicht.

Ja, man muß sich in das Protokoll hineindenken. Und von vornherein
sauber strukturiert die logischen Ebenen programmieren, sonst hat man
nach den ersten Anfangserfolgen irgendwann einen riesigen Ärger, wenn
es voller wird auf dem Bus.

Aber wenn man sich einmal die Mühe gemacht hat ... prima Sache. Und von
einem halben Jahr kann keine Rede sein, zumindest nicht für CANopen (ich
kann schwer eine genauere Angabe machen, weil es immer so nebenher lief
und das besagte Gerät viel Ärger gemacht hat). Und mit fertigen Libs
geht es wahrscheinlich noch schneller, wenn man gerne fertige Libs
benutzt.

An die vorhandenen Busse würde ich aber nicht einmal hörend rangehen
(auch wenn es verlockend ist). Selbst wenn man sicher ist, daß man ganz
passiv bleibt: sie werden Dich verantwortlich machen, wenn nachher ihr
Kram spinnt (und der spinnt heute oft). Und eine Versicherung freut
sich immer, wenn sie eine Ausrede findet, nicht zahlen zu müssen. Wie
überall: wenn das Haus abbrennt, weil der Stümper von der Elektrofirma
Mist gebaut hat, wird die Versicherung nicht zahlen wollen, weil Du an
anderer Stelle etwas "gebastelt" hast; und ja gar keine offizielle
Ausbildung hast.

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich stecke in den letzten Jahren Can-Entwicklung nicht drin. Oft sind
die Sachen aber so: Theoretisch ganz einfach. Das klappt aber in der
Praxis oft auch nur dann, wenn die Komplexität wirklich vorm Anwender
verborgen bleibt. Schönes Beispiel ist ein Handy, wo keiner, der
telefoniert was über HF-Technik wissen muss.

Wenn man aber z.B. fremde Bibliotheken nutzen muss, wenn man
herausfinden muss, warum ein Datagramm gerade schief läuft usw., ist
man ganz schnell an dem Punkt, wo man ins System hineinschauen muss und
dann alle Einzelheiten von CAN kennen muss. Und dann muss man vielleicht
auch begreifen, wie die Bibliotheken intern funktionieren. Und wenn man
dann tausenden von Quellzeilen irgendwie verstehen muss, gehen schnell
mal einigen Wochen bei drauf.

Ich kenne das alles zu gut aus dem Linuxbereich, wo man einerseits in
30 Minuten eine Suse installiert hat aber tausende von Stunden damit
verbringen kann, alles mögliche so anzupassen, wie man es gerne möchte.
Dann muss man nämlich im Detail verstehen, wie die komplexen Dinge
miteinander zusammenarbeiten. Das Wissen ist zwar Gold wert auch für
weitere Projekte, man muss es aber eben erstmal an Zeit investieren.

Es könnte also einfacher sein, sich einen RS485 Wandler zu nehmen und
in einer paar Zeilen Code ein eigenes kleines Simpelst-Protokoll zu
schreiben.

Trotzdem macht es mich neugierig, dass CAN mittlerweile relativ einfach
zu handhaben ist, werde ich mir vielleicht in der nächsten Zeit mal
anschauen.

Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen!

Hat sich schon mal jemand die Mühe gemacht und z.B. den MCP2515 auf ne
kleine extra Platine designed? Quasi SPI auf CAN?

Viele Grüsse

Volker

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch wir haben schon das eine oder andere Gerät an CANOpen oder
DeviceNet angebunden, arbeiten ja beide mit CAN ...
Und ich kann jedem der dies einmal machen möchte eigentlich fast nur
raten keine Kommerzielle Library dazuzukaufen - die Einarbeitung dauert
fast genausolange wie eine Vernünftige Einarbeitung in die
Spezifikationen ...
Wir haben eine kommerzielle Library für unser erstes Projekt gekauft,
diese jedoch nie genutzt, da bis das Ganze geliefert wurde (immerhin
EINE diskette für knappe 15000 DM) unser Prototyp schon recht gut lief
... ich habe mir das ganze dann mal angeschaut und von einer Portierung
auf unser System Abstand genommen. Daraufhin habe ich mir bei Can In
Automation alle Spezifikationen gekauft und das ganze komplett selbst
programmiert. Das ganze war immer noch schneller fertig wie die
komplette Hardwareentwicklung.

Für die Master-Seite bleibt die Frage immer offen ... Wir haben auch
ein Master-Stack programmiert (zumindest für die durch uns benötigten
Funktionen) nur setzte ich wo ich kann entsprechende
Hilscher-Interfaces ein ...

Bis dann
 Michael

Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

Ich arbeite beruflich im Automobilbereich viel mit dem CAN . Ich kann
nur raten tunlichst die Finger von den einzelnen CAN Netzen im Fahrzeug
zu lassen! Selbst beim "nur" mithören können bei einer schlechten
Schaltungsauslegung (Terminierung usw.) einige Probleme auftreten, die
ev. wichtige Funktionen des Fahrzeugs beeinflussen (ESP/DSC,
Motorsteuerung,...).
Mit den richtigen Entwicklungstools (z.B. CANoe von Vector) macht es
viel Spass seine Projekte umzusetzen. Es gibt auch Tools mit denen
beispielsweise Steuergeräte interne Grössen über CAN mess- und
applizierbar gemacht werden. Das ist unheimlich sinnvoll bei
Abstimmungs- und Enticklungsarbeiten. Die CAN Treiber selbst werden
eigentlich nicht mehr selbst programmiert (zumindest im
Automobilbereich). Man greift hier auf fertige und vor allem erprobte
Komponenten unterschiedlicher Hersteller zurück. Leider sind diese CAN
Treiber auch ziemlich mächtig und umfangreich, sodass bei den meisten
Projekten bei uns mindestens ein Mann für die Betreuung und die
Konfiguration des CAN zuständig ist.
Für Heimanwendungen halte ich den CAN für sehr brauchbar. Controller
und Software sind vorhanden und müssen nur noch in die eigene Anwendung
integriert werden. Klar, wer ein HighLevel Protokoll mit Überwachungen,
Entprellungen und Fehlerintegralen implementieren möchte, muss
natürlich einiges mehr an Grips investieren :-) Glücklich ist, wer
seine Schaltung mal eben kurz an CANoe hängen kann und den Restbus
einfach mal simmuliert :-)


Viele Grüsse

Volker

Autor: django (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Untersuchung der Signalintegrität in Bussystemen
(LIN, CAN, und FlexRay)
Die Übertragung von Signalen auf dem Physical Layer von Bussystemen wird 
von vielen Parametern beeinflusst. Die simulatorische Bestimmung der 
genauen Einflüsse einzelner Parameter ist ein Forschungsschwerpunkt am 
Arbeitsgebiet Bordsysteme. Dazu werden verschiedene 
Parameterkombinationen untersucht, die resultierende Signalintegrität 
bei der Übertragung automatisiert ausgewertet und allgemeine Regeln zum 
Aufbau von Bussystemen abgeleitet.

Hauptsächlich wird die Untersuchungen VHDL-AMS als Modellierungssprache 
eingesetzt.


Kaum ein modernes Fahrzeug kommt ohne Bussysteme aus. Dieses interaktive 
Lernprogramm begründet die Vernetzung im Kraftfahrzeug. Es zeigt anhand 
verschiedener Bussysteme die technischen Alternativen, die 
Busstrukturen, Übertragungsgeschwindigkeit und die Datentypen. Dabei 
zeigt es sich, dass es kein "bestes" Bussystem gibt, sondern 
unterschiedliche Anforderungen je nach den Einsatzbereichen. Anhand 
einiger typischer Bordnetzstrukturen wird die Aufteilung auf 
verschiedene Bussysteme beschrieben. Besondere Beachtung verdienen die 
Gateways, die Übergangsstellen zwischen verschiedenen Bussystemen. 
Inhalt: - Diagnose Bus - LIN-Bus - CAN-Bus - MOST-Bus - Bluetooth - Die 
Bussysteme EIA-485, LVDS, D²B, byteflight, Flexray werden kurz 
charakterisiert.

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.