Guten Tag,
ich möchte einen Datenlogger bauen, welcher zum Auslesen direkt an die
USB-Schnittstelle des PC angeschlossen werden soll. Er soll sich als
USB-Stick ausgeben, auf dem eine .txt-Datei mit den geloggten Daten
liegt. Das loggen der Daten bekomme ich hin. Ich bin auf der Suche nach
einem geeigneten Controller, welche möglichst viel von den benötigten
USB-Funktionen schon mitbringt. Leider weiß ich nicht genau, welches die
Stichworte sind, nach denen ich suchen muss, daher meine Bitte an euch,
dass ihr mir sagt, mit welcher Funktion ich sowas realisieren kann.
Bisher habe ich AVR (Atmega328P, Atmega128A) und STM32L152 programmiert
und für beide auch die ISP-Programmer hier. Daher wäre es gut, wenn es
etwas aus einer kompatiblen Familie wäre.
Danke & Gruß!
Georg
Soweit ich weiss eher nicht. Das Massenspeicherinterface auf USB wird
bei den Controllern USB-OTG (on the go) genannt. Also nach diesem
Kuerzel beiden CPUs schauen. Es gibt einige PIC die das koennen. Das ist
im Wesentlichen ein Satz faehiger Pins, und eine Library, die zugelinkt
wird.
Oh D. schrieb:> Soweit ich weiss eher nicht. Das Massenspeicherinterface auf USB wird> bei den Controllern USB-OTG (on the go) genannt.
Nö. OTG bedeutet dass das Gerät als Master sowie als Slave fungieren
kann und hat nichts mit der gesuchten funktion zu tun.
Was der TO sucht ist ein beliebiger Controller mit USB-Schnittstelle +
eine passende Bibliothek. AtMega16/32U... kommt mir da in den Sinn.
STM32 können das (fast?) alle. Du willst ja nicht auf einem stick
speichern, sondern dass sich dein Logger als Stick meldet.
Je nach Geschwindigkeitsanforderungen brauchst einen F2, F4 oder F7 für
High-Speed. Sonst geht jeder.
NXP haben die dafür nötige SW in einem ROM.
NXP und Atmel haben welche mit integriertem High-Speed Phy, falls von
interesse.
Hallo,
um es nochmal deutlicher zu machen: Die Funktion soll ähnlich wie diesem
Teil sein:
http://www.atp-messtechnik.de/product/USB-Datenlogger-fuer-Temperatur/5005-0170.html
Also nach der Loggingphase soll sich das Gerät als Massenspeicher am
USB-Port melden und mir eine Datei präsentieren (im Beispiel PDF, mir
reicht txt mit CSV-Werten). Alles andere kommt später (Dem Ding die
Uhrzeit mitteilen etc.).
VG
Georg
Bierschinken schrieb:> Bisher habe ich AVR (Atmega328P, Atmega128A) und STM32L152 programmiert
Von den Atmegas gibts auch welche mit USB, und der STM32 hat IMO bereits
USB.
V-USB geht nicht als Mass Storage - und wäre auch sehr lahm.
Aber: Ich würde Dir eher zu einer SDHC Karte raten.
Die genannten µCs können alle höchstens USB Full Speed,
da ist jeder SDHC Kartenleser schneller - die können alle mindestens
High Speed.
SDHC Karten können relativ leicht über SPI angesprochen werden, oftmals
gibt es fertigen Beispielcode.
Hallo,
da kommen nicht viele Megabytes zusammen, Geschwindigkeit ist somit fast
egal. Nutzerkomfort ist wesentlich wichtiger. Und der ist mit dem
einfachen Anstecken eines Massenspeichers, auf dem dann die Daten liegen
halt höher als das raus und reinprökeln einer SD-Karte, für die sowieso
nicht an jedem PC ein Lesegerät vorhanden ist.
VG
Georg
Jim M. schrieb:> Die genannten µCs können alle höchstens USB Full Speed,
Nö, die dicken STM32 können auch High-Speed, externen "ULPI" Transceiver
vorausgesetzt.
Für die STM32 gibt es auch Beispiele, wie man mit dem Hardware-USB ein
Mass Storage Device programmiert. Von V-USB ist eher abzuraten, warum
sollte man sich die Mühe mit so einer Popelei machen wenn man auch
richtiges Hardware-USB nutzen kann?
Das Problem ist im Endeffekt das Dateisystem - willst du das komplette
Dateisystem (z.B. FAT32) mit auf deinen Datenträger speichern, oder soll
das beim Auslesen emuliert werden? Alternativ kann man MTP nutzen, dann
verhält sich das wie ein neueres Android-Handy - man kann per Explorer
zugreifen ohne Treiberinstallation, aber du brauchst kein Dateisystem.
Dr. Sommer schrieb:> Das Problem ist im Endeffekt das Dateisystem - willst du das komplette> Dateisystem (z.B. FAT32) mit auf deinen Datenträger speichern, oder soll> das beim Auslesen emuliert werden?
Das weiß ich noch nicht. Derzeit speichere ich die Messwerte auf einem
per SPI angeschlossenen EEPROM. Das funktioniert soweit (ist ja auch
keine Kunst). Sensoransteuerung, Auswertung & Speicherung sind fertig
(auf einem atmega328P). Der Sensor ist relativ komplex, daher habe ich
das zu erst gebaut. Das ganze soll im "Nicht-USB-Modus" natürlich auch
wenig Strom verbrauchen. Daher legt sich der AVR momentan schlafen und
wartet auf einen Interrupt. Dieser wird von der analogen Schaltung (der
Sensor ist etwas mehr als nur ein i2c-Bauteil...) generiert. Dann wacht
der AVR auf und ließt vier ADC-Eingänge ein. Das liegt jetzt alles in
einem selbst erdachten Format im EEPROM. Vielleicht bin ich mit meinem
Lösungsweg auch ganz falsch... Aber da es diese Geräte ja zu Hauf zu
kaufen gibt, bin ich nicht der erste, der sowas bauen will, irgendwie
wird es ja elegant gehen. Diese Temp-Logger haben nicht sehr viele
Messpunkte, meist so um die 32k, daher haben die auch keinen GB-Flash
verbaut, denke ich.
So richtig einen Plan habe ich von dem möglichen Lösungsweg noch nicht.
Daher schreiben die meisten Leute wohl auch auf SD-Karten... :-)
VG
Georg
Bierschinken schrieb:> Daher schreiben die meisten Leute wohl auch auf SD-Karten... :-)
Nicht ohne Grund - die Teile haben riesige Kapazitäten, sind winzig,
leicht austauschbar (z.B. wenn der Flash abgenutzt ist), und an jeder
Ecke kaufbar. Auf einer SD-Karte kannst (und solltest) du ja problemlos
ein Dateisystem nutzen. Dank Libraries wie FatFs ist das schreiben kein
großes Problem, und den Zugriff darauf lässt sich auch per USB Mass
Storage Class bewerkstelligen. Der User muss ja gar nicht sehen, dass da
eine SD-Karte eingebaut ist, sofern er sie nicht tauschen möchte.
Der Nachteil wird hier für dich sein, dass SD-Karten nicht gerade
energie-sparsam sind. Aber man kann die natürlich abschalten solange
keine neuen Daten anliegen.
Bierschinken schrieb:> So richtig einen Plan habe ich von dem möglichen Lösungsweg noch nicht.
Warum? Dir wurden zwei gangbare Wege präsentiert:
1) MTP
2) Storage (das in zwei Varianten:)
a) Exponierung eines physisch vorhandenen Filesystems
b) Emulation eines virtuellen Filesystems
wobei 2)a) für dich nicht in Frage kommt, weil du nach eigener Aussage
auf dem "Massenspeicher" etwas selbstgefrickeltes verwendest.
Was also bleibt, ist:
- Du brauchst ein USB-Interface mit mindestens FullSpeed, weil die
entsprechenden USB-Klassen genau dies erfordern, weil sie Burst-
Transfers erfordern. Damit scheidet der Mega328 aus. Der hat kein
echtes
USB-Interface und kann mittels V-USB maximal LowSpeed und damit darf
er
eben keine Burst-Transfers machen. Heutige Betriebssysteme legen da
auch
tatsächlich Wert drauf. Allerdings nur deshalb, weil der Standard es
so
fordert, einen echten physikalischen Grund für diese Kastration gibt
es
nicht...
- Die Wahl eines µC, der das kann. Es bietet sich der Mega32U4 förmlich
an. Wurde dir auch bereits empfohlen.
- Implementierung des Protokolls, für das du dich entscheidest. Genau da
wird die Säge wohl klemmen...
> Daher schreiben die meisten Leute wohl auch auf SD-Karten... :-)
Das liegt daran, dass die meisten davon AUCH zu faul/doof zum selber
Programmieren sind und dementsprechend nur fremden Code zusammenleimen
wollen oder können. Und die, bei denen das nicht zutrifft, wollen wohl
offensichtlich ihren Code nicht unbedingt für die vielen Nassauer
veröffentlichen...
PIC24 Controller mit der Typenbezeichnung PIC24FJ???GB??? haben OTG-USB.
Du kannst diese Controller sowohl als Mass Storage benutzen als auch
selber Mass Storage (USB-Sticks) ansteuern.
Hier bekommst Du die MLA Microchip Libraries for Applications:
http://www.microchip.com/mplab/microchip-libraries-for-applications
Hier bekommst Du:
- USB Device Stack
- USB Host Stack
- FAT File System
- MMC/SD Card Treiber
Damit sind eigentlich alle Probleme bereits gelöst.
fchk
Einfachste Lösung ist die, einen USB-UART chip zu nehmen (bzw. fertiges
Modul mit Atmega328 + usb-uart) und mithilfe eines einfachen ascii- oder
binärprotokolls die Daten rüberzuschicken. Noch einfacher ist dann nur
noch die Lösung mit SD-Karte und Kartenleser
c-hater schrieb:> Das liegt daran, dass die meisten davon AUCH zu faul/doof zum selber> Programmieren sind
ganz besonders doof ist es, das Rad zum 100. mal zu erfinden
Atmega32u4... die beste Wahl dafür, natives USB an Board. Und du kannst
dir erstmal so nen Arduino Clone besorgen und vergewaltigen zum
ausprobieren. Dein ISP kannste dafür natürlich auch nehmen.
