Forum: Mikrocontroller und Digitale Elektronik Alternative zu Bussystemen


von Martin (Gast)


Lesenswert?

Hallo!

Ich habe vor, dass ich in nächster Zeit ein eigenes Bussystem entwickle. 
Erste Test habe ich schon durchgeführt. Hier spielt natürlich auch der 
Reiz der Erschaffung eine wichtige Rolle.
Ich bin, wenn ich ehrlich bin, vom CAN etwas abgekommen. Der C167CR von 
Infineon besitzt ein integriertes CAN-Interface. All die Register 
richtig einzustellen war ein ziemlicher Aufwand (1 Woche bis alles 
klappte). Es hat zwar alles funktioniert, aber ich will mir nicht für 
jeden Knotenpunkt einen teueren C167-Kontroller zulegen müssen oder 
einen teuren CAN-Kontroller.
Ich hab zwar gehört, dass es in der PIC-Schiene Mikroprozessoren mit 
integriertem CAN gibt, aber ich bin neben dem C167 mehr in der 
Atmel-AVR-Schiene.

Das was mir am CAN-Bus besonders gefällt ist der Umgang mit Kollisionen, 
nämlich, dass sich die dominantere Adresse durchsetzt und die 
Differenzübertragung.
Und genau da beginnt mein Problem: Die Differenzübertragung.

Ich habe mir zum Test CAN-Tranceiver-Bausteine (MCP2551) bestellt, die 
des Potential eines Ausgangspin des µCers in ein Differenzsignal 
wandeln. Das Problem bei dem Ganzen ist, dass diese Tranceiver-Bausteine 
eine Mindestfrequenz verlangen. Ich möchte mich jedoch nicht auf 
Mindestfrequenzen festlegen.

Gibt es andere Tranceiver-Bausteine ohne Mindestfrequenz z.B. im 
RS485-Sektor oder muss man sich da selbst was bauen mit OPVs und MOSFETS 
usw.

Der Bus soll für Steuerungen im Hausbereich eingesetzt werden. Es 
handelt sich hierbei um Knotenpunkte, die auf der einen Seite von der 
RS232 angesprochen werden und auf der anderen Seite mündet der 
Knotenpunkt in das Bussystem. Dabei soll man einen Knotenpunkt als 
Protokoller einsetzten können (Damit man weiß, was da so über den Bus 
schwirrt und wann und wo mal ein Fehler auftrat.). Jeder einzelne 
Knoten-Punkt soll auch über die RS232 durch einfache Befehle auf den 
Empfang verschiedener Nachrichten programmiert werden können 
(Akzeptanzfilter). Der Knotenpunkt soll mit einem Atmel-Mega8-Prozessor 
realisiert werden.

Kann mir jemand zu den Tranceiverbausteinen einen Tipp geben? Was haltet 
ihr im Allgemeinen von dieser Idee?

Tschüss!

Martin

von Michael (Gast)


Lesenswert?

Ich würde mir den Aufwand nicht machen.
In der 8051er Familie gibt es auch CAN-Varianten, so zum Beispiel die 
sehr schönen von Atmel, die auch über CAN geflasht werden können.
Ausserdem gibt es von Microchip einen CAN-Controller, der über SPI 
angeschlossen wird, also für Deinen Fall ideal wäre, wenn Du mit dem 
Atmel arbeiten willst.
Und programmiert sind die Dinger in weniger als einer Stunde.

von Martin (Gast)


Lesenswert?

Danke Michael, ich werde mir den SPI-CAN-Baustein mal anschauen.

von Bernhard Koopmeiners (Gast)


Lesenswert?

Hallo Martin,

ich habe mir einen Hausbus ( KH-Bus ) mit einem Mega8 ( 4 Euro ) und 
einem PCA82C250 ( 1,85 Euro ) aufgebaut. Damit läßt ein auf CAN-Hardware 
laufendes Multimaster-System aufbauen, dass von 1Hz - 1MHz arbeitet. Es 
hat fast alle Möglichkeiten ( über 90% ), die CAN-Basic auch hat, ist 
aber auf Aufgabe im Haus angepasst.
Kleiner Tip: So ein Bus programmiert sich nur in Assembler und läßt sich 
auch nicht in einem Monat auf die Beine stellen.
Der Mega8 hat bei mir übrigens nicht nur die Aufgabe den Bus zu 
bedienen, er erledigt auch alle Sensor- und Aktoraufgaben. Als weiteres 
stellt er auch ein Transparentmodus zur Verfügung, um einen Bustracer 
und ähnliches zu realisieren.

Bernhard

von Martin (Gast)


Lesenswert?

Hallo Bernhard!

Danke für deinen tollen Tipp. Ich hab mir jetzt so einen PCA82C250 
beschafft. Meiner hat jedoch 5€ gekostet. Wo hast du deinen her? 
Und wo bekommst du die Mega8-Prozessoren so billig her?
Erste Testmessungen wurden von mir bereits durchgeführt und es sieht 
sehr vielversprechend aus.

Ich programmiere diesen Bus jedoch in C, obwohl ich überzeugt bin, dass 
du recht hast, nämlich, dass es besser wäre, das Ganze unter Assembler 
aufzuziehen, denn in diesem Fall hat man das Maschinchen voll im Griff. 
Das Problem besteht darin, dass meine Assemblerkenntnisse sehr veraltet 
und nur auf den 8051 anzuwenden sind. Außerdem ist das Asseembler des 
Atmels wieder etwas anders. C kann ich jedoch auf fast jedem µC 
gleichermaßen einsetzten. Die Geschwindigkeit lässt jedoch ab und zu zu 
wünschen übrig. Wenn eine IRQ-Routine in C angesprungen wird, vergehen 
bei 8MHZ ca 3-4µS. Das ist hart. Natürlich werde ich das Ganze noch auf 
16MHZ aufstocken und gewisse optimierungen durchführen.
Das Wichtigste für mich war jedoch, dass das Signal perfekt generiert 
wird, d.h., dass es nie zeitliche Abweichungen gibt. Es war schon etwas 
Trickserei erforderlich.

Martin

von Bernhard Koopmeiners (Gast)


Lesenswert?

Hallo Martin,

du hast den Nagel auf den berühmten Kopf getroffen! C ist mit Abstand 
die beste Programmiersprache, wenn man MC's programmiert. Aber genau die 
Einsprungzeit ist EINES der Probleme. Um eine akzeptable Reaktionszeit 
auf Ereignisse zu erzielen, muß der Bus mit mindestens 10KHz getaktet 
werden. Daraus folgt 100us pro Bit. Also mindestens 2 Routinen ( bei mir 
arbeiten alleine für den Bus 5 Interrupts ) wollen in der Zeit 
abgearbeitet werden. Der Bus darf aber nicht mehr als 30% der Rechenzeit 
beanspruchen, damit AD-Wandler, serielle Schnittstelle, Sensoren, 
Aktoren usw. auch noch zum Zuge kommen.
Ich habe auch zwischenzeitlich mit CodeVision gearbeitet. Dieser 
Compiler ist sehr gut, aber er kann nicht annähernd so schnelle Code 
erzeugen wie ich ihn brauchte.
Eine gesunde Mischung wäre eine Alternative. Den Bus in Assembler und 
die Applikation in C.
Allerdings habe ich mich nicht getraut, da der Streit um die wertvollen 
Register zwischen mir und "Herrn CodeVision" immer in einer Niederlage 
meinerseits endete.

Bernhard

von nobody0 (Gast)


Lesenswert?

Es gibt doch viele Bussysteme wie Firewire und Netzsysteme wie Ethernet; 
wären die denn keine Alternative?

von Bernhard Koopmeiners (Gast)


Lesenswert?

@nobody,
bevor man so ein Projekt angeht muss man über Alternativen, die die Welt 
schon bietet, nachdenken. Wenn dann die Einsatzbedingungen eines Busse 
der als Hausbus arbeiten soll, analysiert werden, kommt man schnell zu 
der Erkenntniss, dass eigentlich als Hardwareplattform RS485 oder CAN 
übrig bleiben.
Ich habe seinerzeit Ethernet und CAN in der engere Wahl gehabt. Echte 
Ethernet- und CAN-Busse kosten aber viel Geld, da pro Knoten ( 6 Taster, 
12 Aktoren, 1 Heizungsthermometer, usw. ) ein Transceiver-Baustein 
eingesetzt wird. Den MC hätte ich dardurch nicht gespart, aber reichlich 
unterfordert. In meiner jetzigen Version kostet ein Sensorknoten ca. 12, 
mit Transceiver wären es schon über 20 Euro.
Ausserdem muss ich kein Protokoll-Overhead mitschleppen um kompatibel zu 
CAN oder Ethernet zu sein. Auch die Geschwindigkeit wäre völlig 
übertrieben.
Hast Du schon einmal gesehen wie klein eine Leerdose plötzlich wird, 
wenn Du eine Platine layoutest.
Letzter Punkt den Martin schon angeführt hat:
... der Reiz der Erschaffung ...

von nobody0 (Gast)


Lesenswert?

Naja, ich kenne die Chips dafür nicht genau, aber theoretisch sollte es 
leicht machbar sein Ethernet zu verwenden und die Daten an die 
Hardware-Adressen per UDP zu schicken u. zu empfangen. Bei embedded PCs 
gibt es ja meist mind. einen Ethernet-Anschluss  und es gibt ja einen 
Ethernet-Standard, bei den auch Versorgungsspannungen über die 
Ethernet-Leitung übertragen werden kann.

von Schmittchen (Gast)


Lesenswert?

@nobody0:
> theoretisch sollte es leicht machbar sein Ethernet zu verwenden [...]

Klar, bloß bezahlbar ist das dann nicht. (Großer Softwareaufwand...dicke 
Prozessoren...).

Schmittchen.

von Bernhard Koopmeiners (Gast)


Lesenswert?

@nobody0,

genau richtig. Wenn Du das alles überwunden hättest, kaufst Du Dir noch 
einen Hub oder Switch für 30 - ? Ethernetknoten. Man bedenke aber das 30 
Knoten nicht viele sind, wenn die Heizung, Rollos, Alarmanlage usw. noch 
zu den Lampen und Tastern hinzukommen. Ich habe in meinem Haus min. 200 
potentielle Sensoren und Aktoren. Übertragen auf ein PC-Netzwerk einer 
mitellgroßen Firma: Wir haben ca. 100 Rechner die im Netz hängen. 
Alleine die Kabel kosten schon mehr als mir meine Chefin ( meine Frau ) 
je genehmigen würde.

Bernhard

von Martin (Gast)


Lesenswert?

Das ist alles sehr interessant. Aber eine Frage habe ich noch zu den 
Kabeln.
Ich und Bernhard haben unser eigenes Bussystem, jedoch lassen wir unser 
Signal über einen CAN-Tranceiver, um ein Differenzsignal zu erzeugen. 
Dadurch ist die Fehleranfälligkeit minimiert, da sich Störsignale 
herauskürzen.
Aber welche Kablen sind für diesen Zweck am besten geeignet?
In diesem Fall wird man wahrscheinlich verdrillte Kabeln nehmen und an 
jedem Ende einen Endwiderstand von jeweils 120Ohm hängen.
Mein Problem dabei ist, dass ich bei jedem Punkt das Kabel 
durchschneiden muss, damit der entsprechende, neue Knoten CAN-HIGH und 
CAN-LOW abgreifen kann. Gibt es hierfür irgendwelche Steckverbindungen, 
T-Stücke oder Endwiderstände, so wie bei den BNC-Kabeln? Oder wie zieht 
man das Bussystem am besten auf, so dass es so wenig Störungen wie 
möglich gibt und das Ganze fachmännisch ist.
BNC-Kabeln wird man ja in diesem Fall nicht nehmen, da diese nicht 
verdrillt sind, sondern innen eine Ader haben und außen geschirmt sind.

Martin

von Bernhard Koopmeiners (Gast)


Lesenswert?

Hallo Martin,

Telefonkabel ist das preiswerteste "Zauberkabel". Es ist 2x2 verdrillt 
und kostet nicht viel. Einziger Haken viel Leistung läßt sich damit 
nicht übertragen.
Da man einen Hausbus tendenziell als Stern verdrahtet widerspricht es 
eigentlich der CAN-Topologie. Deshalb habe ich Versuche gefahren um 
nicht ständig die Abschlusswiderstände ändern zu müssen, wenn ein neuer 
Knoten hinzukommt. Ich schliesse jedes Ende mit 47K ab. Um die 
Gesamtlast zu erreichen, hänge ich den Rest in den Sternpunkt. Mein Test 
dazu bestand aus 4 Knoten die je vom Mittelpunkt ( dort sind übrigens 
auch meine Aktor-Module ) 180m entfernt waren. Dabei konnte ich sogar 
die äußeren Abschlusswiderstände weglassen ohne Störungen in der 
Übertragung bemerkt zu haben. Als Test haben sich die Module ein 
Datenpaket als "stille Post" zugeschoben. Nach 36 Stunden und ca. 30 
Frames pro Sekunde wurde das Datenpaket immer noch fehlerfrei 
übertragen. Einziges Problem: Mein PC, der als Tracer arbeitete, hatte 
sich verabschiedet. Gruß an Bill Gates.

Bernhard

von Michael B. (Gast)


Lesenswert?

Hallo Bernhard!

Du hast anscheinend genau das entwickelt was ich vorhabe - eine Hausbus. 
Was du bis jetzt geschrieben hast hört sich sehr gut an! Besteht die 
Möglichkeit das du den Quelltext veröffentlichst?? Oder mir/uns ein paar 
mehr Details über die Busprogrammierung gibtst??

Gruss, Michael

von Martin (Gast)


Lesenswert?

Hallo Bernhard!

Wie du das mit den Knoten behandelst und den Abschlusswiderständen ist 
einfach genial.
Ich werde in nächster Zeit zum Test mein Bussystem mit meheren 
Teilnehmern aufbauen. Die sollen sich dann kreuz und quer Datenpakete 
schicken.
Ich halte dich gerne auf dem Laufenden.

Danke für deine Hilfe.

Tschüss, Martin

von Bernhard Koopmeiners (Gast)


Lesenswert?

@Martin,
wir können ja 'mal telefonieren. Da kann man sich einfach besser 
austauschen. Sonntag ist XXL-Tag!!

meine email:
Bernhard@Koopmeiners.com

Bernhard

von Schmittchen (Gast)


Lesenswert?

Eine Möglichkeit das ständige Abändern der Abschlußwiderstände zu 
umgehen, wäre eine Linienverkabelung aber (geometrisch/topologisch) als 
Stern ausgelegt. D.h. der zentrale Sternmittelpunkt ist Anfangspunkt und 
Endpunkt zugleich, jeder Knoten führt die Datenleitungen auch wieder 
(über ein 2. Adernpaar) zurück zum Mittelpunkt. Das ergibt dann zwar 
mehrfache Kabellänge, aber bei niedrigen Datenraten ist das ja kein 
Problem.
Auch Mischungen aus Stern- und Linientopologie ist zwar nicht explizit 
erlaubt, bereitet aber keine Probleme.

Zudem hat jeder Knoten bei Sternverkabelung exklusiv die restlichen 
Adern (meist sind ja noch welche im Kabel übrig) für die 
Spannungsversorgung.

> @Martin, wir können ja 'mal telefonieren
Wie wärs im Chat? Dann können sich noch andere beteiligen.

Schmittchen.

von Bernhard Koopmeiners (Gast)


Lesenswert?

@Schmittchen,

so machen es ja Ethernet und Co. Da ich aber nur 4 Adern habe und 2 
davon zur Spannungsversorgung nutze, müßte ich schon 6 Adern nehmen, die 
aber entsprechend teurer sind. Außerdem, wie Du schon sagtest, hat man 
genau doppelt so lange Leitungen. Die Spannungsversorgung wäre auch 
schwieriger, da sich die Ströme der Module addieren. 40mA pro Modul 
kommen da leicht zusammen ohne einen Grossverbraucher, wie Relais oder 
viele LED's zu berücksichtigen. Deshalb habe ich z.B. auch die Aktoren 
in den "Mittelpunkt" gelegt. Mein Netzteil und die Relaismodule sind 
Seite an Seite im Sicherungskasten und werden somit nicht über viele 
Meter * 0,14er Leitungen versorgt.

Live in einem Chat wäre ja auch nicht schlecht! Ich weiss aber nicht wie 
und wo? Organisiere was!!

Bernhard

von Martin (Gast)


Lesenswert?

Die Idee mit dem Chat ist toll. Ich bin dabei.
Schreib uns bitte kurz wann und wo. Am besten ginge es bei mir abends 
nach der Arbeit. Meine Mail: martin.scheiblhofer@gmx.at

Tschüss

Martin

von nobody0 (Gast)


Lesenswert?

Also über die Datenadern kann man doch leicht Versorgungsstrom leiten. 
Ich habe das öfters gemacht und es ist ganz leicht: Der Versorgungsstrom 
wird über eine Drossel auf die Ader gegeben und entnommen und die Daten 
werden mit einem Kondensator eingekoppelt.
Damit kann man nur Flanken übertragen, aber die reichen ja.

von Bernhard Koopmeiners (Gast)


Lesenswert?

@nobody,
einen Bus, der seine Module über die Datenleitung mit Strom versorgt, 
habe ich schon dienstlich kennen gelernt. Ist ja auch ganz nett, aber 
wie Du schon sagtest, ist der Aufwand der Entkopplung recht groß.
Desweiteren ist die Anzahl der Clients doch arg eingeschränkt!! Wenn Du 
als Beispiel nur 10 Module mit je nur 30mA an Deinem Bus hängst, muß 
Deine Spannungsversorgung 300mA anbieten. Wie sollen Deine Treiber 
aussehen? Oder lass einmal 10 LED's blinken. Mit viel Aufwand und 
Einsatz geht das alles, aber die sich daraus ergebenden Einschränkungen 
wiedersprechen dem Einsatzgebiet.
Eines muß ich noch unbedingt loswerden:
Falls es so aussieht, als ob ich meine Idee nur verteidigen möchte, 
nein, ich bin für jeden kritische Anregung dankbar.

Bernhard

von Schmittchen (Gast)


Lesenswert?

@Bernhard:
Lies mal den aktuellen Thread: "Nachfrage IG" durch... evtl. könnte sich 
was in dieser Richtung tun.
http://www.mikrocontroller.net/forum/read-1-24077.html

Bin heute abend naja ca. ab 19.00Uhr im Chat dabei. (Ist ja alles noch 
in der Testphase usw.)

Schmittchen.

von Bernhard Koopmeiners (Gast)


Lesenswert?

@Schmittchen,

ich verstehe nur immer Chat.
Wo ist hier ein Chat?
Oder meinst Du hier das Forum?

Bernhard

von nobody0 (Gast)


Lesenswert?

@Bernhard:
Es gibt u. a. Ethernet mit Stromversorgung über die Ethernet-Leitung, 
die z. B. genutzt wird um Switche oder kleine Endgeräte zu versorgen. 
Ich kenne das nicht genau, aber vermute, dass einfach die Spannung an 
die Ader-Paare gelegt wird.

Relativ billig und einfach könnte man auch mit Optokopplern arbeiten, 
aber das Einfachste wäre starke Signale zu verwenden, die als 
Stromversorgung dienen. Mit einer Diode einfach Pulse zur 
Stromversorgung gleichzurichten und zu glätten ist sehr einfach und 
billig; man braucht dann nur sowas Bit-Stuffing zur Stromversorgung, ist 
aber zur Signalübertragung nicht auf Flanken angewiesen.

von Bernhard Koopmeiners (Gast)


Lesenswert?

@nobody,

viele Wege für zum Ziel. Hohe Ströme bedeuten aber auch große 
Querschnitte. Schon bin ich wieder bei teureren Kabeln. Realistisch hat 
ein preiswertes 4 x 0,6er Telefonkabel 0,1 Ohm/m. Wenn nun 1 Strang 200m 
lang wird, bleibt bei entsprechenden Verbrauchern nicht mehr viel übrig.
Als Stern kämpft man mit wesentlich geringeren Strömen, da nur ein 
Verbraucher die Leitung belastet. Außerdem sind die Verbindungen 5-10 
mal kürzer.

Bernhard

Bitte 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
Noch kein Account? Hier anmelden.