Hat schon jemand (positive) Erfahrungen mit dem USB2CAN Adapter aus China gemacht ? Funktioniert der vor allem unter Linux am PC oder Raspberry Pi? In der Bucht gibts den für ca. 20€. Alternativen gibts aus der EU ab 80€, aber reicht der China Adapter vielleicht auch ? Man braucht ja mindestens 2 um damit was machen zu können, dann geht es schnell ins Geld.
Angehängte Dateien:
-
usb2can-adapter.jpg
31 KB
Hab vor einigen Jahren mal so einen gekauft: Hat unter Windows nie funktioniert. Die Software war nur auf chinesisch, nicht mal englisch und damit nicht bedienbar. Keine Informationen zum Protokoll, somit kann man auch keine eigene Software schreiben. Nimm lieber etwas Erprobtes: https://www.fischl.de/usbtin/
Taucht nix. CAN braucht GND damit er nicht nur zufällig auf dem Schreibtisch funktioniert. Gruß Volker
Da du keinen Link oder ein Datenblatt bietest nur folgende allgemeine Empfehlungen: Kann dieser nur lesend am Bus hängen? - keine ack, keine Errors. Wirklich nur lesend. Kann dieser fehlerhafte Frames ausgeben? - manchmal ganz praktisch, wenn ein Teilnehmer in Bus off geht, aber eigentlich ein anderer TN wegen Reflexionen den Frame fehlerhaft als falsch markiert. Welche Software gibt es dazu? Wie gut sind die APIs dokumentiert? Sg
Angehängte Dateien:
-
Pican2-duo_manhattan.jpg
150 KB
>Da du keinen Link oder ein Datenblatt bietest >Welche Software gibt es dazu? >Wie gut sind die APIs dokumentiert? ich vermute das ist ein 8Devices USB2CAN clone Habe gehofft, ein anderer Sparfuchs im Forum hat den schon mal benutzt. Software sind die Linux CAN-Tools und der Linux CAN Socket wenn es ein Clone ist. Hintergrund: für den RPI habe ich mir schon einen pican2-duo clone gebastelt. Der funzt soweit, aber nur halt am RPI, da eine GPIO Erweiterung. Mit einem USB Adapter würde GPIO komplett frei bleiben und Linux PC Kompatibilität ergeben. (Wer sich über das Layout aufregen will, es ist Manhattan Routing im Lochraster Grid. Chip Shortage hat DIP erzwungen, Fallback falls China Platine nicht kommt). >Nimm lieber etwas Erprobtes: Fischl USBtin doppelt so teuer, Kein Gehäuse oder Anschlussklemme Dann ist ein 8Devices oder Peak USB-CAN Adapter wieder preislich interessant. Von denen weiss ich das sie unter Linux laufen. >CAN braucht GND damit er nicht nur zufällig auf dem Schreibtisch funktioniert. Bei einem 20€ Gerät bastel ich mir das nachträglich dran, daran soll es nicht scheitern
Mit einem China-Adapter hatte ich auch schon Pech. Das Fischl-Ding funktioniert, bei einem von meinen beiden musste ich allerdings erst die Firmware installieren. Richtig billig finde ich die nicht, aber der Markt bestimmt den Preis. Billig (<10€) gibt es CAN-Shields aus dem Arduino-Bereich. Die benutzen den MCP2515 und werden per SPI angeschlossen. Wenn man den 5V-CAN-Treiber gegen einen 3.3V-Typen tauscht kann man die an einen Raspberry anklemmen. Mit ein bischen config geht dann SocketCan, bei mir relativ zuverlässig.
beim Herumstöbern im Netz habe ich die Android App "Robotech CAN bus Analyzer" gefunden. Ich glaube, ich investiere mal das Lehrgeld in die China Lösung. 20€ ist zu verschmerzen wenn es schief geht. >Billig (<10€) gibt es CAN-Shields aus dem Arduino-Bereich. >Die benutzen den MCP2515 und werden per SPI angeschlossen. das ist exakt mein Board, MCP2515-I/P + 12MHz Quarz + 5V/3.3V/CAN Bus Treiber MCP2551-I/P. Läuft auf Anhieb mit den angehängten Einstellungen unter Raspi-OS. Wenn man den 2. MCP2515 auch aktivert kann man im Loop Nachrichten Senden und Empfangen. Oder halt die eigene Applikation debuggen.
Volker Z. schrieb: > Taucht nix. > CAN braucht GND damit er nicht nur zufällig auf dem Schreibtisch > funktioniert. > > Gruß Volker Bei mir im Haus funktioniert das seit 10 Jahren ohne Probleme und mit noch mehr "nogo's" die die Klugscheißer hier verbreiten. Alle Teilnehmer haben isolierte CAN-Tranceiver, es gibt Stichleitungen mit 8m Länge, GND ist nirgends verbunden, die gesamte Buslänge ist ca. 40m bei 100kBaud. CAN ist viel robuster und einfacher als viele behaupten. Der gezeigte CAN Adapter hat wohl sein eigenes serielles Protokoll das zu nichts kompatibel ist. Damit ist er nicht zu empfehlen. Alternativen sind canable https://canable.io/ oder wie oben schon geschrieben usbtin. https://www.fischl.de/usbtin/ Beide benutzen das Standard slcan Protokol. Eigentlich ist usbtin nicht mehr zeitgemäß wegen des wenigen RAM im PIC Controller, aber in diesen Zeiten wo Cortexe mit CAN kaum erhältlich sind, ist das immer noch eine gute Alternative.
>Alternativen sind canable
Leider "sold out" im Webshop. Wenn das mal keine Chip Shortage ist.
drm schrieb: > Leider "sold out" im Webshop. Wenn das mal keine Chip Shortage ist. https://de.aliexpress.com/item/1005003746105255.html?spm=a2g0o.productlist.0.0.af202d8fOLl4qu&algo_pvid=47feeb92-eec1-4fb7-9044-6cfaf8dff2cc&algo_exp_id=47feeb92-eec1-4fb7-9044-6cfaf8dff2cc-0&pdp_ext_f=%7B%22sku_id%22%3A%2212000027291719020%22%7D&pdp_npi=2%40dis%21EUR%21%2124.42%21%21%211.47%21%21%400b0a187916589097019421899e0f42%2112000027291719020%21sea Da sind genügend verfügbar, isoliert oder auch nicht
die Canable sind wohl auch mit den 8Devices Korlan USB2CAN identisch. Selben STM32F042/STM32F072 mit internem CAN Bus und externem Transceiver. Da gab es auch den entscheidenende Hinweis : candlelight firmware https://github.com/candle-usb/candleLight_fw Passt auf den ersten Blick auch auf den USB2CAN Adapter. Ist also alles der selbe CAN Adapter von 1000 verschiedenen Herstellern. Ich nehme den mit Gehäuse für 20€ incl Porto von der Bucht. Dauert ein bisschen bis der in der Post ist, ich werde ggf. berichten falls es jemand interessiert.
mppt schrieb: >> Taucht nix. >> CAN braucht GND damit er nicht nur zufällig auf dem Schreibtisch >> funktioniert. >> >> Gruß Volker > > Bei mir im Haus funktioniert das seit 10 Jahren ohne Probleme und mit > noch mehr "nogo's" die die Klugscheißer hier verbreiten. Alle Teilnehmer > haben isolierte CAN-Tranceiver, es gibt Stichleitungen mit 8m Länge, GND > ist nirgends verbunden, die gesamte Buslänge ist ca. 40m bei 100kBaud. > CAN ist viel robuster und einfacher als viele behaupten. Ein Kollege hat den CAN-Bus ohne Abschluss-Widerstände betrieben. Hat auch (meist) funktioniert. Jeder darf die Theorie der Elektrotechnik soweit ignorieren, wie es für ihn passt. Gruß Volker
>Ein Kollege hat den CAN-Bus ohne Abschluss-Widerstände betrieben. Hat auch (meist) funktioniert. ACK, ein Terminierungswiderstand an beliebiger Position reicht auch oft, 2 an der richtigen Position werden überschätzt in ihrer Wirkung. >Jeder darf die Theorie der Elektrotechnik soweit ignorieren, wie es für ihn passt. No risk, no fun. Wie Grönemeyer in seiner VDE Norm so schön gesagt hat: 1000 Mal berührt, 1000 Mal ist nix passiert. 1000 und eine Nacht und es hat zoom gemacht. Genau dafür gab es ja oben den Hinweis ob der CAN Adapter auch defekte Pakete anzeigen kann. Ob also beim ersten Versuch das Datenpaket durchgeht oder mehrere Versuche nötig sind fällt vielleicht gar nicht auf. Aber das prüfe ich gerne mit meinem LA direkt am Draht.
drm schrieb: > Da gab es auch den entscheidenende Hinweis : candlelight firmware > https://github.com/candle-usb/candleLight_fw > Passt auf den ersten Blick auch auf den USB2CAN Adapter. Diese firmware spricht aber nicht slcan sondern nur socket can. Damit ist Windows als Host wohl raus für diesen Adapter. Wenn man damit leben kann ist es ok. Universell ist aber was anderes.
>Diese firmware spricht aber nicht slcan sondern nur socket can.
Windows interessiert mich nicht, also alles gut für mich, ich brauche
nur Linux.
Wenn diese Chip-Krise nicht wäre... https://github.com/RudolphRiedel/USB_CAN-FD https://github.com/jgressmann/supercan Die Laufen auch unter Linux. Es gibt auch eine Firmware für das "Adafruit Feather M4 CAN Express", da ist zumindest 1 CAN-Transceiver drauf und der Anschluss an dem Board hat auch GND mit drauf. Ist halt "nur" 1 CAN und nicht isoliert und "nur" bis 5MBit/s, aber das Board hat halt auch den ATSAME51J drauf.
In der Firma haben wir die CANUSB aus Schweden, deutsche Wertarbeit ;-) https://www.canusb.com/products/canusb/ Kostet glaub ich um die 100 Euro. Jaja, nicht superbillig, funktioniert aber ohne Handstände und ist frei programmierbar, Schnitstelle liegt offen vor.
Falk B. schrieb: > https://www.canusb.com/products/canusb/ Werden die wirklich noch gebaut? Die Liste der Teile liest sich wie aus dem Antiquariat, der SJA1000 ist doch schon bestimmt 10 Jahre abgekündigt? Ah, es gibt einen SJA1000T.
:
Bearbeitet durch User
Clemens S. schrieb: > Kann dieser nur lesend am Bus hängen? - keine ack, keine Errors. > Wirklich nur lesend. > Kann dieser fehlerhafte Frames ausgeben? - manchmal ganz praktisch, wenn > ein Teilnehmer in Bus off geht, aber eigentlich ein anderer TN wegen > Reflexionen den Frame fehlerhaft als falsch markiert. > Welche Software gibt es dazu? > Wie gut sind die APIs dokumentiert? https://github.com/KevinOConnor/can2040 eventuell ist das ja für dich ein Ansatz. Da kannst du dann komplett bestimmen was du kriegst. Fehlerhafte Frames ausgeben ist etwas was die mir bekannten CAN-Controller in dem µC's nicht können.
der China Adapter ist heute angekommen Tech Spec: USB-Seriell Controller CH9340C, wird von Windows sofort erkannt Geehy APM32 F103CBT6 CPU mit 12 MHz Quarz (96MHz, 128k Flash 20k RAM, Cortex-M3 LQFP48, integrierter CAN Controller) https://geehy.com/support/apm32 SIT1050 CAN Bus Treiber AMS1117-3.3V LDO scheint dem hier sehr ähnlich zu sein: https://www.seeedstudio.com/USB-CAN-Analyzer-p-2888.html es gibt Windows und Linux Tools Kann kein Sochet CAN, hat warscheinlich ein eigenes Seriell zu CAN Protokoll: https://github.com/kobolt/usb-can erste Tests werden bald folgen PS: die Geehy CPUs scheinen gut dokumentiert, sind bei LCSC lieferbar, werden von Keil und IAR unterstützt, Ähnlichkeiten zu STM32 drängen sich geradezu auf.
drm schrieb: > USB-Seriell Controller CH9340C, wird von Windows sofort erkannt > Geehy APM32 F103CBT6 CPU mit 12 MHz Quarz (96MHz, 128k Flash 20k RAM, > Cortex-M3 LQFP48, integrierter CAN Controller) Warum auch immer der eingebaute USB-Controller nicht verwendet wird. Vielleicht, weil die Software nur Copy-Paste ist und der STM32F103 nicht CAN und USB gleichzeitig kann?
Rudolph R. schrieb: > Falk B. schrieb: >> https://www.canusb.com/products/canusb/ > > Werden die wirklich noch gebaut? Das ist "der" Lawicel, zu dem die ganzen Selbstbau-Projekte kompatibel sind. Auf dessen Befehlssatz setzen Tools wie CanHacker oder CanCool auf. So wie Prologix einen Quasi-Standard für GPIB-Adapter geschaffen hat. > Die Liste der Teile liest sich wie aus dem Antiquariat, der SJA1000 ist > doch schon bestimmt 10 Jahre abgekündigt? Philips heisst jetzt NXP, und die verkaufen ihn noch: https://www.nxp.com/products/interfaces/can-transceivers/legacy-can/stand-alone-can-controller:SJA1000T
Hab den von Seeedstudio, da ist es ein: STM32F103 Aber meiner ist kaputt: https://forum.seeedstudio.com/t/usb-can-analyzer-help/7513/4 Brauche die Firmware.. Leider scheint es da keine opensource zu geben was die Chinesen kopiert haben.. Oder noch nicht gefunden.. Wollte den STM mal neu flashen damit ich weiß ob der Pin intern aufgegeben hat oder es Probleme mit der Software im Flash gibt..
Volker Z. schrieb: mppt schrieb: >> Bei mir im Haus funktioniert das seit 10 Jahren ohne Probleme und mit >> noch mehr "nogo's" die die Klugscheißer hier verbreiten. Alle Teilnehmer >> haben isolierte CAN-Tranceiver, Es gibt Isolierte CAN Transceiver welche bei entsprechender Beschaltung ohne GND-Verbindung klarkommen. Es geht darum daß das Niveau des Leitungspaares gegenüber GND der Teilnehmer nicht aus dem zulässigen Gleichtaktbereich "herauswandert". >> es gibt Stichleitungen mit 8m Länge, GND >> ist nirgends verbunden, die gesamte Buslänge ist ca. 40m bei 100kBaud. 100k ist ja auch kurz hinter morsen und 40 Meter ist keine nennenswerte Länge .. >> CAN ist viel robuster und einfacher als viele behaupten. Ja, robust. Allerdings geht die Übertragungsrate bei unsachgemäßer Verkabelung schnell böse in die Knie wenn Messages vielfach gesendet werden müssen damit die beteiligten Nodes sie für glaubwürdig halten.. > Ein Kollege hat den CAN-Bus ohne Abschluss-Widerstände betrieben. Hat > auch (meist) funktioniert. Das halte ich für sehr unglaubwürdig. > Jeder darf die Theorie der Elektrotechnik soweit ignorieren, wie es für > ihn passt. Solange er ausschließlich für sich selber bastelt: Ja. Uwe, Klugscheißer
:
Bearbeitet durch User
drm schrieb: > Hat schon jemand (positive) Erfahrungen mit dem USB2CAN Adapter aus > China gemacht ? Funktioniert der vor allem unter Linux am PC oder > Raspberry Pi? Wozu? Um CAN zu debuggen nimm einen Transceiver und einen Saleae-USB-Logikanalysator-Klon. Zur Teilnahme am CAN-Bus schliess einen Transceiver an die entsprechenden GPIO-Ports des RasPi an. LG, Sebastian
Uwe B. schrieb: > Ja, robust. Allerdings geht die Übertragungsrate bei unsachgemäßer > Verkabelung schnell böse in die Knie wenn Messages vielfach gesendet > werden müssen damit die beteiligten Nodes sie für glaubwürdig halten.. Das wiederholte Senden von Messages hört genau dann auf wenn eine! Node sein ok gibt. Ob alle Nodes am Bus die verstanden haben wird nicht überprüft. Bei schlechter Verkabelung kann es sicher passieren dass einige Nodes etwas nicht mitbekommen, das der Bus mit Wiederholungen geflutet wird ist ehr unwahrscheinlich. Wenn dann ist der Bus schon so schlecht dass die sendende Node seine eigene Message nicht mehr lesen kann. Damit ist dein heraufbeschworenes Szenario einfach nur Bullshit. Uwe B. schrieb: > 100k ist ja auch kurz hinter morsen und 40 Meter ist keine nennenswerte > Länge .. Stimmt genau, und deshalb muss man nicht die gleichen Maßstäbe an die Verkabelung stellen wie bei 1MBit und max. Buslänge. Selbst in Autos gibt es Stichleitungen und von der Norm abweichende Abschlusswiderstände. Irgendwo hatte ich mal einen Artikel von Mercedes gelesen wo genau diese Szenarien beschrieben wurden.
mppt schrieb: > Uwe B. schrieb: >> Ja, robust. Allerdings geht die Übertragungsrate bei unsachgemäßer >> Verkabelung schnell böse in die Knie wenn Messages vielfach gesendet >> werden müssen damit die beteiligten Nodes sie für glaubwürdig halten.. > Das wiederholte Senden von Messages hört genau dann auf wenn eine! Node > sein ok gibt. Es gibt noch weitere Mechanismen zur Fehlererkennung welche den Sender zum erneuten Aussenden der Message aufrufen. Und empfangende Nodes auffordern die Message zu verwerfen. > Ob alle Nodes am Bus die verstanden haben wird nicht > überprüft. Bei schlechter Verkabelung kann es sicher passieren dass > einige Nodes etwas nicht mitbekommen, Der große Vorteil des CAN-Protokolls ist daß genau das nicht passiert. > Damit ist dein heraufbeschworenes Szenario einfach nur Bullshit. Kompetenz drückt sich nicht automatisch durch Verwendung der Fäkalsprache aus. Jedenfalls nicht unter erwachsenen Technikern. Uwe
Sebastian schrieb: > drm schrieb: >> Hat schon jemand (positive) Erfahrungen mit dem USB2CAN Adapter aus >> China gemacht ? Funktioniert der vor allem unter Linux am PC oder >> Raspberry Pi? > > Wozu? Um CAN zu debuggen nimm einen Transceiver und einen > Saleae-USB-Logikanalysator-Klon. Hast du das schonmal gemacht, in einem realen Netzwerk mit ein bisschen Verkehr? Das Protokoll selber braucht man nicht zu "debuggen" auf Nachrichtenebene wäre das Hardcore. > Zur Teilnahme am CAN-Bus schliess einen > Transceiver an die entsprechenden GPIO-Ports des RasPi an. der To möchte mit einem Raspberry am CAN-Bus teilnehmen ohne einen GPIO-Port zu belegen. Er hat das geschrieben, du konntest es lesen. Abgesehen davon, du möchtest das CAN-Protokoll auf dem Raspberry in Software nachbauen? Uwe
mppt schrieb: > Uwe B. schrieb: >> Ja, robust. Allerdings geht die Übertragungsrate bei unsachgemäßer >> Verkabelung schnell böse in die Knie wenn Messages vielfach gesendet >> werden müssen damit die beteiligten Nodes sie für glaubwürdig halten.. > > Das wiederholte Senden von Messages hört genau dann auf wenn eine! Node > sein ok gibt. Ob alle Nodes am Bus die verstanden haben wird nicht > überprüft. Doch, natürlich. Sobald ein Node eine ungültige Botschaft auf dem Bus entdeckt, überschreibt er diese mit einem Error Frame. D.h. sobald einer der Teilnehmer die Botschaft nicht lesen kann, ist diese für sämtliche Teilnehmer ungültig und muss neu gesendet werden. Es gibt einen Sicherheitszähler, um zu verhindern dass ein schlecht angeklemmter oder falsch konfigurierter Node grundsätzlich nichts versteht und deshalb den kompletten Datenverkehr anulliert. Es dürfen pro Teilnehmer maximal 7 Error Frames hintereinander gesendet werden, danach müssen erstmal 128 "gute" Botschaften abgewartet werden. So kann man einen Bus allerdings auch zerlegen: wenn irgendwann alle Teilnehmer in Error Passive sind und sich keiner mehr zu senden traut. Ein Steuergerät muss dann die Master-Rolle übernehmen und den Bus wieder hochfahren.
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.