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"
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.
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.
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?
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.
Wie am besten? Mit Bereitschaft ... zu lernen ! Schaue nicht auf Arduino herab solange Du es nicht besser kannst.
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.
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.
Alex, kannst Du ein paar Anregungen geben, wieso Du das so siehst?
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
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.
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.
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.
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?
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
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!
> 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.
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...
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?
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....
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.
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.
Hast Du Erfahrung damit, eine kleine Windows-Anwendung in C++ zu schreiben?
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/
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.
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.
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.
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...
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.
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.
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.
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.
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.
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
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.
@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.
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
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?
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.
> 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.
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...
Ok danke, Hauptsache ich nerve Dich nicht zu sehr damit.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.