ich möchte einen Datenlogger entwickeln. Analogwerte werden von einem uC eingelesen. Wie kann ich diese vom uC an einen PC senden, um sie dort mit einer Monitor Software ansehen zu können? Von Microchip gibt es uC mit integrierter USB Schnittstelle. Hat da jemand Erfahrung? Wie kann ich auf diese Daten von einem PC wieder zugreifen? Gibt es eine API? Für jede Hilfe dankbar!
Dieter schrieb: > Wie kann ich auf diese Daten von einem PC wieder zugreifen? Gibt es eine > API? > Für jede Hilfe dankbar! Viele Arduinos haben direkt eine USB-Schnittstelle drauf. Es reicht einer mit einem USB-Seriell Wandler. Auf dem PC siehst du einen ganz gewöhnlichen COM-Port. Serielle Verbindungen werden von den meisten Programmiersprachen mit passenden Funktionen direkt unterstützt.
Ich würde wohl auch für solche simplen Anwendungen einen UART-USB-Wandler nehmen. Wie Wolfgang bereits erwähnt hat meldet sich dieser als einfacher Com-Port und die eingehenden Daten können direkt weiterverarbeitet werden. Natürlich vorausgesetzt, du hast keine riesigen Datenmengen, welche in kürzester Zeit übermittelt werden müssen.
Ich habe für eine Reader uralter EPROMs (http://ultronics.de/all/1702A/EprRd1702A_01.jpg) ein Microchip/Atmel ATSAMD21-XPRO Board verwendet, welches über seinen USB-Anschluss neben einer Debug-Schnittstelle auch einen virtuellem COM-Port zur Verfügung stellt. Viele Evaluation-Boards machen dies auf gleiche Weise, z.B. die ganze Nucleo-Boards von SGS-Thomson, so dass die Entwicklung über die Debug-Schnittstelle und die Applikationskommunikation über den virtuellen COM-Port abgewickelt werden kann.
Wie man die Daten in den PC bekommt haengt m.e.a. als Wichtigstes von der benoetigten Datenrate ab. Un die teilst Du uns nicht mit!
Ich empfehle auch, erstmal über einen UART2Seriell-Wandler zu gehen. USB ist alles andere als einfach, man muss ja nicht nur auf dem uC den USB Kram implementieren sonder auch auf PC Seite einen Treiber entwickeln.
Wenn für die geforderte Datenrate eine gewöhnliche serielle Schnittstelle ausreicht: Wie schon angesprochen, kann man die Daten einfach per UART-USB-Converter an einen virtuellen COM-Port des PCs senden. "FTDI" wäre da mal ein Stichwort mit dem man starten kann.
Hallo, zur "Virtuelle Instrumente an serielle Schnittstelle", schau mal bitte hier: # Beitrag "Re: Projekt: Virtuelle Instrumente an serielle Schnittstelle" # http://www.serialcominstruments.com/instrument.php
Dieter schrieb: > Wie kann ich auf diese Daten von einem PC wieder zugreifen? Gibt es eine > API? Windows 10 kann USB CDC Geräte automatich als COM Port anbinden. Praktisch jeder USB µC hat ein Hersteller Beispiel mit USB CDC. Alternativ gäbe es WinUSB oder LibUSB.
Dieter schrieb: > Von Microchip gibt es uC mit integrierter USB Schnittstelle. Hat da > jemand Erfahrung? Ja, wenn du mit PICs schon etwas Erfahrung* hast, dann ist das easy. (* mehr als LED blinken lassen) > Wie kann ich auf diese Daten von einem PC wieder zugreifen? Gibt es eine > API? Ja. Schau mal da: http://www.hs-ulm.de/nocache/wir/Personal/PersonalSaSchr/vschilli/Mikrocontroller/USB-Projekte/ Die Beispiele sind etwas älter. Inzwischen sind die Projekte in den MLA nicht mehr so "generic". Für jeden Controller gibt es jetzt ein separates Projekt und nicht mehr ein Projekt mit dutzenden von Konfigurationen für alle möglichen Controller und Demoboards. Beispiele für PC Software für CDC oder HID Geräte, die keine extra Treiber benötigen: http://www.hs-ulm.de/nocache/wir/Personal/PersonalSaSchr/vschilli/QtProjekte/ Das HID Demo Beispiel hat auf dem nicht zu sehenden "Demo" Tab auch eine Datendarstellung, ähnlich wie das QCustomPlot Beispiel. (siehe -> http://picforum.ric323.com/viewtopic.php?f=46&t=103#p745)
Stefan S. schrieb: > Natürlich vorausgesetzt, du hast keine riesigen Datenmengen, welche in > kürzester Zeit übermittelt werden müssen. Für riesige Datenmengen ist ein Mikrocontroller auch nicht da. Ich habe schon Datenraten von 0,2 MB/s über ein USB-Seriell Wandler mit ein Mikrocontroller erreicht. Was ist deine Definition von Riesig?
Dieter schrieb: > Von Microchip gibt es uC mit integrierter USB Schnittstelle Was häufig übersehen wird, was aber am einfachsten geht, ist USB HID, geht ohne Treiber. Hier sind Beispiele auch für PIC: http://janaxelson.com/hidpage.htm Es gibt aber auch bessere uC dafür als PIC: https://www.silabs.com/products/development-tools/mcu/8-bit/sltb005a-efm8-universal-bee-usb-capable-starter-kit https://www.nxp.com/support/developer-resources/hardware-development-tools/lpcxpresso-boards/lpcxpresso-board-for-lpc1549:OM13056
Welche Grundlagen hierzu hast du denn ? kannst du programmieren ? wieviel Erfahrung hast du mit Mikrokontrollern ? https://www.amazon.de/Elegoo-Mikrocontroller-ATmega2560-ATMEGA16U2-Kompatibel/dp/B01MA5BLQI/ref=pd_cp_147_1?_encoding=UTF8&psc=1&refRID=570KMYH6G370YQK1VX5J Bischen Code schreiben und schon kansst du 16 ADC Kanäle auf deinem PC anzeigen lassen.
Dieter schrieb: > ich möchte einen Datenlogger entwickeln. Analogwerte werden von einem uC > eingelesen. Wie kann ich diese vom uC an einen PC senden, um sie dort > mit einer Monitor Software ansehen zu können? > Von Microchip gibt es uC mit integrierter USB Schnittstelle. Hat da > jemand Erfahrung? Ja. Ein PIC16F1455 (der '1454 hat keine ADCs) ist die billigste und kleinste Lösung. Der hat zertifizierte USB 2.0 Hardware eingebaut und kommt im 14-Pin Gehäuse - auch als DIL14, wenn Du willst, oder als 4mm*4mm QFN16, wenn Du es besonders klein haben willst. Du kannst damit zB USB HID (z.B. Tastatur, Maus, oder custom) oder CDC (virtueller COM-Port) implementieren. Auf dem PC brauchst Du dafür keine speziellen Kerneltreiber - jedes Betriebssystem bringt das erforderliche mit, egal ob Windows, MacOS, Linux, OpenBSD oder was weiß ich. Einen Quarz brauchst Du für USB Betrieb nicht, was die Kosten weiter senkt. Der Chip kostet in Stückzahlen deutlich unter einem Euro. Du brauchst ein PICKIT3, MPLABX IDE, den XC8 Compiler und die MLA Microchip Libraries for Applications (da ist der USB Stack drin) von Microchip. Und natürlich solide C-Kenntnisse. fchk
Lothar schrieb: > Was häufig übersehen wird, was aber am einfachsten geht, ist USB HID, > geht ohne Treiber. Schön! Ist aber nicht wirklich für die Datenübertragung geeignet. Es sei denn man will wirklich eine dauernd quatschende Tastatur und einen zuckenden Mauszeiger
Arduino F. schrieb: > Lothar schrieb: >> Was häufig übersehen wird, was aber am einfachsten geht, ist USB HID, >> geht ohne Treiber. > > Schön! > Ist aber nicht wirklich für die Datenübertragung geeignet. > Es sei denn man will wirklich eine dauernd quatschende Tastatur und > einen zuckenden Mauszeiger Von was redest du da?
ich denke das Problem liegt weniger auf der uC-Seite (dafür gabs ja schon genügend Anregungen) sondern mehr auf der PC-Seite. Wer soll die Daten in Empfang nehmen? Und was damit tun? ich hatte eine ähnliche Anforderung mit einem Datenlogger meiner Wärmepumpe. Viele Daten, viel Redundanz. RRDB ist ein guter Ansatz. Aber "fertiges" habe ich nicht gefunden. Aber der findige Programmierer baut sich halt selbst was... ist aber durchaus aufwändig.
Arduino F. schrieb: > Lothar schrieb: >> Was häufig übersehen wird, was aber am einfachsten geht, ist USB HID, >> geht ohne Treiber. > > Schön! > Ist aber nicht wirklich für die Datenübertragung geeignet. > Es sei denn man will wirklich eine dauernd quatschende Tastatur und > einen zuckenden Mauszeiger So lange Du nicht mehr als 64kB/s brauchst, funktioniert das ganze ganz gut. Beispiele sind z.B. Atmel ICE und JTAGICE3 (mit neuerer Firmware), CMSIS DAP JTAG für ARM, SILabs CP2110 HID USB to UART bridge und viele andere. fchk
Volker S. schrieb: > Von was redest du da? Hiervon: Dieter schrieb: > ich möchte einen Datenlogger entwickeln. Analogwerte werden von einem uC > eingelesen. Wie kann ich diese vom uC an einen PC senden, um sie dort > mit einer Monitor Software ansehen zu können? Ich wäre dir dankbar, wen du mir erzählen könntest wie man das mit einem HID Device hin bekommt. Oder, warum HID an der Stelle besser ist.
Michael R. schrieb: > ich denke das Problem liegt weniger auf der uC-Seite... Bisher ist die Beschreibung des Problems so unscharf, dass wir nicht mal wissen, ob es überhaupt eins ist ;-)
Arduino F. schrieb: > Ist aber nicht wirklich für die Datenübertragung geeignet. > Es sei denn man will wirklich eine dauernd quatschende Tastatur und > einen zuckenden Mauszeiger So ein Unsinn. Zwar sind USB-Mäuse und -Tastaturen allesamt HID-Geräte, aber natürlich gilt die Umkehrung nicht. D.h.: man kann problemlos HID-Geräte implementieren, die weder Maus noch Tastatur sind und dementsprechend weder sinnlose Zeichen plappern noch den Mauszeiger wackeln lassen. Man muss eben einfach nur wissen, was man tut. Sprich: mehr können, als Arduinokram zusammzuleimen...
Arduino F. schrieb: > Ich wäre dir dankbar, wen du mir erzählen könntest wie man das mit einem > HID Device hin bekommt. Mit einem "custom" HID kannst du schicken was immer du willst, solange die dafür verfügbare Bandbreite ausreicht. (<64Byte/ms) Ob es an "der" Stelle besser oder schlechter ist, kann ich anhand der vorliegenden Informationslage nicht abschließend beurteilen. HID ist meiner Meinung nach, bei Datenraten kleiner der 64kB/s, am einfachsten zu realisieren.
Arduino F. schrieb: > Ich wäre dir dankbar, wen du mir erzählen könntest wie man das mit einem > HID Device hin bekommt. > > Oder, warum HID an der Stelle besser ist. Du brauchst keinen Kerneltreiber und bei Windows <10 kein .inf für ein CDC. Die Ansteuerung von HIDs unter Windows geht über SETUPAPI.DLL/.LIB zum Durchsuchen des Device Trees und HID.DLL/.LIB für die eigentliche Kommunikation. Beispiele dafür findest Du in der MSDN Library, das brauche ich hier nicht zu wiederholen. Wenn Du fit in Win32 Programmierung bist, solltest Du das in spätenstens zwei Tagen am Laufen haben. Du brauchst das Windows Driver Kit für die Link-Libraries, die Du ins Visual Studio einbinden musst. fchk
Beitrag #5296035 wurde von einem Moderator gelöscht.
Arduino F. schrieb im Beitrag #5296035: > Den Aufwand das über eine virtuelle Serielle zu machen kann ich > abschätzen. > Geht auch problemlos mit allen übliche Betriebssystemen. Geht mit der HID-API von Alan Ott wunderbar. Das von mir weiter oben verlinkte Beispiel verwendet die. http://www.signal11.us/oss/hidapi/ Einfach den Sourcecode einbinden und das gleiche Projekt ohne Änderungen unter Windows oder Linux compilieren. MacOS müsste aufch gehen, habe ich aber selber noch nie getestet.
Dieter schrieb: > ich möchte einen Datenlogger entwickeln. Analogwerte werden von einem uC > eingelesen. Wie kann ich diese vom uC an einen PC senden, um sie dort > mit einer Monitor Software ansehen zu können? einfach, Arduino nano, fertig Die Frage ist nur welche Rate pro Sekunde? leicht ist es alle 15 Sekunden Temperatur und Luftfeuchte auszugeben hier alle 6 Zeilen eines Nokia LCD5110
1 | if(alt_sek!=RTC.second) |
2 | { alt_sek=RTC.second; |
3 | if(!(alt_sek%15)) |
4 | {
|
5 | if(!strlen(serial_in_buff)) |
6 | {
|
7 | Serial.println(); |
8 | Serial.println(&menu[HAUPT_SCREEN][0][0]); |
9 | Serial.println(&menu[HAUPT_SCREEN][1][0]); |
10 | Serial.println(&menu[HAUPT_SCREEN][2][0]); |
11 | Serial.print(lefts(&menu[HAUPT_SCREEN][3][0], 12)); Serial.print((char)42); Serial.println(&menu[HAUPT_SCREEN][3][13]); |
12 | Serial.print(lefts(&menu[HAUPT_SCREEN][4][0], 12)); Serial.print((char)42); Serial.println(&menu[HAUPT_SCREEN][4][13]); |
13 | Serial.println(&menu[HAUPT_SCREEN][5][0]); |
14 | } // if(!strlen(serial_in_buff)) |
15 | } // if(!(alt_sek%15)) |
16 | } // if(alt_sek!=RTC.second) |
Volker S. schrieb: > Joachim B. schrieb: >> hier alle 6 Zeilen eines Nokia LCD5110 > > Ähhhh, ich blick's absolut nicht ;-) was bitte? etwa "Serial.println(&menu[HAUPT_SCREEN][0][0]);"
Sorry, habe dein Foto gar nicht bemerkt. Konnte überhaupt keinen Bezug zur Frage nach der Kommunikation zwischen uC und PC herstellen. Dachte echt das wäre nur ein Scherz.
Kleine Anmerkung noch zum Thema USB-Serial Wandler, weil das angeblich einfacher wäre. WENN man den ganzen USB Kram selber neu schreiben müsste, wäre das mit Sicherheit so. Das gibt es aber gewöhnlich als Demoprojekt fertig vom Hersteller und quasi nur der projektspezifische Code muss noch ergänzt werden. HID hat einen weiteren Vorteil, was das erforderliche Übertragungsprotokoll betrifft. Im Gegensatz zu CDC (USB-Serial-Converter, virtueller COM Port, ...) ist praktisch gar keines nötig, weil die Pakete immer einzeln und als ganzes zugestellt werden. Deshalb braucht man da gar kein großes Protokoll. Eine ID im ersten Byte reicht meist aus.
Man kann auch ohne CDC (Virtueller COM Port) und ohne HID treiberfreie USB-geräte für Windows entwickeln, in den man sie als WinUSB Device markiert. So ist man flexibler. Im Artikel USB-Tutorial mit STM32 gibt es dazu eine Anleitung zur Implementierung eines eigenen USB Devices auf Basis der USB fähigen STM32 Controller.
Niklas Gürtler schrieb: > Man kann auch ohne CDC (Virtueller COM Port) und ohne HID treiberfreie > USB-geräte für Windows entwickeln, in den man sie als WinUSB Device > markiert. Treiber brauchen natürlich alle USB Geräte. Mit "treiberfrei" meinen die meisten hier wahrscheinlich, das Ding einstecken und es funktioniert ohne noch Treiber (WinUSB, libUSB...) auswählen oder installieren zu müssen. Auch für komplett "vendor specific devices", die dann auf PC-Seite eben WinUSB oder libUSB verwenden, gibt es bestimmt von den meisten Herstellern Beispiele.
Arduino F. schrieb: > Ist aber nicht wirklich für die Datenübertragung geeignet. > Es sei denn man will wirklich eine dauernd quatschende Tastatur und > einen zuckenden Mauszeiger Unsinn. Die HID-Klasse hat die Unterklasse "Generic", die wird von keinem high-level Treiber übernommen und ist per standard file I7O zugreifbar. Die stört Maus und Tastatur überhaupt nicht. Der große Vorteil ist, dass man halt genau keinen speziellen Treiber benötigt. Der Nachteil ist die eingeschränkte Datenrate, die sich durch die HID-Klasse pro Sekunde auf 125 Reports a 8 Byte bei Low Speed und 1000 Reports a 64 Byte bei Full Speed beschränkt.
Guido Körber schrieb: > Der große Vorteil ist, dass man halt genau keinen speziellen Treiber > benötigt. Genau diesen Vorteil haben WinUSB-Devices auch (Treiber ist bei Windows bzw. Linux mitgeliefert und wird automatisch geladen... > Der Nachteil ist die eingeschränkte Datenrate, die sich durch die > HID-Klasse pro Sekunde auf 125 Reports a 8 Byte bei Low Speed und 1000 > Reports a 64 Byte bei Full Speed beschränkt. ... aber diesen Nachteil nicht! Geht aber leider erst ab Windows 8.
und wo klemmt es an virt.COM Treibern? also wenn schon Daten von µC zu PC dann doch normal seriell die ohne Verrenkungen im Klartext von überall angesprochen werden kann.
Joachim B. schrieb: > also wenn schon Daten von µC zu PC dann doch normal seriell die ohne > Verrenkungen im Klartext von überall angesprochen werden kann. Hat auch seine Nachteile, man hat weniger Kontrolle über das Timing, braucht eine manuelle Flusskontrolle, manuelle Paket Erkennung, der User muss den korrekten Port manuell auswählen . Siehe den oben verlinkten Artikel, da sind die Probleme aufgeführt. Klartext ist auch nicht so effizient, braucht Funktionen zum Formatieren/Parsen.
Joachim B. schrieb: > und wo klemmt es an virt.COM Treibern? > > also wenn schon Daten von µC zu PC dann doch normal seriell die ohne > Verrenkungen im Klartext von überall angesprochen werden kann. und wo klemmt es an HID Terminal Programmen? Wenn man das will, kann man ja auch über HID "Klartext" schicken. Der "Umweg" über s $eriell Wandler erfordert auch meiner Meinung nach mehr "Verrenkunen" ;-)
vloki schrieb: > und wo klemmt es an HID Terminal Programmen? Da: Guido Körber schrieb: > Der Nachteil ist die eingeschränkte Datenrate, die sich durch die > HID-Klasse pro Sekunde auf 125 Reports a 8 Byte bei Low Speed und 1000 > Reports a 64 Byte bei Full Speed beschränkt.
Das möchte ich dann aber gerne mal sehen, wie jemand 64 Tausend Zeichen pro Sekunde von einem Terminal abliest, oder in dieses eintippt ;-)
Volker S. schrieb: > Das möchte ich dann aber gerne mal sehen, wie jemand > 64 Tausend Zeichen pro Sekunde von einem Terminal abliest, Hehe, na zum Loggen von Messdaten wird sowas schon mal gemacht... ist vermutlich auch der Haupt Use Case vom (virtuellen) Serial-Port des Arduino außer dem Flashen per Bootloader.
Niklas Gürtler schrieb: > Hehe, na zum Loggen von Messdaten wird sowas schon mal gemacht... ist > vermutlich auch der Haupt Use Case vom (virtuellen) Serial-Port des > Arduino außer dem Flashen per Bootloader. Der typische Fall von Arduinodatenerfassung wird vermutlich auch weit unterhalb der 64kB/s sein. Egal, das muss eh "Dieter" wissen. MEHR als genügend Informationen sollten hier schon zusammengekommen sein, damit er etwas gezielter weiter fragen kann...
Der Dieter ist scheinbar nicht mehr hier. Ich hätte ihm einen ESP8266 empfohlen und damit die Messdaten direkt auf einen Webserver geschickt. Da braucht es auch keinen PC mehr.
Bitte 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.