Gibt es eigentlich einen Microcontroller, der ohne zusätzliche Hardware (FTDI o.ä.) über USB mit einem PC kommunizieren kann?
Wenn du z.B. bei Atmel in den Product Selector gehst findest du eine ganze Menge. Und die gibt es nicht nur bei Atmel.
D.T.Schneiderlein schrieb: > Gibt es eigentlich einen Microcontroller, der ohne zusätzliche Hardware > (FTDI o.ä.) über USB mit einem PC kommunizieren kann? In der Arduino-Welt unter den 8-Bittern zum Beispiel der Atmega32U4 des Arduino Leonardo oder Arduino Micro. Bei den 32-Bittern der ATSAM3XEdes ARDUINO DUE Der kann USB sogar gleich doppelt: Einmal über den USB-Native Port. Und nochmal über den USB-Programming Port. Selbst ein ATtiNY85 ohne UART-Hardware kann aus der Arduino-IDE heraus ohne weitere Adapter-Hardware sowohl programmiert werden als auch eine serielle Schnittstelle bereitstellen, jedenfalls können das die kleinen Digispark-Module, allerdings mit nur eingeschränkter Arduino-Kompatibilität.
Recht preisgünstig bekommt auch auch den STM32F103 in diversen Varianten - auch als Modul.
Es gibt günstige uC von NXP mit integrierten USB-ROM-Treibern für CDC HID MSC RAMDISC hier muss man nichts selbst programmieren und braucht auch keine Library die Flash belegt. Die erforderlichen USB PID Lizenzen sind dabei umsonst: http://www.nxp.com/products/software-and-tools/software-development-tools/software-tools/usb-vid-pid-program:USB-VID-PID-PROGRAM Das wäre alle LPC11Uxx Cortex-M0 und LPC13xx LPC15xx Cortex-M3 und LPC541xx Cortex-M4 Dual-Core. Am einfachsten sieht man es daran dass in der Demo Projekte wie z.B. cdc_rom drin sind: http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/software-tools/lpcopen-libraries-and-examples:LPC-OPEN-LIBRARIES Wir verwenden z.B. als Ersatz für serielle Steuerungen dieses Board für USB HID: http://www.embeddedartists.com/products/lpcxpresso/lpc1549_xpr.php
Die billigste Lösung für Full Speed USB ist ein PIC16F1454. Beschaltung ist einfach - VCC, D+, D-, GND von Prozessor und USB miteinander verbinden, 100nF zwischen VCC und GND am Prozessor, dann vielleicht noch 10k zwischen VCC und MCLR, und das wars. Gibts auch in DIL. fchk
Vielen Dank für die vielen Antworten. Da ist bestimmt was passendes dabei. Ich habe bislang immer chinesische Arduino Nano Clons für meine Projekte verwendet. Da ich aber auch gewerblich unterwegs bin will ich künftig mehr auf ROhS achten. Für die meisten Projekte wird ein einfacher Microcontroller ohne viel Zusatzbeschaltung dann wohl ausreichen. Ich verwende die Microcontroller vor allem für analoge Messungen (Spannung, Strom bzw. Ströme) und zur Ansteuerung von WS2812B LED Stripes. Messergebnisse werden mit PC-Software und/oder LED Stripes visualisiert.
D.T.Schneiderlein schrieb: > Gibt es eigentlich einen Microcontroller, der ohne zusätzliche Hardware > (FTDI o.ä.) über USB mit einem PC kommunizieren kann? Das kann mit Bitbanging theoretisch jeder, der schnell genug ist, siehe v-usb für AVR. Du meinst sicherlich einen mit integriertem Hardware USB transceiver. Rufus Τ. F. schrieb: > Ja, Hunderte. Alleine bei Digikey bleiben in der Rubrik "Embedded-Microcontrollers" nach einer Suche nach "USB" noch >12400 Objekte gelistet. Davon befinden sich >3300 "in Stock". Dazu kommen dannn noch viele weitere aus der Rubrik "Anwendungsspezifisch". Frank K. schrieb: > Die billigste Lösung für Full Speed USB ist ein PIC16F1454. Der 0,76€ teure Si EFM8UB10F8G (c8051) ist darunter als Einzelstück am Günstigsten. (ab 1500 gibts den für 0,567€) Dein PIC16F1454 kostet 1,15€ pro Einzelstück. Da ist sogar ein samD11c14 (M0+) mit 0,93€ pro Einzelstück billiger. D.T.Schneiderlein schrieb: > Gibt es eigentlich einen Microcontroller, der ohne zusätzliche Hardware > (FTDI o.ä.) über USB mit einem PC kommunizieren kann? > Da ich aber auch gewerblich unterwegs bin will ich künftig > mehr auf ROhS achten. Hinweis: Wer gewerblich µCs nutzt, der sollte in der Laage sein absolute Basic's selbst zu recherchieren.
Ich benutze auch die NXP-Serie. Durch die ROM-API ist USB sehr einfach zu implementieren. Das war schnell erledigt.
InFo schrieb: > EFM8UB10F8G Der ist für einfache USB Anwendungen sehr gut allerdings hat der nicht wie die NXP LPC ein USB-API im ROM sondern das kommt in den 8KB Flash der damit dann schon fast voll ist. Weitere Einschränkungen z.B. ist der "12-bit ADC" eigentlich 10-bit mit Hardware-Mittelwertbildung und auch nicht sehr schnell.
Wobei der PIC der billigste ist, der 5V mit DIP-Gehäuse verbindet. Siehe https://hackaday.io/project/6258-two-component-usb-temperature-data-logger
Man sollte sich aber immer ansehen wie das unterliegende Protokol aussieht. Ist es ein HID, dh 64 packete zu wenig byte pro sekunde, oder UART, oder Massenspeicher. Bei massenspeicher wird's schwierig, etwas selbst zu senden. Das muss vom PC abgefragt werden. Man kann den PC eine spezifische Datei pollen lassen, aber das ist eher Muell. Ein eigenes USB Protokoll ? Vom Standard abgeleitet, Test & Measurement, oder auch nicht ... ist alles moeglich, nach einer voellig ueberzogenen Einarbeitungszeit. Und man muss fuer jede Windows Version in der Zukunft einen neuen Treiber bringen. Ein Kollege wollte einen ADC per "Measurement Devices" Protokoll einbinden. Und musste nach 6 Monaten das Handtuch werfen.
Der Nuller schrieb: > Ist es ein HID, dh 64 packete zu wenig byte pro sekunde, oder Meinst du vielleicht 64 Byte Pakete? 1000 davon pro Sekunde können natürlich relativ wenig (oder viel) sein.
Vielleicht ist auch die begrenzte Laenge des USB Kabels von max. 5m ein ungewolltes Limit.
InFo schrieb: > Hinweis: Wer gewerblich µCs nutzt, der sollte in der Laage sein absolute > Basic's selbst zu recherchieren. Vielleicht gab es dafür keine APP ... Gruß Jobst
Jetzt muss ich doch nochmal nachfragen: Ich bin zu dem Schluss gekommen, dass der MC sowohl mit einem PC als auch mit einem Android Endgerät (Smartphone oder Tablet) laufen soll. Der Einfachheit halber soll der MC vom Smartphone mit Strom versorgt werden. Das klappt nur wenn das Gerät OTG fähig ist. Der MC muss also mit einem Android Gerät kommunizieren, das im Host-Modus läuft. Gibt es da bei der Auswahl des MC irgendetwas zu beachten? Ansonsten hatte ich mit für den ATtiny 167 entschieden, weil ich den übers Arduino IDE programmieren kann.
Leider nur ein paar Hundert, von praktisch jedem Hersteller. Gucken musst Du allerdings schon selber. Ich kenne auch keinen Hersteller, der nicht schon, aus Gründer der Übersichtlichkeit, irgendwo auf seiner home page eine Excel kompatible Liste hat, die die Sortierung nach den verrücktesten Eigenschaften zulässt. Aber wie gesagt: Das linke und auch das rechte Auge musst Du schon aufmachen. Vielleicht wirft aber auch der mikrocontrollereigene Suchdienst was aus.
Oh, ich dachte was der ATtiny 85 (z.B. Digispark) kann, dass kann der 167 schon lange :-) Da muss ich wohl nochmal genauer nachsehen. Mir ist vor allem wichtig, dass ich einen möglichst gebräuchlichen MC finde, der sich übers Arduino IDE programmieren lässt und über den ich viele Infos und Tutorials im Netz finden kann. Vielleicht wäre der 32U4 (Arduino Micro) doch die bessere Wahl, wenn er auch ziemlich überdimensioniert ist.
D.T.Schneiderlein schrieb: > Oh, ich dachte was der ATtiny 85 (z.B. Digispark) kann, dass kann der > 167 schon lange :-) Der Tiny85 hat auch kein USB.
Jetzt steh ich irgendwie auf dem Schlauch. Die Digispark-Module können doch auch via USB mit dem PC kommunizieren. Ist das komplizierter umzusetzen als einen MC mit "integriertem Hardware USB transceiver" wie InFo schreibt?
> Der Tiny85 hat auch kein USB. > Jetzt steh ich irgendwie auf dem Schlauch. Die Digispark-Module > können doch auch via USB mit dem PC kommunizieren. Das ist kein "richtiges" USB Interface. Sowohl die Hardware als auch die Software sind mit der heißen Nadel gestrickt. Und es erfüllt nicht die USB Spezifikationen. Außerdem spricht das Ding kein Standard Protokoll. Du kannst ja mal mal "USBASP libusb" googeln und schauen, was für probleme die LOeute damit schon auf gewöhnlichen PC haben. Da wird es mit Smartphones noch heißer. Ganz ehrlich: Es ist schön, daß es diese USBASP Programmieradapter gibt. Sie wurden vom Batsler für Bastler entwickelt, als die kommerziellen Alternativen mindestens das zehnfache kostenen und es Mikrocontroller mit echtem USB Interface nicht zu kaufen gab. Aber für weitergehende Anwendungen, die in Zukunft auch funktionieren müssen, würde ich diesen Code, wo das USB Protokoll per Bit-Banging emuliert wird, auf keinen Fall wieder verwursten. > Ist das komplizierter umzusetzen als einen MC mit "integriertem > Hardware USB transceiver" wie InFo schreibt? Ja, definitiv. Am Einfachsten ist übrigens die Benutzung eines separaten USB-UART Chips, wie das in den ursprünglichen Arduino Modellen gemacht wurde. Aktuelle kann ich Dir da den Arduino Nano empfehlen, der nur ca 3 Euro kostet. Bei Smartphones solltest du unbedingt klären, welche Treiber das jeweilige Handheld Gerät enthält. Nicht daß du einen USB-UART dran steckst, für den du gar keinen Treiber hast. Das selbe Problem hast du auch beim Digispark. Ich war auch mal ganz versessen, Dinge über USB mit Tabklets zu steuern. Bis ich dann merkte, daß alle Geräte, die ich bezahlen konnte, gar kein OTG konnten. Und das einzige OTG fähige Smartphone in meiner Familie hatte wiederum keinen Treiber für meine zahlreichen USB Varianten (die am PC alle laufen). Bluetooth klingt zunächst praktikabler, allerdings sind gute Bluetooth Module relativ teuer (ich mag das BTM-222) und die Smartphones zicken oft herum. iPhones gehen damit gar nicht. Ernsthaft praktikabel ist meiner Meinung nach nur Netzwerk (WLAN). Denn das ist die einzige Schnittstelle, die bei jedem Tablet und Smartphone mit Sicherheit zuverlässig funktioniert. Außerdem kosten WLAN Module mit ESP8266 Chip weniger als 5 Euro und sie sind auch noch programmierbar (sogar mit Arduino). Diese WLAN Module haben so viel Speicherkapazität, dass du dort problemlos sogar die ganze Bedien-Oberfläche (sei es eine App zum Download oder eine interaktive Webseite) unterbringen kannst. Schau mal: http://stefanfrings.de/esp8266/index.html
Stefan U. schrieb: > Das ist kein "richtiges" USB Interface. Sowohl die Hardware als auch die > Software sind mit der heißen Nadel gestrickt. Und es erfüllt nicht die > USB Spezifikationen. Außerdem spricht das Ding kein Standard Protokoll. Woher kommt dieses halbwissen? Vom Hersteller selbst: Fully USB 1.1 compliant low-speed device, except handling of communication errors and electrical specifications. Vusb macht keine Probleme, solange man es richtig einsetzt. D.h. auch keine bulk-endpoints, weil diese bei low-speed verboten sind. Low-speed Devices sind aber überhaupt kein Problem. Die Softwareimplementierung läuft auch stabil. Warum soll vusb kein Standard Protokoll sprechen? Das ist die reine Low Level USB Implementierung. Das Standard Protokoll setzt du als Programmierer drauf, wie bei anderen Mikrocontrollern auch. CSC ist Standardkonform nicht möglich, bei HID stehen einem alle Möglichkeiten offen. Bitte schreibt doch nicht sowas über andere Projekte wenn ihr euch nur der Materie nicht auskennt.
> Woher kommt dieses halbwissen? Das ist in diesem Fall kein Halbwissen. Du hast die inkompatiblen Punkte selbst zittiert: > handling of communication errors and electrical specifications. > Das ist die reine Low Level USB Implementierung. Eben deswegen kannst du es auf Smartphones nur sehr eingeschränkt verwenden. Denn Low-Level Programmierung ist dort gar nicht vorgesehen. > Vusb macht keine Probleme Dann google mal oder lies einfach mal die Beträge dieses Forums hier mit. Ich bin seit vielen Jahren dabei. Und vergiss nicht, es geht inzwischen nicht nur um PC, sondern auch um Smartphones! Kannst du Treiber für Smartphones schreiben und installieren? Aber bitte ohne sie zu rooten!
D.T.Schneiderlein schrieb: > Ich bin zu dem Schluss gekommen, dass der MC sowohl mit einem PC als > auch mit einem Android Endgerät (Smartphone oder Tablet) laufen soll. Ist Dir bewusst, dass viele Android-Telefone keine Host-Funktion zur Verfügung stellen? Das Vorhandensein einer USB-Schnittstelle ist noch keine Garantie dafür, dass man diese auch in der gedachten Form nutzen kann.
H. schrieb: > Ist Dir bewusst, dass viele Android-Telefone keine Host-Funktion zur > Verfügung stellen? Beinahe jedes aktuelle Android Smartphone ist OTG-fähig und besitzt ab Werk Treiber für Hid und Massenspeicher.
InFo schrieb: > Beinahe jedes aktuelle Android Smartphone ist OTG-fähig und besitzt ab > Werk Treiber für Hid und Massenspeicher. "Beinahe". Kann man mit einer App auch rohes HID sprechen? Wenn da nur Tastaturen und Mäuse mit verwendet werden können, bringt das für solche Anwendungsfälle relativ wenig.
> Beinahe jedes aktuelle Android Smartphone ist OTG-fähig Nein. In der preisliga, in der ich einkaufe, sind fast alle nicht OTG fähig. Und wenn es OTG kann, fehlt in der Regel noch der nötige Treiber. > Kann man mit einer App auch rohes HID sprechen? Es gibt dazu keine Java API. Eventuell kann man ein Stück C Code über JNI benutzen, allerdings ist Google gerade fleißig dabei, das native Development Kit zu zerlegen und von seiner Benutzung abzuraten.
Stefan U. schrieb: >> Beinahe jedes aktuelle Android Smartphone ist OTG-fähig > > Nein. In der preisliga, in der ich einkaufe, sind fast alle nicht OTG > fähig. Und wenn es OTG kann, fehlt in der Regel noch der nötige Treiber. Wenn es speziell darum geht: uC USB OTG Android APP da gibt es genau ein komplettes Demo-Kit mit aller Software und Tutorials das würde sich dann eventuell lohnen. Hat noch den Vorteil dass USB elektrisch o.k. ist und das Smartphone nicht schrotten kann wie bei Eigenbau. http://www.embeddedartists.com/products/app/aoa_kit.php
D.T.Schneiderlein schrieb: > Oh, ich dachte was der ATtiny 85 (z.B. Digispark) kann, dass kann der > 167 schon lange :-) Da muss ich wohl nochmal genauer nachsehen. Mir ist > vor allem wichtig, dass ich einen möglichst gebräuchlichen MC finde, der > sich übers Arduino IDE programmieren lässt und über den ich viele Infos > und Tutorials im Netz finden kann. Vielleicht wäre der 32U4 (Arduino > Micro) doch die bessere Wahl, wenn er auch ziemlich überdimensioniert > ist. So wie Du hier fragst: vergiss es. Nimm diesen Chip hier für die Android-Anbindung: http://www.ftdichip.com/Products/ICs/FT312D.html Dieser Chip wurde extra für Android gemacht, und er spielt Host. Heißt also, es sollte mit jedem Phone funktionieren, OTG-fähig muss es nicht sein. An den USB-Port dieses Chips gehört eine USB-A Buchse, weil es ein Host ist. Für die PC-Kommunikation nimmst Du dann den hier: http://www.ftdichip.com/Products/ICs/FT231X.html An den USB-Port dieses Chips gehört eine USB-B Buchse, weil es ein Device ist. Der Microcontroller selber ist dann egal, es muss halt nur ein 3.3V Typ sein und er muss zwei UARTs haben. Ein Atmel ATSAMD21G18, wie er auf dem Arduino M0 ist, wäre keine schlechte Wahl. fchk
Stefan U. schrieb: > Woher kommt dieses halbwissen? > > Das ist in diesem Fall kein Halbwissen. Du hast die inkompatiblen Punkte > selbst zittiert: > > handling of communication errors and electrical specifications. Wenn die USB Implementierung richtig ist treten fast nie communication errors auf. Wie man die uC Pins an den Bus anschließt ist eine andere Sache. Die Diodenlösung ist Pfusch. > Das ist die reine Low Level USB Implementierung. > > Eben deswegen kannst du es auf Smartphones nur sehr eingeschränkt > verwenden. Denn Low-Level Programmierung ist dort gar nicht vorgesehen. Ich habe das Gefühl du hast weder USB noch vusb verstanden. Jeder usb-uC bietet erst Mal ein USB interface, welches auf diesem Level angesprochen wird. Das hat absolut nichts mit dem Host zu tun. Der Programmierer ist dafür verantwortlich, dass der restliche Teil des Standards eingehalten wird. Dieser Teil kommt oftmals vom Hersteller, wie auch bei vusb. Darüber kommt die Implementierung der USB Klasse. Diese muss nun fast immer selbst implementiert werden. Wenn irgendwo ein Fehler ist, hakt es. Und diese Fehler sind in den meistens Fällen dort, wo die Programmierer am wenigstens qualifiziert sind. Bei Hobby Programmierern, welche vielleicht nicht Mal in den Standard schauen, ist das die USB Klasse. Und Fehler werden dann gern auf was anderes geschoben. > > Vusb macht keine Probleme > > Dann google mal oder lies einfach mal die Beträge dieses Forums hier > mit. Ich bin seit vielen Jahren dabei. Und trotzdem fehlen die Grundlagen von USB. Ich hab schon auf verschieden uCs verschiedene USB Klassen implementiert. Meine vusb hid Implementierung lief bisher zu 100% stabil. Ich hatte keinen einzigen Aussetzer, nach den Implementierung stimmte. USB ist ein komplexes Thema - viele Probleme deuten da nicht auf eine fehlerhafte Implementierung vusbs hin. Auch bei anderen USB Controllern gibt es viele Leute die Probleme haben. > Und vergiss nicht, es geht inzwischen nicht nur um PC, sondern auch um > Smartphones! Kannst du Treiber für Smartphones schreiben und > installieren? Aber bitte ohne sie zu rooten! Grundlagen! Was hat denn bitte der Treiber mit der low-level usb implementation zu tun? Genau, gar nichts. Für low-speed Devices ist vusb völlig ausreichend. Für alles andere muss man sich eine Alternative suchen. Wenn ich ein cdc device will, dann fällt vusb raus (wobei ich absolut kein cdc-fan bin - dann lieber hid, falls 64KB/s reichen und dafür fällt die Auswahl des com-ports weg. Ganz nett dagegen ist ein virtuelle Netzwerkkarte über cdc). Bei HID geht das auch mit Smartphones nicht schlechter als nur einem usb-uC. Ganz ehrlich, wenn du Probleme mit USB hast, dann wird das mit 99,9% mit deinem Code zusammenhängen.
Wenn du wirklich vusb mit cdc benutzt hast, dann höre auf vusb deswegen madig zu reden. DU hast die Spezifikationen verletzt, nicht vusb. Vusb ist nicht für bulk-endpoints gedacht!
@avr: Ich glaube Dir gerne, daß du mit vusb ordentliche Anwendungen erstellen können. Und ja, ich kann es nicht. Es geht in diesem Thread aber eigentlich nicht um uns beide, sondern um das Projekt von D.T.Schneiderlein. So wie ich das sehe, braucht er eine Lösung, die mit den Treibern auskommt, die auf dem PC bzw. insbesondere dem Smartphone bereits ab Werk installiert sind. Dies ist beim Digispark nicht der Fall. Auch die Arduino Umgebung hilft dabei nicht. Daß die Hardware-Umsetzung mit ATtinies nicht sauber ist, ist dabei noch das kleinste Übel. Deswegen hätte ich ihn noch nicht abgeraten. Abgeraten habe ich, weil ich keine Chance sehe, daß der TO in absehbarer Zeit einen ATtiny an die USB Schnittstelle seines Handies hängt und eine Anwendung dafür schreibt. Du scheinst allerdings Interesse zu haben, ihm dabei unter die Arme zu greifen, sehe ich das richtig?
Stefan U. schrieb: > Deswegen hätte ich ihn noch nicht abgeraten. Abgeraten habe ich, weil > ich keine Chance sehe, daß der TO in absehbarer Zeit einen ATtiny an die > USB Schnittstelle seines Handies hängt und eine Anwendung dafür > schreibt. Ich hab zwar schon eine Menge im USB Standard gelesen, aber ich weiß nicht was in Smartphones für Treiber vorhanden sind und vor allem auch genutzt werden können. Richtig ist natürlich, dass für hid eine entsprechende API benötigt wird. Mir ging es nur darum, dass vusb nicht in ein falsches Licht gestellt wird. > Du scheinst allerdings Interesse zu haben, ihm dabei unter die Arme zu > greifen, sehe ich das richtig? Ich kenne seinen Kenntnisstand nicht. Programmieranfängern rate ich grundsätzlich von USB auf uCs ab. Wenn jemand eine gewisse Eigenständigkeit mitbringt und dann spezielle Fragen oder Probleme hat, helfe ich gerne. Man sollte bei USB aber wissen, dass debugging sehr langwierig sein kann.
avr schrieb: > Vusb macht keine Probleme, solange man es richtig einsetzt. Warum kämpfst du so verbissen für solch einen Schnee von gestern? Heutzutage hat man genug moderne µC, die einen USB-Device-Peripheriecore enthalten, den man in seiner selbstgeschriebenen Firmware bloß anständig zu benutzen braucht. Und solche µC sind mittlerweile auch billig genug. Wozu sich bei µC-Preisen von einem bis wenigen Euros um 14 Cent streiten, wo die Buchse allein schon ein paar Cent mehr kostet? Oder der passende Quarz nen Euro? Ich halte auch nichts davon, für derartige Unternehmungen verbissen mit 8 Bit AVR arbeiten zu wollen. Man nehme nen billigen Cortex und fertig ist die Laube. Wozu also so eine Verbissenheit? W.S.
Zunächst nochmal vielen Dank für euren Einsatz hier. Es ist wie gesagt tatsächlich so, dass ich meine bisherigen Projekte auf Arduiono Nanos umgesetzt waren. Ich arbeite da tatsächlich auf Anfänger Niveau, wenn ich inzwischen auch schon einige Projekte umgesetzt habe. Es ist aber so, dass ich hier schon jemanden habe, der mit beim Programmieren hilft und der auf einem wesentlich höheren Niveau arbeitet als ich. Allerdings hat er bislang auch nur mit fertigen Arduinos gearbeitet. Wie dem auch sei, wir wollen künftig aus verschiedenen Gründen (z.B. ROhS, Platzgründe, Professionalität) künftig keine Module mehr verwenden und uns darum in die Verwendung von MC in Verbindung mit USB einarbeiten. Meine Frage ist um Grunde die nach den optionalen Bedingungen um und erstmalig mit der genannten Fragestellung auseinanderzusetzen. Die Idee keinen zusätzlichen FTDU Chip zu verwenden entstand um die Schaltung einfacher zu halten. Da der MC vom Handy mit Strom versorgt werden soll ist OTG unumgänglich, denn sonst liegt am USB-Port hat keine Spannung an. Bluetooth und WLAN sind deshalb auch raus. Ich habe zwar eine externe Spannung zwischen 0 und 60V zur Verfügung, aber die Spannung ist öfter auch bei 0V, sodass entweder ein Stromspeicher verwendet werden oder die Verbindung ständig neu aufgebaut werden müsste. Vielleicht sollte ich erst mal einen Arduiono Micro kaufen und damit ein bisschen experimentieren. Wenn ich das richtig sehe wird dort kein externer ftdu chip verwendet. Taugt der Microcontroller, der da drauf ist wohl für meine Zwecke? z.B. sowas:https://www.arduino.cc/en/Tutorial/AndroidAccessoryAnalogRead
D.T.Schneiderlein schrieb: > Da der MC vom Handy mit Strom versorgt werden soll ist OTG unumgänglich, > denn sonst liegt am USB-Port hat keine Spannung an. Bluetooth und WLAN > sind deshalb auch raus. Ich habe zwar eine externe Spannung zwischen 0 > und 60V zur Verfügung, aber die Spannung ist öfter auch bei 0V, sodass > entweder ein Stromspeicher verwendet werden oder die Verbindung ständig > neu aufgebaut werden müsste. Ein Stromspeicher ist ein Akku. So etwas ist Standard. Du solltest davon Abstand nehmen, das Phone als Stromquelle zu verwenden. Manche mögen es nicht. > Vielleicht sollte ich erst mal einen Arduiono Micro kaufen und damit ein > bisschen experimentieren. Wenn ich das richtig sehe wird dort kein > externer ftdu chip verwendet. Taugt der Microcontroller, der da drauf > ist wohl für meine Zwecke? > > z.B. sowas:https://www.arduino.cc/en/Tutorial/AndroidAccessoryAnalogRead Ich denke, Du solltest jemanden mit Know-How in Deiner Nähe haben. Das ist die erste Stufe. Zu Deinem Vorhaben: Schau Dir das da an: https://www.sparkfun.com/products/13907 Hat WLAN, Bluetooth (Classic und LE), und einen Anschluss für einen Akku wie diesen hier. https://www.sparkfun.com/products/13813 Da ist der Schaltplan dabei, aber Abpinnen können müßt Ihr schon selber. Damit hast Du wenigstens eine Chance bei Deinem Kenntnisstand. fchk
> Wie dem auch sei, wir wollen künftig aus verschiedenen Gründen (z.B. > ROhS, Platzgründe, Professionalität) künftig keine Module mehr verwenden Aha, jetzt kommt die Katze aus dem Sack! Es geht also um kommerzielle Produkte, die professionell sein sollen. In diesem Fall ist vusb definitiv ein No-Go. Alleine schon, weil es die USB Spezifikation nicht einhält und daher niemals ein USB Logo tragen darf. Du darfst deinen Kunden nicht einmal sagen, daß diese Geräte eine USB Schnittstelle haben. Du darfst höchstens sagen "Diese Produkte haben eine eingeschränkt USB kompatible Schnittstelle". Wetten, das kauft Dir keiner ab? > Arduino Micro .. Taugt der Microcontroller... wohl für meine Zwecke? Die Antwort hast du bereits ganz am Anfang bekommen. Ja, der ATmega32u4 hat eine "echte" USB Schnittstelle. Was ist mit deiner Smartphone kompatibilität? Hast du einen Plan, wer den nötigen Treiber entwickelt, wer dazu die Java API schreibt und wie du das installiert bekommst? Wie sieht es mit Updates und Funktionsgarantien aus? Dein Kunde wird womöglich ziemlich sauer sein, wenn das alles nach einem Android Upgrade oder anch einem Gerätewechsel nicht mehr funktioniert. Kannst du ihm dann (eventuell 5 Jahre nach dem Kauf) noch helfen? Dein Lösungsansatz, das Smartphone zur Stromversorgung zu missbrauchen ist von Ansatz her schon schlecht. Nur wenige Geräte können das, und die liefern auch nur wenige hundert mA. Da Du zwangsläufig irgendwie das Smartphone aufladen musst, kannst du an dieser Stromquelle auch das externe Gerät betreiben oder aufladen. Schau Dir meine Seite zum ESP8266 an, damit wirst du schnell zum Ziel kommen.
D.T.Schneiderlein schrieb: > Gibt es eigentlich einen Microcontroller, der ohne zusätzliche Hardware > (FTDI o.ä.) über USB mit einem PC kommunizieren kann? Na ja, und dann gibts ja noch die von Cypress. FX2(8051) und FX3(ARM9).
D.T.Schneiderlein schrieb: > (z.B. ROhS, Platzgründe, Professionalität) D.T.Schneiderlein schrieb: > ohne zusätzliche Hardware (FTDI o.ä.) Wenn die Entwicklungsgeschwindigkeit durch die Nutzung eines solchen ICs nennenswert beschleunigt oder vereifacht wird und nicht jeder ct zählt (Massenproduktion), spricht doch nichts dagegen auf eine solche Lösung zu setzen. Da ihr vermutlich das Gehäuse selbst designed ist es doch sicher möglich zB. einen cp2102n (3x3mm) irgendwo unterzubringen. Es existieren im Google Playstore Terminal Programme, die tatsächlich ohne Routen funktionieren. Es geht also. Treiber zB. https://github.com/mik3y/usb-serial-for-android Wie es mit der Lizenz und kommerziellen Projekten aussieht steht auf einem anderen Blatt.
avr schrieb: > Fully USB 1.1 compliant low-speed device, except handling of > communication errors and electrical specifications. Also auf Deutsch: "Zu 100% konform, außer an den Stellen, wo es nicht konform ist".
Okay, also scheint ein zusätzliches Bauteil für die USB-Kommunikation (z.B. FTDI) schon Sinn zu machen. Das werde ich beherzigen. Danke für den Link mit dem Treiber. Das wird und sicher sehr weiterhelfen. Wieso die Stromversorgung nicht vom Handy kommen soll versteh ich nicht so ganz. Wenn ich einen USB-Stick abschließe wird der doch auch über das Handy versorgt. Es ist auch anders Zubehör zu finden, das übers Handy versorgt wird. Microcontroller, Stromsensor und FTDI-Chip sollten zusammen weniger als 30mA benötigen. Ich bin natürlich auch für andere Lösungen offen. Bluetooth 4 möchte ich auch nicht von vornherein ausschließen. Es ist nur so, dass die Verbindung innerhalb von 2-3 Sekunden stehen sollte. Meine Erfahrung ist eher die, dass das eine Sache von Minuten ist und das ist hier definitiv zu lang. Wenn die Handy-App aber quasi immer laufen und den MC suche würde und die Verbindung innerhalb weniger Sekunden aufgebaut würde, dann wäre das schon auch eine Option.
Die ESP8266 Module brauchen für den Aufbau der WLAN Verbindung (incl. Access Point) weniger als 5 Sekunden.
D.T.Schneiderlein schrieb: > Wieso die Stromversorgung nicht vom Handy kommen soll versteh ich nicht > so ganz. Ua. weil der Akku, der heute zunehmend fest verbaut wird zusätzlich belastet wird. (Kümmert den Standard-user weniger) D.T.Schneiderlein schrieb: > Handy-App aber quasi immer laufen Und Bluetooth ist dann auch immer an... Da wird sich der Standardnutzer wundern, warum "das Smartphone so schnell leer ist". D.T.Schneiderlein schrieb: > Bluetooth 4 möchte ich auch nicht von vornherein ausschließen Da beginnt die Schwierigkeit evtl. schon bei der Auswahl des Profils: https://de.m.wikipedia.org/wiki/Bluetooth-Profile Außerdem benötigt dein Gerät dann einen Akku, Tiefentladeschutz und Laderegler. Ich möchte dir von nichts abraten, denn grundsätzlich hängt was und wie du etwas realisierst von deinem Know-How, deiner Bereitschaft zu lernen und der verfügbaren Zeit ab.
D.T.Schneiderlein schrieb: > Ich bin natürlich auch für andere Lösungen offen. Bluetooth 4 möchte ich > auch nicht von vornherein ausschließen. Es ist nur so, dass die > Verbindung innerhalb von 2-3 Sekunden stehen sollte. Meine Erfahrung ist > eher die, dass das eine Sache von Minuten ist und das ist hier definitiv > zu lang. Wenn die Handy-App aber quasi immer laufen und den MC suche > würde und die Verbindung innerhalb weniger Sekunden aufgebaut würde, > dann wäre das schon auch eine Option. Wenn die Geräte einmal gepaart sind, geht der Rest schnell. Der ESP32, den ich Dir vorgeschlagen habe, hat WLAN und Bluetooth, und zwar sowohl klassisches Bluetooth als auch Bluetooth LE (das sind zwei völlig verschiedene Dinge, die nur zufällig so heißen). fchk
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.