Bussystem für Spielereien im Auto

"Philipp Cochems" schrieb im Newsbeitrag news:d8f4g0$ls6$05$ snipped-for-privacy@news.t-online.com...

Hi Philipp,

I2C - Slave-Implementation ist eigentlich nicht ein Ding der Unmöglichkeit! Genügend Beispiele für AVRs findest Du im Web! Auch für längere Strechen kannst Du I2C verwenden, wenn Du mit der Datenrate entsprechend herunter gehst. Hardwaremäßig würde ich im Auto den RS485 verwenden, da dieser, wenn ich mich nicht irre, mit verdrillten Adern arbeitet und somit störfest ist. Ob man I2C auf RS485 aufsetzen kann, weiss ich jedoch nicht.

Gruß Steffen

"Steffen Pokel" schrieb

Unmöglichkeit!

wenn

ist.

Hmm, RS485 werde ich mir mal ansehen. Aber dein Posting bestärkt mich ja dann doch in I2C. Das Implementieren wird man denke ich hinbekommen und CAN wäre wohl sowieso schwieriger. Es geht mir dabei auch sowieso nicht um hohe Geschwindigekiten, höchstens da mal ein Fenster aufmachen, Drehzahl auslesen usw. Also sollte ein langsamer I2C es tun.

Vielen Dank schonmal Philipp

Du kannst I2C im Auto erstmal so nicht verwenden. Du muesstest dazu Bustreiber nehmen. Nun ist I2C aber bidirektional. Mit anderen Worten, unerfreulich viel Aufwand waer notwendig.

Ich wuerde die serielle Schnittstelle deiner Controller verwenden und die auf RS422 umsetzen, also 5V differenziell. Pegelwandler z.B uA9636/37/38/39. Gibt es auch bei Reichelt. :-)

Ein weiterer Vorteil ist das du an diesem Bus dann auch mit einem einfachen Pegelwandler R422/R232 mit deinem Laptop lauschen kannst wenn mal was nicht stimmt.

Olaf

"Olaf Kaluza" schrieb

Achso, ich dachte es reicht evtl. ordentlich geschirmte Kabel zu benutzen und die Leitungen nicht einfach mit dem IO Port des Controllers, sondern mit einem Transistor gegen Masse zu ziehen.

Das Problem ist doch aber dann da, wenn ich mehr als 2 Controller vernetzen möchte oder nicht? Also ich kann ja an TX vom Master alle Slave RX hängen, aber was mache ich mit den TX der Slaves? Wie verhindere ich das sie gleichzeitig auf die Leitung zugreifen? Gibt es da praktikable Lösungen?

Vielen Dank Philipp

Nicht wirklich.

Das ist vornehmste Aufgabe deiner Software. :-) Waere es aber bei I2C auch.

Olaf

Philipp Cochems schrieb:

Hallo,

I2C im Auto ist so eine Sache. Der Bus ist entwickelt worden, um mehrere IC's auf einer Platine zu verbinden, bzw um kurzr Strecken zu überbrücken. Der I2C Bus ist relativ anfällig gegen Störungen. Das müsstest Du dann mit der Software wieder rausfiltern. Es gibt allerdings von Phillips, wenn ich mich richtig erinnere einen Bustreiber für I2C, mit dem man grössere Strecken überbrücken kann.

Eine andere Lösung wäre wirklich der CAN-Bus. Dazu gibt es von z.B. von Atmel einen speziellen Controller den AT90CAN128.

Florian

Hallo Philipp,

| ich bin noch auf der Suche nach einem guten und günstigem Bus System für | diverse Spielereien im Auto. Sicherlich wäre ein CAN Bus dafür sehr

google mal nach dem Stichwort "LIN". Das soll der kleine Bruder des CAN sein, fürs Auto entwickelt genau dort, wo es nicht sicherheitskritisch und mit kleinen Datenraten zugeht, also billig sein soll. Hab ich allerdings auch nur theoretisch und nicht als praktisches Wissen ;-)

MArtin

Hallo!

Hat drei Leitungen GND, +12V und Signal. Max. Übertragungsrate 19,2 KBit. Transceiver ist z.B. ATA6661, aber keine Ahnung, wo man den bekommt. Lässt sich aber direkt an den UART von nem AVR anstöpseln und das ganze Proktokoll kann man bequem in Software erledigen. Laut LIN Spec (kann man ergoogeln) hat das System einen Master, welcher zyklisch (oder halt so, wie ers für richtig hält) die einzelnen Slaves auffordert ihre Daten zu senden und die anderen Slaves hören dann mit. Message ID's sind (glaub ich mich zu erinnern) wie bei CAN Nachrichten IDs und keine Sender/Empfänger IDs..

Michael

CAN Transceiver zu teuer? Hallo? Selbst bei Reichelt kostet ein 82c250 nur

1.40, und der MCP2515 (CAN via SPI) ist für 1.95 zu haben. Ein 90CAN128 kostet etwa 10 Euro und ist schon was feines.

Die 90S1200 und 90S2313 würde ich nicht mehr einsetzen. Die neuen ATmegas und ATtinys sind wesentlich störfester, was im Auto nicht unwesentlich ist. Für die paar Euros, die die Controller kosten, würde ich mich nicht mehr mit subtilen Abstürzen abplagen wollen. Wenn Du noch 20 Stangen auf Lager hast, wär das was anderes, aber bei Dir sinds ja alles nur Einzelstücke.

Bei den PICs gibts auch welche mit CAN onchip. Das liegt auch alles so in der Größenordnung von einigen Euro.

Und CAN funktioniert.

Mit freundlichen Grüßen

Frank-Christian Krügel

Nimm RS485 mit Twistet-Pair-Kabeln (wegen der störresistenz) und benutze einen Transceiver (für kleine Baudraten gibts die für echt wenig Geld). Die Transceiver haben weist einen Transmit-Enable-Eingang auf der TTL-Seite, diesen schließt Du an einen IO-Pin Deines bevorzugten Controllers und verbindest die TTL-TX/RX mit den TX/RX-Pins einer UART von Deinem Controller. Empfangen kannst Du dann immer, zum senden musst Du den Transceiver mit den TE-Signal umschalten. Dabei empfängt die UART aber auch die gesendeten Daten (zumindest bei den meisten Transceiver-Chips). Bei kleinen Baudraten ist die Topologie völlig egal, selbst größere Abzweigungen sind möglich. Nur die Gesamt-Teilnehmer-Anzahl ist beschränkt (siehe Datenblatt des verwendeten Transceivers). Der große Vorteil ist das Du einen zusätzlichen Teilnehmer einfach so an beliebiger Stelle "draufklemmen" kannst. Mit einem Transceiver-Chip (Transmiter auf dauer disabled) und einem MAX232 kann sogar Dein PC über eine RS232-Schnittstelle mithören. Es gibt verschiedene COM-Monitore zum mitprotokollieren für die RS232-Schnittstelle, sowas könnte Dir beim entwickeln echt helfen.

Wenn Du mehr als einen Master benötigst musst Du Kollisionserkennung (wie bei Ethernet) implementieren, ist nicht ganz so einfach aber möglich. Wenn Du mit einem Master, der die Clients regelmäßig abfragt, auskommst ist das viel leichter.

Wir benutzen sowas zur Gebäudeatomation und sind damit sehr zufrieden. Die Gebäude sind dabei wohl wesentlich größer als Dein Auto und die Topologie ist teilweise ein echtes Chaos, trotzdem benutzen wir mit Erfolg 4800 Baud und Multimaster mit Kollisionserkennung.

Grüße Erik

Denau deswegen verwende ich CAN. Die Controller machen sehr viel selber in Hardware, so daß man selber relativ wenig selber programmieren muß. Wenn der Controller einem sagt "Paket erfolgreich gesendet", dann weißt Du, daß das Paket bei allen Busteilnehmern heil angekommen ist. Bei RS485 weißt Du das so erstmal nicht, hier mußt Du selber ein geeignetes Protokoll bauen. Der größte Aufwand liegt in der Konfiguration der Controller selber (Bittiming) und in der sinnvollen Verteilung der Adressen. Und da die Chips in Massen verbaut werden, halten sich auch die Kosten in Grenzen.

Mit freundlichen Grüßen

Frank-Christian Krügel

Philipp Cochems schrieb:

Nimm doch gleich CAN, dann kannst Du nebenbei noch wertvolle Erfahrungen sammeln. ;-)

cu,

Aguja

=>

=> AVR-, PIC- und 8252-Programmer, Apps and more

Frank-Christian Kruegel schrieb:

IMO weist Du nur, dass das Paket bei mindestens einem Teilnehmer richtig angekommen ist, weil nur ein Empfänger ein Ack senden muss.

Die Registerinhalte muss man aber nicht umbedingt selbst zusammensuchen: siehe z.B.

mfg Helmut Neemann

... und irgendwie hätte ich ein total mieses Gefühl, das LWL-Kabel auch in die Türe zu verlegen (dorthin wo der Fensterheber sitzt) ich weiss nicht, ob es das Tür-auf-tür-zu recht lange mitmachen würde.

Ich würde RS485 nehmen. Differentiell, Datenstruktur wie RS232, nur halt alles an einem Strang. Vom Konzept her ein Multi-Master-System. Die Implementierung (busy lockout, Adressierung, ...) ist sowieso eine reine Softwaresache. Und einen RS232-RS485 Treiber-Chip gibt auch um Peanuts.

Heinz

Martin Schönegg schrieb:

Atmel hat auch Appnotes: AVR054 AVR308

Evtl. wäre auch

interessant.

Gruß Gunther

Frank-Christian Kruegel schrieb:

Die CAN-Controller die ich bis jetzt programmiert hab waren auch nicht so ganz ohne Programmieraufwand. Der große Vorteil einer eigenen RS485 Verkabelung ist aber das man einen neuen Teilnehmer einfach so an beliebiger Stelle drauf klemmen kann. Außerdem gibt es für CAN zwar sehr leistungsfähige Analyseprogramme für PC aber auch zu Preisen das einem schlecht wird (zuzüglich einer geeigneten PC-CAN-Karte). Wenn man was selber programmiert reicht eine RS232-Monitor-Freeware-Version zum nachprüfen meist völlig aus. Außerdem ist die Bit-Codierung vom CAN etwas komplexer (natürlich auch besser und weniger Störanfällig) und mit nem preiswertem OSZI nicht so einfach nachzuprüfen. Ein einfaches UART in '8P1'-Konfiguration kann man am Speicher-OSZI schon recht gut nachprüfen.

Also das halte ich für etwas übertrieben, so toll ist CAN nun auch wieder nicht.

Vielleicht möchte der OP ja hier etwas Ehrgeiz rein stecken. Außerdem gibts auch hierbei sehr primitive Varianten. Die Einstiegskomplexität von CAN ist eben doch etwas höher.

Also wenn man keine gute Möglichkeit hat das Gelernte später mal (beruflich) zu nutzen ist das sinnlos verschenkte Zeit.

Wirklich teuer wird die Hardware für die Ansprüche des OP wohl eh nicht werden. Er will wohl seine vorhandenen (eingeübten) Controller verwenden und sich auf sein eigentliches Problem konzentrieren.

Grüße Erik

"Erik Groß" schrieb

Ja, genau so dachte ich. Vielen Dank erstmal an alle die sich hier an dem Thread beteiligt haben. Habe sehr viele Anregungen bekommen und werde einiges mal weiter verfolgen. Mal sehen was es am Ende wird.

Grüße Philipp

Hallo,

Wie jetzt - 'Transceiver zu teuer' ??? Wieviele hundert knoten willst du denn ins Auto bauen ??? So ein TJA1054 kostet bei Farnell 3,68 EUR - und gibt es bestimmt noch deutlich billiger ..