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.
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/
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
>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.
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.
Wenn diese Chip-Krise nicht wäre...
https://github.com/RudolphRiedel/USB_CAN-FDhttps://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.
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?
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
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.
usb2can-adapter.jpg
(31 KB)
