Der perfekte USB-UART-Konverter

[Bauform B. (bauformb)]

existiert nicht. Mahlzeit!

kaum einer hat eine eindeutige Seriennummer. Die meisten brauchen unter 
Windows einen Treiber vom Hersteller, obwohl Windows inzwischen cdc-acm 
spricht? Und wenn man sonst keine Macken findet, kommt das Teil im 
QFN-Gehäuse daher.

Bei den FT232R und XR21B1411 hab' ich bis jetzt nur je einen Nachteil 
gefunden - Windows-Treiber bzw. QFN-16. Wobei die Hälfte der Pins beim 
FT232R ziemlich überflüssig ist und 16 QFN-Pins vielleicht gerade noch 
lötbar sind.

Das ist die erste Frage: ist QFN mit weniger Pins wirklich 
zuverlässiger? Weniger mögliche Kurzschlüsse ist ja klar, aber bei 
mechanischer Belastung und Temperaturwechseln? Und, kann man die Platine 
irgendwie QFN-freundlich gestalten? Könnte eine Art Breakout-Board 
helfen, weil da viel weniger FR4 gegen die Lötstellen arbeiten kann?

Zweitens könnte man mal Ungereimtheiten und Überraschungen mit solchen 
Chips sammeln:

FT2* (außer FT232R) brauchen Längswiderstände in D+ und D- und einen 
externen Quarz, der FT2232D sogar 6(!)MHz. Und sie brauchen je 47p von 
D+ und D- nach GND -- ESD-Schutz soll immer möglichst C-arm sein und 
dann das?

CP21*: die meisten sind abgekündigt, der CP2102 heißt jetzt CP2102N
CP2105: der interne LDO liefert 3.45V; der Default der Seriennummer ist 
"Unique 8 character ASCII string", ABER: "Customizing the serial string 
for each individual device is also recommended if the OEM application is 
one in which it is possible for multiple CP210x-based devices to be 
connected to the same PC."

XR21V14*: das Datenblatt erwähnt die Seriennummer mit keiner Silbe

XR21B142*: "in the Windows OS, an extra INF file is required to install 
the CDC-ACM driver. The custom drivers must also be installed, although 
for Windows 7 OS and newer with Internet access and Windows updates set 
to automatic, the latest Windows-Certified (WHQL/HCK) driver will be 
downloaded and installed automatically."

XR21V1414: als Exar von Infineon gekauft wurde, hat die ganze 
XR21-Familie neue Datenblätter bekommen, nur dieser eine nicht. 
Gleichzeitig ist es der einzige in einem LQFP-Gehäuse. Ist das jetzt 
eine Form der Abkündigung?

STM32: man muss jedes Bit der USB-Register vergleichen, um die passende 
Firmware zu finden (es gibt mindestens ein halbes Dutzend Varianten). 
Und dann ist das nur eine Demo-Version oder man braucht das komplette 
CubeMX oder beides. Gibt es hier im Forum evt. USB-Firmware für neuere 
STM32?

[Frank K. (fchk)]

Deswegen verwende ich MCP2200 und MCP2221A. CDC-ACM/HID Devices, gibts 
in SOIC und DIP, funktioniert für mich, auch an Mac und Linux. Der 
MCP2221A braucht keinen Quarz, kann noch I2C, hat aber kein RTC/CTS.

fchk

[Stefan F. (Gast)]

Bauform B. schrieb:
> existiert nicht.

Vielleicht solltest du mal an deinen seltsam überzogenen Anforderungen 
arbeiten.

> Wobei die Hälfte der Pins beim FT232R ziemlich überflüssig ist

Na und? Hauptsache der Chip passt ins Gerät. Wenn dein Gerät dafür zu 
klein ist, dann ist USB vielleicht ohnehin keine sinnvolle 
Schnittstelle.

> Weniger mögliche Kurzschlüsse ist ja klar, aber bei
> mechanischer Belastung und Temperaturwechseln?

Das ist albern. Bei normal produzierten Platinen entstehen nicht spontan 
Kurzschlüsse.

> FT2* (außer FT232R) brauchen Längswiderstände in D+ und D-

Na und? Kannst du dir keine Widerstände leisten?

> und einen externen Quarz, der FT2232D sogar 6(!)MHz

Es gibt ja extra für dich auch welche ohne Quarz. Abgesehen davon 
arbeiten USB Schnittstellen mit Quarz im allgemeinen zuverlässiger, als 
die ohne. Das ist hier schon oft diskutiert worden.

> Und sie brauchen je 47p von D+ und D- nach GND
> ESD-Schutz soll immer möglichst C-arm sein

Wer sagt das denn? Kondensatoren sind ziemlich wirksam wenn es darum 
geht, kleine kurze Ladungen aufzunehmen.

> CP21*: die meisten sind abgekündigt, der CP2102 heißt jetzt CP2102N
> CP2105: der interne LDO liefert 3.45V

Das kann dir doch egal sein, solange der Chip damit funktioniert. Wenn 
deiner Schaltung 3,45V zu viel sind, nimm dafür halt einen eigenen 
Spannungsregler, wie andere es auch normalerweise tun.

> "Unique 8 character ASCII string"
> ABER: "Customizing the serial string for each individual
> device is also recommended if the OEM application is
> one in which it is possible for multiple CP210x-based devices to be
> connected to the same PC."

Das kommt auf deine Anwendung an. Mit einem guten namen könnte die 
Anwendung zum Beispiel alle "USB Lichterketten" von "Arduino Board" 
unterscheiden. Ob du das brauchst ist deine Sache. Du kannst sie selbst 
konfigurieren oder bereits nach deinen Wünschen vom Hersteller liefern 
lassen. Wo ist also das Problem?

> STM32: man muss jedes Bit der USB-Register vergleichen, um die passende
> Firmware zu finden (es gibt mindestens ein halbes Dutzend Varianten).

Blödsinn. Bei CUbe HAL stellst du das Modell des Mikrocontrollers ein 
und bekommst automatisch den richtigen Code dazu. Außerdem gibt es die 
Appnote 4879, welche die Unterschiede zwischen den vier USB Varianten 
beschreibt und 100% klar angibt, welches STM32 Modell welche der drei 
Varianten enthält.

> Und dann ist das nur eine Demo-Version

Nun, es gibt viele Chips da bekommst du vom Hersteller gar keine 
kostenlosen Programmbeispiele.

> oder man braucht das komplette CubeMX oder beides.

Na und? Du benutzt auch ein komplettes Windows (oder Linux oder was auch 
immer) obwohl du nur einen Bruchteil davon brauchst.

Du blockierst dich selbst mit deiner hohen Erwartungshaltung.

[Kevin M. (arduinolover)]

Also ich finde QFN ist eines der besten Gehäuse, aktuell probiere ich 
mich an BGAs mit 0,8mm Pitch.

Was viel wichtiger als die Frage nach dem perfekten USB zu UART 
Converter wäre wann Analog endlich einen USB Isolator mit 480MBit raus 
bringt. Das wollen die gefühlt schon seit 2017/18, ist ein bisschen die 
neue Kernfusion.

Abgesehen davon muss man heute für allen Scheiß Treiber installieren, da 
regt sich auch keiner auf.

[Thomas Z. (usbman)]

Inzwischen mach mir die in der Regel selbst. Meistens auf Basis der 
CH552 als CDC. Funktioniert seit Win 8 out of the box mit extra inf auch 
ab XP. Die Chips gibts im SO16/TSSSOP20/MSOP10 Gehäuse.
Die Seriennummer generiere aus der chipinternen 40Bit Nummer. Nachteil: 
max 115k Baud.
Neben Spezialvarianten sind auch Dual CDCs möglich. Quarz ist nicht 
notwendig. Der Preis von 0.28 Euro / Chip ist auch interessant.

Ich hab mir gerade Platinen gemacht. Da kann u.A ein Dual CDC oder Dual 
Midi installiert werden. Auf der Rückseite ist dann noch ein optionales 
SPI Flash.

[Harald (Gast)]

Wie wäre es mit dem FT230XS. Hat alle Basics, die man meist so braucht. 
TSSOP16, einfach lötbar.

[Stefan F. (Gast)]

Harald schrieb:
> Wie wäre es mit dem FT230XS. Hat alle Basics, die man meist so braucht.
> TSSOP16, einfach lötbar.

16 Pins sind ihm zu viele - so habe ihn jedenfalls verstanden.

[Harald (Gast)]

Stefan ⛄ F. schrieb:
> 16 Pins sind ihm zu viele - so habe ihn jedenfalls verstanden.

Ja kann auch sein. Ich dachte, ihn stören 16 Pin QFN. TSSOP ist ja bei 
Handlötung etwas einfacher (kommst aber auch sehr auf die verwendete 
Löttechnik an).

[Bauform B. (bauformb)]

Frank K. schrieb:
> Deswegen verwende ich MCP2200 und MCP2221A.

Danke für diese witzigen Expemplare, die passen gut in meine Sammlung. 
Die können ja nicht einmal Parity, nur 8N1. Und der MCP2200 braucht auch 
noch einen Quarz.


Stefan ⛄ F. schrieb:
> Bauform B. schrieb:
>> Weniger mögliche Kurzschlüsse ist ja klar, aber bei
>> mechanischer Belastung und Temperaturwechseln?
>
> Das ist albern. Bei normal produzierten Platinen entstehen nicht spontan
> Kurzschlüsse.

Kurzschlüsse vielleicht nicht so sehr, vor allem entstehen 
Unterbrechungen und das ist wirklich nicht albern.
https://www.dfrsolutions.com/hubfs/Resources/services/The-Reliability-Challenges-of-QFN-Packaging.pdf?t=1502980151115
oder mit mehr Bildern ;)
http://asq.org/reliability/manufacturability-and-reliability-cchallanges-with-qfn.pdf

Stefan ⛄ F. schrieb:
> Na und?
> Du blockierst dich selbst mit deiner hohen Erwartungshaltung.

Was an "perfekt" oder "Ungereimtheiten und Überraschungen" hast du nicht 
verstanden? Warum soll man sich mit weniger zufrieden geben?

Kevin M. schrieb:
> Abgesehen davon muss man heute für allen Scheiß Treiber installieren, da
> regt sich auch keiner auf.

Siehe oben; cdc-acm funktioniert. Wenn der Chip das nicht kann, gibt es 
Minuspunkte.

> Was viel wichtiger als die Frage nach dem perfekten USB zu UART
> Converter wäre wann Analog endlich einen USB Isolator mit 480MBit raus
> bringt. Das wollen die gefühlt schon seit 2017/18, ist ein bisschen die
> neue Kernfusion.

Inzwischen ist das eher "man muss dem Problem nur Zeit lassen, dann 
erledigt es sich von selbst". Mit USB3 wird so ein Isolator wieder viel 
einfacher (wegen getrennter RX- und TX-Leitungen).

[Bauform B. (bauformb)]

Thomas Z. schrieb:
> CH552, Nachteil: max 115k Baud.

Un.glaub.lich. Na gut, es gibt auch dafür Anwendungen. Aber der hat noch 
einen anderen Nachteil :)
https://www.digikey.de/products/de?keywords=ch552
und Mouser kennt den auch nicht. Leider verloren.


Harald schrieb:
> Wie wäre es mit dem FT230XS.

den hatten wir schon unter FT2*, der braucht jede Menge spezielles 
Hühnerfutter.


Harald schrieb:
> Stefan ⛄ F. schrieb:
>> 16 Pins sind ihm zu viele - so habe ihn jedenfalls verstanden.
>
> Ja kann auch sein. Ich dachte, ihn stören 16 Pin QFN.

Mich stören 28 Pins (z.B. FT232R) wenn 16 auch reichen. Ganz unabhängig 
davon sind mir Gehäuse ohne richtige Pins suspekt. Bis gestern war es 
noch eindeutig: QFN und BGA kommen mir nicht ins Haus. Heute gibt es 
gute USB-UART-Chips nur im QFN :(

[Kevin M. (arduinolover)]

Bauform B. schrieb:
> Heute gibt es gute USB-UART-Chips nur im QFN :(

Das wird nicht besser die Zeiten von THT neigen sich dem Ende, zumindest 
in vielen Bereichen. Und selbst irgendwelche SO Packages werden immer 
weniger bei so spezialisierten Chips.

[Uschi (Gast)]

Stefan ⛄ F. schrieb:
> Na und? Du benutzt auch ein komplettes Windows (oder Linux oder was auch
> immer) obwohl du nur einen Bruchteil davon brauchst.

Dafür gibt es Ubuntu Core :)

[PittyJ (Gast)]

Bauform B. schrieb:
> STM32: man muss jedes Bit der USB-Register vergleichen, um die passende
> Firmware zu finden (es gibt mindestens ein halbes Dutzend Varianten).
> Und dann ist das nur eine Demo-Version oder man braucht das komplette
> CubeMX oder beides. Gibt es hier im Forum evt. USB-Firmware für neuere
> STM32?

Ich benutze die USB Hal Routinen. Ging auf Anhieb. Ich wüßte jetzt 
nicht, was man in USB-Registern vergleichen muss.

Ach ja, die USB-Serial Adapter betreibe ich am liebsten mit einem Raspi. 
Keine Treiber notwendig. Anschliessen, und es geht.
Warum so viele Leute auf dieser Ebene mit Windows arbeiten, verstehe ich 
nicht.

[Yalu X. (yalu) (Moderator)]

Bauform B. schrieb:
> Der perfekte USB-UART-Konverter

> Die meisten brauchen unter Windows einen Treiber vom Hersteller,
> obwohl Windows inzwischen cdc-acm spricht?

Ein reiner USB-UART-Konverter, der vorgibt, ein CDC-ACM (also ein Daten-
oder Faxmodem) zu sein, ist nicht perfekt, sondern verstößt gegen die
USB-CDC-Spezifikation.

Wenn Windows nach gefühlten 20 Jahren immer noch keine vorinstallierten
Treiber dafür hat, liegt das Problem nicht am Konverter, sondern an
Windows bzw. Microsoft.

Ich sehe darin aber kein großes Problem, denn Treiberinstallation gehört
ja zum tägliche Brot jedes Windows-Users und ist deswegen eine Sache von
wenigen Minuten.

[Stefan F. (Gast)]

Bauform B. schrieb:
> Warum soll man sich mit weniger zufrieden geben?

Naja, wenn es das Perfekte Bauteil offenbar nicht gibt, dann muss man 
sich mit weniger zufrieden geben. Oder man kommt nicht voran.

[Harald (Gast)]

Bauform B. schrieb:
> den hatten wir schon unter FT2*, der braucht jede Menge spezielles
> Hühnerfutter.

Der FT230XS (nicht zu verwechseln mit dem FTDI Standardprodukt) braucht 
außer einem Abblockkondensator überhaupt nichts.

Bauform B. schrieb:
> Mich stören 28 Pins (z.B. FT232R) wenn 16 auch reichen.

Der FT230XS hat 16 Pins (SSOP)

[Willi (Gast)]

Bauform B. schrieb:
> den hatten wir schon unter FT2*, der braucht jede Menge spezielles
> Hühnerfutter.

Nicht dein ernst ... was ist an einem Widerstand oder an einem 
Kondensator speziell? Was hast du genau vor bei deinen speziellen 
Anforderungen

[W.S. (Gast)]

Yalu X. schrieb:
> Wenn Windows nach gefühlten 20 Jahren immer noch keine vorinstallierten
> Treiber dafür hat, liegt das Problem nicht am Konverter, sondern an
> Windows bzw. Microsoft.

Es liegt weder an Windows noch an Microsofts (vermuteter) Unfähigkeit.

Passende Treiber hat Windows seit langem, aber die Vorschriften, die das 
USB-Konsortium für sich selbst ausgeheckt hat, bewirken letztlich, daß 
ein jeder seine vid und pid gegen Geld zu erwerben hat und seinem 
Produkt selbige im Installationspaket mitzugeben hat.

Ob ich das nun bescheuert oder gar widerlich finde, interessiert die 
anderen nicht.

Und daß Linux dafür nicht abgemahnt wird, liegt wohl nur daran, daß man 
die richtige Adresse dafür nicht findet.

W.S.

[Yalu X. (yalu) (Moderator)]

W.S. schrieb:
> Es liegt weder an Windows noch an Microsofts (vermuteter) Unfähigkeit.
>
> Passende Treiber hat Windows seit langem, aber die Vorschriften, die das
> USB-Konsortium für sich selbst ausgeheckt hat, bewirken letztlich, daß
> ein jeder seine vid und pid gegen Geld zu erwerben hat und seinem
> Produkt selbige im Installationspaket mitzugeben hat.

Das würde doch Microsoft nicht verbieten, den Treiber des Herstellers
(sofern dieser damit einverstanden ist) mitsamt der VID und PID in das
Windows-Installationspaket zu übernehmen, so wie dies für viele andere
Treiber ja ebenfalls gemacht wird?

W.S. schrieb:
> Und daß Linux dafür nicht abgemahnt wird,

Weswegen genau sollte Linux abgemahnt werden? Weil der Kernel bzw. die
Treiber Listen mit den VIDs und PIDs enthalten?

[Hmmm (Gast)]

W.S. schrieb:
> Passende Treiber hat Windows seit langem, aber die Vorschriften, die das
> USB-Konsortium für sich selbst ausgeheckt hat, bewirken letztlich, daß
> ein jeder seine vid und pid gegen Geld zu erwerben hat und seinem
> Produkt selbige im Installationspaket mitzugeben hat.

Das stimmt so nicht, Du kannst auch die Default-VID/PID des jeweiligen 
Chips verwenden. Ohne USB-IF-Membership gibt's aber keine Certification, 
so dass man die entsprechenden Logos nicht verwenden darf.

Das Problem unter Windows ist, dass es USB-CDC-Geräte nicht einfach als 
solche behandelt, sondern eine passende INF-Datei (die dann auf 
usbser.sys verweist) haben will. Meines Wissens wurde das aber mit 
irgendeinem Windows-10-Update geändert.

[Thomas Z. (usbman)]

Hmmm schrieb:
> Das Problem unter Windows ist, dass es USB-CDC-Geräte nicht einfach als
> solche behandelt, sondern eine passende INF-Datei (die dann auf
> usbser.sys verweist) haben will. Meines Wissens wurde das aber mit
> irgendeinem Windows-10-Update geändert.
das ist nicht richtig. Seit Win8 werden CDC-ACM Geräte automatisch dem 
Klassentreiber zugeordnet. Das war notwendig durch die immer strengere 
Treiberzertifizierung die sich auch über die Infs erstreckte. Für Win7 
und älter ist die Inf notwendig.

usbser.sys gehört seit W98SE zum Lieferumfang.

[Hmmm (Gast)]

Thomas Z. schrieb:
> das ist nicht richtig. Seit Win8 werden CDC-ACM Geräte automatisch dem
> Klassentreiber zugeordnet. Das war notwendig durch die immer strengere
> Treiberzertifizierung die sich auch über die Infs erstreckte.

Das kenne ich anders:

Unter Win7 (und früher) brauchte man eine (unsignierte) Inf-Datei, unter 
Win8 musste sie zudem signiert sein, was Verrenkungen erforderte.

Siehe z.B. https://github.com/tewarid/atmel-usb-cdc-virtual-com-driver

Ab Win10 (oder einem der Updates davon) ging es dann von Haus aus.

[Rudolph R. (rudolph)]

Den FT230XS benutze ich inzwischen auch gerne, so als Ersatz für den 
FT232RL mit weniger sinnlosen Pins und für weniger Geld.
Mit der angehängten Schaltung hatte ich mal eine Platine in 25x12 mm 
entworfen von denen ich noch reichlich habe da ich die als "Panels" zu 
je 4 Stück bestellt habe.
Der Spannungsregler war dafür gedacht das Ding an den Debug-Port eines 
Handys mit 2,7V Pegeln zu hängen, benutzt habe ich das so allerdings 
nie, statt dessen lasse ich U1, R1 und R2 normalerweise weg, bestücke C1 
vielleicht mal mit 100nF und ziehe einen Fädeldraht von VCCIO auf 3,3V.
R5 und R6 bestücke ich so mit 10R...100R.

Von der Schaltung im Datenblatt habe ich schon die 10nF und die Spule 
weg gelassen, laufen würde der wahrscheinlich auch mit weniger Teilen - 
nur was soll so ein Experiment bringen solange man davon nur eine 
Handvoll baut?
Und winzig ist das jetzt auch schon.

Irgendwann brauche ich vielleicht wieder neue Platinen und werfe den 
Regler raus, dann ist die nur noch so schmal wie die Micro-USB Buchse.
Zu lang ist die Platine jetzt auch, die Micro-USB Buchse gehört dichter 
an die Kante, das werden dann vielleicht 23x10 mm.

[Bauform B. (bauformb)]

Yalu X. schrieb:
> Ein reiner USB-UART-Konverter, der vorgibt, ein CDC-ACM (also ein Daten-
> oder Faxmodem) zu sein, ist nicht perfekt, sondern verstößt gegen die
> USB-CDC-Spezifikation.

Na großartig, das auch noch. Muss ich das glauben oder muss ich mir die 
ganze USB-Spec holen? Genau das wollte ich vermeiden. Diese 
Einschränkung gibt's doch nur, weil Intel mit Gewalt die COM-Ports 
abschaffen will?

Also vergessen wir das Ganze, "perfekt" gibt's eben nicht. Neulich im 
Biergarten hätte mein Essen die Note verdient gehabt. Leider lag ein 
Salatblatt verkehrt rum auf dem Teller :(


Harald schrieb:
> Der FT230XS (nicht zu verwechseln mit dem FTDI Standardprodukt) braucht
> außer einem Abblockkondensator überhaupt nichts.

Willi schrieb:
> Nicht dein ernst ... was ist an einem Widerstand oder an einem
> Kondensator speziell?

Laut FT230X-Datenblatt braucht der an den Datenleitungen zwei 27R und 
zwei 47p. Die 47p stören mich doppelt, weil ich nicht weiß, wozu die gut 
sind. Speziell sind diese Teile deshalb, weil ich 27R oder 47p sonst 
nirgendwo gebrauchen kann. Das sind zwei neue Bauteile nur für den 
FT230X. Andere Chips brauchen sowas nicht, also bekommt FTDI 
Minuspunkte.

[Harald (Gast)]

Bauform B. schrieb:
> Andere Chips brauchen sowas nicht, also bekommt FTDI
> Minuspunkte.

Wird auch ohne funktionieren, ist halt ein etwas besseres EMV/ESD 
Verhalten.

[René F. (Gast)]

Bauform B. schrieb:
> Diese
> Einschränkung gibt's doch nur, weil Intel mit Gewalt die COM-Ports
> abschaffen will?

Ich denke nicht, das Intel die treibende Kraft ist, die serielle 
Schnittstelle ist im Consumer-Bereich schon vor 20 Jahren gestorben. Man 
bekommt aber auch heute noch problemlos Rechner mit serieller 
Schnittstelle, man muss beim Kauf nur darauf achten, weil sie bei vielen 
Mainboards aufgrund der geringen Verwendung weggespart oder nur auf 
Stiftleisten herausgeführt wird.

[Maxe (Gast)]

Die CH340 wurden noch nicht genannt. Hab 2 davon (CH340G und CH340T) als 
"USB-Stick", funktionieren.

Der CH340N kommt im SOP-8, externe Beschaltung lediglich 
Stützkondensatoren für die Versorgung.

Wie es mit der Seriennummer aussieht, weiß ich nicht. Es gibt noch den 
CH340B mit EEPROM, wo man eine eigene Seriennummer und einen Produktname 
einspeichern kann.

Gibts bei LCSC um günstiges Geld.

[W.S. (Gast)]

Yalu X. schrieb:
> Weswegen genau sollte Linux abgemahnt werden?

Weil da niemand sein Geld den Geiern gegeben hat.

W.S.

[Christopher J. (christopher_j23)]

Die Hersteller zahlen doch für die PID/VID. Welches Betriebssystem die 
dann auf welche Art und Weise auswertet spielt doch überhaupt keine 
Rolle.

[Axel S. (a-za-z0-9)]

Bauform B. schrieb:
> Also vergessen wir das Ganze, "perfekt" gibt's eben nicht

Gibts schon. Nur hast du halt sehr spezielle Vorstellungen, was
für dich perfekt ist. Back dir halt deinen eigenen Chip.
Wenn du das gemacht hast, werden jede Menge Leute kommen und etwas 
bemäkeln. Weil sie eine andere Verstellung von perfekt haben.


W.S. schrieb:
> Yalu X. schrieb:
>> Weswegen genau sollte Linux abgemahnt werden?
>
> Weil da niemand sein Geld den Geiern gegeben hat.

Ich verstehe es nach wie vor nicht. Warum sollte irgendwer bei Linux 
(wer eigentlich? Der Treiber-Entwickler? Der Anwender?) irgendwem Geld 
dafür geben, daß der Treiber mit einer bestimmten VID/PID spricht?

[Bauform B. (bauformb)]

Maxe schrieb:
> Der CH340N kommt im SOP-8

Ja Wahnsinn, bei dem ist wirklich für jeden das passende Gehäuse dabei. 
Wer eine Seriennummer braucht, bekommt zwar nur ein normales SO-16, aber 
immerhin. Im Linux-Treiber (ch341) gibt es nur einen, aber sehr 
interessanten, Kommentar:
/* Some CH340 devices appear unable to change the initial LCR
 * settings, so set a sane 8N1 default. */


Also, was habe ich gelernt:
1. cdc-acm ist auch nicht das gelbe vom Ei. Nett, weil halbwegs genormt, 
aber praktisch auch nicht reibungsloser als FTDI, also ist es kein 
Argument für bestimmte Chips. Das war ja eigentlich klar, ist halt 
Windows.
2. niemand kennt sich mit QFN aus
3. der alte FT232R braucht zwar einen ESD-Schutz, aber ansonsten ist das 
jetzt der Testsieger
4. Niemand benutzt einen STM32L412 mit USB-UART. Echt nicht? Das wäre 
für mich eine echte Alternative, wenn ich das ohne CubeMX und HAL, 
einfach mit gcc und make, zum Laufen bekäme. Der könnte nämlich 2 
Kanäle. Allerdings sind VID und PID noch ein großes Rätsel.

Axel S. schrieb:
> Back dir halt deinen eigenen Chip.

siehe 4.

> Wenn du das gemacht hast, werden jede Menge Leute kommen und etwas
> bemäkeln. Weil sie eine andere Verstellung von perfekt haben.

Kann ich mir überhaupt gar nie nicht vorstellen ;)


René F. schrieb:
> Bauform B. schrieb:
>> Diese Einschränkung gibt's doch nur, weil Intel mit Gewalt
>> die COM-Ports abschaffen will?
>
> Ich denke nicht, das Intel die treibende Kraft ist, die serielle
> Schnittstelle ist im Consumer-Bereich schon vor 20 Jahren gestorben.

Selbsterfüllende Prophezeiung kombiniert mit Mitkopplung?

[Thomas Z. (usbman)]

Bauform B. schrieb:
> Allerdings sind VID und PID noch ein großes Rätsel.

die ist für CDC ACM völlig egal da der Class Driver geladen wird (W10).
Da kannst du auch 0xDEAD 0xBEEF eintragen. Du solltest dir mal den CDC 
code von W.S. bzw eine der Ableger davon anschauen. Das sollte deinen 
Vorstellungen schon ziemlich nahe kommen. Den Uart Teil musst dir dazu 
programmieren.

[PittyJ (Gast)]

Bauform B. schrieb:
> 4. Niemand benutzt einen STM32L412 mit USB-UART. Echt nicht? Das wäre
> für mich eine echte Alternative, wenn ich das ohne CubeMX und HAL,
> einfach mit gcc und make, zum Laufen bekäme. Der könnte nämlich 2
> Kanäle. Allerdings sind VID und PID noch ein großes Rätsel.

Ich benutze die HAL, weil der Code darin recht gut funktioniert, und mir 
Wochen Prokelei erspart.
Allerdings habe ich einen eigenen GCC und arbeite mit Makefiles. Es 
spricht doch nichts dagegen die HAL .c und .h Dateien selber zu 
kompilieren.

VID und PID sind bei USB spezifiziert. Es gibt auch Bereiche für 
Homebrew Software. Letztendlich sind sie aber egal, denn CDC wird durch 
andere Bytes in den USB-Headern definiert.

[Bauform B. (bauformb)]

Thomas Z. schrieb:
> Du solltest dir mal den CDC code von W.S. bzw eine der
> Ableger davon anschauen.

Schon wieder zu viel Auswahl ;) Gibt es evt. einen Link zu einer 
narrensicheren Version?

[Kevin M. (arduinolover)]

Bauform B. schrieb:
> niemand kennt sich mit QFN aus

Ich würde sagen ich schon 🤔

Es muss heißen du kennst dich nicht aus.

[Stefan F. (Gast)]

Bauform B. schrieb:
> Gibt es evt. einen Link zu einer narrensicheren Version?

Ich sage es mal so: In seinem guten Code wurden ein paar Bugs gefunden 
und korrigiert. Während dessen sind aber auch andere Änderungen je nach 
persönlichem Geschmack des jeweiligen Autors eingeflossen.

Meine Variante findest du dort: 
http://stefanfrings.de/stm32/stm32f1.html#vcpnohal

Narrensicher ist USB generell nicht. Ich komme mit diesem Code gut 
zurecht.

[Patrick L. (Firma: S-C-I DATA GbR) (pali64)]

Ich verwende Gerne den CP2102
Kein Quarz, kaum externe Bauteile und gute Dokumentation.
Einfaches Layout.

Nebenbei sehr Robust für die Industrie.

[Stefan F. (Gast)]

Die letzte originale Fassung von W.S. ist dort: 
Beitrag "Re: An W.S.: Läuft deine USB Implementierung auch auf STM32F303?"

Das ist exakt der gleiche Code, den er schon 2015 veröffentlichte.

[dirk st (Gast)]

Gruss

Im professionellen Bereich gibt es auch
Realisationen mit ATtiny/ ATMega mit entsprechender Lizenz.
Das war mal bei mir aus Detail Interesse.

Einen schönen Sonntagabend noch
Dirk St

[Harald (Gast)]

dirk st schrieb:
> Im professionellen Bereich gibt es auch
> Realisationen mit ATtiny/ ATMega mit entsprechender Lizenz.

Du meinst aber hoffentlich nicht diesen very low speed VUSB Kram, oder? 
Weil das hätte mit Professionell nichts zu tun.

[123 (Gast)]

hola,

Zum Thema windows Treiber und Signierung, ... Das hatte bei W7 was mit 
32 / 64 bit zu tun, auch bei Windows 8, ... wenn ich das noch richtig in 
errnnerung habe.

Die frage ist auch sind es KernelMode Treiber oder UserMode Treiber.

Für Kernelmode gilt für 64Bit ab W7 das die Signiert sein müssen.
Wenn ich mich noch richtig errinnere gibt es für windows 10 und USB die 
möglichkeit von User Mode treibern. Diese könnten ggf auch ohne signatur 
laufen. (hab mich damit nicht beschäftigt).

Zum Thema USB Treiber, bzw deren zuweisung. Unter Windows gibt es 2 
machanismmen der Treiber auswahl.
die erste über USB VID und PID. Dazu sind heutzutage passende signierte 
INF files notwendig. in denen die VID und PID hinterlegt sind.

die zweite über den USB Class descriptor. Hier wird wenn es sich um ein 
USB Device Handelt für das ein entsprechender Universeller USB Class 
Driver existiert dieser angezogen. Z.B. HID oder MassStorage. Die 
zugehörigen USB Class spezificationen gibt es bei USB.org.

Treiber Signierung: Private und für die entwicklung git es die 
möglichkeit auch ohne offizielles Codesigning Certificat treiber zu 
Signieren und diese auf Windows zu installieren. ist aber etwas 
umständlich, ... (je nach windows version glaube ich auch ohne self 
signing)

[Bauform B. (bauformb)]

Harald schrieb:
> dirk st schrieb:
>> Im professionellen Bereich gibt es auch
>> Realisationen mit ATtiny/ ATMega mit entsprechender Lizenz.
>
> Du meinst aber hoffentlich nicht diesen very low speed VUSB Kram, oder?
> Weil das hätte mit Professionell nichts zu tun.

Die professionelle Lösung von STM ist aber auch keine Lösung:

SLA0044 Rev5/February 2018

5. No use, reproduction or redistribution of this software partially
   or totally may be done in any manner that would subject this
   software to any Open Source Terms. "Open Source Terms" shall mean
   any open source license which requires as part of distribution of
   software that the source code of such software is distributed
   therewith or otherwise made available, or open source license that
   substantially complies with the Open Source definition specified at
   www.opensource.org and any other comparable open source license such
   as for example GNU General Public License (GPL), Eclipse Public
   License (EPL), Apache Software License, BSD license or MIT license.

Das ist aus der Lizenz der STM32_USB_Device_Library, wie STM sie auf 
github veröffentlicht. Diese Library wird doch benutzt, wenn man ein 
CubeMX-Projekt mit USB baut? Ist dem CubeMX-Benutzer dann eigentlich 
klar, worauf er sich einlässt? Noch dazu, weil in einem "normalen" 
Header wie stm32l412xx.h sowas steht: 
"opensource.org/licenses/Apache-2.0"?

Also, so geht es auch nicht. Und die Versionen von W.S. und Stefan ⛄ F. 
sind für den F103; die USB-Hardware dürfte wenig Ähnlichkeit mit der 
vom L412 haben, auch wenn das in der AN4879-Tabelle so aussieht.

[W.S. (Gast)]

Bauform B. schrieb:
> Also, so geht es auch nicht. Und die Versionen von W.S. und Stefan ⛄ F.
> sind für den F103; die USB-Hardware dürfte wenig Ähnlichkeit mit der
> vom L412 haben, auch wenn das in der AN4879-Tabelle so aussieht.

Was hättest du denn gern?

Also ich hatte im Laufe der Jahre einige USB-Treiber geschrieben, zuerst 
den für die damaligen Chips von Nuvoton - daher der Ursprung der 
vid/pid. Dann kamen einige LPC hinzu, dann erst ein Ableger für die 
STM32F103. Du kannst es dir heraussuchen, aus welcher Version du dir 
deinen Treiber für deine HW machen willst. Das prinzipielle Grundgerüst 
ist überall gleich.

W.S.

[123 (Gast)]

Bauform B. schrieb:
> Also, so geht es auch nicht. Und die Versionen von W.S. und Stefan ⛄ F.
> sind für den F103; die USB-Hardware dürfte wenig Ähnlichkeit mit der
> vom L412 haben, auch wenn das in der AN4879-Tabelle so aussieht.

Vergleich die Register der beiden Datenblätter. Ich vermute das es da 
keine grossen unterschiede gebe wird. auser:
- anzahl der Endpoints
- Startaddresse des Register bereichs
- externe beschaltung
- grösse des DualPortRams
- zusätzliche funktionen wie OTG bzw HS

Der hersteller wird doch nicht für jeden Chip das USB rad neu erfinden 
wollen. bzw neu Lizenzieren wollen. Bedeutet doch nur arbeit / kosten 
für sich selber und seine kunden.

[Radio Men (Gast)]

Bauform B. schrieb:
> Wobei die Hälfte der Pins beim
> FT232R ziemlich überflüssig ist und 16 QFN-Pins vielleicht gerade noch
> lötbar sind.

Welche Pins sind überflüssig?
Wenn Du nur RXD und TXD brauchst, ja, aber Du bist nicht der einzige für 
den der Chip gemacht wurde. Andere brauchen die zusätzlichen Pins schon.

Bauform B. schrieb:
> FT2* (außer FT232R) brauchen Längswiderstände in D+ und D-

Weil Du nicht verstanden hast für was die Widerstände da sind.
Damit will man Probleme verhindern die man bekommen kann wenn das USB 
Kabel nicht so toll ist.

[Thomas Z. (usbman)]

Bauform B. schrieb:
> Also, so geht es auch nicht. Und die Versionen von W.S. und Stefan ⛄ F.
> sind für den F103; die USB-Hardware dürfte wenig Ähnlichkeit mit der
> vom L412 haben, auch wenn das in der AN4879-Tabelle so aussieht.

ich habs jetzt nicht überprüft, aber es gibt im Code #define UMEM_SHIFT 
der die Addressierung der Endpoints beeinflusst, den musst du vermutlich 
für den L412 auf 0 setzen. Zusätzlich must du dann nur noch die Daten an 
den Uart leiten.

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Fuer USB gibt es auch noch libopencm3.

[Bauform B. (bauformb)]

Uwe B. schrieb:
> libopencm3

danke, der Nachmittag ist gerettet! Heute abend dann wieder mimimi ;)

W.S. schrieb:
> Das prinzipielle Grundgerüst ist überall gleich.

Das ist klar, am Stecker soll ja immer cdc rauskommen, aber die vielen 
geheimnisvollen Registerbits...

[Stefan F. (Gast)]

Laut AN4879 hat der STM32L4x2 die Version A von der USB Peripherie. Zu 
dieser passt mein Code.

Wie Thomas schon andeutete enthält die Datei usb.c ein paar 
Konfigurationsparameter bezüglich der Adressierung des Speichers.

// For devices with 2x16 bits/word access schema
// (e.g. STM32L0x2, STM32L0x3, STM32F04x, STM32F072, STM32F078, STM32F303xD and STM32F303xE)
#define UMEM_SHIFT 0
#define UMEM_FAKEWIDTH uint16_t

// For devices with 1x16 bits/word access schema
// (e.g. STM32F103, STM32F302, STM32F303xB, STM32F303xBxC)
#define UMEM_SHIFT 1
#define UMEM_FAKEWIDTH uint32_t

Wenn man die richtig einstellt (müsste es theoretisch klappen.

Im Referenzhandbuch des Mikrocontrollers steht "2 x 16 bits / word", das 
wäre die obere Variante.

[Hmmm (Gast)]

123 schrieb:
> Zum Thema windows Treiber und Signierung, ... Das hatte bei W7 was mit
> 32 / 64 bit zu tun, auch bei Windows 8, ... wenn ich das noch richtig in
> errnnerung habe.

Es ging bloss überhaupt nicht um die Signierung des eigentlichen 
Treibers, sondern um die der INF-Datei, die Windows davon überzeugt, für 
ein USB-CDC-Gerät die systemeigene usbser.sys zu verwenden.

[123 (Gast)]

Die inf datei ist ein obigatorischer teil des Treibers. Ihn ihr ist 
enthalten für welche HW und Windows Version was alles zu installieren 
ist.

Ein Treiber muss vollständig signiert werden wenn er signiert werden 
muss. Dazu erfolgt über eine sogenante Katalog datei (*.cat), in der 
alle zum treiber gehörenden Dateien (inf, sys, dll, ....) enthalten 
sind.

Wenn du die inf modifizierst, um z.B. eine neue VID / PID einzutragen, 
muss du den treiber neu signieren. oder windows verweigert wegen der 
veränderten datei die Installation des treibers.

Das Sys, dll, exe files zusätzlich auch signiert werden ist hoffentlich 
klar.

[Hmmm (Gast)]

123 schrieb:
> Wenn du die inf modifizierst, um z.B. eine neue VID / PID einzutragen,
> muss du den treiber neu signieren. oder windows verweigert wegen der
> veränderten datei die Installation des treibers.

Lies besser weiter oben nach, was bereits zum unterschiedlichen 
Verhalten der Windows-Versionen geschrieben wurde.

[W.S. (Gast)]

Bauform B. schrieb:
> Das ist klar, am Stecker soll ja immer cdc rauskommen, aber die vielen
> geheimnisvollen Registerbits...

Tja, wenn du dich hier beklagst, daß in verschiedenen Chips auch 
unterschiedliche IP's für den USB-Core verbaut sind, dann kann dir auch 
keiner helfen. Das mag nun eben so sein und keiner von uns wird sich 
daran vorbeimogeln können, die Eigenarten des jeweiligen USB-Cores 
verstehen zu lernen - soweit man das aus den Dokumenten des Herstellers 
herauslesen kann.

W.S.

[Stored B. (Firma: drx) (umbrecht)]

Hallo,

ich suche ebenfalls seit Jahren einen perfekten Konverter (für mich: 
DIP-8/16, Automatische Treiber, keine externe Beschaltung).

Doch leider gibt es sowas (bisher) nicht. Jeder Konverter hat seine 
Eigenheiten.

Für den Fall das ich auf UART angewiesen bin, nutze ich eine Linux VM 
unter Windows und einen PL2303. Funktioniert stabil und ist Billig.

Möchte ich aber eine eher "integrierte" Anwendung, bleibt eigentlich 
nichts anderes über als ein Funkmodul zu benutzen. Am besten ein WLAN 
oder GSM fähiges. Spielt man hierbei etwas mit den #ifdefs in C erhält 
man ein Plattformübergreifendes "Tool" für jeden PC (TCP/IP). Schreibt 
man sich noch einen einfachen Bootlader für den verwendeten MC, kann man 
auf diese Konverter scheißen.

Vielleicht hilft dir das was, anhand deiner Posts weiß ich nicht was du 
machen willst.

LG
Umbrecht

[Bauform B. (bauformb)]

Bauform B. schrieb:
> XR21V1414: als Exar von Infineon gekauft wurde, hat die ganze
> XR21-Familie neue Datenblätter bekommen, nur dieser eine nicht.

Grobes Foul: Exar wurde von MaxLinear gekauft, Infineon hat sich Cypress 
einverleibt.

Cypress baut den CY7C65213-28PVXI, der hat genauso zu viele Pins wie der 
FT232RL und soll offensichtlich pinkompatibel sein. Man kann dann per 
Bestückung zwischen FTDI-Treibern und cdc-acm wählen. Das ist doch ein 
starkes Argument, das zählt mehr als die fehlende Seriennummer (die man 
notfalls selber ins interne Flash(!) schreiben könnte).

Der FT232 kann also Testsieger bleiben, aber in Wirklichkeit wird der 
CY7C65213 bestückt ;) Man kann ja zumindest hoffen, dass der dank 
cdc-acm doch ohne extra Windows-Treiber funktioniert. Und wenn nicht, 
ist er wenigstens ein paar Cent billiger.

Die STM32 haben noch zwei nette Macken: "crystal less USB" funktioniert 
nur bei -15 bis +85°C. Selbst wenn das nicht stört, hat man zwar genaue 
48MHz, aber man kann nur USB und RNG damit takten, nicht die UARTs. Das 
betrifft mindestens die L412, 422, 432, 433, 443, 452, 462. Bei den L496 
und L4A6 ist es nicht spezifiziert, obwohl sie scheinbar das gleiche CRS 
haben. Evt. ist der Oszillator besser?

Uwe B. schrieb:
> Fuer USB gibt es auch noch libopencm3.

das ist ja ein Sahnestück, bis hin zum Coding Style "if, while, for 
bekommen immer {}, auch wenn nur ein Statement folgt". So mag ich das!

Mit libopencm3 könnte ich dem Windows auch einen USB-Stick vortäuschen, 
statt USB-UART. Das sollte doch völlig reibungsfrei gehen und der User 
müsste nur 20 Sekunden statt über 1 Minute auf seine Daten warten. Aber 
der Aufwand... damit es sich lohnt, müsste USB-UART trotzdem parallel 
funktionieren, und das mit OTG-USB. Und die Hardware sähe ganz anders 
aus, fetterer uC (deswegen OTG), ein DC/DC-Wandler mehr... Also, das 
behalten wir mal für ganz lange Winterabende im Hinterkopf.

[Patrick L. (Firma: S-C-I DATA GbR) (pali64)]

Bauform B. schrieb:
> ... Also, das
> behalten wir mal für ganz lange Winterabende im Hinterkopf.

Das mit den Langen Winterabende kannst du wohl knicken, wir haben 
globale Erwärmung .....

[Bauform B. (bauformb)]

Stored B. schrieb:
> Für den Fall das ich auf UART angewiesen bin, nutze ich eine Linux VM
> unter Windows und einen PL2303. Funktioniert stabil und ist Billig.

Unter Linux funktionieren eigentlich alle Chips, vielleicht nicht mit 
allen Features, aber stabil.

> Möchte ich aber eine eher "integrierte" Anwendung
möchte man; jedenfalls im Vergleich zur VM
> bleibt eigentlich nichts anderes über als ein Funkmodul zu benutzen.
> Am besten ein WLAN oder GSM fähiges.

Sag' einfach Netzwerk, nicht unbedingt Funk. Es gibt auch diverse Module 
mit RJ45-Stecker. Netzwerk ist zweifellos eine Alternative, gerade wenn 
man mehr als ein paar Byte übertragen will. Ich habe es bisher 
ausgeschlossen, weil so ein Modul mehr Strom braucht als der ganze Rest. 
Und der PC müsste dann zwei NICs haben, "administrative Gründe"...

> Spielt man hierbei etwas mit den #ifdefs in C erhält man ein
> Plattformübergreifendes "Tool" für jeden PC (TCP/IP). Schreibt
> man sich noch einen einfachen Bootlader für den verwendeten MC,
> kann man auf diese Konverter scheißen.

Mit einem Netzwerk-zu-UART-Modul müsste eigentlich der integrierte 
Bootloader im STM32 ohne weiteres funktionieren. Klar, SPI wäre 
schneller, man kann nicht alles auf einmal haben.

> Vielleicht hilft dir das was, anhand deiner Posts weiß ich nicht was du
> machen willst.

Hier und jetzt wollte ich hauptsächlich die Macken der verschiedenen 
Chips sammeln. Wobei mir Windows eigentlich egal sein könnte, aber 
irgendwie gehört es immer noch dazu ;)

[Yalu X. (yalu) (Moderator)]

Bauform B. schrieb:
> Unter Linux funktionieren eigentlich alle Chips, vielleicht nicht mit
> allen Features, aber stabil.

Es ist natürlich komfortabel, wenn man den USB-UART-Konverter einfach
nur einzustecken braucht und ihn sofort benutzen kann. Trotzdem ist es
damit ja auch unter Linux nicht getan, da man i.Allg. noch eine
Anwendungssoftware braucht, die das angeschlossene Gerät für den
Anwender nutzbar macht. Ganz ohne Installation geht es also auch unter
Linux nicht.

Unter Windows muss man halt zusätzlich noch den Treiber installieren.
Falls die Anwendungssoftware im Lieferumfang des Geräts enthalten ist,
kann man die Treiber mit das Installationspaket packen, so dass alles in
einem Aufwasch installiert wird.

[Stefan F. (Gast)]

CDC wird sowohl von Windows als auch von Linux erstmal als Modem 
behandelt. Beide Betriebssysteme senden AT Befehle an das Modem, um es 
anzutesten und ggf. ins Netzwerk einzubinden.

Bei Linux kann man den Modemmanager deinstallieren. Dann kommt aber ein 
anderes "Problem" hoch: Der Kernel hält den Anschluss für eine serielle 
Konsole, so dass man sich dort einloggen könnte (je nach Konfiguration). 
Der PC sendet empfangenen Zeilen als Echo zurück an das externe Gerät.

Sobald aber ein Anwendungsprogramm den virtuellen seriellen Port öffnet, 
kommuniziert nur noch dieses eine Programm (gilt für Linux und Windows 
gleich).

[Frank K. (fchk)]

Bauform B. schrieb:

> Die STM32 haben noch zwei nette Macken:

Warum hängst Du so an denen? Es gibt doch auch anderes. Z.B.

https://www.microchip.com/en-us/product/ATSAMD11C14

Hat full-speed USB, zwei SERCOMs (UART/SPI/I2C), crystal-less USB 
Operation, 14 Pins im SOIC, Cortex M0. Kannst ja mal drüber nachdenken.

fchk

[Hmmm (Gast)]

Bauform B. schrieb:
> Unter Linux funktionieren eigentlich alle Chips, vielleicht nicht mit
> allen Features, aber stabil.

In der Praxis hatte ich (vor Jahren) massive Probleme, die allerdings 
eher Prolific anzulasten waren: Neuer Chip mit identischer USB-VID/PID, 
der dann mit dem Linux-Treiber nicht stabil lief.

Stefan ⛄ F. schrieb:
> CDC wird sowohl von Windows als auch von Linux erstmal als Modem
> behandelt.

Irgendeine Bloatware-Desktop-Distribution mag sowas tun, damit hat aber 
der Linux-Kernel nichts zu tun.

Stefan ⛄ F. schrieb:
> Beide Betriebssysteme senden AT Befehle an das Modem, um es anzutesten

Ganz so trivial ist es zum Glück nicht, es gibt eine einfache 
Aushandlung über die Handshake-Leitungen, erst im Erfolgsfall läuft 
etwas über die Datenleitungen.

Stefan ⛄ F. schrieb:
> Der Kernel hält den Anschluss für eine serielle Konsole, so dass man
> sich dort einloggen könnte (je nach Konfiguration).

Auch das macht nicht der Kernel, sondern init. Mag sein, dass systemd 
o.dgl. auf die hirnrissige Idee kommt, auf jeder neuen TTY erstmal einen 
getty zu starten, normal ist das aber nicht.

[W.S. (Gast)]

Frank K. schrieb:
> Bauform B. schrieb:
>
>> Die STM32 haben noch zwei nette Macken:
>
> Warum hängst Du so an denen?

Hier in diesem Forum wird von den meisten STM32 verstanden, wenn jemand 
32 Bit Controller sagt. Will sagen, daß man hier gar sehr auf die 
Produkte von ST orientiert ist. Entsprechend sind auch die hier 
kursierenden Quellcode-Stücke.

Natürlich wäre es gut, wenn ein Anwender der ATSAM Chips auch mal einen 
selbstgeschriebenen USB-CDC Treiber hier posten würde (oder eine 
Anpassung meiner Quellen an diese Hardware vornähme), aber bei der 
gegenwärtigen Orientierung auf STM32 sehe ich das nicht so bald kommen.

W.S.

[Bauform B. (bauformb)]

Frank K. schrieb:
> Bauform B. schrieb:
>> Die STM32 haben noch zwei nette Macken:
> Warum hängst Du so an denen? Es gibt doch auch anderes.

Vor der Großen Chipverknappung™ sind ein paar Platinen entstanden, für 
die es auch anderes gab - Ergebnis: FT232R, XR21V1414 und FT230XS. 
Anlässlich der nächsten Platinen wird von den 4 Kanälen im XR21V1414 nur 
noch einer wirklich gebraucht, einer zweiter wäre nett zwecks Debug. 
Also hat man an der Stelle viel mehr Auswahl und könnte überall den 
gleichen Typ einsetzen.

Das könnte der CY7C65213 sein. Speziell der STM32L412KBT wäre aber noch 
viel besser, weil der sowieso "überall" drin ist und weil damit 2 Kanäle 
möglich wären. Genauso kämen noch L496 oder L452 in Frage, aber das wäre 
dann doch Verschwendung. Alle anderen Chips, auch STM32xxx, sind von 
daher nur zweite Wahl. Wobei manche Chips keine extra Firmware 
brauchen... Der Aufwand ist schon beim STM32 eigentlich nicht drin, eine 
neue uC Familie ist von daher völlig utopisch.

> Kannst ja mal drüber nachdenken.

Das war jetzt einfach :)

[Frank K. (fchk)]

W.S. schrieb:
> Frank K. schrieb:
>> Bauform B. schrieb:
>>
>>> Die STM32 haben noch zwei nette Macken:
>>
>> Warum hängst Du so an denen?
>
> Hier in diesem Forum wird von den meisten STM32 verstanden, wenn jemand
> 32 Bit Controller sagt. Will sagen, daß man hier gar sehr auf die
> Produkte von ST orientiert ist. Entsprechend sind auch die hier
> kursierenden Quellcode-Stücke.

Im Netz gibts genug, z.B.

https://github.com/kevinmehall/usb

fchk

[Johannes S. (Gast)]

github, das war doch diese Hippster Seite...

[Bauform B. (bauformb)]

Johannes S. schrieb:
> github, das war doch diese Hippster Seite...

definitiv!

Im November 2019 kündigte GitHub an, alle öffentlichen auf der
Plattform vorhandenen Code-Repositorys in einer ehemaligen
Kohlemine auf Spitzbergen zu archivieren. Dafür wurden etwa
21 TByte Daten mit mehr als 100 Millionen Repositorys
auf 186 Mikrofilmrollen gespeichert.

(aus https://de.wikipedia.org/wiki/GitHub)