Posts by irimi

    Was für einen Flash-Chip hast du denn im Display? Vielleicht passen die Erase, etc. Befehle einfach nicht zu deinem Flash?


    Hab zu hause nicht so einen kleinen Schraubendreher zur Hand, aber würde zur BL Theorie passen.


    Meine letzten genannten Analysen kann man vergessen, da war irgendwie der Wurm drin, keine Ahnung warum es immer einen Reset gab.
    Bin jetzt mal mit dem Debugger + Wireshark dran gegangen und es verhält sich so:

    Code
    1. flash_cmd(h, SPM_RES, 1, 0);
    2. flash_cmd(h, SPM_WRSR, 2, 0); // clr status
    3. flash_cmd(h, SPM_WREN, 1, 0);
    4. flash_cmd(h, SPM_FLASH_BE, 1, 0);


    werden erfolgreich ausgeführt und vom DPF immer mit OK quittiert.


    Aber anschließend gibs Probleme bei Abfrage des Flashstatus - über bootloader.c / flash_status_hid() / spilib_process() wird aufgerufen:

    Code
    1. error = transmit(h, umsg);
    2. if (umsg->u.spi.rnum > 0 && error >= 0) {
    3. error = usb_rawread(h->dev.udev, out, 64);
    4. }
    5. if (error < 0) perror("Reading USB");
    6. else error = 0;
    7. return error;


    Der Transmit ist noch erfolgreich, aber beim usb_rawread() gibt es nach 4s eine Fehlermeldung, hierzu der Trace:



    Das interessante: diesen Vorgang kann ich beliebig oft wiederholen, ohne einen weiteren detach machen zu müssen - ABER der Flashspeicher bleibt ungerührt, nichts wird gelöscht.


    Muss ich wohl doch mal den Flashbaustein anschauen - aber erst nach Ostern, fahre ein paar Tage weg.

    So, programmieren der 0.2er Version mit ProgSPI geht jetzt.
    Änderungen sind in http://dpf-ax.svn.sourceforge.net/ drin.


    Gruß
    superelchi


    Bin erst jetzt dazu gekommen, funktioniert super, auch der libhid Ersatz :tup .
    Habe festgestellt dass mein dpflib.py Script nicht kompatibel zur neuen Firmware ist - Ursache ist klar, muss es aber noch modifizieren.


    Außerdem habe ich ein wenig was beim Flash-Problem unter Linux/Python herausgefunden:
    - Problem tritt bei mir nur beim flashen per Bootloader auf
    - Timeouts in der dpflib hochsetzen bringt nichts
    - mit der neuen FW ist leicht zu erkennen, dass gleich nach dem ersten Befehl der Full Erase Flash Sequence "fllash_cmd(h, SPM_RES, 1, 0);" das Display offensichtlich einen Reset durchführt.


    Leider kann ich es nicht genau sehen da wireshark plötzlich keine Bulk Messages mehr mittraced :rolleyes: (ging aber schonmal) . Jedenfalls wird die FW gestartet, damit das Flash nicht gelöscht ! Wenn man das nicht mitgekommt und nochmal das Script startet, begeht die FW Selbstmord und löscht sich selbst 8o .
    Mein Verdacht: eventuell sind unterschiedliche Bootloaderversionen drauf, die ihre Eigenarten haben. Man müsste mal den Flashspeicher an der Stelle auslesen und vergleichen.


    Grüße, irimi

    Könne man da nicht was mit ImageMagick machen?


    Nicht notwenig, kann alles die PIL, läßt sich schnell ändern, wen man es relativ oder anderes haben will.
    Und wie bereits oben noch ergänzt, kann man die Skalierung bereits als Parameter übergeben - einfach mal "dpflib.py help" eingeben.

    Hatte schon überlegt, wie ich das Startbild am einfachsten auf das Display kriege. Ein Programm, das die libpdf.a von hackfin benutzt ist meine Meinung nach nicht so das Gelbe vom Ei für einen "normalen" Anwender. So mit Kompilieren und so...
    Wenn ich das richtig verstehe, brauchts nur die dpflib.py für den Zugriff aufs Display? Wenn ich nen neuen Befehle wie "set splashimage" in die Firmware reinbaue, könnte man dann doch ein einfaches Download-Programm mit der dpflib.py basteln, oder?


    Hat auch Nachteile: es muss noch die Python Image Library (PIL) und pyusb 0.4 nachinstalliert werden. Außerdem ist die notwendige Wandlung nach rgb565 rechenintensiv, was auf kleinen System schon im Sekundenbereich liegen kann - auf meinem Router an dem ich das Display ebenfalls verwende geht es gerade so.
    Vorteil ist aber, dass man von dieser libdpf.a unabhängig ist.
    Der Download mit dpflib.py geht übrigens schon zB

    Code
    1. python ./dpflib.py [Grafikdatei.png|jpg]

    .


    Die Grafik kann kann größer als 320x240 sein - wird dann runterskaliert (allerdings noch absolut)


    Quote

    Hab ja von hackfin Developer-Zugriff auf das dpf-ax Projekt bekommen


    Cool - da kommen noch spannende Zeiten :]


    Quote

    Das Bild würde ich als Resource in die Firmware einbinden.


    Wenn du stattdessen ein bin File erzeugen willst, die Zeile 396-414 ändern in

    Code
    1. [(r565.append((p[0] & 0xf8) |((p[1] & 0xe0) >> 5 )),r565.append(((p[1] & 0x1c) << 3)|((p[2] & 0xf8) >> 3)) ) for p in rgbdata]
    2. import struct
    3. f = open("./RGB565.bin", "wb")
    4. for short in r565:
    5. bindata = struct.pack("h",short)
    6. f.write(bindata)
    7. f.close()


    Ergänzung: die Skalierung kann man bereits als Parameter übergeben ("dpflib.py help") zeigt wie.

    Ne,ne , Kabel, Hub usw. kommen nicht in Frage, habe es jetzt nochmal mit meinem Notebook mit USB3.0 versucht - wieder dieses "Temporary Unavailable " Problem. Schon komisch , bisher nie Probleme gehabt , auch nicht mit dem alten hackit.py.
    Auch mit dem detachen wie erwartet, hidraw komt und geht wie erwartet. Allerdings: alle meine Rechner haben Ubuntu 11.10 ! Aber selbst hackfin/Strubi schreibt

    Quote

    For some reason, there are sometimes too many timeouts on the pearl DPFs.

    Habe da noch eine Idee - ist aber etwas aufwendiger.


    Das mit dem Fulldump habe ich befürchtet :( . Ja, dürfte sich herausfinden lassen, wie man das macht.


    Ach, noch zu meiner "Quick & Dirty" Funktion: habe mal ein kleines Konverter Script geschrieben, was ein entsprechendes C-Array erzeugt.
    Solch ein Array kann je nach Auflösung recht groß werden, was vielleicht mein Compilieren/Linken der FW Probleme machen könnte.


    Zusätzlich kann man den DPF direkt per USB mit Bildern befüllen (alles unter Python), wenn man mal eben schnell eine Grafik auf dem DPF testen will.
    Zu finden unter:
    dpflib.py

    Hallo superelchi,


    das klingt ja höchst interessant mit deinen Änderungen und bin gespannt was du da noch aufbohrst. Mir fehlt leider momentan Zeit und Muße da so tief einzusteigen, bis auf meinen Quick & Dirty Vorschlag.


    Vielen Dank auch für den Tipp es mal so zu versuchen, aber leider ;( kein Unterschied und gleiche Fehlermeldung,
    Habe es übrigens auf 2 verschiedenen Ubuntu Systemen versucht, unterschiedlich HW - einmal 32bit und ein 64bit System.


    Könntest du eventuell einen fulldump der neuen Firmware zur Verfügung stellen ?
    Diese ließe sich dann vielleicht mit ProgSPI flashen und man kann eventuell Rückschlüsse daraus ziehen, wie man gleich ein solchen bin File erzeugt, das von ProSPI akzeptiert wird !?


    Nicht schön aber dann kriege ich die FW hoffentlich auf mein DPF., Könnte mir vorstellen, dass viele das Problem haben .... ?


    Grüße,
    irimi

    Na dann viel Vergnügen. Dann sind wir wieder bei den Pinguinen. Was machst du, wenn jemand gern ein anderes Bild hätte? Soll der das dann auch - ganz easy - "reinpasten"? Oder machst du einen Änderungsdienst auf?


    Zugegeben, eine Lösung bei der ich ein default Image im USB flash drive definiere, welches ich jederzeit austauschen ist natürlich schöner, aber wie du schon schreibst ist das nicht trivial und mal eben schnell gemacht.


    Aber als erste einfache Lösung, wenn jemand unbedingt sein eigenens Image haben will , muss man halt selber compilieren, selbst die FW flashen muss man eh.
    Mir persönlich reicht das, die saubere Lösung ist aber klar vorzuziehen !


    BTW: Ja, verdammt ist schon bald 20 Jahre her, dass ich mit dem 8051 gearbeitet habe

    Vorteil dieser neuer Version wäre nämlich, dass man selbst die Firmware modifizieren könnte: fastoff und eigenes Bild ließen sich sicherlich einbauen ... man muss sich "nur mal" in die Sourcen einarbeiten .


    Da bin ich grad dabei. :D


    Habe mal selber reingeschaut, eigentlich muss man kein großer C-Programmierer sein, um den BSOH zu modifizieren, bzw. sogar eine Grafik reinzupasten:
    In main.c / Funktion umain() gibt es u.a. die Aufrufe:


    Wenn man eine Grafik in den BSOH reinpasten will, muss man nur schauen wie clrscreen() funktioniert:
    Anstelle von einzelnen col Wertes könnte man ein array nehmen, welches die Bilddaten im RGB16/RGB565 Format enthält zB const unsigned short g_splashgfx[] = {...}


    Das sollte es gewesen sein, jetzt muss man "nur noch" (haha, siehe meinen vorhergehenden Eintrag) die modifizerte FW flashen können ...

    Possibly you have to 'sudo libhid-detach-device 1908:3318'


    So, das habe ich nun hinbekommen, aber leider gibt es immer noch Fehler, d.h. restore.py fängt an , den Flashspeicher zu löschen, steigt dabei leider aus:

    Code
    1. sudo python ./fw/restore.py ./src/fw_pearl_landscape.bin
    2. Found AX206 DPF (bootloader)
    3. Erase full flash...
    4. Reading USB: Resource temporarily unavailable
    5. Traceback (most recent call last):
    6. File "./fw/restore.py", line 37, in <module>
    7. flash_restore(d, data)
    8. File "./fw/restore.py", line 12, in flash_restore
    9. d.eraseFlash() # erase full flash
    10. SystemError: 145:(ffffff92): Unknown error


    Eventuell ein Timing Problem ???
    Zum Glück "lebt" anschließend wenigstens der Bootloader noch und ich kann mit ProgSPI den DPF wiederbeleben.


    Also nochmal die Frage, gibt es hier jemanden der erfolgreich mit restore.py flashen konnte ?
    Solange das nicht geht, macht die Modifizierung der Source FW auch keinen Sinn.

    Da widerspreche ich dir doch gleich mal. Richtig benutzt findet apt-file sehr wohl etwas:

    $ apt-file search $(which firefox)
    firefox: /usr/bin/firefox

    Das ist aber nur die halbe Wahrheit :D !
    apt-file funktioniert nur, wie ich inzwischen herausgefunden habe, wenn man mal ein "apt-file update" gemacht hat, ansonsten gabs bei mir kein output, auch nicht mit "apt-file search $(which firefox)".
    Aber dann findet sogar ein "apt-file search libhid" etwas(das eigentliche Problem) , da mingw Pakete anscheinend eine statische libhid.a haben.


    Habe ich doch heute mal wieder was nützliches gelernt ...

    OFF-TOPIC:

    "apt-cache search" durchsucht nur die installierten Pakete nach Dateinamen, mit "apt-file find" (apt-file muss extra installiert werden) kann man nach Dateien in allen vorhandenen Paketen (also alle Pakete in allen eingebundenen Repositories) suchen.

    Sorry, da muss ich leider widersprechen. Beispiel: "apt-cache search tomcat" findet diverse Pakete und von diesen Java Paketen habe ich garantiert nichts installiert, dagegen findet "apt-file find firefox" rein gar nichts, dabei benutze ich ihn gerade !
    Außerdem habe ich in der Vergangenheit häufig fehlende Pakete mit apt-cache erfolgreich gefunden.


    Google ist dein Freund. :] "libhid-detach-device" ist im Paket "libhid" enthalten - wer hätte das gedacht bei dem Namen. :D
    Für neuere Ubuntu-Versionen gibts allerdings kein fertiges Paket mehr. Also selbst ist der Mann - äh Kompilierer!


    Das Display wird im Bootloader-Modus von Linux als "Human Interface Device" erkannt und vom HID-Treiber gemanaged. Um zum Flashen dranzukommen muss man es eben erst dem HID-Treiber wegnehmen.


    Gruß
    superelchi


    Aah :wand , danke für den Hinweis. Das erklärt auch warum bei

    Code
    1. apt-cache search libhid

    nichts gefunden wurde. Hätte ich doch gleich Google probieren sollen ...

    Die Antwort hast du ja selbst gepostet - steht in der Meldung von restore.py.


    Zitat
    Possibly you have to 'sudo libhid-detach-device 1908:3318'

    Damit kann ich aber leider nichts anfangen,was soll das für eine Befehl sein "libhid-detach-device" ???
    Bitte um Aufklärung ?(


    Außerdem müsste doch erst was "attached" sein, bevor ich einen detach machen muss, der Fehler tritt aber auch wie bereits erwähnt , nach einem reboot auf !?

    Interessant ist, dass bei den Sourcen auch ein Bootload-Flasher dabei ist, d.h. eine Ersatz für ProgSPI unter Linux (restore.py im fw-Verzeichnis)!
    Leider gibts damit die selben Probleme wie mit ProgSPI. Displays, die sich damit nicht flashen lassen gehen auch nicht mit restore.py. ;(
    Damit dürfte klar sein, dass es an den Displays und nicht am Flash-Programm liegt - leider.


    Hmm, ist es denn hier schon jemanden gelungen die 0.2 devel Firmware auf ein DPF zu bekommen ?
    Habe folgendes Problem: ProgSPI und das alte hackit.py gehen ohne Probleme, ABER restore.py liefert eine Fehlermeldung - scheint also eher doch am Flasher zu liegen.

    Code
    1. Found AX206 DPF (bootloader)
    2. Error: Failed to claim usb device!
    3. Possibly you have to 'sudo libhid-detach-device 1908:3318'


    Ein Rechte Problem oder gleichzeitiger Zugriff durch eine andere Instanz kann nicht die Ursache sein, da der Fehler bei mir auch nach einem Reboot und mit root Rechten auftritt.
    Mit ProgSPI lässt sich die 0.2 devel nicht flashen, da die 0.2devel Firmwaredatei nicht akzeptiert wird !


    Vorteil dieser neuer Version wäre nämlich, dass man selbst die Firmware modifizieren könnte: fastoff und eigenes Bild ließen sich sicherlich einbauen ... man muss sich "nur mal" in die Sourcen einarbeiten ;D .

    Hallo fretti


    das heisst, der Verbindung zu Amarok hat schon funktioniert, aber das Anlegen des SQLCaches im Verzeichnis [HOME]/.vdramgw/ ist fehlgeschlagen. Eventuell existiert die env Variable HOME nicht oder keine Schreibrechte.


    Mal ein

    Code
    1. env |grep HOME

    versuchen



    Mit vdramgw -C sollte man den Pfad ändern können. (Tipp: vdramgw --help)


    Ich hoffe du kommst damit weiter.


    Grüsse,
    irimi

    Hallo vdr-Gemeinde,


    zum neuen Jahr 2007 habe ein kleines Update des o.g. Plugins zur Verfügung gestellt :lachen3 !


    Zu finden auf


    irimi.host.de


    Verbesserungen:


    - die SQL Abfrage wurde mit Hilfe von Cachefiles auf Gateway Seite erheblich beschleunigt !
    - ein paar kosmetische Änderungen


    Achtung: Das Konfigurationsfile

    Code
    1. vdramgw.conf


    wird nun per default unter

    Code
    1. ~/.vdramgw/vdramgw.conf


    gesucht bzw. neu angelegt, falls jemand die default settings wie User, passwd, port, ... geändert haben sollte.


    Ansonsten alles wie gehabt:


    supported amaroK features
    ======================
    * Playlist view:
    show current playlist of amaroK and active track
    play , stop desired track of current play list
    * Track view:
    show current tracks informations: artist, title, track statistics etc.
    * Edit amaroK's playlst:
    remove single tracks, shuffle playlist, clear playlist
    * amaroK database query:
    add tracks to current playlist by artists/album and resp. or genre/artists
    * amaroK smart lists
    create new playlist: last played, 50 random tracks, never played, ...
    * graphlcd "support"


    Viel Spaß !
    irimi

    Quote

    Original von Soulreaver
    amarokData.h:172: error: extra qualification 'AmarokPlaylist::' on member 'getListSize'
    amarokData.h:215: error: extra qualification 'AmarokQueryResultItem::' on member 'getSubItemSize'
    amarokData.h:258: error: extra qualification 'AmarokQueryResult::' on member 'getListSize'


    Gibts dazu irgend welche Ideen??


    Sorry für die späte Antwort, habe dein Posting erst eben gesichtet.


    Hmm, da ist noch ein Copy-Paste Fehler drin, der sich wohl erst mit gcc4.1 bemerkbar macht. ?(


    Einfach in amarokData.h in den o.g. Zeilen den jeweiligen Klassenbezeichner löschen, also "AmarokPlaylist::" "AmarokQueryResultItem::" und bzw. "AmarokQueryResult::".


    [edit]: Korrekturversion als Attachment hinzugefügt


    Grüße,
    irimi

    Hallo,


    habe bei meinem ausgeführtem Plugin (amaroK) das Problem, dass beim Drücken der Pause Taste der Live Video Capture aktiviert wird !


    Eigentlich sollte das Abspielen der Musik angehalten werden. Beim debuggen habe ich herausgefunden, dass diese Aktivierung merkwürdiger weise aktiviert wird (vdr1.4.0) BEVOR in meinem Plugin die Methode ProcessKey(eKeys key) aufgerufen wird, es also einen anderen Mechanismus für die Tasten gibt !?


    Wie kann ich nun die Pause Taste mit der von mir gewünschten Funktion versehen (ohne Live Capture). Ein kleiner Hinweis auf den Code eines anderen Plugins würde mir schon helfen.


    Danke,
    irimi

    Ja wohl nicht einfach immer hinterher zukommen: das im gentoo.de overlay -r2 geht leider nicht mehr, da der patch57 inzwischen auf keinem ftp server mehr vorhanden ist.


    Bin nämlich gerade dabei nach meinem Urlaub ein paar Updates zu installieren....