@Indeas und Robocat: Und wie werden die Daten vom Rechner aus abgerufen?
Im Endeffekt muss die Datenübertragung (in diesem Fall) nicht so schnell wie möglich stattfinden. Ich könnte mir vorstellen, dass ich über einen µC etwas auswerte und nur 1-2 Mal in der Sekunde einen Messwert an den Rechner sende, bzw. von da abrufe.
In der Regel holt der Rechner (Master) die Daten vom Sensor (Slave) ab.
Z.B. Der PC schickt ein String "*?<CR>" und dann antwortet der Sensor mit dem Datenstring.
Da RS485 oft als Halbduplex ausgeführt wird, kann ohnehin immer nur ein Teilnehmer reden.
Wie sieht denn Dein Sensor aus?
Ich hab bzgl. der obdev-Lösung mal ne Anfrage gesendet.
Wenn ich mir das so durchlese, versteh ich...noch nicht so vielProbleme gibt's nur, wenn man einen Bulk endpoint (eigentlich nicht unterstützt auf low speed devices) konfiguriert. Dann braucht v-usb so um die 80% der CPU-Zeit.
Eine weitere Einschränkung ist die Interrupt-Latency. Weitere Interrupts (zum USB Interrupt) müssen innerhalb von ca. 15 bis 20 Instructions die globalen Interrupts wieder aufdrehen und kein Code darf die Interrupts für länger als 15 bis 20 Instructions abdrehen.
Ausserdem müssen andere Interrupts damit rechnen, dass der USB Interrupt für um die 120 Mikrosekunden lang läuft und sie um so viel später drankommen.
Was ist ein "Bulk endpoint" im USB-Sinne?
Wenn der Messrechner über USB lediglich ein oder zwei Sensoren angeschlossen hat, dürfte die Interrupt-Latency doch keine große Rolle spielen, oder etwa doch?
Am interessantesten finde ich die Lösung "mit einem Attiny und einem dieser FTD-USB Chip". Ich hab mal ein wenig in der Bucht nach den Chips gesucht, aber auf Anhieb keine gefunden.
Ich wollte schon immer mal ein eigenes USB-Gerät basteln...von daher finde ich das Thema schon sehr interessant.
Ich hatte mich mal auf USB.org umgeschaut und als ich gesehen hatte, dass man sich für eigene USB-Sachen ne PID etc. zulegen muss, was kostenpflichtig ist, wars uninteressant.
Gibts zur FTD-Lösung hier vielleicht irgendwo ein Tutorial?
Noch gibts keinen konkreten Sensor, den ich damit nutzen möchte. Aber ich könnte mir einen Beschleunigungssensor, einen Temperatursensor oder sonstiges vorstellen. Ich hab halt bisher wenig Ahnung von den verschiedenen Anbindungen (I2C, RS232, RS485), wehalb ich da endlich mal reinschnuppern möchte
Mit FTD Chips werden vermutlich das http://www.ftdichip.com/ gemeint sein. Die haben USB Wandler zu sehr vielen anderen Schnittstellen (RS232/UART, RS485,....) aber auch andere Chips zum Thema USB (USB Host,...)
Beim USB AVR Lab wird der USB Datenverkehr auch nur mit dem µC bewerkstelligt. http://www.ullihome.de/wiki/USBAVRLab/index
Wie das gemacht wird könntest du bei Christian Ulrich nachfragen wie er es beim AVR Lab gemacht hat.
MfG Hannes
Ah, die FTD-Chips kosten ja gar nicht so viel. Ne Direktverbindung USB-I2C ist damit ja möglich.
Aber nen Chip Usb-RS485 hab ich nicht so auf Anhieb gefunden. Nur n Konverterkabel, das gleich mit ~30 Steinen zu Buche schlägt.
Aber da wäre es vermutlich sinnvoller, den RS485-Sensor an nen AtTiny/Mega zu klemmen und den auszulesen.
Aber welches Protokoll wäre dafür am sinnvollsten? I2C? RS232?
Da ist ja einiges möglich mit den FTDIs:
http://de.rs-online.com/web/c/?searc...t-option=Preis
Das kommt auf deine Bedürfnisse an. Wieviele Bausteine sollen möglich sein, welche Geschwindigkeit wird benötigt, wie sicher soll die Verbindung sein (gegen Störungen => z.B. Industrie),....
MfG Hannes
Puh, also ich könnte mir als Einsatzzweck z.B. vorstellen, meine Terrarien bzgl. Temperatur und Luftfeuchtigkeit zu überwachen.
Hier wäre ein gerinder Datendurchsatz nötig.
Aber ich köntne mir auch vorstellen, irgendwas bewegliches mit nem Beschleunigungssensor oder nem Gyroskop auszuwerten. Hierbei wäre der Datendurchsatz natürlich gräßer.
Gehen wir mal von einem Beschleunigungssensor aus:
3-4 Kanäle, die 'long doubles' übertragen. 4*16 = 64 Bit.
64 Bit * 100 Messungen in der Sekunde = 6400 Bit.
6400 / 1024 = 6,25 kb / 8 = 0,78 kB
USB 1.0 schafft nominell 187,5 kByte/s. Nun stellt sich die Frage, wie schnell ich über I2C, RS232 oder RS485 Daten abrufen kann.
Was meinst du mit Störungen? Z.B. Strahlung in unmittelbarer Nähe oder Kabellänge?
Bei einem Gyroskop oder einem Beschleunigungssensor würde ich von einer kurzen Kabellänge ausgehen. Nehmen wir einen kleinen Roboter mit aufgesetztem Laptop an.
Bei Thermo- und Hygrometer würde ich von einer etwas längeren Kabellänge ausgehen. 1-2m wären hier durchaus denkbar.
Geändert von Cysign (22.03.2013 um 22:01 Uhr)
Berechtigungen
Zitieren
Lesezeichen