UDK 2.1.0.0 Probleme/Feedback

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • UDK 2.1.0.0 Probleme/Feedback

      Hallo cesys-Team,

      nach langer Zeit habe ich mal ein Upgrade der Treiber auf UDK 2.1.0.0 vorgenommen. Betriebssystem ist Ubuntu 9.x/10.x, 64 bit.

      Dabei sind mir einige Punkte aufgefallen, die die Migration momentan verunmöglichen:

      1) Die in der Dokumentation beschrieben ReadBulk()/WriteBulk()-Funktionen existieren nicht mehr, bzw. sind offensichtlich umbenannt, aber nicht mehr zugänglich (private). Der Direktzugriff auf USB ("raw") scheint ohne Eigenentwicklung nicht mehr möglich. Ist das korrekt, oder habe ich da etwas übersehen?
      2) Das Flashen von *.bin-Files per UDKlab klappt zwar ohne Fehlermeldung, doch das Board bleibt tot. Der Download von Designs klappt. Müssen die BIN-Dateien irgendwie konvertiert werden, damit es geht?
      3) Wenn "group" und "others" auf /dev/ceusbuni0 keinen Zugriff (rw) haben, crasht UDKlab ohne Kommentar beim Öffnen des Geräts
      4) UDKlab erwartet offensichtlich einen grossen Bildschirm (y > 768 ), das Fenster lässt sich auch nach dem Verschieben nicht verkleinern. Der "Start-Sequence"-Button ist dann nur noch marginal zu sehen

      Meine Anwendung ist ein relativ primitiver, roher Stream, ohne Wishbone.

      Noch eine Anmerkung zur Compilation: Bei meinem Compiler 4.4.1 läuft der Make-Prozess nicht "from the box" richtig durch:
      /usr/bin/ld: /data/src/UDK2.1.0.0/lib/libplxapi.a(PlxApi.c.o): relocation R_X86_64_32S against `.data' can not be used when making a shared object; recompile with -fPIC

      Habe mal nur auf die Schnelle ein -fPIC an die C_FLAGS in CMakeFiles/plxapi.dir/flags.make angehängt, dann klappt's.

      Schöne Grüsse,

      - Martin
    • Hallo,

      zu Ihren Punkten:

      1) Das ist richtig, da unsere Beispiele und Tools alle auf unser Protokoll aufbauen haben wir den reinen Zugriff aus dem öffentlichen Interface entfernt. Da aber alles als Source-Code mitgeliefert wird, hat jeder die Möglichkeit sich einen Zugang zu diesen Funktionen ins Interface zu legen.
      2) Am .BIN hat sich nie etwas geändert. Sollte der FPGA das Design nicht abweisen, kann er es wohl auch interpretieren (sonst käme eine Fehlermeldung). Was es dann natürlich tut, liegt am Design selbst.
      3) Das betrachte ich jetzt mal als Bug und schaue inwieweit das im nächsten Release berücksichtigt wird.
      4) Das ist natürlich nicht allzuschön, nur gehen wir in der heutigen Zeit von einer gewissen Basisauflösung aus. Falls Sie es für eine kleinere Auflösung benötigen, Projekt und Source-Files liegen alel bei.

      Vielen Danke auch für die Tips bzgl. GCC 4.4.1 . Uns ist es leider nicht möglich immer mit den aktuellsten Systemen up2date zu bleiben, da wir hier ein relativ kleines Team mit verschiedenen Projekten sind. Mal abgesehen davon ist dieser Fehler Teil der PLX-API, welche wie nur mitliefern (die aber durchaus auch veraltet sein kann).

      Mit freundlichen Grüßen,
      Thomas
      Thomas
      Software development
      Cesys GmbH
    • Hallo Thomas,

      danke für die prompte Antwort.

      Zu 2) muss ich nochmals erläutern: Das mitgelieferte led_blinker.bin z.B. zeigt keinen Effekt, wenn ins SPI geflasht. Also: ich wähle "Erase/Program Flash with FPGA design", wähle led_blinker.bin aus, Flash wird gelöscht, und geschrieben. Nach erneutem Einstecken des USB müsste das Ding doch blinken, richtig? So lief es zumindest früher.
      Zu 1) noch: Vermutlich wäre es sinnvoll, die in der Dokumentation noch beschrieben ReadBulk()- usw. zu entfernen.

      Ist für mich ansich kein Problem, in den Sourcen zu graben, aber eine gut funktionierende Referenzumgebung würde viel Zeit sparen. Ich hoffe, Sie sehen das auch eher als Anregung als Kritik.

      Schöne Grüsse,

      - Martin
    • Hallo Martin,

      Kritik wird bei uns hier immer aufgenommen und wir wollen die Dinge immer so ideal wie möglich für unsere Kunden machen. Offensichtliche Probleme versuchen wir immer möglichst schnell aus der Welt zu räumen, andere werden ausdiskutiert.

      Zu Ihren zwei Dingen:
      zu 2) Möglicherweise ist Auto-Power-On nicht aktiv, sprich, der FPGA bekommt erst nach dem ersten API-Zugriff Strom. Ist Auto-Power-On aktiv, erledigt das die Firmware selbständig. Der Linux-Treiber holt sich die Daten aus /etc/modprobe.d/ceusbuni.conf , dort muß "options ceusbuni auto_power_on=1" stehen, außerdem bitte mal in /var/log/messages verifizieren.
      Alternativ: Fängt die LED an zu blinken sobald man sichmit UDKLab auf die Karte verbindet ?
      zu 1) notiert :)

      mit freundlichen Grüßen,
      Thomas
      Thomas
      Software development
      Cesys GmbH
    • Hallo,

      ich beschäftige mich zur zeit ebenfalls damit, eine bestehende Software auf den neuen Treiber zu portieren. Da die bisherige Software und das FPGA Design nicht auf das neu eingeführte Protokoll ausgelegt sind, würde ich gerne wieder zugriff auf den BulkRead/Write bekommen. Jedoch finde ich die Klassenstruktur nicht gerade einfach zu durchdringen. Daher meine Frage:
      Gibt es eine Empfehlung, wie man vom ceDevice am geschicktesten Zugriff auf die Bulk-Methoden eines ceUSBDevice bekommt?

      Grüße
      Andreas