Hallo! ich möchte meinen alten Skoda BJ 85 mit etwas Elektronik ausrüsten. Dazu plane ich, einiges an Sensoren zu verbauen und auch alles Mögliche, wie z.B Lichtsteuerung, Regensensor, usw. über die Arduino Plattform und später über den "nackten" Atmega zu realisieren. Ich gehe mal davon aus, dass ich nicht einfach 5m Draht im Auto verlegen, und dort dann z.B. einen DHT22 Sensor oder irgendeine SPI oder I2C Peripherie dranhängen kann (Leitungslänge, Interferenzen, ...?). Da würde sich so etwas wie CAN Bus ja anbieten - warum das Rad neu erfinden, wenn die Autoindustrie das seit vielen Jahren so macht. Nun scheint es aber nicht ganz so trivial zu sein, CAN Bus zu implementieren und jede Peripherie die über den Bus angebunden werden soll, muss dann ja auch CAN fähig gemacht werden. Daher frage ich mich, ob das alles nicht etwas Overkill ist und ob es nicht einen simpleren Weg gibt, die Anbindung der Peripherie an den Arduino/Atmega zu realisieren. In Anbetracht dessen, dass es in dem Auto ja noch keinen CAN Bus gibt, und ich wohl kaum das gesamte CAN Featureset brauchen werde. Bidirektionale Kommunikation und Zuverlässigkeit über Leitungslängen bis ca 10-15m fallen mir eigentlich als einzige Vorraussetzungen ein... Ideen? Mal abgesehen davon, das Auto so zu lassen wie es ist ;-) Danke und Viele Grüße!
LIN Bus. Dafür brauchst Du nur einen UART. Kannst ja dein eigenes Protokoll drüber fahren und trotzdem LIN Hardware benutzen.
Oder rs485. Ist aber nur eine Hardwarespezifilation, die Software (Protokoll) musst du selber machen. Lucas N. schrieb: > und jede Peripherie die über den Bus angebunden werden soll, muss dann > ja auch CAN fähig gemacht werden. Ich fürchte die brauchst an jedem Sensor einen kleinen MC, der die Daten auf CAN oder was auch immer durchreicht.
Sorry ich hab grad nochmal deinen Einführungstext gelesen... Ich denke nicht das du damit auf die Strasse darfst und iwelche Zulassungen bekommst.
Lucas N. schrieb: > ich möchte meinen alten Skoda BJ 85 mit etwas Elektronik ausrüsten. Also vermutich so einer: https://de.wikipedia.org/wiki/%C5%A0koda_742 Baujahr 85 ist jetzt ein Oldtimer. Warum will man da an der Elektrik rumbasteln? > einen DHT22 Sensor ... dranhängen kann > Da würde sich so etwas wie CAN Bus ja anbieten Nein. CAN-Bus ist ein Bus zur Kommunikation von mehreren Steuergeräten untereinander, nicht für einzelne Sensoren. Erwähnt wurde schon LIN, ist aber auch ein Bus für langsame Steuergeräte. Einzelne Sensoren im Automotive-Bereich verwenden SENT oder PWM-kodierte Protokolle. Und wie soll dann die Verbindung zur originalen Fahrzeugelektrik aussehen? Insgesamt halte ich das Vorhaben für Unsinn.
Hallo! Danke für die Tipps! RS485 gefällt mir schon mal sehr gut, da baut auch DMX drauf auf, mit dem ich schon mal zu tun hatte. Thomas F. schrieb: > Also vermutich so einer: > https://de.wikipedia.org/wiki/%C5%A0koda_742 > > Baujahr 85 ist jetzt ein Oldtimer. Warum will man da an der Elektrik > rumbasteln? Nun ja, einfach aus Spaß an der Freude. Ich habe zwei davon und nur zu einem eine ideelle Bindung (vom Opa geerbt), den lasse ich wie er ist. Ich habe nicht vor, das Auto irreversibel zu verbasteln, d.h. Löcher in Teile bohren für die ich keinen Ersatz habe, usw. Was den Kabelbaum angeht (den ich sicher zerpflücken muss), kann es aber nur besser werden da in dem Alter die Kabel meistens ohnehin schon ausgehärtet und Reif für einen Austausch sind. So viele Kabel hat das Ding nicht, dass man es nicht mit einem Schaltplan wieder in den Originalzustand versetzen könnte. > > Einzelne Sensoren im Automotive-Bereich verwenden SENT oder PWM-kodierte > Protokolle. Wäre das dem RS485 vorzuziehen? Mir ist klar, dass ich bei RS485 wohl bei jedem Sensor etwas Elektronik brauchen werde, die lokal beim Sensor RS485 bereitstellt (z.B. einen eigenen Mikrocontroller). > > Und wie soll dann die Verbindung zur originalen Fahrzeugelektrik > aussehen? Naja, Versorgungsspannung halt, MOSFETs und Relais. Ich werde beim Kabelbaum (sofern man das bei dem Auto überhaupt so nennen kann) wohl einige Leitungen unterbrechen müssen. Über einen Stecker wo ich die Elektronik abstecken kann und alles ist wieder so wie vorher, wird sich das kaum lösen lassen. Oder was hast du gemeint? > > Insgesamt halte ich das Vorhaben für Unsinn. Mir ist schon klar, dass es sinnvolleres auf der Welt gibt. Ich will das nur aus Jux und Tollerei machen. Es ist ja nicht so, dass ich ein Auto umbaue, welches ich täglich brauche und weil ich eine alte Schüssel zwanghaft modernisieren will. Ich sehe es eher als Herausforderung und als riesen Spaß, wenn so eine alte Kiste plötzlich Dinge wie Licht/Regensensor hat und eine RFID Karte/einen RFID Tag verlangt bevor man den Motor starten kann ;-)
CAN ist kein Overkill. Man erspart sich damit sehr viel Zeit in der Softwareentwicklung, weil die Hardware den Großteil selber macht. Bei allen anderen (I2C, RS-485 usw.) muß man jeden Schrunz selber entwickeln und testen, wie Adressierung, Arbitration, Collision, Fehlererkennung, Retry usw. Soll es stabil laufen und man will darüber nicht alt und grau werden, ist CAN die erste Wahl. Ein kleines bischen Arbeit muß man bei CAN noch investieren, wenn man Pakete >8Byte übertragen will (z.B. Firmwareupdate). Die Auswahl an AVRs ist leider nicht sehr groß, z.B.: ATMEGA32M1 oder AT90CAN128.
Peter D. schrieb: > CAN ist kein Overkill. Man erspart sich damit sehr viel Zeit in > der > Softwareentwicklung, weil die Hardware den Großteil selber macht. > > Bei allen anderen (I2C, RS-485 usw.) muß man jeden Schrunz selber > entwickeln und testen, wie Adressierung, Arbitration, Collision, > Fehlererkennung, Retry usw. > > Soll es stabil laufen und man will darüber nicht alt und grau werden, > ist CAN die erste Wahl. > Ein kleines bischen Arbeit muß man bei CAN noch investieren, wenn man > Pakete >8Byte übertragen will (z.B. Firmwareupdate). > > Die Auswahl an AVRs ist leider nicht sehr groß, z.B.: ATMEGA32M1 oder > AT90CAN128. Hmm... dann werde ich mich wohl ins CAN Thema auch einlesen. Es scheint fertige Shields für den CAN Bus zu geben, da ist dann ein Microchip Mikrocontroller drauf. Wenn, dann werde ich wohl etwas nehmen wo eine Arduino Library "Infrastruktur" mit aktiven Entwicklern existiert, um nicht alleine im Wald zu stehen. Ich befürchte halt, dass die meisten "Tutorials" zu Arduino und CAN eher in die Richtung gehen, wie man auf einen bestehenden CAN Bus eines Autos zugreift (was ich ja nicht habe)...
Lucas N. schrieb: >> Einzelne Sensoren im Automotive-Bereich verwenden SENT oder PWM-kodierte >> Protokolle. > > Wäre das dem RS485 vorzuziehen? Mir ist klar, dass ich bei RS485 wohl > bei jedem Sensor etwas Elektronik brauchen werde Busse wie CAN und RS485 verbinden Steuergeräte miteinander, nicht Sensoren. Sensoren, auch mehrere, sind an Steuergeräte angeschlossen. Das Datenformat eines Sensors ist vom Hersteller des Sensors vorgegeben. Zwischen den Steuergeräten kannst du dir dann einen eigenen Bus ausdenken. Wie viele Steuergeräte wolltest du denn so im Fahrzeug unterbringen? > ...MOSFETs und Relais Das meinte ich. Irgendwie soll dein neues Steuergerät auch mit der alten Fahrzeugelektrik interagieren können. Wie Peter schon schrieb: Nimm CAN. Da ist das Protokoll schon fest implementiert, bei RS485 musst du alles selber machen.
:
Bearbeitet durch User
Lucas N. schrieb: > Ich befürchte halt, dass die meisten "Tutorials" zu Arduino und CAN eher > in die Richtung gehen, wie man auf einen bestehenden CAN Bus eines Autos > zugreift (was ich ja nicht habe)... Vergiss bestehende Busse in Autos. Alle die dort lauschen sehen nur eine endlose Folge von Bits und Bytes, können aber damit nichts anfangen da sie diese nicht entschlüsseln können. Für deinen Bus musst du dir deine eigene CAN-Datenbasis zusammen bauen. (Mit Stift, Papier und Gehirnschmalz - weniger irgendwelche zwielichten Tuts mit Halbwissen)
Thomas F. schrieb: > Busse wie CAN und RS485 verbinden Steuergeräte miteinander, nicht > Sensoren. > Sensoren, auch mehrere, sind an Steuergeräte angeschlossen. > Das Datenformat eines Sensors ist vom Hersteller des Sensors vorgegeben. Dessen bin ich mir mittlerweile auch schon bewusst geworden. Eigentlich war mir das schon klar, als die Rede von CAN und RS485 war. Ich habe dann halt die Kombination aus Sensor(en) + Mikrocontroller für CAN oder RS485 noch immer nur als "Sensor" bezeichnet da es in der Gesamtsicht ja nur Peripherie für den "zentralen" Atmega ist, wo alles zusammenläuft und ausgewertet wird, auch wenn es sich eigentlich schon um ein Steuergerät mit angehängtem Sensor (über I2C, onewire, SPI) handelt. > Zwischen den Steuergeräten kannst du dir dann einen eigenen Bus > ausdenken. > Wie viele Steuergeräte wolltest du denn so im Fahrzeug unterbringen? so viele wie notwendig und so wenige wie möglich - so weit bin ich noch nicht bei meinen Überlegungen ;-) aber um mal irgendeine Hausnummer zu nennen, werden es wohl weniger als 10 sein, kann mir nicht vorstellen dass es mehr wird. Hängt immer davon ab, ob mir die Pins auf den Atmegas ausgehen oder ob die Kabellängen zu hoch sind. >> ...MOSFETs und Relais > > Das meinte ich. Irgendwie soll dein neues Steuergerät auch mit der alten > Fahrzeugelektrik interagieren können. ja klar, motorstartfreigabe, lichter, usw. müssten über MOSFETs gehen, da der Starter in weiterer folge sowieso auch jetzt schon über ein Relais betrieben wird. D.h. der Startstrom geht sowieso nicht über meinen Teil der Elektrik/Elektronik (sonst würden die MOSFETS wohl rot glühen binnen kürzester Zeit). Bei z.B. den Scheinwerfern muss ich mir noch überlegen ob ich das über MOSFETs oder über Relais lösen will. Da ist einerseits das Hitzeproblem und andererseits die Zuverlässigkeit (die mit der Hitze einhergeht). Soll ja nicht das Licht ständig ausfallen wegen durchgeschmorter MOSFETs. Muss ich mir noch durchrechnen. > Wie Peter schon schrieb: Nimm CAN. Da ist das Protokoll schon fest > implementiert, bei RS485 musst du alles selber machen. Gut, werde mir CAN auf jeden Fall genau ansehen. Prinzipiell hab ich nichts dagegen, alles selber zu machen - aber so eine hardwired CAN Implementierung hat schon was im Vergleich zu einem in Software gelösten Protokoll ;-)
Wieso eigentlich nicht Arduino und CAN? https://www.cooking-hacks.com/documentation/tutorials/can-bus-module-shield-tutorial-for-arduino-raspberry-pi-intel-galileo/
Thomas F. schrieb: > Lucas N. schrieb: >> Ich befürchte halt, dass die meisten "Tutorials" zu Arduino und CAN eher >> in die Richtung gehen, wie man auf einen bestehenden CAN Bus eines Autos >> zugreift (was ich ja nicht habe)... > > Vergiss bestehende Busse in Autos. Alle die dort lauschen sehen nur eine > endlose Folge von Bits und Bytes, können aber damit nichts anfangen da > sie diese nicht entschlüsseln können. > > Für deinen Bus musst du dir deine eigene CAN-Datenbasis zusammen bauen. > (Mit Stift, Papier und Gehirnschmalz - weniger irgendwelche zwielichten > Tuts mit Halbwissen) Ich lerne halt sehr gut, indem ich mir fertige Projekte anschaue und da dann quasi reverse Engineering betreibe und Schritt für Schritt nachvollziehen zu versuche wie genau alles funktioniert. Zum Glück bin ich meistens in der Lage zu differenzieren und Halbwissen von Fakten zu unterscheiden. Natürlich besteht trotzdem immer die Gefahr, in die Bullshitfalle zu tappen. chris_ schrieb: > Wieso eigentlich nicht Arduino und CAN? > > https://www.cooking-hacks.com/documentation/tutori... Klingt gut, da ich mir CAN ansehen muss, wird das wohl eine valide Möglichkeit sein, danke für den Link!
chris_ schrieb: > Wieso eigentlich nicht Arduino und CAN? > > https://www.cooking-hacks.com/documentation/tutorials/can-bus-module-shield-tutorial-for-arduino-raspberry-pi-intel-galileo/ 35€ ist natürlich ne Menge. Schaltplan konnte ich keinen finden. Vermutlich ist da ein MCP2510 + MCP2551 drauf.
Peter D. schrieb: > chris_ schrieb: >> Wieso eigentlich nicht Arduino und CAN? >> >> > https://www.cooking-hacks.com/documentation/tutori... > > 35€ ist natürlich ne Menge. > Schaltplan konnte ich keinen finden. > Vermutlich ist da ein MCP2510 + MCP2551 drauf. Hab bei Ali was gefunden mit MCP2515 und TJA1050 um ~2€ pro Stück...
Die gute Nachricht: Ein 85er Skoda hat keinen can-bus. Da kann er auch nichts dran verbasteln. > Ich lerne halt sehr gut, indem ich mir fertige Projekte anschaue und da > dann quasi reverse Engineering betreibe und Schritt für Schritt > nachvollziehen zu versuche wie genau alles funktioniert. In deinem Lego-Arduino-Universum vielleicht. Das hat kaum etwas mit der realen Welt zu tun.
Lucas N. schrieb: > Dessen bin ich mir mittlerweile auch schon bewusst geworden. Eigentlich > war mir das schon klar, als die Rede von CAN und RS485 war. Ich habe > dann halt die Kombination aus Sensor(en) + Mikrocontroller für CAN oder > RS485 noch immer nur als "Sensor" bezeichnet da es in der Gesamtsicht ja > nur Peripherie für den "zentralen" Atmega ist, wo alles zusammenläuft > und ausgewertet wird, auch wenn es sich eigentlich schon um ein > Steuergerät mit angehängtem Sensor (über I2C, onewire, SPI) handelt. Dann ist dir auch bewusst, dass du mit N Sensoren-mit-angehängtem-uC-für-CAN plus deinem zentralen Atmega, schon N+1 Softwareprojekte an der Backe hast, die es dann auch noch mit einander zu integrieren gilt? Für ein erstes Projekt würde ich ohne CAN/LIN/RS-485 anfangen und den Atmega/Arduino samt Relais oder MOSFETs einfach so nah wie möglich an den Sensor verbauen.
> 35€ ist natürlich ne Menge. > Schaltplan konnte ich keinen finden. > Vermutlich ist da ein MCP2510 + MCP2551 drauf. Es geht schon auch billiger: http://www.ebay.de/itm/like/201645867463?lpid=106&chn=ps&ul_noapp=true Ich bin ein wenig von "billig" abgekommen, weil ich festgestellt habe, dass meine Zeit begrenzt ist.
Lucas N. schrieb: >> Wie Peter schon schrieb: Nimm CAN. Da ist das Protokoll schon fest >> implementiert, bei RS485 musst du alles selber machen. > Gut, werde mir CAN auf jeden Fall genau ansehen. Prinzipiell hab ich > nichts dagegen, alles selber zu machen - aber so eine hardwired CAN > Implementierung hat schon was im Vergleich zu einem in Software gelösten > Protokoll ;-) Da Du eh schon Microchip CAN-Controller und Transceiver nehmen willst und AVR jetzt auch von Microchip kommt: warum nicht einen kleinen Schritt weiter gehen: PIC18F26K80. Hat eine deutlich verbesserte Version des CAN vom 2515 eingebaut (ECAN, mehr Buffer, weniger Bugs, kein SPI-Flaschenhals), und Prozessor, Speicher und restliche Peripherie sind auch schon drin. Spart Platz, Geld, einen Quarz, nur der Transceiver bleibt extern, und das ist auch gut so. Das ist im Ernstfall das erste, was kaputtgeht, wenn zB das Buskabel beschädigt wird. Bei LIN hat Microchip auch nette 8-pinnige Companion-Chips, sowohl aus eigenem Haus also auch mit Atmel zugekauft. Da es hier ziemlich viele pinkompatible Dubletten gibt, wird die Atmel-Linie wohl langsam auslaufen. Schau Dir mal den MCP2025 an. Das ist ein 8-Pinner, der Spannungsregler und Transceiver beinhaltet und damit einen Mikrocontroller an den LIN-Bus ankoppelt. Gibts auch mit Wakeup-Funktionalität (MCP2050). Pass aber auf, denn die meisten AVRs haben keine vollständige LIN-Unterstützung im UART, d.h. der kann einige LIN-Besonderheiten nicht. Einige wenige können es, zb Attiny167. Bei den PICs können es alle mit einem EUSART, also alle PIC24/dsPIC/PIC32 und alle modernen PIC18 (mit J oder K in der Typenbezeichnung). Und: LIN ist so designed, dass die Slaves keinen Quarz brauchen, weil sie ihr Timing vom Bus bekommen. Nur der Master braucht zwingend einen Quarz. Wie gesagt: ist alles erprobte Technik, massenweise im Einsatz und funktioniert. Noch eine Sache: Du solltest höchstes Augenmerk auf die Stromversorgung und den Schutz Deiner Module legen. Das KFZ ist im Allgemeinen ein sehr widriger Ort für Elektronik. Jede(!) einzelne Leitung, die rein oder raus geht, muss gegen Überspannung geschützt sein, sonst ist Dein Zeug im Nu hinüber. Deine Schaltung muss gemäß ISO 7637-2 auf der 12V Stromversorgung Pulse von bis zu 87V und bis zu 400ms aushalten. Solche Pulse können beim Anlassen oder Abstellen des Motors durchaus auftreten. Auch negative Pulse dürfen keinen Schaden anrichten. Plus: Unterspannungsschutz - beim Anlassen kann die Bordnetzspannung auf 6V einbrechen, und Dein Gerät darf sich dadurch nicht durcheinander bringen lassen. Lies Dir das hier durch! http://www.st.com/content/ccc/resource/technical/document/application_note/1f/d7/fc/6d/2e/27/48/98/CD00181783.pdf/files/CD00181783.pdf/jcr:content/translations/en.CD00181783.pdf Dieses Thema ist noch wichtiger als die Wahl des richtigen Datenbusses, denn sonst entwickelst Du Wegwerfelektronik. Und in diesem Punkt sind alte Autos ohne Elektronik eher schlimmer als neue, die schon viel Elektronik verbaut haben und bei denen eher auf ein sauberes Bordnetz geachtet wurde. Selbstverständlich muss jede Busleitung mit einer Schutzschaltung ausgestattet sein. Bei CAN sind das TVS-Schutzdioden und eine stromkompensierte Drossel als Minimalausstattung. Summa summarum ist ganz klar, dass unmodifizierte Arduino-Module für den Betrieb im Auto nicht geeignet sind. fchk
Peter D. schrieb: > CAN ist kein Overkill. Man erspart sich damit sehr viel Zeit in der > Softwareentwicklung, weil die Hardware den Großteil selber macht. > > Bei allen anderen (I2C, RS-485 usw.) muß man jeden Schrunz selber > entwickeln und testen, wie Adressierung, Arbitration, Collision, > Fehlererkennung, Retry usw. > > Soll es stabil laufen und man will darüber nicht alt und grau werden, > ist CAN die erste Wahl. > Ein kleines bischen Arbeit muß man bei CAN noch investieren, wenn man > Pakete >8Byte übertragen will (z.B. Firmwareupdate). > > Die Auswahl an AVRs ist leider nicht sehr groß, z.B.: ATMEGA32M1 oder > AT90CAN128. Ich interessiere mich auch sehr für diese Thema! Würdest du einen kleinen Schnipsel deines Can Code einstellen? Deine genialen Codes helfen immer immens den Einstig!! Lg
Eric B. schrieb: > Dann ist dir auch bewusst, dass du mit N > Sensoren-mit-angehängtem-uC-für-CAN plus deinem zentralen Atmega, schon > N+1 Softwareprojekte an der Backe hast, die es dann auch noch mit > einander zu integrieren gilt? Ja, ist mir natürlich klar. Ich werde eine Standardfirmware für die Sensorsteuergeräte schreiben, die ich dann modular an die jeweiligen angeschlossenen Sensoren anpassen kann. Das HW Layout sollte gleich sein, damit ich da nicht 5 verschiedene "Peripherie Platinen" hab. Im Prinzip bestehen die Sensorsteuergeräte ja nur aus einem Atmega 328p (z.B.) + pin header für x mal SPI und x mal I2C oder was auch immer die sensoren brauchen + pin header für den LIN/CAN/whatever Uplink zum zentralen Steuergerät. Die Firmware muss dann nur die Daten der unterstützten Sensoren über den Bus zum zentralen Steuergerät weiterleiten. Wie das Ding konfiguriert wird (DIP switch, serial, EEPROM, direkt in der Firmware oder was auch immer) muss ich mir noch überlegen. > Für ein erstes Projekt würde ich ohne CAN/LIN/RS-485 anfangen und den > Atmega/Arduino samt Relais oder MOSFETs einfach so nah wie möglich an > den Sensor verbauen. Ich hätte ohnehin klein und modular angefangen. Ich muss halt entsprechend so programmieren, dass ich die Verbindung über CAN/LIN/... nachträglich einpflegen kann, ohne alles neu schreiben zu müssen. Sollte sich mit Helperfunktionen ja bewerkstelligen lassen. chris_ schrieb: >> 35€ ist natürlich ne Menge. >> Schaltplan konnte ich keinen finden. >> Vermutlich ist da ein MCP2510 + MCP2551 drauf. > > Es geht schon auch billiger: > Ebay-Artikel Nr. 201645867463 > > Ich bin ein wenig von "billig" abgekommen, weil ich festgestellt habe, > dass meine Zeit begrenzt ist. Sowas hab ich bei Aliexpress bestellt. Grundsätzlich hast du schon recht mit deiner Einstellung bezüglich "billig". Frank K. schrieb: > Da Du eh schon Microchip CAN-Controller und Transceiver nehmen willst > und AVR jetzt auch von Microchip kommt: warum nicht einen kleinen > Schritt weiter gehen: PIC18F26K80. Hat eine deutlich verbesserte Version > des CAN vom 2515 eingebaut (ECAN, mehr Buffer, weniger Bugs, kein > SPI-Flaschenhals), und Prozessor, Speicher und restliche Peripherie sind > auch schon drin. Spart Platz, Geld, einen Quarz, nur der Transceiver > bleibt extern, und das ist auch gut so. Das ist im Ernstfall das erste, > was kaputtgeht, wenn zB das Buskabel beschädigt wird. sehe ich das richtig, dass dieser PIC den ganzen Arduino Rödel/Atmega 328p (bzw. welchen auch immer ich nehme) ablöst, oder ging es dir hier rein um die CAN Realisierung? Falls ersteres Zutrifft, muss ich dem leider (noch) eine Absage erteilen da ich noch keinerlei Ahnung von den Microchip Mikrocontrollern habe. Ich hab das am Fahrplan, aber zuerst möchte ich den Atmega zu 100% verstanden und auch mal was in Assembler programmiert haben, um da mal genau zu sehen was die ganzen "Lego" Libraries eigentlich alles machen. Vorher kommt noch der Schritt, die ganzen Basisfunktionen die mit Arduino mitkommen (digitalwrite z.B.) genau zu durchleuchten. Da geschehen ja im Hintergrund 100 Sachen damit das deppensicher funktioniert, die man nicht immer braucht (kostet ja Flashspeicher und Rechenzeit). > Bei LIN hat Microchip auch nette 8-pinnige Companion-Chips, sowohl aus > eigenem Haus also auch mit Atmel zugekauft. Da es hier ziemlich viele > pinkompatible Dubletten gibt, wird die Atmel-Linie wohl langsam > auslaufen. Habe mir den LIN Bus bis gerade eben noch überhaupt nicht angesehen. Welche Vorteile hat er gegenüber dem CAN Bus, abgesehen davon, dass die ICs vermutlich billiger sein werden? Ist die Schaltung auf Sensorseite auch weniger komplex? > Schau Dir mal den MCP2025 an. Das ist ein 8-Pinner, der Spannungsregler > und Transceiver beinhaltet und damit einen Mikrocontroller an den > LIN-Bus ankoppelt. Gibts auch mit Wakeup-Funktionalität (MCP2050). Pass > aber auf, denn die meisten AVRs haben keine vollständige > LIN-Unterstützung im UART, d.h. der kann einige LIN-Besonderheiten > nicht. Einige wenige können es, zb Attiny167. Bei den PICs können es > alle mit einem EUSART, also alle PIC24/dsPIC/PIC32 und alle modernen > PIC18 (mit J oder K in der Typenbezeichnung). Und: LIN ist so designed, > dass die Slaves keinen Quarz brauchen, weil sie ihr Timing vom Bus > bekommen. Nur der Master braucht zwingend einen Quarz. Mir wäre LIN bei den Atmegas vom Arduino UNO und Mega noch nie untergekommen - muss ich mal schauen. Das zentrale "Steuergerät" muss auf jeden Fall auf einem Atmega 328p oder 2560 basieren (oder ähnlichen, die mit der Arduino IDE/vMicro gefüttert werden können), da ich derzeit nur damit umgehen kann. > Wie gesagt: ist alles erprobte Technik, massenweise im Einsatz und > funktioniert. Das motiviert! > Noch eine Sache: Du solltest höchstes Augenmerk auf die Stromversorgung > und den Schutz Deiner Module legen. Das KFZ ist im Allgemeinen ein sehr > widriger Ort für Elektronik. Jede(!) einzelne Leitung, die rein oder > raus geht, muss gegen Überspannung geschützt sein, sonst ist Dein Zeug > im Nu hinüber. Deine Schaltung muss gemäß ISO 7637-2 auf der 12V > Stromversorgung Pulse von bis zu 87V und bis zu 400ms aushalten. Solche > Pulse können beim Anlassen oder Abstellen des Motors durchaus auftreten. > Auch negative Pulse dürfen keinen Schaden anrichten. Plus: > Unterspannungsschutz - beim Anlassen kann die Bordnetzspannung auf 6V > einbrechen, und Dein Gerät darf sich dadurch nicht durcheinander bringen > lassen. > > Lies Dir das hier durch! > http://www.st.com/content/ccc/resource/technical/d... > > Dieses Thema ist noch wichtiger als die Wahl des richtigen Datenbusses, > denn sonst entwickelst Du Wegwerfelektronik. Und in diesem Punkt sind > alte Autos ohne Elektronik eher schlimmer als neue, die schon viel > Elektronik verbaut haben und bei denen eher auf ein sauberes Bordnetz > geachtet wurde. > > Selbstverständlich muss jede Busleitung mit einer Schutzschaltung > ausgestattet sein. Bei CAN sind das TVS-Schutzdioden und eine > stromkompensierte Drossel als Minimalausstattung. Vielen Dank für diese äußerst wertvollen Inputs! Ich werde das beherzigen und entsprechend umsetzen. Gottseidank habe ich auch einen Wissenden der mir direkt bei der Planung und Umsetzung helfen kann, denn viel steiler kann die eigene Lernkurve nicht mehr werden ;-) > Summa summarum ist ganz klar, dass unmodifizierte Arduino-Module für den > Betrieb im Auto nicht geeignet sind. Hatte ich auch nicht vor, nur fürs Prototyping. Möglich, dass das Eingangs anders rübergekommen ist. Ich werde eigene Platinen entwerfen und ätzen (lassen).
:
Bearbeitet durch User
Lucas N. schrieb: > Frank K. schrieb: >> Da Du eh schon Microchip CAN-Controller und Transceiver nehmen willst >> und AVR jetzt auch von Microchip kommt: warum nicht einen kleinen >> Schritt weiter gehen: PIC18F26K80. Hat eine deutlich verbesserte Version >> des CAN vom 2515 eingebaut (ECAN, mehr Buffer, weniger Bugs, kein >> SPI-Flaschenhals), und Prozessor, Speicher und restliche Peripherie sind >> auch schon drin. Spart Platz, Geld, einen Quarz, nur der Transceiver >> bleibt extern, und das ist auch gut so. Das ist im Ernstfall das erste, >> was kaputtgeht, wenn zB das Buskabel beschädigt wird. > > sehe ich das richtig, dass dieser PIC den ganzen Arduino Rödel/Atmega > 328p (bzw. welchen auch immer ich nehme) ablöst, oder ging es dir hier > rein um die CAN Realisierung? ersteres. Arduino wirst Du eh nicht nehmen können. > Falls ersteres Zutrifft, muss ich dem leider (noch) eine Absage erteilen > da ich noch keinerlei Ahnung von den Microchip Mikrocontrollern habe. > Ich hab das am Fahrplan, aber zuerst möchte ich den Atmega zu 100% > verstanden und auch mal was in Assembler programmiert haben, um da mal > genau zu sehen was die ganzen "Lego" Libraries eigentlich alles machen. Vergiss Assembler. Nimm C. > Vorher kommt noch der Schritt, die ganzen Basisfunktionen die mit > Arduino mitkommen (digitalwrite z.B.) genau zu durchleuchten. Da > geschehen ja im Hintergrund 100 Sachen damit das deppensicher > funktioniert, die man nicht immer braucht (kostet ja Flashspeicher und > Rechenzeit). Dann nimm wenigstens einen Teensy 3.1 oder ARM-basierte Arduino-Derivate oder Chipkit (http://store.digilentinc.com/embedded-processors/by-technology/) oder Pinguino (http://www.pinguino.cc/). >> Bei LIN hat Microchip auch nette 8-pinnige Companion-Chips, sowohl aus >> eigenem Haus also auch mit Atmel zugekauft. Da es hier ziemlich viele >> pinkompatible Dubletten gibt, wird die Atmel-Linie wohl langsam >> auslaufen. > > Habe mir den LIN Bus bis gerade eben noch überhaupt nicht angesehen. > Welche Vorteile hat er gegenüber dem CAN Bus, abgesehen davon, dass die > ICs vermutlich billiger sein werden? Ist die Schaltung auf Sensorseite > auch weniger komplex? LIN ist auf geringe Hardware-Kosten optimiert. Deswegen kann man auf Slave-Seite auch auf einen Quarztakt verzichten, und auch auf eine Hardware-UART. >> Schau Dir mal den MCP2025 an. Das ist ein 8-Pinner, der Spannungsregler >> und Transceiver beinhaltet und damit einen Mikrocontroller an den >> LIN-Bus ankoppelt. Gibts auch mit Wakeup-Funktionalität (MCP2050). Pass >> aber auf, denn die meisten AVRs haben keine vollständige >> LIN-Unterstützung im UART, d.h. der kann einige LIN-Besonderheiten >> nicht. Einige wenige können es, zb Attiny167. Bei den PICs können es >> alle mit einem EUSART, also alle PIC24/dsPIC/PIC32 und alle modernen >> PIC18 (mit J oder K in der Typenbezeichnung). Und: LIN ist so designed, >> dass die Slaves keinen Quarz brauchen, weil sie ihr Timing vom Bus >> bekommen. Nur der Master braucht zwingend einen Quarz. > > Mir wäre LIN bei den Atmegas vom Arduino UNO und Mega noch nie > untergekommen - muss ich mal schauen. Ist auch klar - wie ich geschrieben habe, können die AVR-UARTs LIN nicht komplett. Dafür ist AVR (abgesehen von speziellen Automotive-Produkten, siehe zB den ATA6613C) ungeeignet. Es gibt aber genug Alternativen. Auch 8051-Derivate werden hier gerne genommen. > Das zentrale "Steuergerät" muss > auf jeden Fall auf einem Atmega 328p oder 2560 basieren (oder ähnlichen, > die mit der Arduino IDE/vMicro gefüttert werden können), da ich derzeit > nur damit umgehen kann. Siehe oben. fchk
Frank K. schrieb: >> sehe ich das richtig, dass dieser PIC den ganzen Arduino Rödel/Atmega >> 328p (bzw. welchen auch immer ich nehme) ablöst, oder ging es dir hier >> rein um die CAN Realisierung? > > ersteres. Arduino wirst Du eh nicht nehmen können. ähm - wieso nicht? wegen der absicherungsmaßnahmen im automotive bereich (hab das pdf noch nicht gelesen)? hab ich was verpasst, dass das jetzt mit atmegas überhaupt nicht realisierbar sein soll? >> Falls ersteres Zutrifft, muss ich dem leider (noch) eine Absage erteilen >> da ich noch keinerlei Ahnung von den Microchip Mikrocontrollern habe. >> Ich hab das am Fahrplan, aber zuerst möchte ich den Atmega zu 100% >> verstanden und auch mal was in Assembler programmiert haben, um da mal >> genau zu sehen was die ganzen "Lego" Libraries eigentlich alles machen. > > Vergiss Assembler. Nimm C. ich bin sehr wissbegierig, assembler hat mich immer schon interessiert. für das "alltägliche" programmieren nehme ich natürlich C (auch jetzt schon). >> Vorher kommt noch der Schritt, die ganzen Basisfunktionen die mit >> Arduino mitkommen (digitalwrite z.B.) genau zu durchleuchten. Da >> geschehen ja im Hintergrund 100 Sachen damit das deppensicher >> funktioniert, die man nicht immer braucht (kostet ja Flashspeicher und >> Rechenzeit). > > Dann nimm wenigstens einen Teensy 3.1 oder ARM-basierte Arduino-Derivate > oder Chipkit > (http://store.digilentinc.com/embedded-processors/b...) oder > Pinguino (http://www.pingui.no.cc/). :-O was es nicht alles gibt, hab davon noch nie gehört (pinguino, chipkit). Kommt definitiv auf meine Roadmap > LIN ist auf geringe Hardware-Kosten optimiert. Deswegen kann man auf > Slave-Seite auch auf einen Quarztakt verzichten, und auch auf eine > Hardware-UART. verstehe - danke! >> Mir wäre LIN bei den Atmegas vom Arduino UNO und Mega noch nie >> untergekommen - muss ich mal schauen. > > Ist auch klar - wie ich geschrieben habe, können die AVR-UARTs LIN nicht > komplett. Dafür ist AVR (abgesehen von speziellen Automotive-Produkten, > siehe zB den ATA6613C) ungeeignet. Es gibt aber genug Alternativen. Auch > 8051-Derivate werden hier gerne genommen. gibts da nicht genauso wie für CAN eigene ICs die die Kommunikation statt dem Atmega übernehmen?
Frank K. (fchk) >ersteres. Arduino wirst Du eh nicht nehmen können. Das verstehe ich nicht. Hie mal eines von gefühlten 1000: http://www.dx.com/de/p/can-bus-shield-expansion-board-for-arduino-blue-360165?tc=EUR&gclid=CJGnhsnMys4CFYVAGwodSQ4IZA
chris_ schrieb: > Frank K. (fchk) >>ersteres. Arduino wirst Du eh nicht nehmen können. > > Das verstehe ich nicht. > > Hie mal eines von gefühlten 1000: > http://www.dx.com/de/p/can-bus-shield-expansion-board-for-arduino-blue-360165?tc=EUR&gclid=CJGnhsnMys4CFYVAGwodSQ4IZA Sicher verstehen das Arduino Fanboys nicht. Es gibt doch für alles Shield. Also wo ist das Problem? Tja ICH werde sicher keine Mühe investieren um euch irgendwas zu erklären.
Lucas N. schrieb: [LIN] > gibts da nicht genauso wie für CAN eigene ICs die die Kommunikation > statt dem Atmega übernehmen? Braucht man nicht. Jeder UART kann LIN. Das enzige was man ggf in SW noch "bit-bangen" muss ist das Erkennen des "Break"s, der minimum 13 bit lang ist: > 2.3.1.1 Break field > The break field is used to signal the beginning of a new frame. > It is the only field that does not comply with Figure 2.4. A break > field is always generated by the master task (in the master node) > and it shall be at least 13 nominal bit times of dominant value, > followed by a break delimiter, as shown in Figure 2.5. The break > delimiter shall be at least one nominal bit time long. (http://www.cs-group.de/fileadmin/media/Documents/LIN_Specification_Package_2.2A.pdf seite 30) Da du aber eh alles selber implementierst und deshalb nicht gezwungen bist 100% LIN-konform zu sein, kannst du da locker ein bisschen mogeln: Hauptsache dass die Slaves irgendwie zu jeder Zeit den Anfang einer Nachricht detektieren können.
Lucas N. schrieb: > Frank K. schrieb: >>> sehe ich das richtig, dass dieser PIC den ganzen Arduino Rödel/Atmega >>> 328p (bzw. welchen auch immer ich nehme) ablöst, oder ging es dir hier >>> rein um die CAN Realisierung? >> >> ersteres. Arduino wirst Du eh nicht nehmen können. > > ähm - wieso nicht? wegen der absicherungsmaßnahmen im automotive bereich > (hab das pdf noch nicht gelesen)? hab ich was verpasst, dass das jetzt > mit atmegas überhaupt nicht realisierbar sein soll? Ich meine nicht die AVR-Architektur als solches, sondern die für einen Einsatz im KFZ nicht ausgelegten Arduino-Boards. Das betrifft die Schutzschaltungen, die fehlen, als auch den mechanischen Aufbau. Nebenbei: Dein Auto soll bei tiefstem Frost von -30° als auch bei glühender Hitze und 40° im Schatten (das können dann über 70° im Innenraum in praller Sonne sein) funktionieren. Stichwort "erweiterter Temperaturbereich". Für Automotive Parts im Motorraum sind das meist -40°...+125°. >> Ist auch klar - wie ich geschrieben habe, können die AVR-UARTs LIN nicht >> komplett. Dafür ist AVR (abgesehen von speziellen Automotive-Produkten, >> siehe zB den ATA6613C) ungeeignet. Es gibt aber genug Alternativen. Auch >> 8051-Derivate werden hier gerne genommen. > > gibts da nicht genauso wie für CAN eigene ICs die die Kommunikation > statt dem Atmega übernehmen? wäre zu teuer. Die Automobilindustrie nimmt eben die Controller, die das können. Das ist ein riesiger Markt, dafür gibts speziell dafür hergestellte Chips, und wer schlau ist, nimmt die auch. Auf Frickler, die nur eine einzige Architektur kennen, wird keine Rücksicht genommen. fchk
Wenn Du viel SPI Kommunikation dabei hast, koennte isoSPI auch interessant sein. Schau Dir mal den LT6820 von Linear an. Der ist fuer SPI Kommunikation in Fahrzeugen entwickelt worden.
Frank K. schrieb > ähm - wieso nicht? wegen der absicherungsmaßnahmen im automotive bereich > (hab das pdf noch nicht gelesen)? hab ich was verpasst, dass das jetzt > mit atmegas überhaupt nicht realisierbar sein soll? > > Ich meine nicht die AVR-Architektur als solches, sondern die für einen > Einsatz im KFZ nicht ausgelegten Arduino-Boards. Das betrifft die > Schutzschaltungen, die fehlen, als auch den mechanischen Aufbau. achso ja, das war mir klar. arduino nehme ich nur fürs entwickeln und für erste tests im auto, bevor och anfange zu layoutieren und ätzen. > Nebenbei: Dein Auto soll bei tiefstem Frost von -30° als auch bei > glühender Hitze und 40° im Schatten (das können dann über 70° im > Innenraum in praller Sonne sein) funktionieren. Stichwort "erweiterter > Temperaturbereich". Für Automotive Parts im Motorraum sind das meist > -40°...+125°. im winter wird das auto nicht bewegt. ansonsten ist mir klar, dass ich besonderes augenmerk auf die potentielle hitzeentwicklung im fahrzeuginneren nehmen muss. > gibts da nicht genauso wie für CAN eigene ICs die die Kommunikation > statt dem Atmega übernehmen? > > wäre zu teuer. Die Automobilindustrie nimmt eben die Controller, die das > können. Das ist ein riesiger Markt, dafür gibts speziell dafür > hergestellte Chips, und wer schlau ist, nimmt die auch. Auf Frickler, > die nur eine einzige Architektur kennen, wird keine Rücksicht genommen. alles klar. zu teuer stört mich vorerst nicht, da ich das ja nur für mich baue.
>Ich meine nicht die AVR-Architektur als solches, sondern die für einen >Einsatz im KFZ nicht ausgelegten Arduino-Boards. Das betrifft die >Schutzschaltungen, die fehlen, als auch den mechanischen Aufbau. Wenn es um ein echtes "Automotive System" geht hast Du sicherlich recht. Die Frage ist, in wie weit man diese Anforderungen an ein selbst gebautes System stellen will: http://forum.4dsystems.com.au/forum/forum-aa/tips-and-important-information/anna-s-sandbox/42911-4d-systems-as-an-automotive-multi-gauge-display
Mark W. schrieb: > Wenn Du viel SPI Kommunikation dabei hast, koennte isoSPI auch > interessant sein. Schau Dir mal den LT6820 von Linear an. Der ist fuer > SPI Kommunikation in Fahrzeugen entwickelt worden. das ist ja mal ein cooles ding, danke für den tipp!
chris_ schrieb: >>Ich meine nicht die AVR-Architektur als solches, sondern die für einen >>Einsatz im KFZ nicht ausgelegten Arduino-Boards. Das betrifft die >>Schutzschaltungen, die fehlen, als auch den mechanischen Aufbau. > > Wenn es um ein echtes "Automotive System" geht hast Du sicherlich recht. > Die Frage ist, in wie weit man diese Anforderungen an ein selbst > gebautes System stellen will: Er soll erstmal wissen, wie man es richtig macht. Mit genügend Wissen kann man dann besser entscheiden, welche Kompromisse man eingeht. @Lucas Neumann: Es dürfen eigentlich nur Dinge im KFZ verbaut werden, die ein ECE-Prüfzeichen haben. Wenn Du mit selbst gebasteltem Zeugs, das fest installiert ist, erwischt wirst, ist das Fahren ohne gültige Zulassung, denn die erlischt dann einfach. Im Tatbestandskatalog steht das mit 70€ und einem Punkt drin. Bei einem Unfall wird es noch teurer. Das ist dann zwar nicht mein Problem, aber wenn Du Sachen verbaust, sollten die wenigstens theoretisch eine E1-Nummer bekommen können. Besser ist das. fchk
Frank K. schrieb: > Er soll erstmal wissen, wie man es richtig macht. Mit genügend Wissen > kann man dann besser entscheiden, welche Kompromisse man eingeht. da bin ich schon auch dafür. > @Lucas Neumann: > > Es dürfen eigentlich nur Dinge im KFZ verbaut werden, die ein > ECE-Prüfzeichen haben. Wenn Du mit selbst gebasteltem Zeugs, das fest > installiert ist, erwischt wirst, ist das Fahren ohne gültige Zulassung, > denn die erlischt dann einfach. Im Tatbestandskatalog steht das mit 70€ > und einem Punkt drin. Bei einem Unfall wird es noch teurer. ich kann ja versuchen, das typisieren zu lassen. bei oldtimern ist man hier bei uns recht gnädig. > Das ist dann zwar nicht mein Problem, aber wenn Du Sachen verbaust, > sollten die wenigstens theoretisch eine E1-Nummer bekommen können. > Besser ist das. Ich gebe mein Bestes! "It will do" ist nicht mein Motto.
Frank K. schrieb: > Es dürfen eigentlich nur Dinge im KFZ verbaut werden, die ein > ECE-Prüfzeichen haben. Wenn Du mit selbst gebasteltem Zeugs, das fest > installiert ist, erwischt wirst, ist das Fahren ohne gültige Zulassung, > denn die erlischt dann einfach. Im Tatbestandskatalog steht das mit 70€ > und einem Punkt drin. Bei einem Unfall wird es noch teurer. Dir ist aber schon klar, das es ein Skoda aus CSSR-Produktion von 1985 ist? Wie sollte da ein E-Prüfzeichen drauf kommen? Die Feile hat kein ABS, Motor Strg etc.! Für das, was er machen will reicht LIN doch prima! Er muss ja kein LIN-Protokoll machen, denn die 0,2€ für ein Quarz wird er ja wohl haben. Ansonsten ist das doch bloss UART auf Eindraht mit 12Volt. So etwas verwende ich in meinem Garten auch als Steuerbus. Ich habe seinerzeit mal was mit LIN für einen Golf III gebaut (der immer noch jedesmal die HU bekommt, obwohl sogar Flugzeugteile reichlich verbaut sind...) siehe: http://r-ost.de/atmel/lin/lin.html Oh Mann, ein Skoda, dürfte ein S105 sein bei dem Baujahr. Haben wir damals als "böhmisch-mährische Schnellroster" tituliert... ;-) Just my 2 Cents Elux
Reiner O. schrieb: > Dir ist aber schon klar, das es ein Skoda aus CSSR-Produktion von 1985 > ist? Wie sollte da ein E-Prüfzeichen drauf kommen? > > Die Feile hat kein ABS, Motor Strg etc.! Für das, was er machen will > reicht LIN doch prima! Er muss ja kein LIN-Protokoll machen, denn die > 0,2€ für ein Quarz wird er ja wohl haben. Ansonsten ist das doch bloss > UART auf Eindraht mit 12Volt. So etwas verwende ich in meinem Garten > auch als Steuerbus. > > Oh Mann, ein Skoda, dürfte ein S105 sein bei dem Baujahr. Haben wir > damals als "böhmisch-mährische Schnellroster" tituliert... ;-) gefällt mir ;-) ist übrigens ein 120GL mit 5 Gang Getriebe ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.