Eine Frage aus Neugier, wenn ich einen kleinen AVR (sagen wir mal einen ATtiny85) an einen CAN Bus anschließen würde, was wäre dann der übliche Weg? Per Software mit Bit-Banging oder ein extra Chip für das Protokoll? Die Software Variante stelle ich mir schwierig vor, was die Verhinderung von Kollisionen angeht. Aber vielleicht ist das gar nicht so schwer.
CAN-Controller (z.B. MCP2515) über SPI angebunden und ein CAN-Transceiver daran, das wäre der Klasiker.
Thorsten S. schrieb: > z.B. MCP2515 Oh, der ist aber teuer. Jetzt verstehe ich, warum entsprechende Schaltungen so selten diskutiert werden.
Ich würde allerdings schon einen Controller verwenden, der nicht gar so geizig mit Schnittstellen ist, wie der Tiny85. Der hat nur einen USI, welchen du als SPI-Schnittstelle brauchst. Dann gibts kein I2C mehr. Und einen UART hat der auch nicht. Wenn der Tiny also nicht nur (im Sinne von ausschließlich) am CAN-Bus aktiv sein soll, fehlen Schnittstellen für die Außenwelt. Dies USI ist ein ziemliches Gewürge, ich bin mir nichtmal sicher, ob es das Lesetiming für Daten vom MCP2515 in SPI-Mode 0 kann. Im Tiny Datasheet ist das zu lesende MSB sehr lange im voraus gültig. Habs mir aber noch nicht im Detail daraufhin angeschaut. Ich bevorzuge Controller mit Peripherals für SPI, I2C und UART
Stefan ⛄ F. schrieb: > Oh, der ist aber teuer. Jetzt verstehe ich, warum entsprechende > Schaltungen so selten diskutiert werden. Ohne sowas dürfte dein Tiny85 komplett mit der CAN-Kommunikation ausgelastet sein (subjektive Einschätzung).
Stefan ⛄ F. schrieb: > Oh, der ist aber teuer. Knapp 3€ bei Mouser für ein Einzelstück in SOIC und sogar verfügbar... Das finde ich jetzt nicht teuer. Oder geht es um industrielle Grosserie und nicht um ein Hobbyprojekt?
Thorsten S. schrieb: > Knapp 3€ bei Mouser für ein Einzelstück. > Das finde ich jetzt nicht teuer. Ich mag die AVR wegen ihrer Einfachheit, aber bei dem großen Preisunterschied tue ich mir doch lieber einen STM32 (oder andere) an. Klar, die Verfügbarkeit wäre ein Problem, wenn ich es jetzt bauen wollte. Habe aber gerade keinen Bedarf.
Stefan ⛄ F. schrieb: > Thorsten S. schrieb: >> z.B. MCP2515 > > Oh, der ist aber teuer. Jetzt verstehe ich, warum entsprechende > Schaltungen so selten diskutiert werden. Teuer? http://www.kreatives-chaos.com/artikel/ansteuerung-eines-mcp2515 Uwe
Uwe B. schrieb: > Teuer? Ja teuer, immerhin kostet der Chip mehr ein vielfaches von dem Attiny. Danke für den Link. Er zeigt, dass die Programmierung einfach ist, aber das meinte ich nicht mit "teuer", im Sinne von Aufwändig.
Stefan ⛄ F. schrieb: > Oh, der ist aber teuer. 3,19 Mäuse sind dafür zu teuer? https://www.pollin.de/p/mcp2515-i-p-101114 Allerdings im bastelfreundlichen DIP-18
Stefan ⛄ F. schrieb: > Uwe B. schrieb: >> Teuer? > > Ja teuer, immerhin kostet der Chip mehr ein vielfaches von dem Attiny. Wir reden über 2,50 Euro. Der Virus und Putin haben offensichtlich nicht gereicht, spätestens nachdem die Pelosi in Taipeh war ist es an der Zeit die Maßstäbe neu zu sortieren.. Uwe
:
Bearbeitet durch User
Matthias S. schrieb: > 3,19 Mäuse sind dafür zu teuer? Zu teuer habe ich nicht geschrieben. Ein STM32 mit CAN konnte man vor dem Chipmangel für ca. 1 Euro bekommen. Da hat man dann µC und CAN zusammen zu 1/3 des Preises. Da macht es schon Sinn zu erwägen, diesen zu bevorzugen, finde ich. Denn Rest deines Beitrages lasse ich mal unkommentiert, da er hier nicht hin gehört.
Naja, der MCP2515 stammt noch aus einer Zeit, als arme wesentlich "komplizerter" waren (wenn sie überhaupt schon beschaffbar waren). Der Vorteil für Bastler liegt halt in der Gehäuseform: man kann ihn problemlos auf eine Lochraster-Platine löten. Das ist dir aber vermutlich klar.
statt einem ATtiny85 einen STM32F103C8T6 mit integriertem CAN Controller. Wegen Chipmangel von einem Bluepill board runterfummeln, die sind lieferbar. Sind mit Sicherheit Clone, aber wenns billig sein soll ...
ach ja, der ESP32 hat auch CAN integriert, ein Wroom Modul (nicht Breadboard!) ist genau so teuer wie ein Bluepill Board oder der Atting85.
STK500-Besitzer schrieb: > Der Vorteil für Bastler liegt halt in der Gehäuseform: man kann ihn > problemlos auf eine Lochraster-Platine löten. > Das ist dir aber vermutlich klar. Ja. Wenn ich mal etwas mit CAN baue, werde ich auf jeden Fall erwägen, ihn zu verwenden. Denn mit AVR und Lochraster bin ich viel mehr vertraut, als mit den moderneren ARM. (Aber das darf man hier ja nur sagen, wenn man Shitstorm vertragen kann)
Auf dem ATmega hat mal jemand Lowspeed-USB als Bitbanging implementiert. "IgorUSB" nannte sich das, nach seinem Erfinder Igor Češko. Für Mäuse, Tastaturen und Gamecontroller hat es gereicht. Von daher sollte sich auch ein CAN-Knoten mit Bitbanging implementieren lassen. Der schafft sicher kein Mbit mit 99% Buslast und vollbelegten Akzeptanzfiltern, aber hin und wieder einen UDS-Job rausrotzen und die Antwort abholen könnte machbar sein.
Soul E. schrieb: > "IgorUSB" nannte sich das Vielen Dank für den Tipp! Ich hatte schon einmal gesucht aber kein Projekt gefunden.
Hmm, wer es schafft CAN per Bitbanging umzusetzen und dann auch noch auf nen 8bitter der hat fast nen Nobelpreis verdient. Es hat wohl auch seinen Grund warum es selbst bei "großen" Controllern noch keine SW-Can gibt. 🙄 Man braucht bei CAN ca die 10fache Abtastfrequenz von eigentlichen Bitrate. Die Spec schreibt nunmal so lustige Sachen wie Abtastzeitpunktverschiebung und auch erkennen ob das Bitsetzen auch erfolgreich war (testen ob Rx-Pin gleich Tx-Pin).
Bit-Banging sollte möglich sein, einen Transceiver IC brauchst du aber trotzdem. Am µC braucht man einen Pin als Ausgang und einen Pin als Eingang. Man muss immer das zurück lesen was man sendet. Ist es unterschiedlich, hört man wärest der Arbitrierung einfach auf. Ist es danach, sendet man einen Error-Frame. Der Rest ist "nur" einhalten des Timings (auch den richtigen Abtastzeitpunkt treffen). Auf Bit Stuffing achten. CRC Berechnen/überprüfen.
Jens R. schrieb: Hmm, wer es schafft CAN per Bitbanging umzusetzen und dann auch noch auf nen 8bitter der hat fast nen Nobelpreis verdient. https://github.com/KevinOConnor/can2040
Fchk schrieb: > Warum will man das? Es gibt genug kleine PICs, die die passende Hardware > drin haben Weil einigen Leuten langweilig ist und sie UNBEDINGT die 2,50 für einen CAN-Controller sparen wollen . . .
Roland schrieb: > Jens R. schrieb: > Hmm, wer es schafft CAN per Bitbanging umzusetzen und dann auch noch auf > nen 8bitter der hat fast nen Nobelpreis verdient. > > https://github.com/KevinOConnor/can2040 Das ist kein 8 Bitter, sondern ein fetter Doppel-ARM-M0, dazu noch 8 Spezial-PIO Controller, die als programmierbare Statemachine Bitfummelei machen können. Die PIOs sind näher an einem FPGA als du denkst.
Roland schrieb: > Jens R. schrieb: > Hmm, wer es schafft CAN per Bitbanging umzusetzen und dann auch noch auf > nen 8bitter der hat fast nen Nobelpreis verdient. > > https://github.com/KevinOConnor/can2040 Schönes Beispiel das es eben nicht "einfach" geht. Wie schon geschrieben ist das ein Beispiel für eine Hardware-Interrupt-Lösung. Dann steht ja schon in der Beschreibung das der 125MHz Arm Core bei einem ausgewachsenen CAN Netzwerk wohl schon zu 30% ausgelastet sein wird. Ach und eben nicht mehr linear läuft, weil die Reaktion auf die Bitflanken eben im Interrupt gelöst sind. Also jede Millisekunde eine Unterbrechung der normalen CPU Arbeit. Und dann fehlt noch immer ein ganz wichtiger Teil. Die Übertragungssicherheit im CAN wird durch das Error Managment sicher gestellt. Und das fehlt in dem Software Core. Warum eigentliche? Noch besser, wenn der SW CAN aus dem Rythmus kommt, wird der den kompletten Bus lahm legen weil kein Bus Off State umgesetzt ist. Also nein, das da ist kein CAN nach Spec. Das ist ein Versuch am Bus teilzunehmen. Ähnlich wie ein Kind mit dem Fahrrad auch auf der Autobahn fahren kann.
Stefan ⛄ F. schrieb: > Die Software Variante stelle ich mir schwierig vor, was die Verhinderung > von Kollisionen angeht. Aber vielleicht ist das gar nicht so schwer. Wie Jens schon schrieb, schwierig. OK, seit dem PoorMans-Scope auf PIC12-Basis wird auch CAN gehen. Aber dann macht der 8-Bitter nichts anderes mehr. CAN ist nicht vergleichbar mit SPI, I2C oder UART. Als reine Spielerei kannst Du "nur mitlesen" implementieren oder "nur senden". Dafür gibt es Einsatzzwecke. Sowas wie "LED an, bei Telegramm X". Auch mit 4 IOs (oder weniger) den Transceiver sparen ist ein respektables Projekt.
Fchk schrieb: > Warum will man das? Es gibt genug kleine PICs, die die passende Hardware > drin haben Proof of concept. Spec-konform wird man die SW-Lösung nicht hinbekommen und die FH Zwickau wird einen beim Conformance Test hochkant rauswerfen, aber Grundfunktion dürfte hinzubekommen sein. IgorUSB (heute V-USB) ist auch nicht normgerecht. Für den Aufwand funktioniert das aber erstaunlich gut.
Soul E. schrieb: > Auf dem ATmega hat mal jemand Lowspeed-USB als Bitbanging implementiert. > "IgorUSB" nannte sich das, nach seinem Erfinder Igor Češko. Für Mäuse, > Tastaturen und Gamecontroller hat es gereicht. V-USB läuft stabil, es gibt zahlreiche Anwendungen damit. https://www.obdev.at/articles/implementing-usb-1.1-in-firmware.html Das Projekt ist auch die Basis für den ATtiny85 Arduino USB-Bootloader (micronucleus). https://github.com/micronucleus/micronucleus https://github.com/ArminJo/micronucleus-firmware
Jens R. schrieb: > Wie schon geschrieben ist das ein Beispiel für eine > Hardware-Interrupt-Lösung. > Dann steht ja schon in der Beschreibung das der 125MHz Arm Core bei > einem ausgewachsenen CAN Netzwerk wohl schon zu 30% ausgelastet sein > wird. Ach und eben nicht mehr linear läuft, weil die Reaktion auf die > Bitflanken eben im Interrupt gelöst sind. Also jede Millisekunde eine > Unterbrechung der normalen CPU Arbeit. Das kann man sicher deutlich besser lösen. Auf einem RP2040. Der Mann kann mit den PIOs noch nicht wirklich gut umgehen. Aber er ist offensichtlich lernfähig, wenn er so weiter macht, wird er es möglicherweise irgendwann schaffen. Fakt ist nämlich: der RP2040 kann alles Nötige für eine vollständig standardgerechte CAN-Implementierung leisten und hat dann immer noch SEHR ordentliche Teile seiner Resourcen für eine Anwendung über. Aber auf einem AVR8 (und um die ging es ja eigentlich in diesem Thread) sehe ich keine Chance, selbst auf den modernsten unter Ausnutzung aller ihrer Hardware-Features nicht. Und auf einem Tiny85 natürlich schon garnicht.
STK500-Besitzer schrieb: > Der Vorteil für Bastler liegt halt in der Gehäuseform: man kann ihn > problemlos auf eine Lochraster-Platine löten. Bist du im letzten Jahrhundert hängen geblieben? Fünf Custom-Platinen in professioneller Technik kosten heutzutage weniger als ein MCP2515.
Wolfgang schrieb: > STK500-Besitzer schrieb: >> Der Vorteil für Bastler liegt halt in der Gehäuseform: man kann ihn >> problemlos auf eine Lochraster-Platine löten. > > Bist du im letzten Jahrhundert hängen geblieben? Fünf Custom-Platinen in > professioneller Technik kosten heutzutage weniger als ein MCP2515. So wie das aktuell aussieht werden wir Boomer (die aus dem letzten Jahrhundert), die noch mit Lochrasterplatinen, Logik-ICs und Transistoren als Schüttgut umgehen können, demnächst unseren großen Auftritt haben... Uwe
Wolfgang schrieb: > Fünf Custom-Platinen in > professioneller Technik kosten heutzutage wenig Mag sein, aber in der Zeit wo ich darauf warte, habe ich meine Lochraster Platine schon lange fertig. Außerdem muss ich dazu den Umgang mit der Layout Software lernen*. Mit Lochraster bin ich hingegen routiniert vertraut. *) Die Nummer habe ich schon 2x hinter mir, damals noch beruflich. Ich weis wie zeitaufwändig das ist und ich weiß dass man viel Erfahrung braucht, bis sie schon beim erste Wurf etwas taugen. Beide Programme gibt es nicht mehr, ein drittes will ich nicht mehr erlernen. Wenn du das mit "im letzten Jahrhundert hängen geblieben" meinst, dann sei es so. Andere Generation, andere Arbeitsweise. Das ist völlig normal. Und falls du es sträflich ineffizient findest kann ich dich trösten: Ich mache das nur als Hobby.
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.