mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Controller via USB an Computer: Wie am besten?


Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Thema wurde hier bestimmt schon etliche Male durchgekaut... ich 
hoffe daher auf ein paar Erfahrungswerte um die Fehler zu vermeiden, die 
andere bereits abgehakt haben.

Ich benötige in nicht allzu ferner Zukunft wahrscheinlich das nötige 
KnowHow, um einen Controller mit Daten aus dem PC zu füttern. Ich 
brauche keine hohe Geschwindigkeit, einfach und zuverlässig reicht aus.

Am liebsten würde ich einen AVR-Controller verwenden, weil ich mit denen 
vertraut bin. Aber wenn sich diese dafür absolut nicht eignen, würde ich 
evtl. die "Chance" nutzen und mich auch mit einem leistungsfähigeren IC 
auseinandersetzen. Mein Favorit (ohne die genau zu kennen bzw. ohne 
echte Übersicht zu haben) wäre der STM32 bzw. ARM Cortex, evtl. M3. 
Schön wäre, wenn dieser Controller dann auch noch eine Weile zu 
erhältlich ist.

Wahrscheinlich führt dann auch kein Weg mehr an C vorbei, finde ich 
recht ärgerlich, aber irgendwann muß das wohl passieren.

Hat jemand Lust, mir Hilfestellung beim Einstieg zu geben?

1) Welchen Controller würdet ihr empfehlen?

2) Welche Programmierumgebung für den Controller? Ich bin gut in 
Assembler und PHP, vielleicht hilft das bei der Auswahl welcher 
C-Compiler mir liegen könnte. Es heißt immer C und PHP wären ähnlich, 
aber jedes Mal wenn ich mir C so angeschaut habe, hatte ich massive 
Probleme damit.

Danke euch. Ich werde auch im PC-Software-Forum einen Thread eröffnen 
und dort fragen wie das dazu passende PC-Programm aussehen müsste. Denn 
auch da muß ich dann wahrscheinlich die recht bittere Pille C fressen.
Link: Beitrag "USB-Datenaustausch mit µC, Hilfe beim Einstieg in C gesucht"

Autor: W.A. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ben B. schrieb:
> Das Thema wurde hier bestimmt schon etliche Male durchgekaut...

Stimmt.

Auf die Gefahr, dass jetzt ein fürchterlicher Shit Storm losbricht:
Nimm einen Arduino - AVR bis ARM Cortex M3 steht dir zur Auswahl.

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Dir für den Tip, der ist sicherlich nicht schlecht. Aber ich will 
es nicht nur mit Ardunio-Kram zusammenstecken, sondern mir geht es um 
eigene Lösungen ohne Arduino-Bootloader. Ich würde auch gerne verstehen 
wie es funktioniert, damit ich Probleme beheben kann wenn es welche 
gibt.

Autor: Volker S. (vloki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst du "einfach und zuverlässig"vielleicht noch etwas genauer 
spezifizieren? Braucht man dafür einen 32 Bit Controller, oder tut es 
vielleicht ein 8Bit?

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
8 Bit Controller wäre mir der AVR lieb, von denen kenne ich sehr viele, 
aber wenige bis keine haben USB-Unterstützung und der Umweg über einen 
USB/RS232-Umsetzer ist naja suboptimal irgendwie.

Also wenn der Sprung zu einer andere µC-Familie ratsam ist, dann gleich 
was größeres 32bittiges mit guten Zukunftsaussichten. Am Beispiel des 
anderen Threads: Es macht aus meiner Sicht für mich keinen Sinn, wenn 
ich mich so auf die AVRs eingeschossen habe, jetzt noch die 8-Bit-PICs 
dazuzulernen. Wenn dann richtig, auch wenn's vielleicht Quatsch ist, mit 
einem STM32 ein paar LEDs blinken zu lassen. Für den Anfang reicht mir 
das und das Wissen um den µC kann man dann brauchen, wenn die Projekte 
umfangreicher werden.

Autor: imkeller (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Wie am besten?

Mit Bereitschaft ... zu lernen !
Schaue nicht auf Arduino herab solange
Du es nicht besser kannst.

Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
WIllst du wirklich direkt mit den uC an USB?
Das ist eine haarige Sache. Für jemanden der mit C grad anfängt nicht 
wirklich optimal.
Als triviale Lösung würde mir eher einfallen einen USB-Uart Chip mit auf 
die Platine zu packen und darüber mit dem uC zu kommunizieren.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ben B. schrieb:
> Am liebsten würde ich einen AVR-Controller verwenden, weil ich mit denen
> vertraut bin.

Das ist kein Problem. Es gibt AVRs mit integriertem 
USB-Device-Controller, die man also mit wenig Aufwand an einen PC 
anschließen kann.

Auch wenn Du außerhalb der Arduino-Umgebung arbeiten möchtest, bietet es 
sich an, zunächst mit einem (passenden) Arduino anzufangen, denn da 
bekommst Du für recht wenig Geld eine fertig aufgebaute funktionierende 
Platine. Und der Platine ist es egal, ob die die Programme, die darauf 
laufen, nun mit der Arduino-IDE oder was auch immer schreibst.

Entscheidend ist der Typ des Arduino - hier geht es um den "Arduino 
Leonardo" bzw. dessen kompakteren kleinen Bruder, den "Arduino Micro". 
Auf beiden ist ein Atmega32U4 verbaut.

"Nachbauten" dieser Platinen bekommt man für ein paar Euro.

Als Entwicklungsumgebung kannst Du einfach die Dir vertraute 
weiterverwenden, wenn Du eh' schon mit AVRs unterwegs bist, ist das 
sicherlich der bequemste und einfachste Weg.

Solltest Du mit C arbeiten, ist die LUFA-Bibliothek etwas, was Du Dir 
ansehen solltest, die nimmt Dir das ganze recht komplexe Gehampel mit 
dem USB-Protokoll ab, ist gut "abgehangen" (d.h. ausreichend lange und 
ausreichend oft eingesetzt worden) und auch Grundlage der 
Arduino-Unterstützung für Leonardo/Micro.

Im Prinzip könnte man USB auch mit der Softwareemulation "V-USB" 
umsetzen, aber das kann nur Low-Speed-USB, was einige Einschränkungen 
mit sich bringt, so ist im Grunde genommen nur die HID-Geräteklasse 
damit zuverlässig nutzbar. CDC (für serielle Schnittstellen) ist nicht 
spezifikationskonform und funktioniert nicht mit jedem Betriebssystem.

Der Vorteil des V-USB-Ansatzes ist natürlich der, daß der auch mit 
beliebigen AVRs im bastelfreundlichen DIP-Gehäuse verwendet werden kann, 
aber das ist eine Sackgasse, die man, wenn man z.B. den Arduino Micro 
oder einen seiner vielen Nachbauten verwendet, echt nicht beschreiten 
muss.

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex, kannst Du ein paar Anregungen geben, wieso Du das so siehst?

Autor: U. M. (oeletronika)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
> Ben B. schrieb:
> 8 Bit Controller wäre mir der AVR lieb, von denen kenne ich sehr viele,
> aber wenige bis keine haben USB-Unterstützung und der Umweg über einen
> USB/RS232-Umsetzer ist naja suboptimal irgendwie.
Aber genau das würde ich dir als Alternative empfehlen.
Ich habe in den letzten 10 Jahren regelmäßig den FTDI-Chip FT323R 
benutzt, um  von UART auf USB umzusetzen (am als virtuelles COM-Port zu 
benutzen).
Die Sache ist recht einfach, man braucht aber eben den Chip zusätzlich.

> Also wenn der Sprung zu einer andere µC-Familie ratsam ist, dann gleich
> was größeres 32bittiges mit guten Zukunftsaussichten.
Da kannst du dir jederzeit auch mit einem ARM Cortex Mx (x=0,1,2,3...) 
aussuchen.

> Wenn dann richtig, auch wenn's vielleicht Quatsch ist, mit
> einem STM32 ein paar LEDs blinken zu lassen.
Du mußt wissenk was du brauchst und was evtl. später interessant wird.
Gruß Öletronika

Autor: Volker S. (vloki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:
> WIllst du wirklich direkt mit den uC an USB?
> Das ist eine haarige Sache. Für jemanden der mit C grad anfängt nicht
> wirklich optimal.
> Als triviale Lösung würde mir eher einfallen einen USB-Uart Chip mit auf
> die Platine zu packen und darüber mit dem uC zu kommunizieren.

Wenn man den USB Teil selbst programmieren müsste, dann würde ich hier 
absolut zustimmen. Gewöhnlich gibt es aber ein Framework vom 
Chiphersteller, dass man da verwenden kann.

Autor: Anregungen? Gigabyteweise. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wir sollten besser eine Liste von MC-Familien und Serial-USB Wandlern 
aufstellen, mit denen es nicht geht.

Die Liste wird auf jeden Fall kürzer.

Und was sollst - Experimentierplatine kostet 10€. Entwicklungsumgebung 
mit Tutorial und Beispielen ist kostenlos. Da kann man ja mal einen 
Fehlkauf riskieren.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
U. M. schrieb:
> Aber genau das würde ich dir als Alternative empfehlen.

Damit kann man dann halt nichts anderes als serielle Datenübertragung 
machen.

Wenn nur das das Ziel ist, ist das definitiv der zu beschreitende Weg, 
ob die USB-Seriell-Bridge dabei von FTDI, Silabs, Prolific oder Wch 
kommt, ist zunächst auch zweitrangig (auch wenn FTDI die beste 
Dokumentation und Treiberunterstützung liefert).

Sobald man aber was anderes mit der USB-Schnittstelle anfangen möchte, 
sei es, eine Tastatur, eine Maus oder ein sonstiges Eingabegerät 
nachzubilden, oder ein MIDI-Instrument, ist ein frei programmierbare 
USB-Device-Controller zu bevorzugen.

Auch bei der CDC-Anwendung (serielle Schnittstelle) hat so etwas gewisse 
Vorzüge, wenn die Daten direkt vom µC verarbeitet werden sollen. Dann 
nämlich kann man Baudraten-, Parity- etc.-Fehlanpassungen umgehen, so 
daß es völlig egal ist, was auf dem Host-PC jeweils für die verwendete 
Schnittstelle eingestellt wird.

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gewissermaßen würde die serielle Datenübertragung "erstmal reichen". 
Also ein Stapel Daten zum Controller und ein "OK" oder "nicht OK" 
zurückbekommen.

Anstrebenswert ist eine Lösung, die man direkt an den PC/Laptop 
dranstecken kann und dann ohne lange Treiberinstallation an den 
Controller drankommt.

Ok Zwischenfrage: Ist die Kommunikation mit USB für den Controller 
wirklich so kompliziert? Was muß der Controller denn 
machen/können/senden, damit der PC ihn als USB Device bzw. als 
Schnittstelle erkennt, was sind die Schwierigkeiten dabei? Ich hab davon 
noch nicht viel Ahnung, aber mein Gefühl wäre wenn man das in Software 
machen kann, ist's dann wirklich so schwer?

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:
> Danke Dir für den Tip, der ist sicherlich nicht schlecht. Aber ich
> will
> es nicht nur mit Ardunio-Kram zusammenstecken, sondern mir geht es um
> eigene Lösungen ohne Arduino-Bootloader. Ich würde auch gerne verstehen
> wie es funktioniert, damit ich Probleme beheben kann wenn es welche
> gibt.

Dieses steht im krassen Widerspruch zu:

Ben B. schrieb:
> 2) Welche Programmierumgebung für den Controller? Ich bin gut in
> Assembler und PHP, vielleicht hilft das bei der Auswahl welcher
> C-Compiler mir liegen könnte. Es heißt immer C und PHP wären ähnlich,
> aber jedes Mal wenn ich mir C so angeschaut habe, hatte ich massive
> Probleme damit.

Denn:
Bei massiven Problemen, sind die Erfolgschancen naturgemäß eher gering.

Arduino bietet dir erstmal einen leichten Zugang.
Dann basiert es größtenteils auch C++.
Das kann man als Vorteil, oder als Nachteil werten.
Aber als PHP Krieger, dürften dir die OOP Konzepte bekannt sein.

Ben B. schrieb:
> Danke euch. Ich werde auch im PC-Software-Forum einen Thread eröffnen
> und dort fragen wie das dazu passende PC-Programm aussehen müsste. Denn
> auch da muß ich dann wahrscheinlich die recht bittere Pille C fressen.
> Link: Beitrag "USB-Datenaustausch mit µC, Hilfe beim Einstieg in C
> gesucht"
Die CmdMessenger Lib bietet einen leichten Zugang zur Arduino<->Pc 
Kommunikation. Allerdings: C# auf PC Seite



Bitte nicht als Werbung für Arduino verstehen. Es ist mir völlig 
wurscht, was du verwendest.
Aber mir scheint, als hättest du noch nicht die nötige Kompetenz 
entwickelt, um Arduino auf ein "nicht nur mit Ardunio-Kram 
zusammenstecken" reduzieren zu dürfen.

Arduino geht auch ohne Bootloader
Arduino geht auch ohne Shields oder auch mit eigenen
Arduino IDE geht auch ohne Arduino Board
Arduino Boards funktionieren auch ohne Arduino IDE
usw...

Arduino besteht aus 3 Teilen:
Board
Framework bzw. API
IDE
Alle drei kann man nach belieben gegen Fremdprodukte oder 
Eigenentwicklungen austauschen.
Es ist keine Einbahnstraße.

Ob Arduino, oder nicht.
Das lernen wird Zeit brauchen.
Vermutlich: Jahre.
Es ist eben nur der Vorteil des niederschwelligen Zugangs und der 
schnellen Teilerfolge, welche für Arduino sprechen.
Das kann sich allerdings auch als Nachteil auswirken, wenn man nach den 
ersten drei blinkenden LED meint, man hätte es voll auf dem Schirm.


--------

Ben B. schrieb:
> Ist die Kommunikation mit USB für den Controller
> wirklich so kompliziert?
Wenn du wirklich verstehen willst, wie USB funktioniert.
Die Sprache lernen möchtest
Den betreffenden µC verstehen lernen
Alles selber schreiben.
Dann schätze ich auf 3 bis 5 Jahre, je nach Vorwissen, bis das 
vernünftig funktioniert. Treiber und Kosten für eigene VID und PID noch 
gar nicht eingerechnet.

Dein Projekt (vereinfacht formuliert)
ATMega32U4 quatscht mit PC, ist mit Arduino, ohne jedes Vorwissen in 2 
Stunden zu schaffen.
Je mehr Tiefgang, desto mehr Zeit/Einsatz ist erforderlich

Autor: Volker S. (vloki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:
> Was muß der Controller denn machen/können/senden, damit der PC ihn als
> USB Device bzw. als Schnittstelle erkennt, was sind die Schwierigkeiten
> dabei?

Sinnvoller Weise hat der Controller eine Hardwarekomponente, die den 
untersten Level der Kommunikation erledigt.
Was für eine Geräteklasse dann erkannt wird ist dann im allgemeinen von 
der Software abhängig.

Der Host fragt das USB Gerät, um was es sich handelt. Es muss sich quasi 
selbst anhand der sogenannten Device Desktoptoren beschreiben. Dies wird 
bei der sogenannten Enumeration erledigt. Abhängig von den Angaben des 
Gerätes bezüglich der Geräteklasse wird dann auch der Treiber 
ausgewählt.

Ist alles relativ komplex, aber man muss es nicht im Detail, bzw. fast 
gar nichts darüber wissen, um es benutzen zu können!

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Bei massiven Problemen, sind die Erfolgschancen naturgemäß eher gering.
Quatsch, das finde ich normal wenn man sich noch nicht eingearbeitet 
hat.

Mein Problem mit zuviel fertigem Code ist immer, daß ich oft mehr Zeit 
brauche um mich da reinzuarbeiten und den zu verstehen und für meine 
Anforderungen zu modifizieren, als wenn ich es selbst schreibe. Bei 
Arduino ist gefühlt alles irgendwie fertiger Code.

Vielleicht hast Du Recht und man bekommt irgendwas in kurzer Zeit 
zusammen, daß ein µC mit dem PC quatscht. Aber deswegen kann man noch 
lange gar nichts, vor allem nicht dann, wenn man Deine Zeitrechnung 
zugrunde legt.

Naja, vielleicht doch Umweg über FTDI. Ist ja egal ob FT232 oder MAX232.

Autor: Volker S. (vloki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Kosten für eigene VID und PID noch gar nicht eingerechnet.

Wichtiger Punkt!
Jedes USB Gerät braucht offiziell eine eigene Vendor(Hersteller) und 
Produkt ID. Diese kann man unter Umständen als Sublicence vom 
Chiphersteller kostenlos erhalten. Will man grössere Stückzahlen in 
Verkehr bringen, dann muss man die aber käuflich erwerben, was schon ein 
paar tausend € kosten dürfte...

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja um sowas kümmere ich mich erstmal nicht. Es ist keine 
Massenproduktion geplant, sondern erstmal nur schauen wie es 
funktioniert.

Gibts da keine allgemeinen freien Bereiche, mit der Einschränkung, daß 
von diesen Geräten immer nur eines am PC angeschlossen sein darf, damit 
es keine Kollisionen gibt bzw. einen Bereich, in dem man vor Kollisionen 
eben nicht geschützt ist? Ähnlich den lokalen IP-Bereichen, die jeder 
LAN-Betreiber für sein eigenes Netz verwenden kann?

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:
> Gibts da keine allgemeinen freien Bereiche, mit der Einschränkung, daß
> von diesen Geräten immer nur eines am PC angeschlossen sein darf, damit
> es keine Kollisionen gibt bzw. einen Bereich, in dem man vor Kollisionen
> eben nicht geschützt ist?

Nein!

Du darfst beliebig viele Geräte mit identischer VID/PID anschließen.
Das ist kein Problem.

Du darfst auch gerne eine eigene Seriennummer verwenden.
So kann der PC zwischen den ansonsten gleichen Geräten unterscheiden.



Ben B. schrieb:
> Bei Arduino ist gefühlt alles irgendwie fertiger Code.
Wenn du meinst....

Ich sehe das so:
> Wer will, findet Wege.
> Wer nicht will, findet Gründe.

Ben B. schrieb:
>> Bei massiven Problemen, sind die Erfolgschancen naturgemäß eher gering.
> Quatsch, das finde ich normal wenn man sich noch nicht eingearbeitet
> hat.

Ne...
Ich meinte deine Aversion gegenüber C.
Da liegt der Hase im Pfeffer.
Diese Aversion in eine Zuneigung zu wandeln....

: Bearbeitet durch User
Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zuneigung wäre wohl übertrieben. So ein Zustand "damit klarkommen" würde 
mir reichen... wenn mir da jemand einen brauchbaren Compiler nennen 
kann, so daß sich der Programm-Aufbau bzw. Syntax für PC- und 
µC-Programmierung eignet, wäre ich auf jeden Fall dankbar dafür.

Falls es keine Lösung gibt, die beides gut beherrscht, wirds auf jeden 
Fall nervig wenn man beide Varianten gleichzeitig lernen muß. Also 
einerseits um einen größeren Controller wie den STM32 programmieren zu 
können, andererseits das PC-Programm, mit dem er kommunizieren können 
soll.

Aber was soll ich machen? Irgendwann muß ich das lernen, spätestens wenn 
die AVRs mal weg vom Fenster sind. Einen ARM in Assembler zu 
programmieren ist zwar lustig, aber wenn die immer mehr Funktionen 
bieten, machts irgendwann nur noch wenig Sinn. Also auch wenn ich 
Assembler sehr mag, ich hätte nichts dagegen wenn der Funktionsumfang 
meiner AlarmSau die Spitze meiner Assembler-µC-Programmierung ist.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ben B. schrieb:
> so daß sich der Programm-Aufbau bzw. Syntax für PC- und
> µC-Programmierung eignet,

Ja, schau an....
Da sind wieder wieder bei Arduino und seinem C++...

(nicht nur)Arduino nutzt den GCC.
Den gibts auch für PCs.
Und eine riesen Menge an verschiedensten Prozessoren.

C++ ist recht weit verbreitet.
Das gleiche gilt übrigens auch für Arduino und C

Stellt man es geschickt an, läuft der geschriebene Code auf PC und µC.
Ohne jede Veränderung.

Ben B. schrieb:
> Zuneigung wäre wohl übertrieben. So ein Zustand "damit klarkommen" würde
> mir reichen...
Ich meine schon Zuneigung entwickeln.
Das ist der effektivste Weg, dem inneren Schweinehund/Dialogpartner eine 
positive Einstellung aufzuprägen.

: Bearbeitet durch User
Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast Du Erfahrung damit, eine kleine Windows-Anwendung in C++ zu 
schreiben?

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:
> Hast Du Erfahrung damit, eine kleine Windows-Anwendung in C++ zu
> schreiben?

Naja..
Kleine, ja... meist Kommandozeilen Programme.
Wenig, oder eher einfaches, grafisches Zeugs.

z.B. meist mit http://www.codeblocks.org/

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Alex G. schrieb:
> Willst du wirklich direkt mit den uC an USB?
> Das ist eine haarige Sache. Für jemanden der mit C grad anfängt nicht
> wirklich optimal.

Definitiv. Es reicht ja ein Blick in das USB-Tutorial mit STM32, um 
abzuschätzen wieviel Aufwand allein ein CDC auf dem STM32 ist.

> Als triviale Lösung würde mir eher einfallen einen USB-Uart Chip mit
> auf die Platine zu packen und darüber mit dem uC zu kommunizieren.

Und genau das kriegt man fix und fertig und für ein Spottgeld unter der 
Bezeichnung: Arduino. Z.B. als Arduino nano für ca €2,- vom Chinesen.

Ben B. schrieb:
> ich will es nicht nur mit Ardunio-Kram zusammenstecken

Niemand verlangt von dir, irgend etwas zusammenzustecken. Sieh den 
Arduino nano einfach als einen IC mit USB-Buchse.

> sondern mir geht es um eigene Lösungen ohne Arduino-Bootloader.

Du mußt auch den Bootloader nicht verwenden. Der nano hat den 6-poligen 
ISP-Stecker. Du mußt auch nicht die Arduino-IDE verwenden oder auch nur 
C. Du kannst da Assembler, Pascal, BASIC und was-du-sonst-willst 
Programme per ISP draufspielen.

Das einzige, was du nehmen mußt, wie es kommt, ist der 16MHz Quarz an 
den XTAL-Anschlüssen und der USB-UART am RxD und TxD.

> Ich würde auch gerne verstehen wie es funktioniert, damit ich
> Probleme beheben kann wenn es welche gibt.

Und dazu mußt du die USB-UART Bridge und den ATmega selber auf eine 
Platine gelötet haben? Ich glaube, nicht.

Autor: Bauform B. (bauformb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:
> ... einen Controller mit Daten aus dem PC [zu] füttern. Ich
> brauche keine hohe Geschwindigkeit, einfach und zuverlässig reicht aus.

> Naja, vielleicht doch Umweg über FTDI. Ist ja egal ob FT232 oder MAX232.

Zwischen PC und Controller habe ich gerne Optokoppler. In dem Fall ist 
der FT232 sogar preisgünstig, weil der per USB vom PC versorgt wird, 
praktisch selbstfunktionierend. Andere Lösungen müssen selbst für die 
PC-seitige Stromversorgung sorgen oder sind noch teurer.


Axel S. schrieb:
>> Ich würde auch gerne verstehen wie es funktioniert, damit ich
>> Probleme beheben kann wenn es welche gibt.
>
> Und dazu mußt du die USB-UART Bridge und den ATmega selber auf eine
> Platine gelötet haben? Ich glaube, nicht.

Ich glaube, die beiden Chips haben neben der eigentlichen Hardware noch 
Platz. Dafür muss ja sowieso eine Platine entwickelt werden.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Bauform B. schrieb:
> Zwischen PC und Controller habe ich gerne Optokoppler.
Wlan?

z.B.
PC(PHP) <-> ESP8266/ESP32(C++,Lua)

Hätte zumindest den Vorteil, dass PHP schon bekannt zu sein scheint, und 
für die ESP auch die C++ STL bereit steht.

: Bearbeitet durch User
Autor: Volker S. (vloki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:
> Es ist keine
> Massenproduktion geplant, sondern erstmal nur schauen wie es
> funktioniert.
>
> Gibts da keine allgemeinen freien Bereiche, mit der Einschränkung,

In dem Fall, nimmst du einfach die voreingestellten IDs von 
irgendwelchen Hersteller Dem-Programmen und gut...

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der User W.S. hat hier zweimal seine persönliche Sammlung von USB CDC 
Implementierungen für ARM Controller zur freien Verwendung 
veröffentlicht.

Ich habe daraus ein Projekt für das Blue-Pill Board (ist ein gängiger 
STM32 mit Cortex M3) gemacht, dass ich gerne als Basis für weitere 
Entwicklungen verwende: http://stefanfrings.de/stm32/index.html#vcpnohal

> Es heißt immer C und PHP wären ähnlich,

Nee, ganz sicher nicht. Dazwischen liegen Welten - wenn nicht gar 
Universen.

Alle anderen Fragen von Dir sind auf der verlinkten Webseite 
beantwortet.

: Bearbeitet durch User
Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok danke euch, die beiden verlinkten Seiten muß ich erstmal lesen. Vor 
allem die erste sieht beim Überfliegen sehr gut aus.

Im Moment würden die 64kbit locker ausreichen. Aber wenn man sieht wie 
die Entwicklung voranschreitet, ist immer die Frage wie lange reicht 
das. Gerade bei den größeren ARM-Controllern, die ja teilweise richtig 
viel Speicher haben oder wo man evtl. irgendwann mal eine SD-Karte 
dransteckt. Oder irgendwann heißt's dann plötzlich USB 64kbit wird nicht 
mehr unterstützt, tja Pustekuchen. Deswegen sollte das was ich mir dann 
in Richtung USB aneigne möglichst zukunftssicher sein.

Ich habe auch kein Problem damit, Platinen selbst zu entwickeln. Also 
ich muß nicht Arduino, nur um die Platinen zu haben. Egal wie billig die 
sind. Wenn ich etwas baue, kann ich auch die Platine entwerfen und mit 
USB-Anschlüssen ausstatten usw. RS232 mit Hardware geht ja auch recht 
einfach ohne Arduino.

Mal sehen wo das noch hinführt.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:
> Im Moment würden die 64kbit locker ausreichen. Aber wenn man sieht wie
> die Entwicklung voranschreitet, ist immer die Frage wie lange reicht
> das.

Alle mir bekannten USB-UART schaffen locker 1Mbit, manche auch mehr. 
Allerdings sollte man dann den Quarz des Mikrocontrollers dazu passend 
wählen.

16MHz AVR und 115200 Baud ist zum Beispiel eine ganz schlechte 
Kombination, obwohl wesentlich mehr geht. In den Datenblättern der AVR 
gibt es zum Design praktische Tabellen.

Autor: Multitasking (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hmmm... nur mal so ein Gedanke...

Wenn man einen Controller mit USB-Modul benutzt, muss sich die 
Hauptschleife alle paar Millisekunden um das USB kümmern. Das Programm 
kann kein delay() benutzen. Man muss alles in kurze Routinen aufteilen.

Wenn man sowieso alles mit Zuständen und kurzen Schritten macht, kann 
man problemlos mit einem Beispiel aus dem USB Democode anfangen und die 
eigene Funktionalität in die Hauptschleife einhängen.

Will man dagegen mit lang laufenden Funktionen oder gar mit delay() 
arbeiten, braucht man einen USB-UART.

Die Frage "Wie am besten?" hängt davon ab, ob du sowieso Multitasking in 
deiner MC Anwendung brauchst.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Multitasking schrieb:
> Wenn man einen Controller mit USB-Modul benutzt, muss sich die
> Hauptschleife alle paar Millisekunden um das USB kümmern. Das Programm
> kann kein delay() benutzen.

Das ist nicht richtig. Die Implementierung von W.S. ist komplett 
Interrupt-getrieben. Die Implementierung in Cube HAL ebenfalls, soweit 
ich das gesehen habe.

Trotzdem empfehle ich, das ganze Multitasking-fähig zu implementieren, 
denn früher oder später will man während der Kommunikation 
gleichzeitig etwas anderes tun.

: Bearbeitet durch User
Autor: Volker S. (vloki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Multitasking schrieb:
> Das Programm kann kein delay() benutzen.

Der beste Argument gegen einen uC mit USB Modul das ich je gehört habe 
;-)



Ben B. schrieb:
> Im Moment würden die 64kbit locker ausreichen. Aber wenn man sieht wie
> die Entwicklung voranschreitet, ist immer die Frage wie lange reicht
> das.

Bin mir nicht sicher, ob du das richtig verstanden hast. Die 64kBit sind 
eine Einschränkung der Geräteklasse HID und das ist nur Software also 
von der Controller Hardware unabhängig. Also wenn du dir jetzt einen 
Controller auswählst, kannst du da zukünftig immer noch die Geräteklasse 
wechseln.

Im Falle einer angeschlossenen SD Karte, wäre dann die Geräteklasse MSD 
(Mass Storage Device) nicht schlecht. Die SD Karte könnte dann an deinem 
Rechner wie eine externe Festplatte im Dateisystem angezeigt werden.

Ein uC kann auch mehrere Klassen, z.B. CDC und MSD, implementieren und 
sozusagen als mehrere Geräte auftreten (Composite Device).

: Bearbeitet durch User
Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Multitasking schrieb:
> Wenn man einen Controller mit USB-Modul benutzt, muss sich die
> Hauptschleife alle paar Millisekunden um das USB kümmern.

Das gilt nur für die Enumeration, da erwartet der Host relativ kurze 
Timeouts. Danach handelt die USB-Peripherie alles komplett autonom ab, 
man kann den Controller prinzipiell beliebig lange blockieren. Und 
natürlich macht man das komplett in Interrupts, sodass das Hauptprogramm 
beliebig langsam sein darf.

Multitasking schrieb:
> Will man dagegen mit lang laufenden Funktionen oder gar mit delay()
> arbeiten, braucht man einen USB-UART.
Den braucht man nie unbedingt, wenn der Controller nicht gerade zu 
100% ausgelastet ist und man keine 0,1% für die USB-Interrupts abzweigen 
kann...

Ben B. schrieb:
> Ok Zwischenfrage: Ist die Kommunikation mit USB für den Controller
> wirklich so kompliziert?
Schon etwas. Es muss eine Reihe von Nachrichten ausgewertet und 
beantwortet werden, Deskriptoren erstellt werden, das Protokoll für 
Control-Endpoints implementiert werden... Einen Controller mit 
USB-Hardware vorausgesetzt, welcher Pakete automatisch senden & 
empfangen kann.

Lies doch mal mein USB-Tutorial mit STM32. Da sollten sich diverse 
Fragen klären, inklusive Vor-und Nachteilen, und auch die PC-Seite. 
C++-Kenntnisse sind vorausgesetzt, in C lässt sich so etwas einfach 
nicht schön  strukturieren und Assembler wäre völlig ungeeignet.

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefanus
Mit dem USART des AVR bin ich fit, da habe ich absolut keine Probleme. 
Den hab ich erst kürzlich bei meiner AlarmSau dreimal benutzt ... (2mal 
auf dem Hauptmodul und 1mal auf dem Terminal), wenn USB auch so einfach 
wäre alles gut. Das einzige Problem, was ich mit RS232 habe ist, daß es 
fast kein Computer heute mehr unterstützt. Ansonsten würde ich einen 
MAX232 draufpappen und alles wird gut, 1Mbit reicht bestimmt noch ein 
paar Jahre.

Ich sehe nur das Folgeproblem (wenn man sich jetzt mit 64kbit 
zufriedengibt), daß irgendwann in x Jahren jemand kommt und sagt hier, 
schaufel doch mal den Inhalt dieser DVD via USB auf eine SD-Karte. 4,7GB 
das sind 37,6 Gigabit, rechnen wir mit etwas Overhead glatte 43GBit, 
dauert mit 64kBit/s eine Woche und 18 Stunden. Das kann man also 
vergessen. Mit 1Mbit/s wäre es in 12 Stunden zu schaffen, mit 10Mbit 
wären es eine Stunde und 12 Minuten. Also um sich für diesen Fall zu 
rüsten wären mindestens 1Mbit anzuraten, 10Mit schöner wenn der STM32 
das kann. Und wenn ich mir die Entwicklung von (V)DSL usw. anschaue (was 
hier bei mir 11 Megabyte pro Sekunde erreicht, 100Mbit LAN  bremst schon 
aus) wird's in x Jahren schon schwer genug, jemandem zu erklären, daß 
die Übertragung seiner winzigen DVD mit den drei Urlaubsbildern drauf 
über eine Stunde dauert. :(

@Multitasking
Das Problem hast Du beim USART des AVR auch schon, der kann maximal ein 
Byte puffern (während ein zweites in das Empfangsregister geschoben 
wird), manche können wohl zwei Byte puffern (weiß ich nicht genau). Also 
in dem Moment wo Dein Programm sowas wie delays benutzt, brauchst Du 
mindestens Interrupt-Routinen, die eingetroffene Bytes vom 
Empfangsregister in den Speicher schaufeln. Damit habe ich kein Problem, 
hatte ich bei meiner AlarmSau nicht ein Problem mit. Da werden auch 
keine echten Delays benutzt, sondern die Funktionen, die zeitverzögert 
ausgeführt werden sollen, reagieren auf eine Art Zähler vom 
Timer-Interrupt, der mit 10Hz läuft.

@Volker
So wie ich das mitbekommen habe, implementiert die "besonders einfache 
Verwendung" von USB wohl die HID-Klasse und damit die Limitierung auf 
64kbit. Die SD-Karte ist nur ein Beispiel was in den nächsten 20 Jahren 
mal passieren könnte und wo ich dann nicht wieder anfangen will, USB neu 
zu lernen wenn's USB dann noch gibt.

@Niklas
Das verlinkte USB-Tutorial ist von Dir? Bitte ehrliche Antwort, auch 
wenn das vermutlich im Laufe des Lernprozesses einige Fragen an Dich zur 
Folge haben dürfte, auch oder gerade C++ betreffend... ;)
Ja na klar lese ich das. Ich hab es bislang kurz überflogen, sieht sehr 
vielversprechend aus.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ben B. schrieb:
> Das verlinkte USB-Tutorial ist von Dir?

Ja. Du kannst gerne Detailfragen stellen. Ist ja nicht ausgeschlossen 
dass uneindeutige Formulierungen da drin sind...

Ben B. schrieb:
> 10Mit schöner wenn der STM32
> das kann

Du versteifst dich zu sehr auf die 64 KBit/s. USB Low Speed kann 1.5 
MBit/s, Full Speed kann 12 MBit/s und High Speed kann 480 MBit/s. Nur 
wenn du - warum auch immer - USB HID verwendest, beschränkst du dich 
unnötig auf diese 64 KBit/s. HID wurde gerne zweckentfremdet um unter 
alten Windows-Versionen die Treiber-Installation zu umgehen. Das ist 
seit Win8 obsolet - siehe Artikel.

Fast alle STM32 können USB Full Speed, einige können High Speed.

Aber Achtung: Es gibt bei den STM32 3 verschiedene USB-Module:
- Nur "USB" genannt - relativ simpel, kann nur Full Speed und nur 
Device. Darauf bezieht sich das o.g. Tutorial.
- "OTG_FS" kann Host und Device und nur Full Speed. Ziemlich komplex. 
m.W. gibt es dafür nur 1 offene Treiber-Bibliothek, die von ST.
- "OTG_HS" ähnlich, aber auch für High Speed.

Wenn es einigermaßen überschaubar sein soll, nimm einen Controller mit 
der "USB"-Peripherie. Das sind z.B. die STM32F103, aber nicht die 
STM32F105.

: Bearbeitet durch User
Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke das werden mehr Fragen wegen C++ werden, einmal in Richtung 
Controller, einmal in Richtung PC.

Der große Vorteil bei USB ist, daß man bestimmt irgendwie die 
Kommunikation mit dem PC aufzeichnen kann (Wireshark?). Also wenn ich 
beim Protokoll Fehler mache, kann ich auf diese Weise nachsehen was 
schiefgeht bzw. "anders aussieht" als es andere Geräte machen. Bleibt 
erstmal die Aufgabe, überhaupt etwas über den USB senden und empfangen 
zu können.

Ich glaube man sollte auf USB Full Speed zielen. Sollte irgendwann der 
Fall mit großen Datenmengen eintreten, gibts da evtl. auch andere 
Lösungen wie z.B. einen USB-Stick als Datenspeicher zu verwenden und das 
Dateisystem mit dem Controller direkt auszulesen. Wenn nicht, müssen die 
12MBit halt reichen, so wenig ist das ja nicht (wird in 20 Jahren anders 
aussehen, aber das ist dann halt so... dann implementiere ich WLAN mit 5 
Terabit und WPA8... Erstmal völlig egal. ;)

Gleich die erste Frage: Welchen Compiler verwendest Du auf Controller- 
und PC-Seite, irgendwas unter Windows? Welchen Programmieradapter für 
die STM32?

Autor: Niklas Gürtler (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ben B. schrieb:
> Welchen Compiler verwendest Du auf Controller

https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads

Ben B. schrieb:
> und PC-Seite,

Auch GCC. Unter Windows eine der 64bit-MinGW-Versionen und zusätzlich 
auch MSVC.

Ben B. schrieb:
> Welchen Programmieradapter für die STM32?

J-Link EDU.

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> J-Link EDU.
Okay, von Segger? Kann das Ding on-Chip-Debugging, also daß man zur 
Laufzeit oder nach einem Crash des Controllers schauen kann, was im RAM 
oder in den Registern drinsteht?

Ich besorge mir mal die Hardware und werde danach bestimmt Deine Hilfe 
brauchen, eine lauffähige Entwicklungsumgebung aufzubauen, die Dein 
Tutorial compilieren kann (µC- und PC-Seite). Dann kann ich probieren, 
hinterher eigenen Code darauf aufzubauen. Meinst Du, das ist ein 
gangbarer Weg?

Danke Dir auf jeden Fall für Deine Tips.

Autor: Niklas Gürtler (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ben B. schrieb:
> Okay, von Segger?

Ja.

Ben B. schrieb:
> Kann das Ding on-Chip-Debugging, also daß man zur Laufzeit oder nach
> einem Crash des Controllers schauen kann, was im RAM oder in den
> Registern drinsteht?

Ja natürlich, das ist der Sinn von dem Teil.

Ben B. schrieb:
> Meinst Du, das ist ein gangbarer Weg?

Klar, so ist das gedacht...

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok danke, Hauptsache ich nerve Dich nicht zu sehr damit.

Autor: Niklas Gürtler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch nicht ¯\_(ツ)_/¯
Wie gesagt, lies den Artikel, auch den STM32, da klärt sich schon 
einiges.

Autor: FS (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Wenn es Controller-unabhängig sein soll, kann ich den MCP2221A 
empfehlen. Es ist eine USB 2.0 Full Speed-nach-UART/I²C-Bridge, die ein 
Composite-Device implementiert: CDC und HID. Dank Klassentreiber 
funktioniert die Anbindung unter Windows/Linux ohne zusätzlichen Treiber 
out-of-the-box. Ein externes Quarz für die 12 MHz wird auch nicht 
benötigt und es gibt den IC sogar im PDIP-Gehäuse. UART geht soweit ich 
weiß bis 460800 Baud. Man ist allerdings auf 8-N-1 beschränkt. Aus 
Controller-sicht hat man nur mit dem UART zu tun und muss sich um keine 
USB-Details kümmern. Simpel und effektiv für solche, die nativ kein USB 
bieten.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.