CAN- als Haus-Bus

Es gibt HUB Chips für den CAN Bus, z.B. AMIS42700 von ON Semi, mit denen 
Du verschiedene CAN-Segmente designen kannst. Damit kannst Du auch eine 
Stern-Topologie verwirklichen. Aber auch hier gilt die Regel jedes 
Segment ordnugsgemäss mit einem Widerstand zu terminieren.

Es gab von Maxim, glaube ich, mal eine App. Note wie die Widerstände 
aufgeteilt werden muessen, damit du wieder 60Ohm auf dem Kabel hast, 
sprich Sterntopo. Mehr kann ich dir dazu aber auch nicht berichten, es 
soll aber "theoretisch" funktionieren.

Hmm wie löse ich denn mein Problem?

diese AMIS42700 hab ich jetzt bei keiner meiner Bezugsquellen gefunden, 
wobei mir das auch nicht ganz gefällt für quasi jeden Knoten einen 
Verteiler zu brauchen...

Es muss doch irgend einen simplen, bezahlbaren, mulimasterfähigen Bustyp 
geben den man in Baumstrukturen bringt!
Mit simpel meine ich etwas in Richtung CAN-einfachheit.
Und bezahlbar heißt unter 5€ pro Knoten...

Kann ich durch begrenzen der Baudrate da was machen? ich wüsste eh keine 
großen Datenmengen die über den Bus müssten...

Meine Erfahrungen sind nur mit Einfamilienhäusern gesammelt, aber mit 
ein paar Anpassungen von Baudrate und ein bißchen probieren mit dem 
Widerstand ging es.
Hier spricht auch ein Anwender:
http://koervernet.de/joomla1.5/index.php?option=com_content&view=article&id=47&Itemid=65

Welche Topologie hast du denn?

http://atw.huebsch.at/tipps_tricks/Terminator.htm

Also ich habe hier ein Hausbus-System in der Entwicklung, das Routing 
beherrscht, sodass du einfach mehrere Linienbusse vernetzen kannst.
So hat man wirklich von einander unabhängige Segmente, zwischen denen 
man allerdings trotzdem kommunizieren kann. Das funktioniert auch 
soweit, inklusive Bootloader.

Was mir bisher mehr Sorgen macht, ist der Stromverbrauch: Bisher bin ich 
bei ca. 100 mW pro Knoten, mit ein wenig Arbeit schaffe ich wohl auch 
noch ca. 60 mW/Knoten. Ist irgendwie immer noch viel, dafür, dass der 
Knoten eigentlich nichts tut. Dummerweise kann man den Stromsparmodus 
beim von mir eingesetzten MCP2515 nicht nutzen, weil man dann laut 
Datenblatt das Frame verliert, das ankommt während der MCP2515 schläft.

Daher ist eine Idee, eventuell "dumme" Knoten einzuführen, die kein CAN 
benutzen und schon daher weniger Strom brauchen.

Horst Hahn schrieb:
> @NochAmBasteln:
> wenn der schlafende Empfänger nicht quittiert, wird doch nochmal
> gesendet oder nicht, oder wohl, oder doch?

Eine zuverlässige Nachrichtenverteilung mit Rückmeldung hatte ich zwar 
zuerst vor, allerdings ist CAN zum einen sehr zuverlässig,
und zum anderen kann man davon ausgehen, dass jeder Knoten, den man 
ansprechen möchte, schläft. Dadurch würden die Nachrichten in jedem Fall 
doppelt versendet werden, was auch unelegant ist.
Implementiert sind beide Protokolle, aktuell wird aber das nicht 
zuverlässige genutzt.
Denn das zuverlässige erlaubt nur Punkt-zu-Punkt-Verbindungen, und das 
ist nicht genug, weil oftmals mehr als ein Knoten angesteuert werden 
muss.
Sowas wird aktuell als Broadcast auf Linienebene oder global gemacht, 
einfach und schmerzlos, aber ohne Möglichkeit, dass jeder Empfänger 
quittiert.
Das ganze sequentiell anstatt per Broadcast zu machen, wäre zwar 
möglich, aber doch sehr mühsam.

Und es wäre wohl viel eleganter, wenn der MCP2515 einen Schlafmodus 
hätte, wo der Quarz läuft und nur Teile des Chips schlafen, bis 
Aktivität auf dem Bus erkannt wird. Und dann sollte man doch wohl 
schnell genug aufwachen können. Kennt jemand zufällig einen 
Mikrocontroller oder CAN-Controller, der sowas beherrscht?
Also außer AT90CAN*, der braucht schon im IDLE-Modus mehr Strom als mein 
ATmeta644 (IDLE) + MCP2515 (aktiv) zusammen.

Markus Müller schrieb:
> Schaue mal in das Datenblatt vom STM32F103. Lasse den gemütlich mit 8MHz
> ohne PLL laufen. Alle Pheriperieeinheiten kann der Clock einzeln
> zugeschaltet werden.
> Schaue mal hier, Artikel: STM32

Das gucke ich mir mal an, sieht wirklich vielversprechend aus. Danke.
Wird wohl langsam Zeit, auch für die Hobby-Projekte auf ARM-Kerne 
umzusteigen. Nur schade, dass man dann seinen Code schwer mitnehmen kann 
auf die neue Plattform. :-(

Welche Bitrate faehrst du denn mit dem MCP? Ich hab meinen Bus auf 
20kBit am Laufen, zuerst alle Pakete einfach 3fach nacheinander gesendet 
um mit den ersten beiden die Knoten aufzuwecken (Alternativ nutzloses 
Wakeup-Paket vorwegschicken wenn die Events nicht mehrfach auftreten 
duerfen), inzwischen ist das rausgeflogen und ich sende nur einfach... 
weder die MCPs im Sleep-Mode noch der 90CAN128 im PowerDown-Mode haben 
ein Problem damit bereits das erste Paket zu empfangen, da die 
Arbitrierungsphase bei 20kBit fuer den Chip wohl gefuehlt 1 Jahr lang 
ist ;-)
Der Bus selbst ist einfach als Pseudo-Stern aufgebaut, also zu jedem 
Knoten CAN-L/H-hin und CAN-L/H-rueck, also halt 6 statt 4 Leitungen 
(incl. Versorgung).

Wenn's nicht auf die Geschwindigkeit ankommt wäre LIN velleicht noch 
eine alternative. Da es als Eindrahtbus konzipiert ist reicht 
(theoretisch) eine Leitung und Masse, wobei es sicher nicht schadet 
alles auf eine gemeinsame Masse zu ziehen.
Weiß jemand welche Kabellängen bei den typischen LIN Geschwindigkeiten 
19.2kbaud bis 2.4k möglich sind?
Kenne es nur aus dem Fahrzeug und da sind es eben nur ein paar meter bei 
19.2kbaud.

http://www.vector-elearning.com/index.php?seite=vl_einfuehrunglin_de&root=376493&wbt_ls_kapitel_id=452449&wbt_ls_seite_id=455770&d=yes