Hallo. Ich möchte ein System für Temperaturmessung mit mehreren LM75 Sensoren aufbauen. Nun suche ich einen USB-Controller, um die Werte zum PC zu übertragen. Die Cypress EZ FX2 Controller hab ich mir zwar schon angeschaut, nur übersteigen die mein Budget. Kann mir jemand sagen, was es sonst noch an USB Controllern mit I²C Schnittstellen gibt, ich find da nicht viel?
AT90USB* die 162 und 82 Varianten sind klein und günstig und sollten für das was du vorhast ausreichen. Je nachdem kannst du auch einen normalen AVR nehmen und dann http://www.obdev.at/products/avrusb/index.html der Tiny45 und Tiny26 bieten sich hier an, da du dann nichtmal einen Quarz brauchst.
I²C-Tiny-USB: http://www.harbaum.org/till/i2c_tiny_usb/index.shtml Zitat: Attach any I2C client chip (thermo sensors, AD converter, displays, relais driver, ...) to your PC via USB ... quick, easy and cheap! Drivers for Linux, Windows and MacOS available. Baut auf der oben erwähnten obdev.at USB-Library für AVRs auf.
Ach ja, und nachdem oben jemand "PIC" geschriehen hat, hier: http://www.elektor.de/jahrgang/2008/juni/thermo-snake.497315.lynkx Bis zu 128 Sensoren am USB, über einen PIC18F2550. Allerdings über einen OneWire Bus, also kein I²C.
Spricht was gegen den FT2232? Dessen MPSSE kann mit entsprechenden DLLs auf der Clientseite unterschiedlichste serielle Protokolle implementieren, so auch I²C : http://ftdichip.com/Projects/MPSSE/FTCI2C.htm
Danke für die Antworten - muss ich mir erstmal zu gemüte führen :)
Der AT90USB162 hat kein Hardware TWI/I2C. Das ist beim AT90USB82 wahrscheinlich genauso.
Budget = 100 Euro? Ich dachte, du suchst nur einen günstigen Prozessor. Sollen mit den 100 Euro etwa Entwicklungsumgebung UND das eigentliche Produkt abgedeckt werden? Na, viel Spaß. Dann bleibt ja wirklich fast nur ein AVR mit GCC und irgendeiner Parallelport-Programmierer Frickellösung.
... oder IRGENDEIN Prozessor, der einen UART hat + FT232R/CP2102. Oder gibts es einen Grund, warum du einen Mikrocontroller mit integriertem USB suchst? So kam deine Anfrage zumindest bei allen rüber.
Hallo, FT2232D, Bausatz Modul Buch gibts hier http://www.b-redemann.de, auch günstig. Im Buch ist ein Beispiel mit dem LM75. J.
Von der Nutzung des FT2232 rate ich ab. Dafür gibt es zwei Gründe: 1. Es gibt keinerlei hilfreiche Dokumentation über die MPSSE. Der Hesteller verweist auf Anfrage auf seine Windows-DLL. Wer es also unter Linux versuchen will, muss erstmal Reverse-Engineering betreiben. Soweit ich weiß, hat bisher niemand die MPSSE wirklich zum laufen bekommen. 2. Implementationen gibt es unter Nutzung des Bit-Bang-Modes. Das ist auch das, was b-redemann in seienm Buch macht. Das Timing dabei ist ziemlich zufällig (aber es funktioniert). Das Problem ist, dass der FT... nach meinen Erfahrungen keine Open-Collector-Ausgänge besitzt, wie sie eigentlich für I2C notwendig sind. Dass es trotzdem funktioniert scheint daran zu liegen, dass die Ausgänge eine Strombegrenzung haben, die schaltungstechnisch genutzt wird, wenn ein anderes Gerät SDA (oder SCL) auf L-Pegel zieht. Das ist sicherlich keine elegante Lösung. Auf Anfrage wollte sich der Hersteller dazu nicht äußern. Angaben über die Ausgangskonfigurationen gibt es im Datenblatt nicht. Ob es im MPSSE-Mode anders ist, ist auch nicht bekannt. Sollte jemand weiterführende Infos haben, ich bin für jeden Tip dankbar. Jens
> 1. Es gibt keinerlei hilfreiche Dokumentation über die MPSSE. > Der Hesteller verweist auf Anfrage auf seine Windows-DLL. > Wer es also unter Linux versuchen will, muss erstmal Reverse- > Engineering betreiben. > Soweit ich weiß, hat bisher niemand die MPSSE wirklich zum > laufen bekommen. Das OpenOCD-Projekt nutzt, soweit ich weiß, die MPSSE um damit JTAG zu sprechen. Das aber gibt es auch für Linux, vielleicht sind dort ja ein paar Erfahrungswerte dokumentiert worden.
Hi, als fertig Baustein findest du was bei www.roboter-teile.de Grüße Rocky
>Das Problem ist, dass der FT... nach meinen Erfahrungen keine Open- >Collector-Ausgänge besitzt, wie sie eigentlich für I2C notwendig sind. Dann halt noch 'nen Transistor dran gemacht und einen separaten RX/TX Pin für die SDA Leitung genutzt.
>Dann halt noch 'nen Transistor dran gemacht und einen separaten RX/TX >Pin für die SDA Leitung genutzt. Ich mache es auch so. Und benutze den Bit-Bang-Mode. Es läuft auch zufriedenstellend. Aber etwas mehr Support seitens des FTDI wäre sicher nicht schlecht und würde viel Mühe ersparen.
Nur so ein Tip am Rande: www.codemercs.com Die IO-Warrior haben alle IIC im Chip drin und kommen mit ordentlicher Softwareunterstützung für Windows, MacOS und Linux.
...wobei aber nur der ganz "dicke" IOW auch i²c mit 400kbit kann, die beiden anderen (24 und 40 polig) sind grotten lahm
Hallo, ich habe mit dem FT2232 arge Probleme gehabt. FTDI lässt im Demo-Projekt einen I2C-Speicher beschreiben. Redemann liest einen LM75 aus. Ich habe einige Jahre Erfahrung mit I2C-Bussen und habe diverse Ansteuerungen verwendet, CC2 , PC mit einfacher Serieller Schnittstelle. Zum Testen habe ich eine kleine Schaltung mit PCF8574. Den beschreibe ich, lass LED´s aufleuchten und lese den Port wieder aus. Durch den Vergleich Schreiben/Lesen stelle ich Übertragungsfehler fest. Ganz simpel, aber ausreichend. Der FT2232 war wirklich sehr schnell (>100KHz Takt) und das über 40m Telefon-Litze 8 adrig. Das Schreiben klappte ja toll. Nur mit dem Lesen, da hatte ich Probleme. Dies war mir nicht möglich. Und das bei einem PCF8574, der eigentlich einer der einfachsten Bausteine ist und gegenüber dem Bus-Timing nicht so empfindlich ist. Der Support von FTDI wollte mich nicht verstehen. Es lag sicher auch an meinem Englisch. Aber auch von Redemann erhielt ich nur eine Floskel, dass er zur Zeit sehr beschäftigt ist. Vor ca. einem Jahr habe ich feststellen müssen, dass das Bus-Timing sehr wichtig ist. Der DS1631 ist da etwas anspruchsvoll. Aber auch der PCF8591, 8-Bit AD, machte mit mit der einfachen seriellen Schnittstelle Probleme. Schon vor ca. 4 Jahren bemerkte ich Aussreisser bei den Messwerten und führte dies auf Störungen im Analogteil der Schaltung und langen Leitungen zurück. Die traf aber nicht zu. Dies konnte ich mit dem MSP430F2013 beweisen. TI hat sich beim Bus-Timing wirklich Mühe gemacht. Das sieht man allein schon in der Doku. Damit waren die Fehler weg. Gruss Klaus.
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.