|
Anzeige
|
CAN Grundlagenfrage
Gast
#280395
Hallo, ich habe eine grundlegende Frage zu Thema CAN. Wollte ich jetzt mehrere CAN Teilnehmer miteinander verbinden, ähnlich einem CAN@Home Projet, wie muss ich sie dann verbinden. Bei CAN gibts doch eine Tx und eine RX Leitung... bei zweien scheint es leicht, aber wie ist es mit drei Teilnehmern.. ist eine übertragung in beide richtungen gleichzeitig möglich?? Danke! Martin
Gast
#280396
alle Teilnehmer parallel denk ich ... Abschlußwiederstand nich vergessen chris
Gast
#280397
alle Tx leitungen zusammen, und alle rx leitungen, wie kann das gehen??? wenn man sternförmig legt, wohin mit dem 120 ohm wiederstand!? Martin
Gast
#280398
du brachst noch nen bustreiberbaustein, z.b. den PC82C250 http://www.semiconductors.philips.com/acrobat_download/datasheets/PCA82C250_5.pdf ...für jeden teilnehmer einen... in den kommen deine Tx und Rx leitung... raus kommen dann neue signale: CAN_L und CAN_H ...alle parallel anschliesen... CAN_H zu allenCAN_H und CAN_L zu allen CAN_L
Gast
#280399
...natürlich einen 120R am einen ende, und noch einen 120R am anderen ;-) länge: Faustregel: länge[m]= (40[m]/ übertragungsrate[MBit/s]) -->1MBit/s : 40m -->0.5MBit/s : 80m etc.
Gast
#280400
Hallo Bone. ahhh, klar, den habe ich auch schon bei reichelt entdeckt! setzt der das dann passend um??? könnte ich 2 can devs direkt gekrosst verbinden kennst du eine gute can grundlagensite, also ü raten ü rahmenlänge ü standarts usw... weißt du zufällig wo ich einen für LIN her bekomme, habe da auch schon exemplare raus gesucht... MCP201 TJA1020 leider nicht bei reichelt.. danke martin Hier gibts ne gute Zusammenfassung des Can Bus http://www.kvaser.com bei education / can
Gast
#280402
Hallo Paul, vielen Dank, werde mich da mal umsehen. jetzt bereiten mir die LIN Transceiver noch sorgen, weis nicht wo ich die mal am besten her bekommen kann. als standart gibt hier wohl der mcp201 oder tja1020, aber die gibts nirgendwo... martin
Gast
#280403
wenn du versprichst sie keinem weiterzugeben!!!, schicke ich dir einen teil aus meiner diplomarbeit, in der alles was du wissen musst steht...
Gast
#280404
ausser LIN... nur can
Gast
#280405
Hallo Bone, das ist ein schwieriges versprechen! ich kann dir nur versprechen das ich sie weder öffentlich, noch auf einer i site, noch in sonst irgendeiner form geschäftlich - oder kommerziell einsetzten werde, mein interesse ist rein privat, und das wird auch bleiben.... wenn das reicht... brauch ja nur was zum einlesen... damit ist aber immer noch meine LIn Transceiver frage offen, mensch die muss es doch irgentwo geben.... martin
Gast
#280406
Hallo Martin, CAN ist ein Bussystem deswegen werden alle Teilnehmer, wie schon besrieben, an eine Leitung gelegt. Beim CAN-Bus werden die Teilnehmer mit Hilfe von Adressen angesprochen. Eine Übertragung in beide richtungen gleichzeitig ist meines Wissens nach nicht möglich, da die beiden Datenleitungen CAN_H und CAN_L ein zueinander invertiertes Signal führen. Das dient der Übertragungssicherheit. Am besten du siehst dir diese Seite mal an http://www.elektrocrew.de/modules.php?name=News&file=article&sid=3 das ist die beste die ich auf die schnelle finden konnte. Ich hoffe das hilft dir weiter.
Gast
#280407
mit lin hab ich mich noch nicht befasst, nur ethernet/lan can spi i2c rs232 rs485 pci (usb)grad am erlernen ich werde dir heute abend (wenn endlich zu hause) den CAN-grundlagenteil mal schicken... (halte dein obiges wort ;-) !!)
Gast
#280408
Hallo Viktor, so langsam wird mir die sache mit dem Bussystem klarer... Also ein differenzielles Übertragungsverfahren auf dem Medium, ähnlich Ethernet... gut zu wissen... dann ist auf jeden fall klar das man nur in eine richtung auf mal senden kann, und es eines zugriffsverfahrens bedarf wenn man mehrere bussteilnehmer hat.... ich versuche zwei fujitsu mb90385 miteinander zu verknüpfen und einfach daten zu übertragen, die site schaut interessant aus, dank dir, sehe mich mal um, martin
Gast
#280409
Hallo bone, da hast du ja schon eine menge bussysteme durch...vor allem pci sticht dort etwas raus, hut ab, pci kann ich mir garnicht vorstellen, also das man da als normal sterblicher nocht mit um kann... :-) ich halte mein wort. binn gespannt was kommt.. größer als 4 mb kann probleme geben... jetzt bleiben noch die lin sorgen, bezüglich des beschaffens... ich versuche zwei fujitsu 90385 zum kommunizieren zu bringen, es gibt auch einige app notes dazu, aber meine herren, einen can uart anzusprechen ist im gegensatz zu einen rs232 uart eja eine tortur kann das sein!? martin
Gast
#280410
@viktor: >Beim CAN-Bus werden die Teilnehmer mit Hilfe von Adressen angesprochen. -ausgerechnet beim CAN ist das nicht so... beim can wird die information des telegramms adressiert... -jedes telegramm ist (topolodiebedingt) ein broadcastobjekt... die Teilnehmer(Knoten bzw. Nodes) entscheiden dann anhand dieser adresse ((informations-)IDENTIFIER) ob die information für sie selbst interessant ist... >Das dient der Übertragungssicherheit. -schonwieder nicht... :-) stichwort MAC (medium access controll) ... ...der buszugriff zu deutsch... es kann immer nur ein packet über den CAN-Bus laufen! keine zwei oder mehr gleichzeitig!! (topologie mal wieder) beim CAN eng verknüpft mit der Kabellänge! weil hier durch die sogenannte arbitrierung die telegrampriorisierung stattfindet. LAUFZEITEN etc. müssen berücksichtigt werden!!!
Gast
#280411
Hallo Bone, in einer app ist mir noch ein zusätliches bauteil aufgefallen, es ist eine art übertrager, aber länks geschaltet, drosselspule!? also in reihe zu canh und canL, vorab noch 2 folien c's zu masse. ähnlich wie bei ethernet, wo auch eine art übertrager vor der rj buchse sitzt. bei den apps auf can at home, ist diese nicht vorhanden. das ganze dient ja nun der störunterdrückung ähnlich EIB,Ethernet,S0(ISDN) usw... ich habe ein problem mit der beschaffung und der beschaffenheit dieser spulen/drosseln/übertrager... eine idee, oder infos??
Gast
#280412
Überigens einen CAN Abschlusswiderstand von ca. 120 Ohm wird nur in der Highspeed- CAN Technologie verwendet. Beim Lowspeed CAN nicht zwingend erforderlich. Der Transceiver von Philips TJA 1054 empfehlenswert, da das Bauteil sehr hohe ESD Schutz besitz. Gruß Eddy
Gast
#280413
@Bone, deine Can ausarbeitung ist leider nicht angekommen, sie würde mich dennoch sehr interessieren. Martin
Gast
#280414
sorry, bin nicht dazu gekommen... hab es aber schon parat gelegt ;-) heute abend schick ichs dann rüber :-) (vermutlich gegen 22uhr)
Gast
#280415
hi, wie gesagt, bin mal gespannt. martin
Gast
#280416
keine zu groosen erwartungen :-) sind nur etwa 10 seiten ;-)
Gast
#280417
...Hey Hey, so wie ich dich verstanden habe, handelt es sich um einen ausschnitt aus deinem diplom, wenn ich da keine erwartungen haben soll, wo denn dann :-)) Martin Nabend zusammen, ich habe mal ein kleines Bild angehängt, was mein MCP2515 nach dem init und der 1. gesendeten Nachricht macht. Ich sende nur ein Telegramm, aber wenn ich das richtig deute, hört der gar nicht mehr auf, oder muss das so sein? Hat da jemand Erfahrungswerte? Wenn ich von der Zeit her runter gehen, kann ich verschieden lange HIGH Impulse erkennen. Die langen Impulse sind ca. 4,4µs, die kurzen etwa 3µs. Einen ganz Kurzen mit 1,3 µs habe ich außerdem noch finden können. Gemessen habe ich zwischen CAN_H und CAN_L vom Treiber IC. Ronald
Angehängte Dateien:
Gast
#524022
Das muss so sein, wenn keiner da ist der die Nachricht entgegeb nimmt, also dein Sender kein Ackn bekommt. Hier noch das 2. Bild mit einer anderen Eionstellung der Zeitachse.
Angehängte Dateien:
Danke für die SUPER schnelle Antwort. Dann habe ich soeben mein erstes CAN Telegramm mit einem MCP2515 versendet. :-) Vielen Dank ronald
Gast
#524031
...ich vermute mal, das dein CAN-kumpl "alleine ist" wenn er nimanden hat, der ihm das CAN-packet abnimmt(indem er im ACK-slot des packets einen dominanten pegel sendet) dann denkt DEIN CANchip IHM sei ein fehler unterlaufen, und wiederholt das versenden.... dabei incrementiert er seinen fehlerzähler... ....wenn sein fehlerzähler einen gewissen stand erreichte(siehe datenblatt) wird er sich ausschalten.... dh. wenn dein chip "allein" am bus ist, dann gratulation zum test, du hast ein CAN-packet verschickt... wenn noch ein (bereits auf die gleiche(!) baudrate konfigurierter) chip am bus hängt, solltest du nochmals prüfen, ob beide WIRKLICH die GLEICHE baudrate benutzen...
Gast
#524033
ich sollte nich so lange ich was tippe davonlaufn :( war zu spät :(
Gast
#524035
Es reicht aber nichjt nur die richtige Bautrate, sonder der Empfangsfilter des Empfängers muss auch die ID der Massage akzeptieren.
Gast
#524037
Naja war ja etwas ausführlicher deine Antwort.
Gast
#524044
@obelix: nicht ganz richtig... der ACK wird gesetzt, wenn das CAN-Packet von seiner struktur her korrekt auf dem Bus abgebildet wurde( anzahl bits, stuffregln eingehalten, ifs nicht unterschritten). dies wird von jedem Busteilnehmer mit einem ACK belohnt... erst jetzt prüft der chip, ob er das packet in einen buffer schiebt oder verwirft (anhand filterverwendung und -wert)... ( ISO 11898 )
Gast
#524062
Bist du dir da sicher? Teste ich bei Gelegenheit mal aus.
Gast
#524064
sehr sicher, hab (fast) täglich mim CAN zu tun ;) noch ein buchtip, für alle dies interessiert: Wolfhard Lawrenz "CAN Controller Area Network Grundlagen und Praxis" Hüthig Verlag ISBN 3-7785-2780-0 ....lässt keine fragen offen :) Obelix wrote:
> Bist du dir da sicher? Teste ich bei Gelegenheit mal aus.
Ja, es reicht, wenn ein Teilnehmer das Paket für gut befindet.
Ob auch der gewünschte Empfänger das Paket erhalten hat, weißt Du nicht.
Beim CAN wird auch nur der Identifier arbitriert, nicht das Datenpaket.
Wenn also zufällig 2 Teilnehmer den gleichen Identifier aber
unterschiedliche Daten senden, ist der Bus erstmal ne Weile tot, bis
dann beide das Senden aufgeben, weil ihr Errorcounter übergelaufen ist.
Ein Kollege hatte sich mal gewundert, weil der CAN-Bus nur ganz langsam
vor sich hin tröpfelte. Er hatte versehentlich 2 gleiche Geräte
angeschlossen.
Peter
Gast
#524100
Aha, gut zu wissen. Man lernt halt nie aus :-)
Gast
#524250
@Peter Dannegger es reicht keineswegs dass nur ein Teilnehmer das Paket für gut befindet. Es ist zusätzlich auch noch zwingend notwendig dass kein anderer Busteilnehmer das Paket ablehnt (durch senden eines Errorframes). Die Empfänger dürfen das Paket erst zur Applikation durchreichen wenn diese Bedingung erfüllt ist. Wenn der Sender ein Errorframe erkennt versucht er das Paket erneut zu senden. Dirk Mahzeit, also ich habe nun 2xMCP2515 mit µC an meinem BUS. Ich kann auch von einem µC LEDs am 2. ein bzw. ausschalten. Nur sendet mein 2. µC ein ACK zurück und somit muss ich nach dem 1. senden den "Sender" reseten und dann kann ich weiter machen. Also wird das ACK nicht von selbst gesendet, wenn es einen 2. Teilnehmner auf dem BUS gibt. Nur wir komme ich jetzt mein ACK? Ronald
Gast
#526419
kannst du dein letztes Post noch mal etwas genauer beschreiben? Also wenn du über den CAN ein/ausschalten kannst, dann funktioniert der CAN doch? Das ACK wird automatisch von MCP übernommen. Warum musst du den Sender anschließend resetten? Das habe ich jetzt nicht ganz verstanden. Ich würde sagen, dass da in der Programmierung des Programmes was nicht stimmt... Hi ich habe 4 Taster an meinem 1. µC angeschlossen. Bei Tastendruck soll er ein Telegramm senden. Dieses wird vom 2. µC auch empfangen und ausgewertet. Sprich meine LED am 2. µC geht entweder an oder eben aus. Das funktioniert auch alles wunderbar. Das Problem leigt nun am ACK, welches der 2. µC an den 1. als Bestätigung senden soll. Dieses passiert, aus welchen Günden auch immer, nicht. Der 1. sendet also munter weiter, da er ja denkt das Telegramm sei ncht angekommen. Wer erzeugt mein ACK? Ist es der CAN Controller (MCP2515) oder, wie ich es auch schon gelesen habe der BUS Treiber? Oder muss ich meinen µC dazu bringen es zu senden? Da der 1. ja nun mal nicht mehr aufhört mit dem Senden muss ich ihn erst einen drüber geben um dann wieder ein neues Telegramm senden zu können. Beide µC habe ich im Normal Mode laufen, also kann es auch nicht an der fehlenden berechtigung zum senden (Listen only) liegen. PS: Habe mich, was die Grundstruktur an geht an die Anleitung von http://www.kreatives-chaos.com/artikel/ansteuerung-eines-mcp2515 gehalten. Ronald Ronald Hensen wrote: > munter weiter, da er ja denkt das Telegramm sei ncht angekommen. Wer > erzeugt mein ACK? Ist es der CAN Controller (MCP2515) oder, wie ich es > auch schon gelesen habe der BUS Treiber? Sag bloß, Du hast keine CAN-Treiber dazwischen, dann kanns auch nicht gehen. Beide müssen sich selbst und den anderen mithören. Peter
Gast
#526579
Der CAN-Treiber macht nur die Pegelanpassung sonst nichts. Alles andere was zum Protokoll gehört macht der CAN-Controller selbstständig.
Gast
#526606
Der CAN-Treiber macht nur die Pegelanpassung sonst nichts. Alles andere was zum Protokoll gehört macht der CAN-Controller selbstständig. ^^ AUTSCH naja, bis auf die tatsache, das erst der treiber die "dominanten" und überschreibbaren "rezessiven" pegel schafft.... TREIBER == UNVERZICHTBAR!!!!
Gast
#526700
Ausserdem kann der sendende Knoten seine eigenen Daten nicht zurücklesen, also ohne Bustreiber keine Funktion.
Gast
#526839
@bone
Warum AUTSCH?
Ich habe es natürlich nur stark vereinfach gesagt.
> naja, bis auf die tatsache, das erst der treiber die "dominanten" und
überschreibbaren "rezessiven" pegel schafft....
Kurz gesagt Pegelanpassung.
Für Testzwecke könnte man die beiden TXD über ein AND (74HC08) verknüpfen und den Ausgang dann auf beide RXD. Peter Keine Sorge. Als Treiberbaustein habe ich den PCA82C250 eingebaut. Wie schon gesagt. das 1. senden von einem zum anderen Controller ist möglich, nur hört es mit dem Senden nicht mehr auf. Kann ich denn sehen, ob das ACK vom 2. µC gesendet wird (also auf dem Oszi)? Habe auch auf beiden Seiten einen Abschluss mit (da ich nichts anderes da hatte) 130 Ohm gemacht. Die Entfernung sollte so etwa 1m betragen. Ronald Ich bins dann doch noch einmal. Inzwischen bin ich der Meinung, das das ACK Bit doch gesendet wird. Jedenfalls versucht wird zu senden. Ich habe das Oszi mit dem 1. Kanal auf die TX Leitung des MCP2515 vom Empfänger der Nachricht gehängt und den 2. Kanal auf CAN LOW. Jedesmal an der gleichen Stelle vom Frame wird ein Impuls über den TX vom "Empfänger" gesendet. Hab mal ein Bild gemacht. Ronald
Angehängte Dateien:
Oh mann. Das nenne ich mal eigene Dummheit!!! Habt alle einen gut bei mir! Das ACK wird natürlich am MCP2515 gesendet, nur kann der BUS Treiber, wenn ihm die 5V Ub fehlen wenig damit anfangen! Hab auch 1000x die Schaltung kontrolliert, sogar mit Lupe und jetzt, nachdem ich die IC's aus den Sockeln genommen hatte um mal die Spauungen zu messen, fehlte der Pegel an Pin 3 (Vcc). Ich habe alles so oft kontrolliert und nichts gefunden - jetzt bei gutem Licht und einer Lupe war da eine kleine Unterbrechung auf der Platine. Fazit: Ein Bustreiber ohne Spannung kann immernoch empfangen. UND! Wer misst misst nicht immer nur misst. Vielen Dank für eure Unterstützung! Ronald
Gast
#526947
@obelix: Kurz gesagt Pegelanpassung. eben NICHT einfach nur eine Pegelanpassung... einfach nur eine pegelanpassung wäre zB: bei rs232treibern der fall...(!) rezessiv und dominant sind nicht einfach NUR pegel... das verhalten ist die crux!! einfaches beispiel hierfür: I2C... ...schont bitte eure canchips :) spendiert ihnen treiber :) ps: AUTSCH nur ugs. ;)
Gast
#527321
Es geht auch ohne den CAN Transceiver. http://de.sitestat.com/infineon/infineon/s?infineon.pdf.Guest.Home.Products.Product_Categories.Microcontrollers.16_Bit.C166_Family.C167CS.Documents.ap292101.pdf&ns_type=pdf&ns_url=[http://www.infineon.com/upload/Document/cmc_upload/migrated_files/document_files/Application_Notes/ap292101.pdf Falls der Link nicht funktioniert, mit Google nach ap292101.pdf suchen. mfg, Stefan.
Gast
#527372
das is ja cool :D ...gefällt mir :) schon von jmd von euch realisiert?
Gast
#527399
Ich habe das für Testaufbauten so realisiert. Funktioniert ganz prima, ist schnell aufgebaut und ist billig. Wer keine Transceiver in der Bastelkiste hat, sollte das ausprobieren. Der Nachteil ist, daß man diesen "Bus" nicht mit dem normalen CAN-Bus koppeln kann. mfg, Stefan.
Beitrag #6768052 wurde von einem Moderator gelöscht.
Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
