mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik CAN Bus Alternative für Arduino


Autor: L. N. (derneumann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: marty mcfly (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
LIN Bus. Dafür brauchst Du nur einen UART. Kannst ja dein eigenes 
Protokoll drüber fahren und trotzdem LIN Hardware benutzen.

Autor: Baendiger (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Baendiger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso und nie am CAN oder LIN des Fahrzeugs rumspielen!

Autor: Baendiger (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Sorry ich hab grad nochmal deinen Einführungstext gelesen... Ich denke 
nicht das du damit auf die Strasse darfst und iwelche Zulassungen 
bekommst.

Autor: Thomas Forster (igel)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: L. N. (derneumann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: L. N. (derneumann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)...

Autor: Thomas Forster (igel)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Thomas Forster (igel)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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)

Autor: L. N. (derneumann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: chris_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso eigentlich nicht Arduino und CAN?

https://www.cooking-hacks.com/documentation/tutori...

Autor: L. N. (derneumann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Peter Dannegger (peda)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: L. N. (derneumann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: ./. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Eric B. (beric)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: chris_ (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> 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.

Autor: Frank K. (fchk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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/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.

Summa summarum ist ganz klar, dass unmodifizierte Arduino-Module für den 
Betrieb im Auto nicht geeignet sind.

fchk

Autor: undef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: L. N. (derneumann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Frank K. (fchk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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/b...) 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

Autor: L. N. (derneumann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: chris_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-bo...

Autor: Cyblord ---- (cyblord)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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-bo...

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.

Autor: Eric B. (beric)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/L...
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.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mark W. (kram) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: L. N. (derneumann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: chris_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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-...

Autor: L. N. (derneumann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: L. N. (derneumann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Reiner O. (elux)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: L. N. (derneumann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

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.