Forum: Haus & Smart Home CAN-Bus + Protokoll bereits im Chip


von der kleine Niels (Gast)


Lesenswert?

Servus,

beim Einlesen in das Thema Hausbus bin ich  auf folgende Aussage 
gestoßen:
1
 CAN-Bus
2
    + Protokoll bereits im Chip
Quelle: http://www.mikrocontroller.net/articles/Hausbus

Ganz schlau werde ich darus aber nicht. Soll das heißen, dass ich mit 
meinem uC auf der einenseite z.B. über UART mit dem Controller 
kommuniziere, der das über dan CAN-Bus überträgt und ich an anderer 
Stelle wieder von einem Controller mit wieder UART empfangen kann?
und da das Protokoll im Chip vergossen ist muss ich mir keine Gedanken 
über parity-checks oder gar freiheit des Busses machen?

oder wie ist da zu verstehen?

danke schonmal
lg
Niels

von (prx) A. K. (prx)


Lesenswert?

der kleine Niels schrieb:

> Ganz schlau werde ich darus aber nicht. Soll das heißen, dass ich mit
> meinem uC auf der einenseite z.B. über UART mit dem Controller
> kommuniziere,

Was ist bei dir der Unterschied zwischen "uC" und "Controller"? Was du 
schreibst klingt nach Selbstgespräch über UART ;-).

> der das über dan CAN-Bus überträgt und ich an anderer
> Stelle wieder von einem Controller mit wieder UART empfangen kann?

CAN hat nichts mit UART zu tun.

> und da das Protokoll im Chip vergossen ist muss ich mir keine Gedanken
> über parity-checks oder gar freiheit des Busses machen?

Korrekt.

von der kleine Niels (Gast)


Lesenswert?

Was ich fragen wollte nochmal neu formuliert.
folgendem Aufbau:
uC -(UART?)-> CAN-Transceiver -> CAN-Bus -> mehrere CAN-Transceiver 
-(UART?)-> mehrere uCs

Das soll heißen, die uCs kommunizieren nur mit ihren CAN-Transceivern 
und diese kümmern sich dann um die Verbreitung der Informationen auf dem 
gesammten Bus.
Sollten also mehrere uCs gleichzeitig senden wollen, dann fangen die 
CAN-Transceiver diesen Konflikt ab und lösen ihn ohne dass ich(uC) mir 
Gedanken darüber machen muss oder etwas davon mitbekomme.
Ebenso werden nicht ordnungsgemäß übertragene Daten (parity-check) von 
den Trasceivern automatisch erkannt und erneut gesendet.

So stelle ich mir das aktuell vor...

Oder als Geschichte:
Der Transceiver ist also ein kleiner Sekretär, der von uC1 einen Befehl 
bekommt:
"Setz dich ans Telefon(CAN-Bus) und Teile allen zuverlässig mit, dass 
ich mich nicht drum kümmern will."
und bei den andern Mikrocontrollern kommt dann deren 
Sekretär(CAN-Transceiver) angewackelt und meldet, dass der faule 
Hund(alas uC1) sich nicht kümmern will.


Ich glaube jetz habe ich mich verständlich ausgedrückt. Spätestens in 
kombination aller Mitteilungsversuche ^^

danke nochmal

von TestX .. (xaos)


Lesenswert?

> Das soll heißen, die uCs kommunizieren nur mit ihren CAN-Transceivern
> und diese kümmern sich dann um die Verbreitung der Informationen auf dem
> gesammten Bus.
> Sollten also mehrere uCs gleichzeitig senden wollen, dann fangen die
> CAN-Transceiver diesen Konflikt ab und lösen ihn ohne dass ich(uC) mir
> Gedanken darüber machen muss oder etwas davon mitbekomme.
ja das machen die dann so..schau dir mal die can spezifikionen zu 
CollisionD etect an..

> Ebenso werden nicht ordnungsgemäß übertragene Daten (parity-check) von
> den Trasceivern automatisch erkannt und erneut gesendet.
checken musst du die selber durch ein protokoll etc. can ist 
packetorientiert. es werden bis zu 8 bytes übertragen. gibt aber noch 
darauf aufbauende protokolle wie CANOpen, die checken dann auch alles 
und machen ein bisle mehr als RAW CAN ..

> Oder als Geschichte:
belassen wirs lieber beim technischen ;)

von (prx) A. K. (prx)


Lesenswert?

der kleine Niels schrieb:

> uC -(UART?)-> CAN-Transceiver -> CAN-Bus -> mehrere CAN-Transceiver
> -(UART?)-> mehrere uCs

uC -> CAN-Transceiver -> CAN-Bus -> mehrere CAN-Transceiver -> mehrere 
uCs

> Das soll heißen, die uCs kommunizieren nur mit ihren CAN-Transceivern
> und diese kümmern sich dann um die Verbreitung der Informationen auf dem
> gesammten Bus.

Korrekt. Nur hat das nichts mit UART zu tun.

Eine UART mit einem draussen angeklebten CAN Tranceiver ist kein CAN 
Bus, sondern ähnlich RS485 aber etwas abweichender elektischer 
Busdefinition. Keine automatische Retransmission, keine automatische 
CRC, keine automatische Arbitrierung.

> Sollten also mehrere uCs gleichzeitig senden wollen, dann fangen die
> CAN-Transceiver diesen Konflikt ab und lösen ihn ohne dass ich(uC) mir
> Gedanken darüber machen muss oder etwas davon mitbekomme.

Wenn du den Begriff "CAN-Tranceiver" durch "CAN-Controller" ersetzt, 
dann passt es.

> Ebenso werden nicht ordnungsgemäß übertragene Daten (parity-check) von
> den Trasceivern automatisch erkannt und erneut gesendet.

Wenn du den Begriff "Tranceiver" durch "CAN-Controller" ersetzt, dann 
passt es.

> Der Transceiver ist also ein kleiner Sekretär, der von uC1 einen Befehl
> bekommt:

Ein Tranceiver ist nur ein spezieller externer Treiberbaustein, eine Art 
Pegelwandler, nicht mehr. Das was du meinst erledigt der CAN-Controller.

Um das also klarzustellen: Ein CAN-Controller ist ein Gerät wie SJA1000 
und MCP2515 (extern), kann auch in diversen µCs eingebaut sein (z.B. 
AT90CAN). Ein Transceiver wie der MCP2551 oder PCA82C251 passt diesen an 
die elektrische Definition des CAN-Bus an und ist stets extern.

von der kleine Niels (Gast)


Lesenswert?

Wow Danke,

das ist genau das was ich wissen wollte. Die Kommunikation zwischen uC 
und MCP2515 läuft also über SPI, auch interessant.

Leider ist es aber nicht das was ich wollte. Schade eigentlich. CAN kann 
wohl keine Baumstrukturen. Und dafür ists mir dann doch noch zu teuer. 
100 Dank trotzdem!!!

von Ein (Gast)


Lesenswert?

CAN ist sicher schon dass was du wolltest, denn teuer ist es sicher 
nicht.

Gehe mal auf die

mikroe dot com

Seite. Da suchst du dir einen Compiler nach deinem Geschmack aus und 
suchst mal, in der Hilfedatei zu dem Compiler, ein CAN Bespiel.

Übrigens gibt es PIC-Controller integrierte CAN-Controller, zB 18F258, 
sodass du auch nur noch einen Treiber hinterherschalten mußt.

Einfacher geht es nicht, und preiswerter wohl auch nicht.

Habe gerade ein Projekt dazu gebastelt, und ich habe kein Abitur.

von Ein (Gast)


Lesenswert?

Nachtrag: Baumstruktur?
Warum soll das nicht gehen?
Das habe ich auch gemacht, das geht schon.

von (prx) A. K. (prx)


Lesenswert?

Ein schrieb:

> Einfacher geht es nicht, und preiswerter wohl auch nicht.

Wobei Mega8+MCP2515 zusammen deutlich billiger sind als der PIC18F258.

von (prx) A. K. (prx)


Lesenswert?

Ein schrieb:

> Das habe ich auch gemacht, das geht schon.

Nur ist dann die Leitungsanpassung nicht mehr gegeben und es kann etwas 
klingeln. Mit niedriger Datenrate und per Rs (Transceiver) stark 
gedrosselter Flankensteilheit kann das jedoch funktionieren.

von Ein (Gast)


Lesenswert?

Worüber reden wir?

Echt um 2 oder 3 Euro?

KNX/EIB hat 9600 Boud, Mein CAN-Bussystem wählte ich mit 125khz, ohne 
was zu probieren ob was schneller geht......   WOZU auch ..

Es zählt was hinten raus kommt.

Einfach mal probieren.

18B20, Touch, GLCD, Solidstaterelais, Master /Slave, alles machbar.

von (prx) A. K. (prx)


Lesenswert?

Ein schrieb:

> Echt um 2 oder 3 Euro?

Es waren deine Worte, dass es nicht preiswerter ginge ;-).

Ansonsten mag bei wilder Topologie die Länge der Segmente im Verhältnis 
zur Datenrate durchaus eine Rolle spielen.

von Ein (Gast)


Lesenswert?

Richtig, damit beende ich, für mich, diese philophischen Betrachtungen.

Fakt ist:

Schalterdosenmodul mit 18B20, PIC-Controller, TreiberIC und der Rest 
muss nicht teuer sein, Master/Slave, Stellventil, GLCD, Touch usw geht 
damit auch.

Einfach mal machen, es geht.

von der kleine Niels (Gast)


Lesenswert?

> CAN ist sicher schon dass was du wolltest, denn teuer ist es sicher
> nicht.
Hmm. Nach erneuter recherche denke ich du hast recht. Ich hab nicht an 
Digikey gedacht und dass ich da versandkostenfrei bestellen kann. (gut 
wenn man den richtigen Arbeitgeber hat)
Werde wohl dann Hardwarmäßig auf den MCP2551 in Verbindung mit 
irgendwelchen SPI-fähigen Atmel-Controllern festlegen.

> Gehe mal auf die
> mikroe dot com
> Seite. Da suchst du dir einen Compiler nach deinem Geschmack aus und
> suchst mal, in der Hilfedatei zu dem Compiler, ein CAN Bespiel.
das hab ich, hab mir diese mikroC_PRO_AVR geladen und ausprobiert, aber 
schlau werde ich da nicht.
C-Dateien ohne jegliche Includes oder Funktionsdefinitionen und trotzdem 
werden wilde Funktionen benutzt. Das leuchtet mir nicht ein.

Nunja ich werde mich mal wieder ein paar Tage zurückziehen und den 
MCP2551 studieren, neben den beiden Uni-Prüfungen diese Woche...

Ich bedanke mich bei allen, die hier mitgeschrieben haben und mich gut 
beraten haben. Ihr seid Spitze!
DANKE

MfG Niels


PS:
> ... und ich habe kein Abitur.
Als besitzer eines solchen kann ich sagen, dass das überhaupt nichts 
bedeutet! Nur am Rande.

von der kleine Niels (Gast)


Lesenswert?

Sorry Tipfehler:
MCP2551 sollte MCP2515 heißen

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.