Hallo, ich will einige Controller über einen Bus verbinden. Die max. Kabellänge ist etwas über 50m. Es kommen Atmegas und Attiny25 zum Einsatz. Ich will möglichst auf einen Hardware unterstützen Bus setzen weil die Tiny Controller nunmal Tiny platz haben :) Als Kabel ist bis jetzt einfach geschirmtes Cat5E Kabel vorgesehen. Parallel zum Kabel liegen nur Gleichstrom Kabel und eine (PE) Wasserleitung. Welchen Bus sollte ich bei dieser Distanz verwenden? Die übertragenen Datenmengen sind klein (~4-10 Byte). Der Bus sollte schon >10khz schaffen. Danke an alle die sich hierfür Zeit nehmen.
Würde sagen entweder RS485 oder CAN. Wobei ich in letzter Zeit gerade bei mehreren Teilnehmern immer mehr zu CAN tendiere. Grüße
Hallo, beruflich arbeite ich mit CAN und bin immer wieder überrascht wie gut und einfach damit alles ist... daher wäre CAN auch meine Empfehlung... Ach so: und rechne mal durch wie hoch der Spannungsabfall deiner Versorgungsspannung am Ende des Kabels ist (falls du über das CAT5-Kabel auch die Versorgung übertragen möchtest). Gruß, Alex
CAN geht per Definition auf einer gewöhnlichen fast beliebigen
Zweidrahtleitung bis 1000m, dann ist die Bitrate aber nur noch 10kBit/s.
Die Abstufungen Bitraten und Leitungslängen stehen aber in den
CAN-Spezifikationen. CAN ist aber in der Übertragung sehr sicher, weil
da schon Hardwaremechanismen zum Fehlerhandling fest eingebaut sind. CAN
hat von alleine immerhin HD6. HD, Hamming-Distanz, das findet man im
Internet.
> geschirmtes Cat5E Kabel
Was hat denn dieses Kabel für Drahtquerschnitte?
Auf die Schirmung kann man evtl. auch verzichten. Zweidrahtleitungen
machen bei Störfeldern Common-Mode-Spannungen, die sich in der Summe
aufheben. Ein Transceiver kann sowas in Grenzen aushalten, sonst muß man
noch Suppressor-Dioden am Transceiver vorsehen. Ich verwendete mal
solche mit 12V an jeder Leitung gegen Masse. Eine nicht zu hohe
Kapazität sollten sie haben, damit hatte ich schon Probleme bei Bitraten
über 250.000. Darunter, spielt es keine Rolle.
Wilhelm Ferkes schrieb: > Ich verwendete mal > solche mit 12V an jeder Leitung gegen Masse Wenn man z.B. den SN65HVD1050 benutzt dürfen die Signale, wenn ich mich recht erinnere, auf ~200V gegen GND liegen. Aber ohne Gewähr...
Alex Bürgel schrieb: > Wenn man z.B. den SN65HVD1050 benutzt dürfen die Signale, wenn ich mich > recht erinnere, auf ~200V gegen GND liegen. Aber ohne Gewähr... Ja, das ist doch was. Wenn ich mich recht entsinne, ich hatte schon eine Weile nichts mehr mit den Dingen zu tun, aber da halten gewöhnliche bekannte Transceiver auch 27 bis 47V aus. Fragt sich nur, in welchem EMV-verseuchten Umfeld man diese Spannungen überhaupt bekommt. Vielleicht streng kilometerweit entlang einer Bahnlinie. Telefonleitungen. Das gibt es aber auch. Ich verwendete nach den Frequenzproblemen anstatt der normalen Transil-Dioden mal was mit NUP in der Bezeichnung, genau weiß ich sie nicht mehr, aber es waren spezielle Schutzdioden extra für CAN mit geringer Diodenkapazität. Hatten aber auch schlechtere ESD-Eigenschaften. Besser als gar nichts.
Wow so viele Antworten an einem sonnigen Sonntag :) Coole idee den MCP2515 zu nutzen. Ich werde mich mal in CAN bus einlesen. Was das Kabel angeht überlege ich mir lieber ein Stromkabel als Erdkabel zu legen um die 50m zu überbrücken. Für die kürzeren Distanzen und die Anbindung (Platine <-> Erdkabel) sollte das Cat5E dann ausreichen. oder?
Jo Ka schrieb: > Was das Kabel angeht überlege ich mir lieber ein Stromkabel als Erdkabel > zu legen um die 50m zu überbrücken. Für die kürzeren Distanzen und die > Anbindung (Platine <-> Erdkabel) sollte das Cat5E dann ausreichen. oder? Da solltest du aber wenigstens 3*4mm² Erdkabel nehmen. ;-) Mal im Ernst, Cat5-Kabel hat einen DC-Widerstandvon weniger 100 Ohm/km, da sind bei niedriger Bitrate (10kbit) über 5km drin. Bei Reichelt gibt es übrigens ein Netzwerkkabel als Erdkabel, falls das Kabel unter die Erde verschwinden soll. Das wäre dann auch sehr vorteilhaft bezüglich elektromagnetischer Störungen.
Jo Ka schrieb: > Wow so viele Antworten an einem sonnigen Sonntag :) > Coole idee den MCP2515 zu nutzen. Ich werde mich mal in CAN bus > einlesen. Und wenn Du dann den MCP2515 durch einen PIC18F25K80 ersetzt, bekomst Du auch noch gleich einen integrierten Prozessor mitgeliefert. Vorteil: kein SPI zwischen Prozessor und CAN MAC, damit effizientere Programmierung und schneller, weniger Platz auf der Leiterplatte. Dabei ist der PIC18F25K80 nicht wesentlich teurer als der MCP2515. Denke auch dran: der MCP2515 bzw der CAN-Teil des PIC18F25K80 ist nur der MAC, d.h. der Digitalteil. Du brauchst IMMER noch einen PHY dazu. Wenn Du bei Microchip bleiben willst, wäre das der MCP2551. fchk
Vielen Dank für euren input. Ich hätte ohne euch viel zeit gebraucht um die ganzen Sachen zurecht zu legen. Da ich die Atmegas und Tinys herumliegen habe werde ich nicht auf PIC setzen diesmal. Mein Plan ist jetzt: Controller -> MCP2515 -> MCP2551 -> CAT5-Kabel Stromversorgung wird über ein separates Kabel laufen welches einen größeren Querschnitt hat. Der CAN-Bus ermöglicht mir wirklich viel mehr Optionen als ich mir erhofft habe. Sobald ich alles am laufen habe werde ich mal Beispiel Codes und Schaltungen rein setzen falls jemand irgendwann mal die selbe frage im Kopf hat.
Jo Ka schrieb: > Stromversorgung wird über ein separates Kabel laufen welches einen > größeren Querschnitt hat. Für was? Für den kleinen MEGA? Wegen den 50-100mA wo das Ding braucht? Jo Ka schrieb: > Mein Plan ist jetzt: > Controller -> MCP2515 -> MCP2551 -> CAT5-Kabel Als kleiner Tipp: Schau mal bei Kreatives Chaos vorbei, da gibts ne fertige Library für den MCP2515 & Atmel: http://www.kreatives-chaos.com/artikel/universelle-can-bibliothek Wenn Du da die Anleitung durchliest, hast Du innerhalb von ner halben Stunde ne CAN-Verbindung. Grüße
Frank K. schrieb: > Und wenn Du dann den MCP2515 durch einen PIC18F25K80 ersetzt, bekomst Du > auch noch gleich einen integrierten Prozessor mitgeliefert. Vorteil: > kein SPI zwischen Prozessor und CAN MAC, damit effizientere > Programmierung und schneller, weniger Platz auf der Leiterplatte. Dabei > ist der PIC18F25K80 nicht wesentlich teurer als der MCP2515. Es ist da fast ziemlich Wurst, ob man einen PIC oder LPC2129 oder sonstwas nimmt. Der im µC integrierte CAN-Controller macht in der Software auf jeden Fall viel weniger Aufwand, als ein externer CAN-Controller. Im µC hat man einfach direkt Register, das ist viel komfortabler. Für manche µC gibt es bei den Herstellern bzw. auch Compilerherstellern Demo-Code, mit dem man sofort loslegen kann. Die CAN-Transceiver sollte man nie vergessen, die sind meistens noch außerhalb des µC, erledigen den elektrischen Teil.
NopNop schrieb: > Jo Ka schrieb: >> Stromversorgung wird über ein separates Kabel laufen welches einen >> größeren Querschnitt hat. > Für was? Für den kleinen MEGA? Wegen den 50-100mA wo das Ding braucht? Ne, da hängt noch anderes Zeug dran.
Wilhelm Ferkes schrieb: > Frank K. schrieb: > >> Und wenn Du dann den MCP2515 durch einen PIC18F25K80 ersetzt, bekomst Du >> auch noch gleich einen integrierten Prozessor mitgeliefert. Vorteil: >> kein SPI zwischen Prozessor und CAN MAC, damit effizientere >> Programmierung und schneller, weniger Platz auf der Leiterplatte. Dabei >> ist der PIC18F25K80 nicht wesentlich teurer als der MCP2515. > > Es ist da fast ziemlich Wurst, ob man einen PIC oder LPC2129 oder > sonstwas nimmt. Der im µC integrierte CAN-Controller macht in der > Software auf jeden Fall viel weniger Aufwand, als ein externer > CAN-Controller. Im µC hat man einfach direkt Register, das ist viel > komfortabler. Genau. Ich hatte hier den PIC aufgeführt, um so Äpfel() mit Äpfeln() vergleichen zu können, was Kosten (wenn ich mich entsinne waren das 60 Cent mehr für den PIC) und Schaltungsaufwand angeht. Genauso finde ich diese ganzen AVR+ENC28J60 Projekte ziemlich sinnfrei. Auch vom ENC28J60 gibts eine Version mit eingebautem PIC18, und der Schaltungsaufwand ist bei ENC28J60 solo und dem äquvalenten PIC18F67J60 ziemlich exakt gleich, mit dem Unterschied, dass man sich den AVR und den extra Quarz dafür spart. Und wenn man dann weiß, dass der PIC18F67J60 bei Microchip Direct bei irgendwas um die 2.60€ in 1k rangiert, dann ist es klar, dass die Kombination AVR+ENC28J60 wirtschaftlich und technisch gesehen Unsinn ist. fchk
Jo Ka schrieb: > Es kommen Atmegas und Attiny25 zum Einsatz. Einen ATtiny25 mit einem CAN aufzupeppen, finde ich abartig! Deine Anforderungen kenne ich nicht, aber eine soft-UART mit RS485-Treibern (oder auch CAN-Treibern) sollte die angemessene Lösung sein. Ein ATtiny2313 wäre allerdings besser, der er eine UART schon auf dem Chip hat und noch mehr IO bietet; der Preis ist doch fast gleich.
Guckel schrieb: > Jo Ka schrieb: >> Es kommen Atmegas und Attiny25 zum Einsatz. > > Einen ATtiny25 mit einem CAN aufzupeppen, finde ich abartig! > Deine Anforderungen kenne ich nicht, aber eine soft-UART mit > RS485-Treibern (oder auch CAN-Treibern) sollte die angemessene Lösung > sein. > Ein ATtiny2313 wäre allerdings besser, der er eine UART schon auf dem > Chip hat und noch mehr IO bietet; der Preis ist doch fast gleich. Tiny2313 hat kein ADC. Wie gesagt ich habe die Megas und Tinys herumliegen und sehe kein Problem einen Tiny via SPI an ein CAN Interface anzubinden. Würde ich jetzt etwas entwickeln was in größeren Stückzahlen produziert würde, so wäre sicher eine ein Chip Variante sinnvoller.
Hallo, zum Thema PIC vs Atmel: Auch von Atmel gibt es diverse Controller mit CAN MAC, man müsste sich also nicht in eine neue Architektur einarbeiten; abgesehen davon hat der TE ja schon mindestens dreimal gesagt, dass er die Dinger schon da hat. Zum Thema CAN-Anbindung: Hier kann man den MCP2515 wirklich nur empfehlen, da es für ihn verschiedenste Bibliotheken gibt (die schon genannte von Kreatives Chaos ist schon nicht schlecht, auch gibt es diverse Bootloader, die ein Flashen über CAN ermöglichen). Als PHY kann ich noch den TJA1050 anstelle des MCP2551 empfehlen, der ist von Haus aus EMC optimiert und benötigt deswegen keine Einstellung der Flankensteilheit. Ach ja, Tiny25 könnte etwas knapp werden, mit SoftSPI und ein paar kleinen Goodies liegt mein CAN-Bootloader bei knapp 2k, würde also den 25 vollständig füllen. Ein Tiny45 könnte hier helfen (und bitte nicht wieder die Diskussion mit dem PIC: den größten Umfang hat die Initialisation der Empfangs-Filter und Register, die hat man mit einem internen MAC genauso). Ist der Tiny25 gesetzt, muss man also entweder auf CAN-Komfort verzichten (z.B. die Botschaftenfilterung nicht benutzen), oder auf RS485 ausweichen. Schöne Grüße, Martin
maveric00 schrieb: > Als PHY kann > ich noch den TJA1050 anstelle des MCP2551 empfehlen, der ist von Haus > aus EMC optimiert und benötigt deswegen keine Einstellung der > Flankensteilheit. Was sich aber auch nur in einem Widerstand widerspiegelt; also äußerst überschaubarer Mehraufwand.
Hallo, richtig, allerdings legt man sich bei der Bestückung (mehr oder weniger) auf die Baudrate fest... Andere Kleinigkeiten, wie z.B. dass beim 2551 von "up to 115 nodes" und beim TJA "at least 110 nodes" gesprochen wird, machen mir diesen auch sympathisch. Zugegeben, der TJA ist als Einzelstück 10 Cent teurer, dafür im 1000er-Preis 15-20 Cent billiger. Der TJA ist als Bare Die verfügbar, der MCP als DIP. Da die beiden als SOIC Pinkompatibel sind ist es dann wohl eher eine Geschmackssache. Schöne Grüße, Martin
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.