Benötige Hilfe bei Einstieg in Cypress CY7C68013a USB - I2C Programmierung

[Borsty B. (mantabernd)]

Hi zusammen,

ich möchte eine USB - I2C "Bridge" auf Basis eines Cypress CY7C68013a 
programmieren.

Hardware dazu habe ich das ebay CY7C68013a Mini Board.

Der Controller wird auch vom PC erkannt und meldet sich mit der DEV ID 
0x8613 und Vendor ID 0x04B4 am PC an.

Folgendes möchte ich erreichen:

- der CY7C68013a soll sich mit einer von mir vergebenen Vend ID am PC 
anmelden (enumierieren)
- ich möchte mit C# eine Anwendung schreiben um auf den I2C Bus 
zugreifen zu können (über den CY7C68013a).

Welche Software benötige ich nun um die Firmware für den CY7C68013a zu 
schreiben?
Ich habe mir den Cypress PSoC Designer installiert aber leider kann ich 
den CHIP dort nicht auswählen.
Dann gibt es noch einen GPIF Designer, dort kann ich zwar den Chip 
auswählen, mir ist aber nicht so ganz klar was ich mit der Software 
machen kann.


Das Keil µVision2 hat es mir auch mit installiert.

Leider fehlt mir total der rote Faden wie ich nun anfangen meinen 
CY7C68013a zu programmieren.

Vielleicht möchte mir hier jemand beim Einstieg helfen :)

Vielen Dank!

[Andreas (Gast)]

Ich nehme an, Du brauchst die SW,
die Du hier
http://www.cypress.com/documentation/development-kitsboards/cy3684-ez-usb-fx2lp-development-kit
runterladen kannst.
Der FX2LP ist kein PSoC, PSoC creator ist nur fuer PSoC.
Uebrigens koenntest Du die Aufgabe mit einem PSoC leicht erledigen.

Steht alles hier:
http://www.cypress.com/products/ez-usb-fx2lp

Andreas

[Borsty B. (mantabernd)]

Danke erstmal für deine Antwort.

Hmm ok mir war nicht klar dass es einen Unterschied zwischen FX2LP und 
PSoC gibt. Danke erstmal dafür.

Leider finde ich keine Dokumentation wie ich die Vendor ID programmieren 
kann.

Für I2C Kommunikation habe ich ein paar Codeschnipsel gefunden:

EZUSB_WriteI2C(0x21, 0x01, 0xF9);
/* EZUSB_WriteI2C(I2C Device Address,
Number of Data bytes, Data)
*/ EZUSB_WaitForEEPROMWrite(0x21);

Programmiert wird dann mit dem Keil µVision2, oder? Nur leider finde ich 
dort keinerlei Möglichkeit den Chip auszuwählen... Ich kenne das halt 
vom Atmel Studio dass ich ein neues Projekt erstelle und dort angebe 
welchen Chip ich verwende.

Mir fehlt da grad vollkommen der Einstieg... :(

[Borsty B. (mantabernd)]

Ha :)

Ich habe es geschafft zumindest schon mal die Dev und Vend. ID zu 
beinflussen.

Der Controller meldet sich nun mit der von mir vorgebenen ID am PC an.
Sehr schön :)

Nur leider... ist das Beispiel von der Cypress Seite abartig 
unübersichtlich. Braucht man wirklich soviel Code um die ID zu 
erstellen?

Auf dem Screenshot links... was ist denn das alles??

Ich bräuchte eigentlich nur eine simple USB <-> I2C Brücke um aus meiner 
Software heraus die I2C Geräte auf der Platine ansprechen zu können.

[Borsty B. (mantabernd)]

Hmm...

also ich habs nun sogar geschafft meine eigene Vendor ID und Dev ID in 
das Eeprom zu laden und von dort aus zu booten :)

Kleiner Schritt für mich :)

Jetzt steig ich aber definitv aus, in der Demosoftware finde ich noch 
nicht mal eine Mainschleife oder irgendeinen Anhaltspunkt wie das 
Programm abläuft.

Mag mir dabei jemand unter die Arme greifen und mir eine I2C <-> USB 
Bridge implementieren?

Vielen Dank!!

[Patrick C. (pcrom)]

Ich habe zufaellig installiert auf mein PC : USB Control Center von 
Cypress. Der gibt ins menu "Program FX2". Das programm ist teil von USB 
Suite von Cypress. Weiter keine erfahrung mit diesem chip

Aber ich arbeite taeglich mit CY8CKIT-059 ($10) unds musz sagen die 
service von Cypress ist super. Im Forum oder direct ein meldung zu die 
developer, man bekommt immer antwort.

Die CY8CKIT-059 benutze ich oft zusammen mit das PC-programm I2C Bridge 
mit viele moeglochkeiten zowie auch via I2C chips auszesen und die dann 
im graphik sehen lassen

[Borsty B. (mantabernd)]

Danke schon mal...

Ich habe mir das viel einfacher vorgestellt. Dacht ich schreib mir ein 
Programm wo ich die Vend und Dev ID als Variable mitgebe und eine 
Dauerschleife in der Main() in der ich die Befehle vom PC an den I2C Bus 
weitergebe.

... leider war das wohl ein Trugschluss.

Die von dir erwähnte Bridge Sofware erkennt bei mir nur die seriellen 
COM Ports am PC. Eine Kommunikation mit meinen I2C Devices ist nicht 
möglich.

[Patrick C. (pcrom)]

Ok aber die USBSuite hat doch viele programmen die du benutzen kannst 
oder ?

[Borsty B. (mantabernd)]

... Ich glaube wir starten hier mal nochmals komplett durch und fangen 
von vorne an ...


Was ich erreichen möchte:

Ich möchte eine C# Anwendung im Microsoft Visual Studio schreiben und 
dort auf der Konsole oder einer grafischen Oberfläche die Werte meiner 
I2C Hardware auslesen bzw. auch manipulieren können.

Die C# Applikation bekomme ich hin... da bin ich mir ziemlich sicher.

Das Layer zwischen dieser Anwendung und der Hardware bereitet mir 
Bauchschmerzen...

Ich habe nun gesehen dass es für den CY7C68013a eine dot.Net Framework 
Library gibt.

Möchte mir jemand bei der Entwicklung meines Vorhabens unter die Arme 
greifen?

[X- R. (x-rocka)]

USB zu I2C:

Da gibt's wesentlich einfachere Sachen als den FX2.
Such mal bei FTDI, die haben bestimmt ne I2C-USB Bridge.

[Borsty B. (mantabernd)]

X- R. schrieb:
> Da gibt's wesentlich einfachere Sachen als den FX2.
> Such mal bei FTDI, die haben bestimmt ne I2C-USB Bridge.

Wäre zwar möglich auf FTDI umzusteigen, jedoch habe ich den Cypress 
schon ziemlich fix in meinem Projekt eingeplant.

Es gibt auch kleine Fortschritte.

Ich habe mich in Visual Studio an die Arbeit gemacht und es mittels der 
CyUSB.dll geschafft das Gerät zu erkennen.

Kennt jemand die CyUSB.dll und weiß ob man daraus direkt das I2C 
Interface ansprechen kann? Ich habe zumindest in der Dokumentation 
nichts darüber gefunden.

Vielleicht hat hier ja jemand etwas Erfahrung damit und kann mir 
weiterhelfen?

Danke!!

[Borsty B. (mantabernd)]

Was darf ich mir eigentlich unter den Endpoints vorstellen?

Soweit ich das Datenblatt verstanden habe muss ich mich um die Enpoints 
im I2C Betrieb nicht kümmern, oder?

[Peter Kranl (Gast)]

Wirf den Cypress weg - mit einem SC18IM700 (NXP) + USB to UART (FT232RL) 
geht die Kommunikation ganz einfach über den Virtual Com Port Driver 
(VCP).
Das läuft sicher unter C# und jeder anderen Sprache und egal ob Windows 
oder Linux.

[Borsty B. (mantabernd)]

Das Problem ist dass ich den Cypress für eine andere Anwendung benötige.

Es gibt quasi einen USB Anschluss, dort soll zum einen eine Software 
laufen die nicht von mir kommt und dann noch eine die eben von mir 
kommt.

Ich möchte ungern zwei USB Anschlüsse implementieren, und auch ein 
Umschalten möchte ich verhindern.

Ich habe jetzt mal dem Cypress Support geschrieben. Ich konnte gestern 
noch ein wenig weiter programmieren und die Endpoints auswählen und 
sogar drauf zugreifen, viel kann dann ja nicht mehr fehlen um I2C zu 
realisieren.

[Borsty B. (mantabernd)]

Guten Abend zusammen,

unglaublich aber nach all den Startschwierigkeiten habe ich es geschafft
meine ersten I2C Befehle aus meiner C# Anwendung auf den Bus zu
bringen!! :=)

Mir ist nun vieles klar geworden, aber diese Cypress Chips sind schon
eine andere Hausnummer als ein schönder Atmel AVR. Zumindest muss man
sich in die Denke etwas hineinarbeiten.

Richtig fies finde ich ja dass man die I2C Adressen, die man später
ansprechen möchte fest im Chip als Vendor ID eintragen muss. Total
freaky oO...

Danke erstmal an eure Hilfe!! Ich werde sie sicher noch öfter brauchen
:)

[Thomas (Gast)]

Da liegst du ganz sicher falsch. Du kannst mit entsprechender Firmware 
beliebige i2c Adressen ansprechen. Das hat nichts mit der vendor oder 
device ID zu tun.
Vermutlich liest du einfach das Boot EEPROM aus.
Vermutlich hast du das Konzept der Cypress Bausteine noch nicht 
verstanden.

Es ist schon etwas mehr Arbeit eine entsprechende Bridge zu 
programmieren.
Du mußt das halt selbst machen und nicht nur die vorgefertigten 
Beispiele benutzen.
Thomas

[Lothar (Gast)]

Thomas schrieb:
> Es ist schon etwas mehr Arbeit eine entsprechende Bridge zu
> programmieren.

Es gibt uC mit USB ROM Treiber und kompletter USB I2C Bridge Software 
z.B.

LPC11U37 oder LPC1347 mit usbd_rom_hid_i2c und freier USB PID Lizenz

[Borsty B. (mantabernd)]

Thomas schrieb:
> Da liegst du ganz sicher falsch. Du kannst mit entsprechender Firmware
> beliebige i2c Adressen ansprechen. Das hat nichts mit der vendor oder
> device ID zu tun.
> Vermutlich liest du einfach das Boot EEPROM aus.
> Vermutlich hast du das Konzept der Cypress Bausteine noch nicht
> verstanden.

Schade dass ich grad die etnsprechende App. Note von Cypress nicht zur 
Hand habe. Dort war das ziemlich gut erklärt dass es über die USB API 
für C# keine direkten I2C Befehlssätze gibt und man deshalb die Geräte 
über einen Vendor Request ansprechen muss. Diesen Vendor Request trägt 
man dann in der Firmware des Cypress Chips ein und gibt ihm vor was er 
damit machen soll (in meinem Fall eine I2C Transaktion)

Und nein ich lese nicht das Boot EEprom aus (das war am Anfang aber der 
Fall ... haha).
Der Screenshot zeigt meinen Logikanalyzer auf Hardwarelayer und ich kann 
sogar LEDs steuern. Die I2C Kommunikation steht also.

Ich werde am Montag mal die entsprechende App Note heraussuchen und hier 
posten. Vielleicht habe ich wirklich was falsch verstanden. Für den 
Moment bin ich aber froh dass es funktioniert.

[Thomas (Gast)]

Ja genau diese vendor requests sind eben dazu gemacht mit dem Boot 
EEPROM zu kommunizieren. Das Stichwort lautet A2 Download.
Wie kommt denn deine Firmware auf den Chip? Ist diese fest im EEPROM 
drin oder lädst du die im Treiber? Ich habe mit den Cypress Teilen 
einige Projekte abgeschlossen allerdings habe ich immer eigene Treiber 
und Firmware gemacht.
Achtung
Dein Chip hat 16k RAM da funktioniert einiges etwas anders wie mit den 
alten 8k Chips.
Thomas

[Lothar (Gast)]

Borsty B. schrieb:
> Dort war das ziemlich gut erklärt dass es über die USB API
> für C# keine direkten I2C Befehlssätze gibt und man deshalb die Geräte
> über einen Vendor Request ansprechen muss

Bei den erwähnten LPC uC ist die USB I2C Bridge als Generic HID Device 
realisiert, man nutzt also in .net nur die normalen Write/Read Reports 
um I2C Write/Read zu machen.

Thomas schrieb:
> Ich habe mit den Cypress Teilen
> einige Projekte abgeschlossen allerdings habe ich immer eigene Treiber
> und Firmware gemacht

Da als HID Device realisiert ist auf dem PC kein Treiber erforderlich.

[Christian R. (supachris)]

Thomas schrieb:
> Ja genau diese vendor requests sind eben dazu gemacht mit dem Boot
> EEPROM zu kommunizieren. Das Stichwort lautet A2 Download.

Das ist aber nur der erste Teil. Über den A2 Request lädt man eine 
Firmware in den RAM und startet die dann. Danach kümmert sich die 
Firmware um die I2C Kommunikation. Für diese gibts aber auch 
Beispielcode in dem Firmware Setup Paket. Und ja, das Ding ist etwas 
unübersichtlich, aber dafür kann der halt USB High Speed ohne großartige 
Verrenkungen. Aber der 8051 ist mit Keil schon gruselig. Etwas besser 
gehts mit Eclipse und SDCC, aber da sind die Header Files alle 
anders...naja. Hat Cypress aber stillschweigend beim FX3 SDK mit 
reingepackt.

[Conny G. (conny_g)]

Ich kenne den uC nicht, aber wie ich den Chip verstehe sieht es mir so 
aus als müsstest Du auf dem Cypress jetzt irgendeine Art von Gerät 
implementieren, das der PC sehen und ansprechen kann.
Das braucht einen Treiber auf der PC-Seite, der das implementiert.
Also kannst Du ein Gerät implementieren für das es schon einen Treiber 
gibt wie einen virtuellen COM oder eine Tastatur etc
Oder Du schreibst Dir einen USB Treiber auf der Windows-Seite und auf 
der USB Seite was Du willst. Das ist m.E. Aber viel zu aufwändig, 
Virtual COM ist viel einfacher, gibt es schon Treiber bei Windows.
Könnte mir vorstellen, dass Cypress genau dafür schon ein Bespiel hat.
Das mit dem Vendor Requests ist eher eine Gurke "hintenrum" um die 
Implementierung eines Geräts mit Treiber zu vermeiden.

[Thomas (Gast)]

Conny G. schrieb im Beitrag
> Dir einen USB Treiber auf der Windows-Seite und auf der USB Seite was Du
> willst. Das ist m.E. Aber viel zu aufwändig, Virtual COM ist viel
> einfacher, gibt es schon Treiber bei Windows.
Niemand verwendet den fx2 um einen COM-Port zu bauen dafür ist er 
deutlich überdimensioniert. Dafür gibt es in der Tat bessere Lösungen. 
Aber zeig mir mal eigenen USB Chip der locker 22 MByte übertragen kann. 
Der op hat ja ausdrücklich geschrieben dass mit dem Chip mehr gemacht 
werden soll.

> Das mit dem Vendor Requests ist eher eine Gurke "hintenrum" um die
> Implementierung eines Geräts mit Treiber zu vermeiden.
Das sieht du falsch. Nichts geht bei USB ohne Treiber auch vendor 
requests brauchen Treiber. Es ist nur so dass fuer einige Klassen das OS 
schon Treiber bereit stellt.
Für solche einfachen Dinge wie I2C sind vendor requests perfekt 
geeignet.

HID und co sind nur fuer niedrige Datenraten zu gebrauchen.
Für einenen wirklich guten USB Treiber würde ich bei Thesycon 
vorbeischauen allerdings brauchts dort für den lizenzierten Treiber 
ordentlich Kleingeld. Zum Testen reicht die Demo.
Thomas

[Christian R. (supachris)]

Thomas schrieb:
> Für einenen wirklich guten USB Treiber würde ich bei Thesycon
> vorbeischauen allerdings brauchts dort für den lizenzierten Treiber
> ordentlich Kleingeld. Zum Testen reicht die Demo.

Nö, unnötig, es gibt doch LibUSB und WinUSB.

[Lothar (Gast)]

Thomas schrieb:
> Aber zeig mir mal eigenen USB Chip der locker 22 MByte übertragen kann.
> Der op hat ja ausdrücklich geschrieben dass mit dem Chip mehr gemacht
> werden soll.

Und wozu? Selbst I2C Fast Mode Plus schafft max. 1000 kbit/s das sind 
125 kB/s

[Thomas (Gast)]

Lothar schrieb:
> Thomas schrieb:
> Aber zeig mir mal eigenen USB Chip der locker 22 MByte übertragen kann.
> Der op hat ja ausdrücklich geschrieben dass mit dem Chip mehr gemacht
> werden soll.
>
> Und wozu? Selbst I2C Fast Mode Plus schafft max. 1000 kbit/s das sind
> 125 kB/s

Weil der OP das braucht? Der OP wird schon einen Grund haben den fx2 zu 
verwenden.
Ich klinke mich hier mal aus.
Thomas

[Borsty B. (mantabernd)]

Thomas schrieb:
> Weil der OP das braucht? Der OP wird schon einen Grund haben den fx2 zu
> verwenden.

Ja, weil ich vom fx2 abhängig bin.

Es handelt sich um eine Platine die über eine andere Software gesteuert 
wird. An diesen USB Bus hänge ich mich dran und schreibe meine eigene 
Anwendung.

Am Ende soll es eine Software sein in der ich zwischen den zwei 
Anwendungen umschalten kann, dabei wird natürlich der fx2 entsprechend 
neu geflashed, bzw. zwischen zwei Booteeproms umgeschaltet (da bin ich 
mir noch nicht sicher).

> Wie kommt denn deine Firmware auf den Chip?

Es gibt von Cypress ein Programm "CyConsole", dort wähl ich den Chip aus 
und übertrage die in der Keil Umgebung generierte hex Datei.


Zusammenfassend:

Spricht denn etwas dagegen meine I2C Devices über die Vendor Requests 
anzusprechen oder hat jemand eine bessere Idee mit DIESEM Chip?

[Christian R. (supachris)]

Borsty B. schrieb:
> Spricht denn etwas dagegen meine I2C Devices über die Vendor Requests
> anzusprechen oder hat jemand eine bessere Idee mit DIESEM Chip?

Spricht nix dagegen, hab ich genauso realisiert und das geht parallel 
zum Slave FIFO Interface. Braucht man nicht die Firmware umschalten. 
Übrigens lässt die Firmware sich auch im Betrieb durch den A2 Download 
tauschen und dann starten, sogar optional mit Re-Enumeration, falls sich 
die Deskriptoren geändert haben. Der FX2 kann schon ziemlich viele 
Sachen.

[Borsty B. (mantabernd)]

Hey Leute... ich fürchte ich benötige eure Hilfe nochmals.

Ich habe nun meine Vendor Request fertig konfiguriert und ich kann über 
diese Requests I2C Befehle auf dem Bus absetzen.

Die große Frage ist nun wie ich die Daten in meine C# Anwendung 
übertragen kann...?

Soweit ich das verstanden habe läuft die gesamte Geschichte über den 
Endpoint 0x00 ab und es gibt einen Endpoint0 Buffer (EP0BUF[]), korrekt?

Ich sammle die Daten vom I2C bus aktuell folgendermaßen ein:

    for(i=0; i<readlen; i++) {
      while (!(I2CS & bmDONE));
      *(EP0BUF+i) = I2DAT;
    }

Der EP0BUF wird mit den Busdaten gefüttert. Nur wie greife ich nun auf 
dieses Buffer aus meiner C# Anwendung zu?

[Thomas (Gast)]

Borsty B. schrieb im Beitrag #46027
>
> Ich sammle die Daten vom I2C bus aktuell folgendermaßen ein:    for(i=0;
> i<readlen; i++) {
>       while (!(I2CS & bmDONE));
>       *(EP0BUF+i) = I2DAT;
>     }
>
Siehe 13.4.4 im TRM Manual. Da fehlt die komplette Fehlerbehandlung

> Der EP0BUF wird mit den Busdaten gefüttert. Nur wie greife ich nun auf
> dieses Buffer aus meiner C# Anwendung zu?

Dein vendor Request hat ein wlenght Feld. Sobald deine Daten im Puffer 
stehen werden sie von der Engine übertragen. Das bedingt natürlich dass 
deine Firmware in dem Bereich ok ist. Deine Anwendung stellt einen 
Buffer mit wlenght size oder mehr bereit dort sind deine Daten.
Thomas

[Borsty B. (mantabernd)]

Danke erstmal für eure Bemühungen und die Unterstützung!

Es läuft jetzt für's erste. Die Daten kommen teilweise korrekt an, muss 
mich noch etwas tiefer reinhängen damit es 100%ig läuft aber fürs erste 
ist das schon mal ein Erfolg :) (für jemanden der sowas noch nie zuvor 
gemacht hat)