FTDI mit Atmel-uC

[Uwe K. (pidhunter)]

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.

[Ulrich (Gast)]

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.

[Uwe K. (pidhunter)]

@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.