Hi alle, hat schon mal jemand einen I2C EEPROM über einen EZ-USB (AN2131) programmiert. Ich frage, weil beim Tool fxload beschrieben steht, dass es einen entsprechenden Loader beim Cypress Dev. Kit geben würde. Dort kann ich leider keinen finden. Cypress' Webpresenz ist heute auch nicht zugebrauchen :) viele lustige Fehlermeldungen. Besten Dank und viele Grüße PS: Diese Anfrage richtet sich in der Tat nur an diejenigen, die es schon wissen. Ich möchte ausdrücklich davon Abstand nehmen, hiermit jemanden implizit dazu aufgefordert haben, an meiner statt Google zu bemühen. Nur so zur Sicherheit ;-) um nicht gleich virtuelle Kloppe zu bekommen.
Hallo Thomas, kloppe bekommst von mir keine ;-) Du kannst das EEprom wie bei einem normalen 8051er ansprechen, halt über die I2C Register. Passe aber bitte auf, das Du Deinen AN2131 nicht dazu überredest, die Devicedescriptor aus dem I2C Eeprom zu lesen oder gar daraus das Programm zu laden, denn dann gibts Probleme mit der USB Core. Die daten daraus lesen ist nicht das große Problem, eher das Du zuerst für Dein Device einen Treiber brauchst, denn der 0815 Treiber kann nur das Programm hochladen. Gruß Marcus
Hi Marcus, ich will ihn doch gerade dazu überreden, dass Programm und den Descriptor ausm EEPROM zu lesen :) Dazu die ganze Übung... Deswegen wollte ich das EEPROM ja auch nicht selbst aus dem 8051 ansprechen, sondern diesen "Second-Stage" Bootlader verwenden, der das können soll.
@Marcus warum soll es Probleme geben mit dem Programm Download aus dem EEprom? Ich mache das schon lange (B2 Download) ohne die geringsten Probleme. Das Device ist mehrer 1000 mal im Einsatz. @Thomas B2 Download in den Docs lesen das ist alles was du brauchst. Die Second Stage brauchst du nur wenn dein Programm > als das interne Ram ist. Das habe ich noch nie gemacht da ich die Chips im standalone Mode nutze. Prinzipell sollte das aber so funktionierenn dass zuerst ein B2 Teil kommt in den (1 8k) der das EEprom handeln kann. Dann sollte diese Firmware den Rest nachladen können. Thomas
Hi, das Ding ist doch, dass man für gewöhnlich eine Firmware baut, die sich nicht selbst in den EEPROM laden kann. Deswegen muss das Upload-Programm dies beistellen. Das fxload hat eben nach eigenen Angaben, nur einen Loader für externen RAM nicht aber für EEPROM. Im Devkit sind aber in der Tat zwei Sachen bei, die dies können. 1) Das Tool Control Panel. Wie mir scheint ist der nötige Loader als Tabelle im Source abgelegt. Jede weitere Verwendung ist untersagt. Mit dem fertigen Programm kann man ja auch in der Tat einen Upload ins EEPROM vornehmen. Dumm ist nur, dass es danach nicht mehr von der Software erkannt wird, wenn es eine andere VID/PID hat :) 2) Es gibt einen C-Source für eine Firmware, die allerlei Vendorrequests unterstütz, so auch den A2-Upload ins EEPROM. Nur kompiliert habe ich diese noch nicht, weil ich den SDCC noch nicht konfiguriert habe... Aber schreib doch bitte mehr dazu :) So ganz schlau werd' ich aus deinem Statement nämlich nicht.
Also noch mal etwas ausführlicher: Es gibt keinerlei Unterschied ob du eine FW baust die aus demm EEprom kommt oder ins Ram geladen wird. (bis auf ReEnum siehe unten) Der einzige Request den der EZUSB in HW handlen kann ist der A0 Request der auf funktioniert wenn das Teil im Reset ist. Alle anderen Verfahren musst du schon mit FW abdecken. Nichts anderes macht übrigens der Treiber und das Controlpanel (deine Tabelle) Es gibt ein utility dass eine firmware ins B2 format konvertiert B2 Images sind aus dem EEprom ladbar die VID PID infos im EEprom werden dann ignoriert und stattdessen die Deskriptoren aus der FW benutzt. (HexToBix _-IR -O) Siehe auch Ezusb Manual. Du kannst jederzeit eine FW in den Chip laden die den Vendor Request zum Programmieren eines EEproms enthält damm kann jede App die diesen Request absetzt das EEprom programmieren. Als Notausgang wenn dein EEprom verflasht ist einfach SDA und SCL brücken denn meldet sich das Device wieder mit EZUSB-EEprom missing. Du brauchst für dein Produkt sowiso gedrennte PIDs VIDs sonst ist der Ärger im Feld schon vorprogrammiert. Es hindert dich aber niemand daran eine INF zu schreiben die genau das gleiche macht wie die Cypress Inf. Bei der Gelegenheit ist es sinnvoll auch gleich den Treiber umzubenennen falls du den wirklich benutzen willst. Wenn du den B2 Download verwendest kein ReEnum durchführen das ist nicht notwendig und erzeugt nur 2 PlugIn Events. Ich habe mich übrigens dafür entschieden, einen anderen VendorRequest zu nehmen und benutze den Cypress Treiber nur um meinen Firmware Flasher zu betreiben. Mein Produkt hat allerdings einen eigenen Treiber. Thomas
Hi, >Es gibt keinerlei Unterschied ob du eine FW baust die aus demm EEprom >kommt oder ins Ram geladen wird. (bis auf ReEnum siehe unten) Ich weis :) Schliesslich wird die ausm EEPROM ja zur Ausführung ins RAM geholt. Es geht ja auch darum, wie sie ins EEPROM kommt ;-) >Der einzige Request den der EZUSB in HW handlen kann ist der A0.. Jo. Schon klar. >Alle anderen Verfahren musst du schon mit FW abdecken. Nichts anderes >macht übrigens der Treiber und das Controlpanel (deine Tabelle) Richtig. Und deswegen gibt es ja die Second-Stage Loader. Und der beim fxload dabei ist, kann eben nur den A3-Upload, d.h. in externes RAM. [hex2bix] Ja, das ist mir bekannt. Das braucht man ja auch, wenn das EEPROM mit dem Control Panel schreiben will. Und auch dann, wenn man beispielsweise per Ponyprog das EEPROM schreibt. >Du kannst jederzeit eine FW in den Chip laden die den Vendor Request >zum Programmieren eines EEproms enthält damm kann jede App die diesen >Request absetzt das EEprom programmieren. Richtig, und genau dafür hat der Loader dazusein. Und genau den suchte ich, so wie es den a3load.hex beim fxload dazu gibt. Der andere Weg ist ja ohnehin das WriteEEPROM feature permanent in die Firmware einzubauen. Dann hat man zumindest auch die Möglichkeit den EEPROM neu zu programmieren, ohne an der Hardware rumbiegen zu müssen. Mein "Produkt" hat auch einen eigenen Treiber :) Linux. Viele Grüße
A3Load.Hex ist nur dafür gedacht den Keil Monitor ins externe Ram zu kopieren da der B2 download aus dem EEprom nur mit den internen 8k umgehen kann. Das ist nur für den expanded mode mit ext Speicher gedacht. Da der Monitor nicht frei ist gibts eben nur diese Tabellen. A3 Load bedeutet aber, dass du eine FW unten hast die diesen A3 Request kann. Du kannst natürlich auch einen Request definieren der dir den Raminhalt einfach ins EEprom schreibt. Wenn ich mich richtig entsinne ist das B2 Format recht primitiv. Allerdins ist das potentiell gefährlich und kann schon mal dazu führen dass das device das EEprom nicht korrekt erkennt. Ich kann da auch keinen Sinn drin erkennen, da es ja speziell bei Linux relativ einfach ist belibige Requests abzusetzen. Thomas
Hi, das a3load.hex, welches beim fxload dabei ist, ist sicherlich nicht (nur) für den Upload eines Monitors gedacht. Was sollen die Entwickler schliesslich mit Keil am Hut gehabt haben? Eine A2-Loader zu haben und zu verwenden, ist nunmal für meine Begriffe genau die Herangehensweise von Linux. Viele kleine Tools. Statt die "Betriebs"-firmware damit zu belasten ein dediziertes Tool verwenden. Aber du hast schon recht, es ist nicht so unheimlich wild, einen solchen Request in der normalen Firmware zu implementieren. Muss man halt den Treiber anpassen und noch ein Uploadtool bauen. Mit eingebauter hex2bix-Funktionalität. Gute Nacht
Hallo Thomas Burkhardt, Der Thread ist zwar schon etwas älter, aber hat sich für dein Problem eine Lösung ergeben? Du warst ja auf der Suche nach einem "a3load.hex fürs eeprom" oder? Ich habe genau dasselbe Problem, auch unter Linux. Hast du da eine Lösung gefunden?
Ein paar vielleicht sachdienliche Hinweise könnten sich dem hier entnehmen lassen: http://www-user.tu-chemnitz.de/~heha/bastelecke/Rund%20um%20den%20PC/USB2LPT/ul-10.htm (Das ist ein Selbstbau-USB-Parallelportadapter mit AN2131)
@Martin auch nach einem Jahr gilt immer noch das oben gesagte: A3 Download funktioniert nur ins externe Ram und ist für den Keil Monitor gedacht (Betrieb des Eval Boards mit den Keil Tools) Ein A3 Download ins EEprom geht nicht! Du musst dir diese Funktionalität schon selbst schreiben wenn du via A3 ein Eprom flashen willst. Thomas
Hallo Martin, danke dass du den ein Jahr alten Thread wieder hochgeholt hast. Leider bin ich in den letzten Monaten (von Monaten zu sprechen ist eigentlich geschönt) überhaupt nicht dazu gekommen etwas in der Richtung zu unternehmen. Mein Hirn ist in dieser Hinsicht ziemlich leer, da muss ich mich erstmal wieder einlesen, was da bisher eigentlich schon erreicht wurde. Traurig, auf der Platine steht 09/04, das ist schon ewig her und wahrscheinlich ist der EZUSB jetzt endgültig abgekündigt... Ansonsten fürchte ich, dass Thomas recht hat. Diese Funktionalität muss man selber machen. So weit ich mich erinnern kann, bin ich erstmal so verblieben per Ponyprog das EEPROM händisch zu programmieren. Da gibts so einen machmal-schnell Programmieradapter. Allerdings denke ich, dass ich in nächster Zeit (hoffentlich) mich wieder etwas damit beschäftigen kann. Ich würde mich also freuen, wenn wir uns in der Hinsicht austauschen könnten. Was hast du eigentlich damit vor? Viele Grüße
Es geht um ein System, in welchem die Board-Erkennung im EEPROM dynamisch vergeben werden soll. Dazu soll per fxload in einem Linux-System beim Anstöpseln eines neuen, noch nicht konfigurierten Boards die ID ins EEPROM gebraten werden, so dass das Board nach einem Restart mit der neuen bekannten ID (VID/PID) hochkommt.
Das ist innerhalb einer Stunde programmiert. Im Prinzip must du mit FX Load nur eine FW runterladen die in der Lage die ersten 10 Bytes des EEproms mit deiner Kennung zu programmieren. (B0 Download) Firmware Beispiele um das EEprom anzusprechen sind im EZ USB Paket. Nach dem Flashen einfach einfach den Pullup abschalten, 3 sec warten und einen Reconnect machen das sollte reichen damit sich das Teil mit der neuen Kennung meldet Thomas
halo zusammen hab heute gesucht, was für tools ich noch brauche um mit meinem fx2 komplett unter linux zu entwickeln. 8051 monitor programme gibts ja, nur leider keiner der auf den fx2 portiert ist. heist nettes basteln in den nächsten tagen (ein monitor ist nett, dann brauch ich keine ez-usb konsole mehr). interessanter war da schon das iic fileformat, internet scheint nichts zu wissen wie das aufgebaut ist und cypress sagt auch nix. auch egal, denn das cypress Hex2Bix.exe läuft einwandfrei mit einem steinalten wine! find ich sehr schön, da alles andere das ich in den letzten 5 jahren versucht habe zu benutzen mit wine war hald eben nicht benutzbar...
Thread beobachten
Seitenaufteilung abschaltenBitte 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.