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
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.
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
> 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 ;)
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.
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!!!
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.
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.
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.
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.
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.
> 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.