Hallo, ich habe noch nichts mit USB-Programmierung gemacht, habe aber mit serieller Kommunikation schon einiges gemacht. Wie ich gelesen habe ist der Weg USB aus ATMEL nativ über DDK der beschwerliche Weg durch Unterholz. Das will ich nach Möglichkeit vermeiden. Ich bin mit dem Board AT89C5131A an XP nicht zufrieden. Nun will ich mit dem FTDI232 ein USB-Projekt für Temperatursensoren realisieren und zwar mit einen FTDI232 an einem Atmega, falls dann verfügbar ein Atxmega44. Ich habe weiter zu USB gegoogelt und bin auf den FTDI232 aufmerksam geworden. -- Frage zu USB-Konzept am uC -- Wenn ich das USB-Konzept richtig verstanden habe wird bei USB mit serialisierten Datenstrukturen, wie 2x2 structs je eine für lesen und schreiben auf jeder Seite über serielle Verbindung zwischen den zwei Einheiten ständig wechselseitig abgeglichen und das rhythmische Datenbefüllen der structs kann auch ein Atmel oder ein FTDI232 erledigen. Also mit lesen und schreiben auf relativen Adressen der structs zu jedem Gerät (ähnlich wie über COM serialisierter Shared Memory) bedient. Das klassenabhängige Protokoll regelt dann welche Speicherstellen zu welcher Zeit beschrieben werden werden. Ergo welche Adressreihenfolge bei der seriellen Übertragung nötig ist. Dabei wäre aber das Medium welches zur seriellen Übertragung zwecks Synchronisation beider structs benutzt wird erstmal protokollunabhängig frei wählbar. Es scheint nur die Taktrate festzuliegen und das heisst, wenn weniger Daten anliegen Burstbetrieb. Stimmt das soweit oder habe ich das falsch aufgefasst? Vermutlich wird beim FTDI232 USB-seitig mit Bursts gearbeitet, da die serielle IO langsamer ist. Zwei FTDI-Chips müssten sich dann aber auch gegeneinander betreiben lassen und auf beiden Seiten wäre dann wieder eine serielle Schnittstelle da - oder geht das schon mal nicht ?? - 5V käme von extern. -- Welche Com-Schnittstelle am FTDI232 ??? -- Für den FTDI-Chip gibt es, soweit ich das gelesen habe einen generischen Treiber und damit dürfte aus cygwin32 mit gtk-gui ein fopen() auf einem /dev/ttySx device sicherlich funktionieren - ich hoffe es zumindest. Problem : Wie kriege ich aber die Nummer x für den PC heraus, also gleiches Problem mit fertigen USB/Seriell-Wandlern. Wie finde ich immer die richtige COM-Schnittstelle, die ich dem fopen() übergeben muss oder muss ich bei USB open() benutzen weil fopen() gepuffert arbeitet? -- Atmel-Parametrierung mit FTDI232 ??? -- Wenn das klar ist, soll folgendes passieren: Der PC bestromt und kommuniziert über FTDI232 den Atmel und schreibt dort eine Adresserierung und paar Kommunikationsparameter rein. Dann soll der Atmel diese segmentiert in den Flash schreiben und nach dem abziehen auch behalten. Ich hoffe das segmentierte lesen/schreiben geht bei den Atmels auch bei USB-Versorgung ?? Hoffentlich wird nicht dabei auch die Firmware zur Kommunikation des Atmels mit gelöscht - das wäre schlecht. -- Busarbitierung mit FTDI232 ??? -- Nach dem Abziehen soll der parametrierte Atmel ohne PC mit 3 weitereren baugleichen Platinen von einen passiven 4er-Hub mit ext-Netzteil ohne PC weiter bestromt werden und selbstständig Temperaturprofile messen, zwischenspeichern und Steuersignale uC-seitig ausgegeben. Der Strom der Gesammtschaltung schwankt etwa zwischen 40-400mA Die Messung hat schon ein paar hundert Millisendunden Zeit, Temperaturen ändern sich nicht so sehr schnell, es muss aber punktweise genau sein und die Zeit erfasst werden. Ok das schein lösbar zu sein. Da die restliche Schaltung für USB-Verhältnisse relativ viel Strom braucht und alternativ auch Solarstrom zu Einsatz kommen soll, wird eine Busarbitierung benötigt, damit nicht der Fall eintritt dass alle Einheiten gleichzeitig messen, steuern und kommunizieren wollen - der Stromverbrauch soll ja auf diese Weise klein und weitgehend konstant sein. Gut wäre es wenn sich 2-3 passive Hubs sich kaskadieren lassen würden, da ja immer nur eine Einheit aktiv ist. Also nur ein 500mA Netzteil nötig wäre. Round Robin-Verfahren - weniger Teilnehmer pro Strang mehr Meßwerte. Dazu sollen timergesteuert eine minimale Kommunikation über den passiven Hub zu den anderen Platinen aufgebaut werden: Etwa so - Wer ist alles am Bus - Ahja - Achtung an Alle - Bus jetzt bitte freigeben -> ich brauch viel Strom und will messen -> von allen die gehört wurden ein ACK -> Timeout nach letztem ACK abwarten -> Bus ist jetzt 100% meine -> allen Strom her -> messen -> nach Timeout Mittelwert bilden -> so, fertig mit messen -> Bus ist wieder euer -> so Busteilnehmer koennt nun int x sekunden lang den Bus wiederhaben. Dann wiederholt sicht das. Irgendwann soll dann der passive Hub vom Netzteil abgezogen werden und an den PC gesteckt werden und dann sollen alle Baugruppen der Reihe nach ihre Messdaten an den PC übertragen. Ich habe in den anderen Beiträgen gelesen, dass der FTDI nicht von seiner seriellen Seite aus gesteuert werden kann ??, also nur von PC Seite aus die Kommunikation aufgebaut werden kann. Gilt das auch für meinen Fall , da man den USB-Stack in den uC packen könnte und die notwendigen Routinen dafür einprogrammiert und wenn das geht, wäre die Frage ist viel Aufwand für den FTDI232 im uC ? Wenn das hardwaremäßig aber garnicht erst geht, welcher Chip würde das unter SP mit cygwin32 tun, da die ATMEL-USB mit XP/Win2K nicht so recht funktionierte - schlechte Erfahrungen mit dem AT89C5131A-UL.
Ziehmlich viele Fragen auf einmal. Hier ein paar Antworten: Den FTDI kann man praktisch wie einen USB-RS232 Wandler nutzen, nur die Umsetzung auf +-10 V Pegel zwischendurch kann man sich sparen. Der USB Bus braucht eigentlich immer den Master = PC, wenn der fehlt, geht eigenlich gar nichts mehr. Die FT232.. Chips können nicht die Masterfunktion übernehmen und das ist wohl auch nicht mal vorgesehen das der Master überhaupt wechselt. Der Logischere Aufbau wäre da wohl eine USB-µC Brücke und dann die Verbindung zwischen den Einheiten mit einem anderen BUS (I2C, CAN,1-Wire,...). Das sollte auch den Stromverbrauch klein halten. Einen USB Bus mit eigenem Master nur für eher langsame Temperaturdaten ist einfach übertrieben. Für Konfigurationsprameter oder so haben die µCs ein EEPROM, das kann Byteweise geschrieben werden. Zum Teil kann auch der Flash Speicher mit zur Laufzeit beschieben werden, dann aber nur Blockweise, und wenn man einen Fehler macht, ist auch mal das Programm überschrieben. Wenn es mehr Daten werden die zwischengespeichert werden müssen, würde sich ein externer Dataflasch Baustein anbieten. Da hat man Speicher in der Größenordnung MBytes in einen kleinen 8 bin Gehaüse.
@Ulrich wg. USB --------------- Das System soll sich über den Bus mit Strom versorgen (dies gänge auch mit EIB ist aber viel zu teuer) und soll nach Möglichkeit direkt am Laptop ohne Zusatzadapter ansteckbar sein. Seriell ist nicht hubfähig und hat nicht jeder Laptop. Parallel hat nicht genug Strom und die restlichen Schnittstellen eigenen sich auch nicht wirklich. Hast aber recht je eher die Daten da sind desto länger muss gewartet werden - das stört aber nicht. Die Wahl USB ist auch zu 50% durch die günstigen Preise der Hubs und deren Stromversorgung bedingt, aber ich will wenn es läuft dies noch ausbauen. @Ulrich wg. USB-Master ---------------------- Meine Frage war kann man eine Firmware in den Atmel schreiben, die über die serielle Schnittstelle oder SPI den FTDI so mit Daten "bedient", dass am anderen Ende am passiven Hub der gleiche Adapter denkt es hänge ein Master dran, der mit ihm kommunizieren will - notfalls eben die Datenleitungen hardwäremäßig umschalten ? Wenn es keine Möglichkeit gibt den FTDI über Com oder SPI sozusagen "von hinten durch durch die Brust" ala OTG-Device zur Kommunikation zu überreden geht das vermutlich überhaupt nicht damit zu lösen. Die Frage wäre dann gänge es mit dem AT89C5131A uns seiner USB-Schnittstelle, wenn ja wie könnte man damit einen FTDI-Chip softwaremäßig emulieren, damit die Signale sauber durch den XP-Host durchgehen.
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.