Guten Abend, ich hoffe ich bin im richtigen Unterforum gelandet mit meinem Problem. Ich möchte für ein kleineres Studienprojekt quasi ein USB-Gerät aufbauen, was sowohl Daten sendet, als auch empfängt. Soweit alles recht einfach, soweit man nen Terminal verwendet und sich die Datenströme anschaut. Ich möchte jedcoh nicht im Terminal arbeiten, sondern überwiegend Daten vom µC zum Computer senden, selten Steuersignale vom PC zum µC. Das ganze soll letztlich von einer plattformunabhängigen Software geregelt/genutzt werden. Was mir fehlt sind Suchbegriffe um für diese Thematik Texte zu finden. Ich kann mir von der Terminal-Ebene zur Software-Ebene rüber wenig vorstellen. Komme eher aus der Analogtechnik... Viele Grüße Walter
Das Standard Interface ist USB-to-Serial zB von FTDI. Auf der PC Seite steckt man USB ein, und das Device erscheint als Serialport. Auf der anderen Seite ist es ein UART, das kann man direkt mit dem UART des controllers verbinden.
Oder, du nimmst dir gleichen einen USB µC ala Atmega32u4 oder ein PIC Derivat und setzt dort einen USB CTC (Das gleiche wie ne UART-USB Bridge) auf. Ob nun mit einem FTDI oder direkt einem USB-µC - aber UART ist das was du suchst.
Es gibt viele verschiedene USB Klassen, z.B. CDC (serielle Schnittstelle über USB). Die serielle Schnittstelle kannst Du mit relativ wenig Aufwand in Deiner PC Software ansprechen und von dieser lesen und schreiben. Dann gibt es noch die HID (Human Unterface Device) Klasse, das passt gut wenn Du Potis, Knöpfe, LEDs, etc. ansprechen willst.
HID kann allerding nur etwas 64 Meldungen pro Sekunde. Das UART ist der Weg. Darauf kann man mehr als nur ein Terminal abbilden. Mit einem passenden Protokoll drauf ist es geeignet fuer Computer-Computer/Controller Interaktionen.
:
Bearbeitet durch User
Oh D. schrieb: > HID kann allerding nur etwas 64 Meldungen pro Sekunde. Die minimale Intervall-Zeit liegt bei bei 1ms. Aber wieviel nun tatsächlich rauskommt, wäre schon mal Interessant zu wissen. Ich arbeite gerade an einer HID, kann ja mal ne Messung mit implementieren.
Warum besteht ihr alle auf UART? FTDI liefert doch gute Treiber für
direkte USB-Verbindung.
Oder meldet sich der Chip als HID an und darauf bezieht sich
> HID kann allerding nur etwas 64 Meldungen pro Sekunde.
?
Dussel schrieb: > Warum besteht ihr alle auf UART? Weil früher™ die µCs noch kein eingebautes USB hatten, und das die Standard-Schnittstelle für den separaten USB-Chip war. Was der Bauer nicht kennt, frisst er nicht.
>Warum besteht ihr alle auf UART? FTDI liefert doch gute Treiber für
direkte USB-Verbindung.
Die FTDI Loesung stellt ein UART dar. Auf PCSeite arbeitet man mit einem
UART Treiber.
Und Uart, resp seriell ab UART, ist auch eine sinnvolle Verbindung im
industriellen Umfeld, waehrend USB es eben nicht ist. USB ist limitiert
auf 5m, und Serial, dh UART eben nicht. Mit einem UART und passendem
Hardwaretreiber, kann man locker 100m bei 3MBit machen. Oder 1MBit und
300m.
Deswegen haben alle meine Geraete eine DSub15 Schnittstelle. Da kann man
auch ein USB-to-Serial einstecken. Problem geloest.
:
Bearbeitet durch User
Dussel schrieb: > Warum besteht ihr alle auf UART? FTDI liefert doch gute Treiber für > direkte USB-Verbindung. Warum immer das Pferd von hinten aufzäumen?! Für eine einfache Kommunikation zwischen PC und µC - egal in welche Richtung - ist nunmal UART die beste Lösung. Sie läuft ohne Treiber, sie läuft auf allen Systemen, sie läuft unter µCs - sie läuft. Hab ich dann noch nen doofen USB Stack dazwischen fangen doch die Probleme wieder an - Angefangen bei den Treibern für die einzelnen Systeme (Oder das man überhaupt einen Treiber braucht!) darüber das man nichtmal eben flexibel nen anderes System (vom µC über nen Oszi hin zum Pc) anstöbseln kann, und aufgehört das man ja das PC Programm auch noch schreiben muss.
Ich mach das auch über UART. Von der Programmierung her einfach die Serial-Lib einbinden. Port ansprechen und dann lesen oder schreiben.
Draco schrieb: > Warum immer das Pferd von hinten aufzäumen?! Für eine einfache > Kommunikation zwischen PC und µC - egal in welche Richtung - ist nunmal > UART die beste Lösung. Sie läuft ohne Treiber, sie läuft auf allen > Systemen, sie läuft unter µCs - sie läuft. > > Hab ich dann noch nen doofen USB Stack dazwischen fangen doch die > Probleme wieder an Zu einfach gedacht. Es kommt, wie immer, auf den konkreten Anwendunggsfall an. Ein HID kann durchaus sinnvoll sein. UART ist zwar (im ersten Moment) einfacher. Aber dann kommen die Probleme. UART kennt nur einzelne Bytes ohne Bezug zu einander. Synchronisation, Fehlerhandling, EOM-Erkennung, Absicherung - alles nicht vorhanden. Du wirst also, zumindest bei ernsthaften Anwendungen, irgendein Protokoll implementieren dürfen. Dieses Protokoll verursacht Arbeit (Design, Implementieren, Debuggen) und wird niemals an bereits bewährte, gut abgehangene Standardlösungen heranreichen. Du hast am Ende also auch deinen "doofen Stack", nur dass du diesen direkt ins Anwendungsprogramm und in deine Obhut verlagert hast. Ein Minusgeschaft. UART ist eine Bastlerlösung. Das muss aber nicht per se schlecht sein. Manchmal reichts auch. Oft wär aber eine andere Lösung klüger, es scheitert aber am Tellerrand des Entwicklers (Fricklers).
Le X. schrieb: > UART ist eine Bastlerlösung. Deßhalb wird sie auch heute noch reichlich in der Industrie eingesetzt. Dummschwätzer.
Auch für eine Hid Device muss man sich ein eigenen Parser schreiben um zu sehen welches Bit / Byte an welcher Position steht. Die Arbeit für einen Parser bleibt einem bei überhaupt keiner Kommunikation aus, sei es UART, HID oder I2C... Und das UART eine Bastlerlösung ist... :-D Naja, dazu sag ich mal nun nichts mehr ^^ Bei uns im Labor werden ALLE Aparaturen per UART angesprochen, seien es die Präzisionswagen, der Gas-Chromatograph oder der Maschinenpark an sich. Also wo du diese Einstellung gelernt hast... kein Plan! :-D
> Du wirst also, zumindest bei ernsthaften Anwendungen, irgendein
Protokoll implementieren dürfen. Dieses Protokoll verursacht Arbeit
(Design, Implementieren, Debuggen) und wird niemals an bereits bewährte,
gut abgehangene Standardlösungen heranreichen.
Schwätzer. Weg mit dem Troll.
Oha, da scheine ich einen wunden Punkt getroffen zu haben wenn die Emotionen so hoch kochen. War die Vermutung mit dem Tellerrand wohl richtig. Gute Nacht meine Lieben, und kommt wieder runter bevors allzu sehr aufs Gemüt schlägt.
> und wird niemals an bereits bewährte, gut abgehangene Standardlösungen
heranreichen.
Und diese gut abgehangenen Standardlösungen waeren ?
-CAN ? .. Der Brüller. Eine maximale Packetgroesse von 8 Byte, oder so.
-USB ? .. der Brüller. Nach 5m Kabel ist Schluss.
-HPIB ? .. der Brüller. Das Kabel taugt sogar gegen Einbrecher.
жтампф ден троль schrieb: > Und diese gut abgehangenen Standardlösungen waeren ? > -CAN ? .. Der Brüller. Eine maximale Packetgroesse von 8 Byte, oder so. > -USB ? .. der Brüller. Nach 5m Kabel ist Schluss. > -HPIB ? .. der Brüller. Das Kabel taugt sogar gegen Einbrecher. Wo ist das Problem? Jede Lösung hat ihre Vor- und Nachteile. Bei UART zum PC ist eben normalerweise bei 115200 Baud Ende. Knapp 12 KB/s. Das ist ungefähr so schnell wie ein HID bei Low-Speed. Mit Full-Speed erreicht man 64 KB/s. Ohne speziellen Treiber, ohne großen Softwarestack, anschließbar an so ziemlich jedes Gerät mit USB. Und im Gegensatz zu UART paketbasiert. Für Kommunikation mit PCs o.ä. ist USB heutzutage einfach Standard. Auf der anderen Seite ist USB natürlich nicht so einfach wie eine serielle Schnittstelle. Das liegt einfach daran, dass USB so viel mächtiger ist und vor allem auch ziemlich viel automatisiert abläuft.
Dazu kommt auch noch, dass Datenuebertragung nicht alles ist. Was soll mit den Daten geschehen ? Auf die disk schreiben ? USB hat das Problem, dass man zu jeder neuen Windowsversion potentiell einen neuen Treiber liefern muss, resp einen geliefert bekommen muss.
Zwölf M. schrieb: > USB hat das Problem, dass man zu jeder neuen Windowsversion potentiell > einen neuen Treiber liefern muss, resp einen geliefert bekommen muss. Nein. Bei HID liefert Windows bzw. alle anderen Betriebssysteme den generischen Treiber. Für ein HID muss man selbst keinen Treiber schreiben. Genauso verhält es sich bei den ganzen Standard-USB-Klassen. Auch für die gibt es generische Treiber. Nur, wenn man was recht spezielles braucht, muss man einen eigenen Treiber schreiben.
> Bei UART zum PC ist eben normalerweise bei 115200 Baud Ende.
Diese Geschwindigkeit ist nur relevant, wenn auch wirklich
per (echter) RS-232 Geraete angesteuert werden sollen.
Wenn man nur die serielle USB-Emulation benutzt, ist die
eingestellte Schnittstellengeschwindigkeit voellig ohne Belang.
Ich habe mir hier zum Beispiel einen USB Paralleladapter gebaut,
der per serieller Emulation angesprochen wird.
Den juckt die eingestellte Geschwindigkeit ueberhaupt nicht.
P.S.: Viele serielle USB-Adapter unterstuetzen mittlerweile
auch 1 Mbit/s bzw. 921600 bit/s.
avr schrieb: > Mit Full-Speed > erreicht man 64 KB/s. Ohne speziellen Treiber, ohne großen > Softwarestack, anschließbar an so ziemlich jedes Gerät mit USB. Was nützen mir 64KB/s wenn nicht alle Pakete ordentlich ankommen?! Ich schreibe gerade ein HID Device über einem Atmega32u4 mit FullSpeed, beidseitig Interrupt gesteuert. btw... die Initialisierung des Mega:
1 | /*(Full-Speed 12Mbit/s) und Interrupts*/
|
2 | void usb_init_device(void) |
3 | {
|
4 | UHWCON = (1<<UVREGE); //Regelkreis zur Versorgung der D+ und D- Leitung einschalten |
5 | USBCON = ((1<<USBE) | (1<<FRZCLK) | (1<<OTGPADE)); //0xB0 USB Sender/Empf.,Takt und VBUS-Leitung einschalten |
6 | USBCON &= ~(1<<FRZCLK); // FRZCLK=0, noetig, sonst kein WAKEUP Int |
7 | USBCON |= (1<<FRZCLK); // FRZCLK=1 Strom sparen |
8 | |
9 | // Starte PLL
|
10 | PLLCSR = 0x10; // PLL Vorteiler fuer den Quarz |
11 | PLLCSR |= (1<<PLLE); // starte PLL (PLLEnable=1) |
12 | while (!(PLLCSR &(1<<PLOCK))); // Warte bis PLOCK = 1 (PLL eingerastet) |
13 | USBCON &= ~(1<<FRZCLK); // FRZCLK=0, aktiviere den Takt |
14 | UDCON &= ~(1<<0); |
15 | UDIEN = (1<<EORSTE); //0x08 erlaube End Of ReSeT Interrupt |
16 | }
|
Nur Probleme damit, die Datenpakete kommen mitunter nicht komplett an, ein Workaround dafür hab ich auch noch nicht gefunden, die 64kbit sind sowieso nur ein theoretischer Wert. Wenn der Endpoint und der Device Descriptor nicht richtig sitzt fischt man sowieso nur im Dunkeln weil man überhaupt keinen Hinweis bekommt wo der Fehler sein könnte und Debuggen is da nicht. Von dem riesigen USB Stack in C# will ich garnicht erst anfangen (Gut, in C++ wird das sicherlich einfacher sein - geb ich zu) Und dann wie gesagt: Der gelegentliche Datenverlust alle paar Sekunden. Und deine Aussage: Also ich habe noch auf KEINEM Gerät eine USB-CDC Treiber gebraucht, der ist ebenso standardisiert wie der HID Treiber. Und wer ne USB-HID aufsetzen kann, dem traue ich auch zu das er eine UART Paket basierend programmieren kann. Mein Fazit: Sollte es mir demnächst möglich sein, setze ich bei sowas definitiv wieder auf eine UART bassierte Lösung! Nach dem Theater den ich gerade mitmache mit HID, kommt bei mir das nur in die Tüte wenn es wirklich zwingen notwendig ist, aber für ne reine Datenübertragung?! Nie und nimmer wieder!
Wenn ich Datendurchsatz will nehm ich doch besser Ethernet. Ich muss ja nur eine bescheidene Funktionalitaet implementieren. Braucht halt eben eine ganz andere Hausnummer an Strom.
Walter schrieb: > Ich möchte für ein kleineres Studienprojekt quasi ein USB-Gerät > aufbauen, Schau doch mal da: http://www.hs-ulm.de/wir/Personal/PersonalSaSchr/vschilli/Mikrocontroller/USB-Projekte/ > Das ganze soll letztlich von einer plattformunabhängigen Software > geregelt/genutzt werden. http://www.hs-ulm.de/wir/Personal/PersonalSaSchr/vschilli/QtProjekte/
:
Bearbeitet durch User
Aus meiner Sicht ist der Hauptgrund, der gegen eine direkte USB-Verwendung spricht, die Vendor ID sowie die damit verbundenen Kosten.
Ich schrieb: > Aus meiner Sicht ist der Hauptgrund, der gegen eine direkte > USB-Verwendung spricht, die Vendor ID sowie die damit verbundenen > Kosten. Für Insellösungen ist das doch nicht relevant. Da kann man doch die IDs von den Herstellerbeispielen beibehalten. Dann gibt es (zumindest von Microchip) die Möglichkeit einer Sublizenz http://www.microchip.com/usblicensing/Default.aspx
Draco schrieb: > Was nützen mir 64KB/s wenn nicht alle Pakete ordentlich ankommen?! Was heißt nicht ordentlich? USB-Transfers (außer isochronous) sind gesichert. > Ich > schreibe gerade ein HID Device über einem Atmega32u4 mit FullSpeed, > beidseitig Interrupt gesteuert. btw... die Initialisierung des Mega: Für ein konformes HID-Device ist das nur ein Bruchteil des Codes. > Nur Probleme damit, die Datenpakete kommen mitunter nicht komplett an, > ein Workaround dafür hab ich auch noch nicht gefunden, die 64kbit sind > sowieso nur ein theoretischer Wert. Wenn der Endpoint und der Device > Descriptor nicht richtig sitzt fischt man sowieso nur im Dunkeln weil > man überhaupt keinen Hinweis bekommt wo der Fehler sein könnte und > Debuggen is da nicht. Richtig, Debuggen ist nicht einfach, wenn man keine entsprechenden Tools hat. Aber 64kBit sind keinesfalls theoretisch. Sofern kein Paket verloren geht ist das Normalität. > Und dann wie gesagt: Der gelegentliche Datenverlust alle paar Sekunden. Was heißt Datenverlust? Ich würde das eher auf ein Softwareproblem anstatt USB-Problem schieben. Wenn ein Paket verloren geht, dann sind das 64 Byte. Das merkt man kaum. Falls du Daten über mehrere Outputreports übertragen solltest, ist das schon der falsche Weg. Bei größeren Datenmengen sollte man eher zu Featurereports greifen und diese auch so groß machen wie die zu übertragenden Daten. > Und deine Aussage: Also ich habe noch auf KEINEM Gerät eine USB-CDC > Treiber gebraucht, der ist ebenso standardisiert wie der HID Treiber. > Und wer ne USB-HID aufsetzen kann, dem traue ich auch zu das er eine > UART Paket basierend programmieren kann. Wenn nicht das Problem mit dem Öffnen und Schließen von Ports wäre. Es ist besser als bei den Hardware-COMs aber immernoch vorhanden. Außerdem brauchst du unter Windows eine .inf Datei. Für mich gewinnt hier ganz klar das HID-Device. > Mein Fazit: Sollte es mir demnächst möglich sein, setze ich bei sowas > definitiv wieder auf eine UART bassierte Lösung! Nach dem Theater den > ich gerade mitmache mit HID, kommt bei mir das nur in die Tüte wenn es > wirklich zwingen notwendig ist, aber für ne reine Datenübertragung?! Nie > und nimmer wieder! Kannst du ja machen. Bei mir ist es genau andersherum. HID funktioniert, wenn es mal einigermaßen richtig implementiert ist, fantastisch.
avr schrieb: > Was heißt nicht ordentlich? USB-Transfers (außer isochronous) sind > gesichert. Es kommen fehlerhaften Daten an. avr schrieb: > Für ein konformes HID-Device ist das nur ein Bruchteil des Codes. Das ist sicherlicher richtig, das ist bloß das starten des USB als HS Device. avr schrieb: > Richtig, Debuggen ist nicht einfach, wenn man keine entsprechenden Tools > hat. Aber 64kBit sind keinesfalls theoretisch. Sofern kein Paket > verloren geht ist das Normalität. Was heißt hier richtige "Tools"? Das Debugen des Megas zeigt zwar welche Daten wo hin raus gehen, das sie rausgehen, wenn aber der Rechner das HID Device nicht erkennt weil was im Device Descriptor schief liegt, oder etwas in der Endpoint Zuordnung, dann hilft auch kein "Tool" selbst USB Diagnose Tools fallen dann aus, weil die ein angemeldetes Device brauchen. avr schrieb: > Was heißt Datenverlust? Ich würde das eher auf ein Softwareproblem > anstatt USB-Problem schieben. Wenn ein Paket verloren geht, dann sind > das 64 Byte. Das merkt man kaum. Es sind nichtmal 64Byte die ich übertrage, zumindest nicht im 1. Endpoint, der 0. Endpoint setzt dies ja vorraus, wird aber auch nur einmal abgefragt. Ich arbeite mit 16Byte. avr schrieb: > Falls du Daten über mehrere Outputreports übertragen solltest, ist das > schon der falsche Weg. Bei größeren Datenmengen sollte man eher zu > Featurereports greifen und diese auch so groß machen wie die zu > übertragenden Daten. Ein Outputreport mit 16byte und ein Inputreport mit 3Byte:
1 | static const uint8_t PROGMEM Rep_Desc_OutIn[32] = |
2 | {
|
3 | |
4 | // Output
|
5 | 0x06, 0x00, 0xFF, // USAGE_PAGE (Vendor Defined Page 1) |
6 | 0x09, 0x01, // USAGE (Vendor Usage 1) |
7 | 0x15, 0x00, // LOGICAL_MINIMUM (0) |
8 | 0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (255) |
9 | 0x75, 0x08, // REPORT_SIZE (8) |
10 | 0x95, 0x10, // REPORT_COUNT (16) |
11 | 0x91, 0x02, // OUTPUT (Data,Var,Abs) |
12 | |
13 | // Input
|
14 | 0x06, 0x00, 0xFF, // USAGE_PAGE (Vendor Defined Page 1) |
15 | 0x09, 0x01, // USAGE (Vendor Usage 1) |
16 | 0x15, 0x00, // LOGICAL_MINIMUM (0) |
17 | 0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (255) |
18 | 0x75, 0x08, // REPORT_SIZE (8) |
19 | 0x95, 0x03, // REPORT_COUNT (3) |
20 | 0x81, 0x02 // OUTPUT (Data,Var,Abs) |
21 | };
|
avr schrieb: > Wenn nicht das Problem mit dem Öffnen und Schließen von Ports wäre. Es > ist besser als bei den Hardware-COMs aber immernoch vorhanden. Außerdem > brauchst du unter Windows eine .inf Datei. Für mich gewinnt hier ganz > klar das HID-Device. Ok, das mit dem "Auffinden" des richtigen Ports - da gebe ich mich geschlagen, das ist korrekt. Ich habe mir da aber angewöhnt ne "Abfrage" in meine Programmierung mit "einzubauen" - bei Auflisten der einzelnen Ports auf der Rechnerseite wird, sofern möglich, jeder Port geöffnet - eine Zeichenfolge geschicht, welcher (wenn der µC an diesem Port hängt) beantwortet und eine andere definierte Zeichenfolge zurückschickt. Sollte keine Zeichenfolge zurückkommen, oder eine andere, wird der Port wieder geschlossen und der nächste probiert. Das hat sich eigentlich bis jetzt sehr gut bewährt. Das HID da einfacher mit VID/PID angesprochen werden kann - sehe ich richtig, das stimmt. Sofern man noch Windows XP/Vista einsetzt braucht man eine .inf - richtig. Aber ab Windows 7 schon nicht mehr, da greift er auf ein Standard CDC zurück. avr schrieb: > Kannst du ja machen. Bei mir ist es genau andersherum. HID funktioniert, > wenn es mal einigermaßen richtig implementiert ist, fantastisch. Die Betonung liegt auf "einigermaßen" ;-)
Draco schrieb: > Es kommen fehlerhaften Daten an. Das kann nicht sein. Da muss noch irgendwo was gewaltig schief gehen. Wie gesagt, die USB-Übertragung ist CRC gesichert, solange man keine Isochronous endpoints verwendet. Draco schrieb: > Was heißt hier richtige "Tools"? Es gibt verschiedene Arten von Tools: Man kann man PC Programme nehmen, die sich dort einklinken. Gerade wenn sehr früh etwas schief geht, helfen die auch nicht immer so viel. Es gibt aber auch richtige Hardware, die auf der USB-Leitung mitsnifft. Das geht mit Logikanalysern oder eben mit teurer Hardware, die dann auch entsprechende Analysesoftware mitbringt. Dein HID-Descriptor kommt mir ein bisschen seltsam vor. So gut kenne ich mich jetzt auch nicht mehr aus, aber ich meine das diese mindestens eine Collection haben müssen. Ich würde folgenden nehmen:
1 | Usage Page Vendor |
2 | Usage Vendor |
3 | Collection Application |
4 | Usage Page Vendor |
5 | Logical Minimum/Maximum |
6 | Report Size/Count |
7 | Input |
8 | Usage Vendor |
9 | Report Size/Count |
10 | Output |
11 | End Collection |
Außerdem stimmen deine Kommentare bei deinem Descriptor nicht immer überein. Zumindest steht da zweimal Output. Bei den PC-Debugging-Tools gibt es durchaus auch Programme mit Testversionen. Z.B. USBlyzer. Damit kann man solche Fehler auch finden. Denn wenn der Fehler in dem HID Descriptor steckt, dann wird dieser zumindest übertragen und das bekommt das Programm mit.
avr schrieb: > die USB-Übertragung ist CRC gesichert, solange man keine > Isochronous endpoints verwendet Auch isochrone Pakete haben CRC; der Unterschied ist, das der Controller sofort "ätsch, war nix" sagt, anstelle es noch einmal zu probieren. (Abschnitt 5.12.7 der USB-2.0-Spec.)
avr schrieb: > Dein HID-Descriptor kommt mir ein bisschen seltsam vor. So gut kenne ich > mich jetzt auch nicht mehr aus, aber ich meine das diese mindestens eine > Collection haben müssen. Ich würde folgenden nehmen: Das ist richtig - Das ist nur der Teil des Descriptors welche den Output und den Input Descriptor sicherstellt. Ohne die korrekte Struktur würde die Device sowieso nicht als Hid erkannt werden und einfach ein "fehlerhaftes USB-Device" aufgeführt. Der Descriptor String wird ja in mehreren Phasen vom Host abgefragt bei der Initialisierung - da wird er auch erst komplett gebildet. avr schrieb: > Außerdem stimmen deine Kommentare bei deinem Descriptor nicht immer > überein. Zumindest steht da zweimal Output. Ja das ist richtig - die hab ich nicht immer mitgeändert, nicht nur dort :-D Das ist mitunter Fahrlässig von mir und wird leider immer nen bissle Stiefmüterlich behandelt, aber es fällt mir auch immer regelmäßig auf die Füße wenn ich mal was suche.
Draco schrieb: > Die Betonung liegt auf "einigermaßen" ;-) Gibt es eigentlich keine "einigermaßen" funktionierende Demo Apps direkt von ATMEL für deinen Controller, die du "anpassen" könntest? (für irgendwelche Eval-Boards oder so...)
Walter schrieb: > Ich möchte für ein kleineres Studienprojekt quasi ein USB-Gerät > aufbauen, was sowohl Daten sendet, als auch empfängt. Soweit alles recht > einfach, soweit man nen Terminal verwendet und sich die Datenströme > anschaut. So wie ich das interpretiere ist bereits ein "Eigenes USB-Gerät" vorhanden, oder er weiß zumindest was er verwenden will. Er sucht nach einer > plattformunabhängigen Software Ich bezweifle, dass es eine fertige (plattformunabhängige) Software für sein Gerät gibt. Zumal noch nicht mal bekannt ist, was diese Software genau machen soll außer Daten senden und empfangen. Walter schrieb: > Was mir fehlt sind Suchbegriffe um für diese Thematik Texte zu finden. > Ich kann mir von der Terminal-Ebene zur Software-Ebene rüber wenig > vorstellen. Möchtest du dir ein eigenes Programm schrieben? Wenn es einfach ist die Daten in einem Terminal anzuschauen, dann wird das USB-Gerät wohl als (virtueller) COM-Port im System eingebunden. Was du brauchst ist eine Entwicklungsumgebung, die den COM-Port ansprechen kann.
John schrieb: > So wie ich das interpretiere ist bereits ein "Eigenes USB-Gerät" > vorhanden, Darüber kann man nur spekulieren. Vielleicht hat sich Walter schon vor Grausen abgewendet weil der Faden hier ja etwas verloren gegangen ist und wir werden es nie erfahren ;-)
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.