bussystem mit avr

Oliver Joa schrieb:

aar

Hallo,

Frequenz auf dem Bus kleiner als 100 kHz sein.

Wenn es aber betriebssicher sein soll, dann mache die Stichleitungen nur

maximal 5 cm lang und schliesse den Bus an beiden Enden mit Wellenwiderstand ab.

Bye

Dafür gibts den 90CAN128, der gleich einen CAN-Controller enthält und ganz gut funktioniert. Du brauchst dann nur noch einen Transceiver wie z.B. Philips PCA82C250 o.ä.

Mit freundlichen Grüßen

Frank-Christian Krügel

Das sieht sehr nach smd-Technik aus, womit ich noch keine Erfahrung habe. Und guenstig ist der auch nicht. Alternativen?

Danke

Olli

Heisst das, dass ich meine jetzigen Probleme auch nur wegen den Stichleitungen habe?

Olli

"auch nur" möglicherweise nicht. Allerdings ist ein Bus ohne korrekte Terminierung an beiden Enden und mit Stichleitungen bei hinreichender Länge immer problembehaftet. Mir fällt momentan nur ISDN ein, das Stichleitungen bis 1m erlaubt, ansonsten sind sie bei allen Bussen - egal ob CAN, Ethernet, oder wasauchimmer verboten.

Mit freundlichen Grüßen

Frank-Christian Krügel

Es gibt von Microchip den 2515, einen Can-Bus Controller mit SPI-Interface. Ist dadurch bedingt aber umständlicher zu programmieren als der 90CAN128. Oder Du hängst einen SJA1000 an einen großen AVR mit externem Businterface (d.h ab Mega 64, der das gleiche Gehäuse wie der 90CAN128 hat, so daß Dir auch nicht geholfen ist). Viel billiger wirds da auch nicht.

Oder Du nimmst einen PIC 18F458. Den gibts auch als PDIP, und der hat CAN schon drin. PICs sind aber nicht so schön zu programmieren wie AVRs. Du solltest unbedingt einen ICD2 Debugger/Programmer haben, um vernünftig arbeiten zu können.

Den externen Transceiver brauchst Du bei jedem Controller.

Mit freundlichen Grüßen

Frank-Christian Krügel

Wenn es wirklich nur um die Übertragung der Messwerte geht und darum, mal einem Computer einen Einschaltbefehl zu senden, könnte man sich Gedanken darüber machen, wie oft die Messungen geupdated werden sollen. Wenn es um die Messung von Raum- oder Außentemperaturen geht, so werden sich diese innerhalb von 10 Sekunden kaum gravierend ändern. Wenn also alle 10 Sekunden nur ein Satz Messungen übertragen wird, so könnte man den I2C Bus doch auf ein paar hundert Hz verlangsamen. Im der I2C Empfangsfirmware müsste dann auch ein Filter programmiert sein, der nur entsprechend langsame Impulse durchlässt und etwa wie eine Tastenentprellsoftware funktioniert:

Man baut einen Zähler, der von 0 bis 15 zählt. Dieser Zähler hat oben und unten einen Anschlag, über den er nicht hinauszählen kann. Das I2C-Eingangssignal wird periodisch mit einer Frequenz 64 mal so groß wie die des I2C Bus (am besten über einen timergesteuerten Interrupt) gescannt. Ist der Eingang "0", zählt der Zähler runter. Ist er "1", zählt der Zähler rauf. Erreicht der Zähler die 15, wird der Filterausgang auf "1" gesetzt. Erreicht er die Null, wird der Filterausgang auf "0" gesetzt. Man rechnet 16 Zählerschritte * 1/64 =

Außerdem muss bei der Implemetirung der I2C Firmware dauf geachtet werden, dass die Antwortzeiten dem langsamen Bustakt angemessen sind. Mit dieser Busgeschwindigkeit und dem Filter sollte selbst ein "Verhau" von Busleitungen kein Problem mehr sein.

Wenn allerdings Deine Fernsteuerung dazukommt, ist das Konzept am Ende und CAN, wie Du schon sagtest, eine gute Lösung. Es gibt von Microchip Controller mit eingebautem CAN aber auch Stand-alone-CAN-Controller, die als Peripherie an deinen ATMEL angeschlossen werden können. Bei Microchip gibt es viele Applikationsschriften zum CAN Bus. Die zusammenfassende Übersichtsseite hierzu findest Du hier:

Oliver Joa schrieb:

Du solltest wenigstens schreiben, wie groß die gesamte Ausdehnung des Busses ist und welche Datenraten Du brauchst.

Die "Implementierung" von CAN machst Du auch nicht selbst, die ist im uC oder im CAN-Controller und im Transceiver.

Du implementierst das über CAN abgewickelte Protokoll. Muß ja nicht gerade CANopen sein, obwohl das auch nicht so schlimm ist und eine gute Investition (z.B. wegen der Organisation der Daten im Object Dictionary).

Betreffend der Empfehlung von Erik und Falk: RS485 ist m.E. eine Fehlkonstruktion, weil man ihn "vorspannen" muß, um im passiven Zustand einen definierten Pegel zu erhalten. Weshalb dann überhaupt noch aktiv in die gleiche Richtung treiben? CAN ist in der Hinsicht viel ehrlicher.

Servus

Oliver

Oliver Betz schrieb:

Dem kann ich wirklich nicht widersprechen, ist aber in kleinen Bussen kein allzu schlimmes Problem. Das "Augendiagram" sieht dann nicht mehr ganz so schön aus, eben stark asymmetrisch. Für ein ordentliches Design nimmt man besser Empfänger mit 2 Schaltschwellen so das zwischen den beiden aktiven Pegeln eine "verbotene" Zone existiert (10MBit-Ethernet für TP-Kabel macht das auch so, soweit ich weis).

Performance, die "Vorspannwiederstände" sollten möglichst groß sein damit sie die eigentliche Datenübertragung nicht zu sehr stören. Bei I2C ist die richtige Dimensionierung der Pullups auch eine knifflige Angelegenheit.

Ja, und das dominante/rezessive Gegeneinander der 2 aktiven Pegel ermöglicht kollisionsfreie Busallocationen.

Grüße Erik

"Erik S." schrieb:

vielleicht - RS485 wird ja teilweise schneller betrieben als CAN und dann könnten parasitäre Kapazitäten das Signal verzerren. Ob das relevant ist, weiß ich nicht.

Bei CAN ist der Übergang dominant->rezessiv praktisch gleich "performant" wie die umgekehrte Flanke. Das kann aber daran liegen, daß bei 1MBit/s die durch parasitäre Elemente bedingte Asymmetrie nicht so auffällt wie bei 10MBit/s.

Ich meinte den gleichen Störspannungsabstand bei allen Zuständen, da es bei CAN ja nur zwei Zustände gibt.

Bei RS485 haben die _drei_ unterschiedlichen Zustände "high", "low" und "passiv" unterschiedliche Störspannungsabstände.

Servus

Oliver

Hallo Oliver Betz,

Ich kenn einen Haus-Automatisierungs-Bus, wird von einer Firma (die ich jetzt hier nicht namentlich nenne, auch wenns mein Exarbeitgeber ist) stümperhaft entwickelt und professionell vertrieben, der mit 4800Baud (UART mit 8E1) über RS485 mit "freier" TP-Verkabelung arbeitet. Jeder Busknoten hat zwei "Terminierungswiderstände" von je 50kOhm, einer von A nach +5V und der andere von B nach GND, um den Pegel immer auf "Stopbit" zu lassen wenn niemand aktiv treibt. Die Signale sehen auf dem Oszi einfach nur Scheiße aus und ab etwa 20 Knoten oder 200m Gesamtlänge gibts Probleme. Auch die drüber liegende Protokollschicht kann daran auch nicht viel ändern, ist eben das Erstlingswerk des dortigen Entwicklers. Wer so naiv ist und so ein System für größere Einrichtungen vorsieht der fällt eben auf die Nase. Jetzt versuchen die sich an einer EIB-to-????-Bridge und wollen ihre preiswerten Module, die teilweise wirklich gute Fähigkeiten haben, als preiswerte Alternative anbieten. Es sollen damit bei einer EIB-Installation Räume, die mehrere Module brauchen, mit einer solchen Bridge und ein paar billigen Modulen ausgestattet werden. Das ist meiner Ansicht nach (die mir dann auch die Kündigung brachte) auch das höchste wo man sowas einsetzen sollte.

Für alles wo mehr gebraucht wird sollte der RS485 mit drei Pegeln und einer DC-freien Codierung benutzt werden. Natürlich ist auch eine ordentliche Bustopologie und ein vernünftiges Protokoll Pflicht wenns zuverlässig funktionieren soll. Für kleine Bastelprojekte ist das obige Konzept aber durchaus brauchbar und vor allem mit wenig Aufwand preiswert umsetzbar.

Gibt es eigentlich Differential-Receiver mit zwei Ausgängen: Ausgang H = High if Ua-Ub > +500mV Ausgang L = High if Ua-Ub < -500mV ?? Sowas könnt ich gut gebrauchen, dann müsst ich das nicht mehr mit mehreren OpAmps, Widerständen und zwei Komparatoren diskret aufbauen. Schön währ noch ein dritter Ausgang der den Zwischenraum anzeigt.

Grüße Erik

"Erik S." schrieb:

wozu denn DC-frei?

kenn ich nicht, würd ich nicht verwenden.

Servus

Oliver

Hallo Oliver Betz,

Damit man das Signal auch mal über einen Trafo vom aktuellen Potential trennen kann. Bei einer bidirektionalen Halbduplex-Verbindung ist das mit Optokopplern nicht ganz einfach, die müssten die Richtung automagisch erkennen.

Grüße Erik