Hallo, wer auf der Suche nach einem preiswerten CAN-Interface ist, wird hier fündig: https://github.com/GBert/misc/tree/master/stm32-slcan Blue Pill + CAN-Transceiver + USB2Serial Adapter = CAN Interface für weniger als 5 Euro :-)
5€? Habe ich was verpasst? Ist das nicht zum Selbermachen? Viele Grüße, Stefan
Stefan K. schrieb: > 5€? Habe ich was verpasst? Ist das nicht zum Selbermachen? > > Viele Grüße, Stefan Jepp - zum Selbermachen :-)
Der STM32F103 ist für ein PC-CAN-Interface keine gute Wahl weil man CAN und USB nicht gleichzeitig nutzen kann. Ich würde eher den STM32F072 vorschlagen, dort gibt es diese Einschränkung nicht.
:
Bearbeitet durch User
Gerd E. schrieb: > Der STM32F103 ist für ein PC-CAN-Interface keine gute Wahl weil > man CAN > und USB nicht gleichzeitig nutzen kann. > > Ich würde eher den STM32F072 vorschlagen, dort gibt es diese > Einschränkung nicht. Stimmt, der STM32F072 wäre besser geeignet. Aber das Blue Pill Board gibt es schon für 1,40 incl. Versand (!) zu kaufen. Ein USB2Serail gibt es ab 1 Euro, auch incl. Versand. Den Preis kriegst Du mit einem STM32F072 Fertig-Board nicht hin. Zudem brauchst Du Dich nicht mit USB-Programmierung rumschlagen. Weiterhin existiert ein SLCAN Trainer für Linux bzw. Windows - dadurch wird alles sehr einfach und schnell umsetzbar. Gruß Gerd
:
Bearbeitet durch User
Gerd B. schrieb: > Aber das Blue Pill Board > gibt es schon für 1,40 incl. Versand (!) zu kaufen. Ein USB2Serail gibt > es ab 1 Euro, auch incl. Versand. Den Preis kriegst Du mit einem > STM32F072 Fertig-Board nicht hin. Ganz ehrlich... Den Preis bekommt man so auch nicht hin. Selbst bei extrem großen Stückzahlen, WIE soll das gehen?
Dennis X. schrieb: > Gerd B. schrieb: >> Aber das Blue Pill Board >> gibt es schon für 1,40 incl. Versand (!) zu kaufen. Ein USB2Serail gibt >> es ab 1 Euro, auch incl. Versand. Den Preis kriegst Du mit einem >> STM32F072 Fertig-Board nicht hin. > Ganz ehrlich... Den Preis bekommt man so auch nicht hin. Selbst bei > extrem großen Stückzahlen, WIE soll das gehen? Wir nicht - aber die Chinesen: https://de.aliexpress.com/item/Free-Shipping-1pcs-lot-STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-For-Arduin0/32498344057.html
:
Bearbeitet durch User
Hat sich denn noch keiner erbarmt ein Wochenende zu investieren und auf einem STM32 einen USB<->CAN Adapter mit echtem USB Interface implementiert, das dann auch mit einem voll ausgelasteten CAN Bus klar kommt (im Gegensatz zu Seriell Interface)? Diese Frickelei ist ja traurig!
Dr. Sommer schrieb: > Hat sich denn noch keiner erbarmt ein Wochenende zu investieren > und auf > einem STM32 einen USB<->CAN Adapter mit echtem USB Interface > implementiert, das dann auch mit einem voll ausgelasteten CAN Bus klar > kommt (im Gegensatz zu Seriell Interface)? Diese Frickelei ist ja > traurig! Die "Frickelei" sprich Umweg über Seriell ist sogar der Garant für die Performance. Bei einem binären Format muss Du Dir Gedanken über das Timing und Zusammenpacken der Frames machen (USB-Frames 8000 Sekunde bei max. 22.000 CAN Frames die Sekunde). Bei Seriell (auch über USB) ist das nur "write and forget". Einzig der USB2Serial Wandler muss ca. 2,5 mal höhere serielle Baudrate machen können. Frech behaupte ich mal das ich mit diesem Ansatz (CAN<->Serial<->USB) jeden kommerziellen CAN-USB Adapter in der Performance (sprich CAN-Pakete pro Sekunde ohne Vertauschungen und Drops) schlage ;-) Gruß Gerd P.S.: Das Gleiche mit PIC (8Bit CPU @ 16MHz by Darron Broad) https://github.com/GBert/misc/tree/master/can-can-test
Gerd B. schrieb: > Bei Seriell (auch über USB) ist das > nur "write and forget". Ja schön, weil der Wandler einen Puffer hat. Überraschung, man kann auch auf einem Mikrocontroller puffern. Gerd B. schrieb: > Frech behaupte ich mal das ich mit diesem Ansatz (CAN<->Serial<->USB) > jeden kommerziellen CAN-USB Adapter in der Performance (sprich > CAN-Pakete pro Sekunde ohne Vertauschungen und Drops) schlage ;-) Weil du glaubst dass kommerzielle Hersteller nicht in der Lage sind Puffer zu implementieren, und deswegen immer bei hohen CAN-Datenraten Paketverlust haben? Ob die professionellen Adapter von z.B. Vector die ca. 1k€ kosten wirklich so schlecht sind? Die Daten vom USB-Seriell Wandler müssen aber auch durch den USB Port. Der Wandler kann also die Performance vom USB Port nicht erhöhen. Und selbst Full Speed USB hat nunmal schon eine viel höhere Datenrate als Seriell...
Ich werfe mal das in die Runde: http://canable.io/ STM32F042C6 Open Source Software, Firmware und Hardware. Firmware: https://github.com/normaldotcom/cantact-fw/archive/fb0f55fd3beb5c66446def5f60fd6e1adcc1178b.zip Hardware: http://hg.protofusion.org/canable/archive/tip.zip LG Stefan
:
Bearbeitet durch User
Gerd B. schrieb: > Stimmt, der STM32F072 wäre besser geeignet. Aber das Blue Pill Board > gibt es schon für 1,40 incl. Versand (!) zu kaufen. Ein USB2Serail gibt > es ab 1 Euro, auch incl. Versand. Den Preis kriegst Du mit einem > STM32F072 Fertig-Board nicht hin. Die STM32F072 gibts für ca. 1,36 EUR in China: https://www.aliexpress.com/item//32467632421.html Ist vielleicht kein Fertig-Board, aber Du brauchst ja eh noch eine Platine für den CAN-TRX und um die ganzen Breakout-Boards zu verbinden. Da kannst Du auch gleich eine nehmen auf der der µC auch mit drauf ist. So ein kleiner STM32 ist ja jetzt kein BGA-Hexenwerk oder ähnliches.
Dr. Sommer schrieb: > Hat sich denn noch keiner erbarmt ein Wochenende zu investieren und auf > einem STM32 einen USB<->CAN Adapter mit echtem USB Interface > implementiert neben dem von Stefan genannten gäbe es z.B. noch dieses hier: http://www.elektronik-keller.de/index.php/projekte/stm32/stm32-can Dort kommt ein STM32F105 zum Einsatz um das Problem mit dem gleichzeitigen USB und CAN beim STM32F103 zu umgehen.
Gerd E. schrieb: > Dr. Sommer schrieb: >> Hat sich denn noch keiner erbarmt ein Wochenende zu investieren und auf >> einem STM32 einen USB<->CAN Adapter mit echtem USB Interface >> implementiert > > neben dem von Stefan genannten gäbe es z.B. noch dieses hier: > http://www.elektronik-keller.de/index.php/projekte/stm32/stm32-can > > Dort kommt ein STM32F105 zum Einsatz um das Problem mit dem > gleichzeitigen USB und CAN beim STM32F103 zu umgehen. stimmt - gibt es auch und - verwendet SLCAN API (serielles Protokoll) ;-)
:
Bearbeitet durch User
Stefan O. schrieb: > Ich werfe mal das in die Runde: http://canable.io/ > > STM32F042C6 > > Open Source Software, Firmware und Hardware. > Firmware: > https://github.com/normaldotcom/cantact-fw/archive/fb0f55fd3beb5c66446def5f60fd6e1adcc1178b.zip > Hardware: http://hg.protofusion.org/canable/archive/tip.zip > > > LG Stefan verwendet auch SLCAN API ;-)
Dr. Sommer schrieb: > Gerd B. schrieb: >> Bei Seriell (auch über USB) ist das >> nur "write and forget". > Ja schön, weil der Wandler einen Puffer hat. Überraschung, man kann auch > auf einem Mikrocontroller puffern. > > Gerd B. schrieb: >> Frech behaupte ich mal das ich mit diesem Ansatz (CAN<->Serial<->USB) >> jeden kommerziellen CAN-USB Adapter in der Performance (sprich >> CAN-Pakete pro Sekunde ohne Vertauschungen und Drops) schlage ;-) > Weil du glaubst dass kommerzielle Hersteller nicht in der Lage sind > Puffer zu implementieren, und deswegen immer bei hohen CAN-Datenraten > Paketverlust haben? Ob die professionellen Adapter von z.B. Vector die > ca. 1k€ kosten wirklich so schlecht sind? Die Adapter sind galv. getrennt entsprechen div. Standards. Sehr gut - keine Frage - aber nicht so schnell. Hast Du schon mal mit so einen USB-Adapter mit max. Geschwindigkeit mit SFF und DLC0 bearbeitet ? Richtige CAN-Adapter werden aus gutem Grund nicht per USB angebunden sondern via PCI&PCIe bzw sind Teil des verwendeten SoCs. Das Delay ist zudem wesentlich geringer. > > Die Daten vom USB-Seriell Wandler müssen aber auch durch den USB Port. > Der Wandler kann also die Performance vom USB Port nicht erhöhen. Und > selbst Full Speed USB hat nunmal schon eine viel höhere Datenrate als > Seriell... Das Problem beim binären Format ist das Framing. Halt kurz inne und denk drüber nach ;-) Skizziere mal, wie so ein Puffer aussehen muss und wie Du Ihn mit dem USB Timing synchronisierst. Bedenke bitte, das Du auch mal 3 CAN Frames in einem USB Frame übertragen musst. Beim seriellen Format: Schreibe/Lese was Du hast. Ein \r ist das Zeichen für einen neuen Frame. Der USB-Adapter überträgt was er gerade hat. Die USB-Geschwindigkeit ist hier nicht das begrenzende Merkmal. Gruß Gerd PS: Herrliche Diskussion :-)
:
Bearbeitet durch User
Gerd B. schrieb: > Die Adapter sind galv. getrennt entsprechen div. Standards. Auch die nichtisolierenden sind so teuer. Bestimmt nicht weil die Frames verlieren. > Sehr gut - > keine Frage - aber nicht so schnell. Hast Du schon mal mit so einen > USB-Adapter mit max. Geschwindigkeit mit SFF und DLC0 bearbeitet ? Nein, was ist das? Small Form Factor, was hat das damit zu tun? Ich hatte nur mal einen fast vollen CAN Bus, war natürlich kein Problem. > > Richtige CAN-Adapter werden aus gutem Grund nicht per USB angebunden > sondern via PCI&PCIe bzw sind Teil des verwendeten SoCs. Das Delay ist > zudem wesentlich geringer. USB HS kann 480 MBit/s, und das soll nicht für einen popeligen CAN mit 1 MBit/s reichen?! Nur das Delay ist hier ein Argument. > >> >> Die Daten vom USB-Seriell Wandler müssen aber auch durch den USB Port. >> Der Wandler kann also die Performance vom USB Port nicht erhöhen. Und >> selbst Full Speed USB hat nunmal schon eine viel höhere Datenrate als >> Seriell... > > Das Problem beim binären Format ist das Framing. Halt kurz inne und denk > drüber nach ;-) Denkst du überhaupt nach? > Skizziere mal, wie so ein Puffer aussehen muss 4 Bytes für ID und Flag, 8 Bytes für Daten, wo ist das Problem? Könnte man z.B. 1:1 so machen wie in der CAN-Peripherie vom STM32. > und wie > Du Ihn mit dem USB Timing synchronisierst. Bedenke bitte, das Du auch > mal 3 CAN Frames in einem USB Frame übertragen musst. Gar nichts muss ich. Ein Ring-Puffer ist jetzt keine grandiose neue Erfindung. Damit kriegt man vieles synchronisiert. Nichts anderes arbeitet auch in deinen hochgelobten USB-Serial-Adaptern. Ein USB End Point ist letztendlich nur ein serieller Bytestrom, wie beim UART. Da kann man auch beliebig Puffer binär oder ascii übertragen. > > Beim seriellen Format: Schreibe/Lese was Du hast. Ein \r ist das Zeichen > für einen neuen Frame. Oder man lässt das Frame nach DLC+4 Bytes enden, dann spart man das \r und vereinfacht das Parsen. Was hat überhaupt ASCII vs. binär mit Serial vs. USB zu tun?! Man kann binäre und ASCII Daten beliebig über Serial oder USB übertragen. Effizienter ist es natürlich in beiden Fällen, die Daten direkt binär zu übertragen. > Der USB-Adapter überträgt was er gerade hat. Ja und? Der USB-Controller nicht? Erkläre mal bitte, wieso ein USB-Serial-Adapter die Qualität/Geschiwndigkeit des USB (FS)-Busses magisch erhöhen soll, und dann auch noch schneller als USB HS? Was passiert deiner Logik nach, wenn man den UART einspart und den virtuellen Serial Port direkt auf dem Mikrocontroller implementiert? Wird es dann auch magisch schneller als wie wenn ich die CAN Daten "direkt" übertrage? > Die USB-Geschwindigkeit ist hier nicht das begrenzende Merkmal. Sondern, das Karma? > PS: Herrliche Diskussion :-) In der Tat! Trollst du nur oder glaubst du wirklich was du hier verzapfst?
Gerd B. schrieb: > Sehr gut - > keine Frage - aber nicht so schnell. PS: Hier das Manual der Vector VN16 Reihe: http://vector.com/portal/medien/cmc/factsheets/VN16xx_FactSheet_EN.pdf "Flexible FPGA-based CAN and LIN implementation allows 100% bus load on all channels" "Fast baudrates: CAN (max. 2 Mbit/s), CAN FD (max. 8 Mbit/s) and LIN (max. 330 kbit/s)" "USB 2.0 High-speed" Spricht für sich denke ich. Als Marktführer wird Vector da kaum lügen.
Gerd B. schrieb: > Das Problem beim binären Format ist das Framing. Halt kurz inne und denk > drüber nach ;-) Skizziere mal, wie so ein Puffer aussehen muss und wie > Du Ihn mit dem USB Timing synchronisierst. Bedenke bitte, das Du auch > mal 3 CAN Frames in einem USB Frame übertragen musst. Ich vermute Dir fehlt hier ein wenig die programmiertechnische Fantasie. Die CAN-Hardware und die USB-Hardware im STM32 haben jeweils eigene, voneinander unabhängige Puffer. Die bedienst Du am besten per DMA, geht aber auch ohne. Damit laufen CAN und USB asynchron zueinander. Der Core kümmert sich nur drum die jeweiligen Frames zu analysieren, die Daten umzupacken und wieder auf die Reise zu schicken. Währenddessen laufen die beiden Hardware-Einheiten unabhängig voneinander weiter. Händisch irgendwelche CAN-Frames mit USB-Frames synchronisieren zu wollen ist dagegen kein geeigneter Ansatz. Das einzige Thema ist die Latenz die bedingt durch das USB dazukommt. Dagegen braucht man vielleicht in ganz wenigen Ausnahmefällen so eine PCIe-Karte. Diese Latenz betrifft Deinen USB/Seriell-Wandler aber ganz genauso wie einen µC der das USB selbst bedient.
Gerd E. schrieb: > Gerd B. schrieb: >> Das Problem beim binären Format ist das Framing. Halt kurz inne und denk >> drüber nach ;-) Skizziere mal, wie so ein Puffer aussehen muss und wie >> Du Ihn mit dem USB Timing synchronisierst. Bedenke bitte, das Du auch >> mal 3 CAN Frames in einem USB Frame übertragen musst. > > Ich vermute Dir fehlt hier ein wenig die programmiertechnische Fantasie. > > Die CAN-Hardware und die USB-Hardware im STM32 haben jeweils eigene, > voneinander unabhängige Puffer. Die bedienst Du am besten per DMA, geht > aber auch ohne. > > Damit laufen CAN und USB asynchron zueinander. Der Core kümmert sich nur > drum die jeweiligen Frames zu analysieren, die Daten umzupacken und > wieder auf die Reise zu schicken. Währenddessen laufen die beiden > Hardware-Einheiten unabhängig voneinander weiter. Wahrscheinlich fehlt mir dazu die Fantasie ;-) Gerne würde ich so eine Implementierung mal sehen. Also: Wer schreibt das mal schnell an einem Wochenende ? Gruß Gerd
Dr. Sommer schrieb: > Gerd B. schrieb: >> Sehr gut - >> keine Frage - aber nicht so schnell. > PS: > Hier das Manual der Vector VN16 Reihe: > http://vector.com/portal/medien/cmc/factsheets/VN16xx_FactSheet_EN.pdf > "Flexible FPGA-based CAN and LIN implementation allows 100% bus load on > all channels" > "Fast baudrates: CAN (max. 2 Mbit/s), CAN FD (max. 8 Mbit/s) and LIN > (max. 330 kbit/s)" > "USB 2.0 High-speed" > > Spricht für sich denke ich. Als Marktführer wird Vector da kaum lügen. OK. Die sind schnell genug. Gruß Gerd
Gerd B. schrieb: > Gerne würde ich so eine Implementierung mal sehen In erster Näherung genau wie beim Serial Port. Die Ausgabe schickst du aber nicht direkt in die Peripherie Register, sondern in einen Ringpuffer. Der wird dann asynchron per USB verschickt. Die Implementierung von Ringpuffern gibt's im Internet zuhauf. Gerd E. schrieb: > Händisch irgendwelche CAN-Frames mit USB-Frames synchronisieren zu > wollen ist dagegen kein geeigneter Ansatz. Danke für diesen Beitrag, so meinte ich das und mit fehlten die Worte...
Schöne Diskussion, aber hat von euch schon mal wer in die von mir verlinkten git sources geschaut? Dort wird meiner Meinung nach genau das gemacht wovon ihr hier schreibt. CAN und USB Peripherie initialisieren. Pakete annehmen, umpacken weiterschicken und das in beide Richtungen. Ein paar Zeilen Code (abgesehen von dem ganzen Elend der für USB Descriptoren und Co notwendig ist) LG
Dr. Sommer schrieb: >> Richtige CAN-Adapter werden aus gutem Grund nicht per USB angebunden >> sondern via PCI&PCIe bzw sind Teil des verwendeten SoCs. Das Delay ist >> zudem wesentlich geringer. > USB HS kann 480 MBit/s, und das soll nicht für einen popeligen CAN mit 1 > MBit/s reichen?! Nur das Delay ist hier ein Argument. Bis vor einiger Zeit waren USB CAN Interfaces, welche USB-HS nutzen noch Mangelware. Aber so langsam wird es besser und entschärft so das Problem. dass USB der Flaschenhals ist. Und auch das Delay-Problem entschärft sich etwas.
Dr. Sommer schrieb: > Gerd B. schrieb: >> Gerne würde ich so eine Implementierung mal sehen > > In erster Näherung genau wie beim Serial Port. Die Ausgabe schickst du > aber nicht direkt in die Peripherie Register, sondern in einen > Ringpuffer. Der wird dann asynchron per USB verschickt. Die > Implementierung von Ringpuffern gibt's im Internet zuhauf. Ringbuffer ist mir ein Begriff. Verwendet auch der verlinkte Code. > > Gerd E. schrieb: >> Händisch irgendwelche CAN-Frames mit USB-Frames synchronisieren zu >> wollen ist dagegen kein geeigneter Ansatz. > > Danke für diesen Beitrag, so meinte ich das und mit fehlten die Worte... Keine Frage - eine reine USB Implementierung mit STM32F105 oder STM32F0x2 sind sicherlich eine reizvolle Aufgabe. Ein Lösung mit SLCAN hätte den Vorteil, da es fertige Treiber bzw. Software bereits zuhauf existieren. Ein Protokoll auf binärer Basis (ohne den Umweg über ASCII) ist der Königsweg. Für Linux ist es aber nicht trivial, einen Treiber dafür zu bauen und in den offiziellen Kernel zu bekommen. Aber zurück zum eigentlichen Thema: Preiswerter CAN-Adadpter mit Blue Pill sprich billigst Board. Alle Schmähungen und Buhrufen zum Trotz: Diese 5€ Lösung kann es mit gekauften Adapter aufnehmen und sticht diese teilweise aus (abgemilderte Provokation ;-) ! Gruß Gerd
:
Bearbeitet durch User
Billige UART-USB-Wandler haben kein Flowcontrol und sind weniger zuverlässig bei hohen Baudraten. Mit 1MBit CAN und SLCAN ist 3 MBit Datenrate erforderlich. Bei einem klassischen USB-Device ist der Treiber ein Thema. Ideal wäre also eine direkte USB-Verbindung, bei der sich das USB-Gerät trotzdem als virtueller COM/tty beim USB-Host meldet und SLCAN spricht.
Hier gibt es eine gute alternative: https://github.com/HubertD/candleLight_fw Vorteil: USB <-> CAN mit guter Linux SocketCAN Unterstützung Nachteil: Entsprechende Boards sind weniger verfügbar bzw. teurer
Gerd B. schrieb: > Hier gibt es eine gute alternative: > https://github.com/HubertD/candleLight_fw > > Vorteil: USB <-> CAN mit guter Linux SocketCAN Unterstützung > Nachteil: Entsprechende Boards sind weniger verfügbar bzw. teurer Und so ein kleiner stm32f042 verdaut 1Mbps-ssf-dlc0 ohne Probleme?
Gerd, wo genau kann ich alle erforderlichen Bauteile (inkl. PCB, falls ich selbst aufbauen soll) kaufen? Nutzt Du Deinen Lösungsvorschlag noch selbst, nun nach 2,5 Jahren? Bis zu welcher Bus-Geschwindigkeit gibt es bei 100% Buslast keinen Verlust?
Wie wäre dieses STM32F303 Board?: http://stefanfrings.de/stm32/stm32f3.html#stm32f3mini Das kann auch USB und CAN gleichzeitig. Das Programm muss natürlich an den Mikrocontroller angepasst werden.
Gerd E. schrieb: > Der STM32F103 ist für ein PC-CAN-Interface keine gute Wahl weil man CAN > und USB nicht gleichzeitig nutzen kann. Habe es nicht ausprobiert, aber wenn ich CubeMX bemühe geht es mit dem 103er doch. Erst USB aktivieren, dann CAN. In dem Fall wird CAN auf PB8/PB9 gemappt.
Martin B. schrieb: > Habe es nicht ausprobiert, aber wenn ich CubeMX bemühe geht es mit dem > 103er doch. Erst USB aktivieren, dann CAN. Nur weil sich die Pins nicht überschneiden, heißt das nicht dass es geht! Zitat RefMan: In low, medium-, high- and XL-density devices the USB and CAN share a dedicated 512-byte SRAM memory for data transmission and reception, and so they cannot be used concurrently (the shared SRAM is accessed through CAN and USB exclusively). The USB and CAN can be used in the same application but not at the same time. Also ziemlich nutzlos als USB-CAN-Adapter.
Angehängte Dateien:
Martin B. schrieb: > Habe es nicht ausprobiert, aber wenn ich CubeMX bemühe geht es mit dem > 103er doch. Erst USB aktivieren, dann CAN. In dem Fall wird CAN auf > PB8/PB9 gemappt. Das funktioniert aber nicht, weil beide Schnittstellen sich den selben Pufferspeicher teilen. Wenn man mit dem Referenzhandbuch arbeiten würde, anstatt mit Cube MX spielen würde, wüsste man das.
Stefanus F. schrieb: > Wie wäre dieses STM32F303 Board?: > http://stefanfrings.de/stm32/stm32f3.html#stm32f3mini > Das kann auch USB und CAN gleichzeitig. > > Das Programm muss natürlich an den Mikrocontroller angepasst werden. Es mangelt nicht an Boards, die CAN und USB gleichzeitig können, sondern an einer SW-Implemtierung für selbige, bei der auf PC-Seite keine (sonstigen) Treiber erforderlich sind (virtuelles serial). Und im Falle von Gerds Ansatz wäre ein Board mit integriertem USB-UART sinnvoll, bei dem hardware flow control enthalten ist. Ein Vorteil von CAN ist ja gerade die hohe Zuverlässigkeit. Da wäre es ungeschickt, dann die Pakete im Adapter zu verlieren.
:
Bearbeitet durch User
Lars R. schrieb: > Es mangelt nicht an Boards, die CAN und USB gleichzeitig können, sondern > an einer SW-Implemtierung für selbige, bei der auf PC-Seite keine > (sonstigen) Treiber erforderlich sind (virtuelles serial). Was den USB Teil angeht, habe ich auf der selben Webseite weiter unten die USB CDC Implementierung von W.S. in angepasster Form veröffentlicht. Flow Control (im Sinne der virtuellen seriellen) ist da nicht mit drin.
Lars R. schrieb: > Es mangelt nicht an Boards, die CAN und USB gleichzeitig können, sondern > an einer SW-Implemtierung für selbige, bei der auf PC-Seite keine > (sonstigen) Treiber erforderlich sind (virtuelles serial). Virtuelle Serial-Ports sind eine Krücke. Die machen nur alles komplizierter und fehleranfälliger. Dank WinUSB und libusb braucht man auch für eigene USB-Geräte mit "richtigem" USB-Protokoll keine Treiber.
Ich denke, bei USB CDC braucht es kein flow control, wenn die Buffer groß genug sind. Physikalisch gibt es ja keine limitierende Baudrate mehr für diese Anwendung. Dr. Sommer schrieb: > Lars R. schrieb: >> Es mangelt nicht an Boards, die CAN und USB gleichzeitig können, sondern >> an einer SW-Implemtierung für selbige, bei der auf PC-Seite keine >> (sonstigen) Treiber erforderlich sind (virtuelles serial). > > Virtuelle Serial-Ports sind eine Krücke. Die machen nur alles > komplizierter und fehleranfälliger. In welcher Hinsicht? Der Ansatz von Stefanus/W.S. sieht doch gut aus.
Dr. Sommer schrieb: > Dank WinUSB und libusb braucht man > auch für eigene USB-Geräte mit "richtigem" USB-Protokoll keine Treiber. Ein Tutorial dazu wäre mal was feines, und zwar eins für Leute, die mit dem USB Protokoll an sich noch nicht vertraut sind. Ich jedenfalls weiß über USB nicht viel mehr, als wie herum man den Stecker einstecken muss. Diese Technik ist für Hobbyelektroniker schwer zugänglich. Ethernet kommt mir da viel zugänglicher vor.,
Lars R. schrieb: > In welcher Hinsicht? Der Ansatz von Stefanus/W.S. sieht doch gut aus. Man wirft die von USB gratis gebotene Fluss Kontrolle und Paketierung weg. Auf PC Seite muss man sicher stellen den richtigen COM Port zu öffnen. Man muss sich mit FIFO-puffern im Treiber rumschlagen. Man hat nur einen "Endpoint". Man muss sich was ausdenken um den Anfang einer Kommunikation/Paket zu finden. usw usf. Stefanus F. schrieb: > Ein Tutorial dazu wäre mal was feines, und zwar eins für Leute, die mit > dem USB Protokoll an sich noch nicht vertraut sind. Äh... Du kennst doch das Tutorial im Wiki?
Stefanus F. schrieb: > Diese Technik ist für Hobbyelektroniker schwer zugänglich Weil alle USB-Spezifikationen offen runterzuladen sind? Weil zumindest USB-LS/FS kaum Hardware braucht (übertrager usw)? Weil man nicht ein Dutzend Protokolle beherrschen muss (Ethernet, ARP, IP, DHCP, AUTOIP, DNS, TCP, UDP, ICMP...)? Weil man sich nicht den Kopf über einen Konfigurations/Discovery Mechanismus zerbrechen muss? Weil man sich nicht mit Firewalls rumschlagen muss?
Dr. Sommer schrieb: > Äh... Du kennst doch das Tutorial im Wiki? Ja, von dem verstehe ich immer noch höchstens 50%. Mit fehlt da auch der Teil der PC Programmierung, und zwar für Linux, Windows und Mac.
Stefanus F. schrieb: > Mit fehlt da auch der Teil der PC Programmierung, und zwar für Linux, > Windows und Mac. https://www.mikrocontroller.net/articles/USB-Tutorial_mit_STM32#Eigene_Anwendung_f.C3.BCr_PC-Seite
Oh, dieses Tutorial kannte ich noch nicht. Sieht vielversprechend aus.
Lars R. schrieb: > Gerd, wo genau kann ich alle erforderlichen Bauteile (inkl. PCB, falls > ich selbst aufbauen soll) kaufen? BluePill bekommst Du über ebay oder Aliexpress. Die restlichen Bauteile über Reichelt z.B. . > > Nutzt Du Deinen Lösungsvorschlag noch selbst, nun nach 2,5 Jahren? > Bis zu welcher Bus-Geschwindigkeit gibt es bei 100% Buslast keinen > Verlust? ich nutze den Lösungsvorschlag nicht mehr. Ich nehme entweder: http://lnxpps.de/bpi/ https://github.com/GBert/misc/blob/master/RPi-MCP2515/README.md zusehends auch: https://github.com/GBert/misc/blob/master/RPi-MCP2517/README.md bzw. PIC18F25K80 in Verbindung mit Linux-Mini Rechnern wie Omega2+: http://lnxpps.de/can2udp/srseII/pictures/omega2-first-board-01.jpg Ein Vorteil des PICs ist, das dieser in der Schaltung einfach und schnell upgedated werden kann. Aufgrund der überschaubare Auslastung übernimmt der PIC auch noch andere Aufgaben.
Stefanus F. schrieb: > Wie wäre dieses STM32F303 Board?: > http://stefanfrings.de/stm32/stm32f3.html#stm32f3mini > Das kann auch USB und CAN gleichzeitig. > > Das Programm muss natürlich an den Mikrocontroller angepasst werden. könnte klappen. Alternativ gibt es noch dieses: https://www.electrodragon.com/product/can-usb-debugger-board/ Mit integrierter SLCAN Firmware. Ich habe das Board zwar, aber habe es bisher nicht ausführlich getestet.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.