Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: VDR Portal. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

21

Montag, 11. April 2011, 21:34

Hi,

Habe hier auch einen SPF-87-H und komme einfach nicht richtig in laufen.
Auf meinen beiden (yavdr 0.3a und Kubuntu 10.10) Systemen taucht der Rahmen unter lsusb nur auf, wenn ich ihn in den Massenspeichermodus schalte. Auch unter Windows ist der Frame Manager dauernd inaktiv. Ich denke also, dass ich etwas grundlegend falsch mache, nur was?
Habt Ihr mal nen Tritt in die richtige Richtung?

Mein Endziel ist GraphTFT unter yavdr 0.3a zu betreiben.

Gruß

Joachim
Registrieter VDR User Nr. 1237

Derzeit kein VDR, wegen Sky Pairing. ;(

22

Mittwoch, 13. April 2011, 10:10

So. Ich hatte ein Brett vorm Kopf. Das SPFtool läuft jetzt auf meinem yaVDR mit der udevregel und ich kann per playusb Bilder auf das Display schieben. Jetzt bleibt nur noch das Problem unter yaVDR GraphTFT zu patchen ohne mir die ganze Installation zu zerhauen.

Allerdings habe ich nosh eine andere Frage an die Programmierer: Glaubt Ihr es wird mit dem Display jemals eine automatische Lösung möglich sein, bei der ich das Display nicht anschalten und in den Mini-Monitor-Modus versetzen muss?

Joachim
Registrieter VDR User Nr. 1237

Derzeit kein VDR, wegen Sky Pairing. ;(

23

Freitag, 29. April 2011, 15:51

Hallo Andi,

vielen Dank für das super Tool. Habe hier ein verstaubtes SPF-83H wieder
vorgekramt und es funktioniert , zumindest JPEGs konnte ich schon
erfolgreich anzeigen lassen :-)

hier mein Eintrag in der playusb.h

{
.name = "Samsung SPF-83H",
.vendorid = 0x04e8,
.productid_massstorage = 0x200c,
.productid_photo = 0x200d,
.xres = 800,
.yres = 600,
},


Wie das mit dem graphTFT plugin läuft hab ich noch nicht begriffen.
Muss das plugin zwingend gepatched werden ? Hab hier die yaVDR
Pakete am laufen und will ungern daran rumfummeln.

bis denn

Andreas

24

Samstag, 30. April 2011, 09:30

Hallo Andi,

ich habe nun einige Zeit versucht den framebuffer anzusprechen, leider ohne Erfolg.

So bin ich vorgegangen:

- das Kernel-Modul habe ich gebaut und mittels dem beigefügten load script geladen

make -C /lib/modules/2.6.38-8-generic/build M=/home/andreas/build/spfb modules
make[1]: Betrete Verzeichnis '/usr/src/linux-headers-2.6.38-8-generic'
CC [M] /home/andreas/build/spfb/spfb.o
Building modules, stage 2.
MODPOST 1 modules
WARNING: modpost: Found 1 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
CC /home/andreas/build/spfb/spfb.mod.o
LD [M] /home/andreas/build/spfb/spfb.ko
make[1]: Verlasse Verzeichnis '/usr/src/linux-headers-2.6.38-8-generic'



- zuerst hab ich versucht per sudo cat /dev/urandom > /dev/fb1 etwas in den framebuffer zu
schreiben um es dann per playusb ausgeben zu lassen. Das funktioniert leider nicht, da
cat auf das fb1 device nicht funktioniert und hängenbleibt.

- hab dann das fbv tool besorgt und versucht mit diesem tool was in das fb1 device
zu schreiben aber mit dem selben Ergebnis wie mit dem cat Befehl.

Mir scheint das framebuffer device bzw. das Modul funktioniert nicht korrekt auf meiner
Maschine.


Kannst du mir einen Tip geben wie ich hier weiterkomme ?

Danke

Andreas

25

Samstag, 30. April 2011, 09:47

sudo cat /dev/urandom > /dev/fb1

So kann das ja auch nicht funktionieren - wenn du es so aufrufst gilt das sudo nur für cat, nicht für die Umleitung der Ausgabe.
Sieh dir mal den entsprechenden Abschnitt zu sudo mit Umleitungen an.
Denkbar wäre z.B. sudo bash -c "cat /dev/urandom > /dev/fb1"
yaVDR-Doku

Meine VDRs

VDR 1: Point of View Ion-330-1 (Intel Atom 330@1,6 GHz). 2GB, 4TB HDD, KNC One DVB-C, Sundtek MediaTV Pro (DVB-C), Atric IR-Einschalter Rev.5, yaVDR 0.6 testing
VDR 2: Acer Revo 3610, 4GB Ram, 1x HDD 320 GB, Pinnacle PCTV SAT 452e, Medion X10, YaVDR 0.5 testing
VDR 3: Intel DH67BL, Celeron 540, 4 GB Ram, POV Geforce 210 512 MB, 500 GB, DD Duo-flex CT, Arch LInux, VDR 2.2.0, CIR-Empfänger
Client 1: Raspberry Pi Model B, Arch Linux ARM, VDR 2.2.0
Client 2: Raspberry Pi 2, Arch Linux ARM, VDR 2.3.1
vdr-epg-daemon + MariaDB auf Cubietruck mit 32 GB SSD, Arch Linux ARM, optional Sundtek MediaTV Pro III + VDR 2.2.0
Ceterum censeo enchiridia esse lectitanda.

26

Samstag, 30. April 2011, 15:38

Hallo seahawk1986,

danke für deine Antwort, allerdings ändert das auch nichts.
Egal wie ich es mache, versuche ich etwas in das fb device
zu schreiben so hängt sich der Vorgang auf ( keine Rückkehr
zu shell , kein CTRL-C nicht mal kill hilft)

bis denn

Andreas

27

Donnerstag, 15. Dezember 2011, 18:46

Python-only

Falls noch von Interesse: das Ganze geht auch mit reinem Python.

siehe http://pyframe.blogspot.com/

28

Donnerstag, 15. Dezember 2011, 19:20

aber doch immer noch nicht ohne den Bildschirm nach dem Einschalten von Hand in den richtigen Mode zu bringen, oder?
CKone: yavdr 0.6pre/2.2.0 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 700, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
CKtwo: yavdr 0.6pre/2.2.0 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 700, atric USB
PowerEdge: Ubuntu Server 16.04 LTS auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, Digital Devices MaxS8, Samsung 840 EVO 120GB, 3x WD Red WD30EFRX 3TB in SW Raid5

29

Freitag, 16. Dezember 2011, 13:38

Das automatische Einschalten ist keine Funktion der verwendeten Programmiersprache, sondern durch die Hardware, genauer die Firmware, des SPF-87H bedingt. Die Firmware meines Rahmens nach Update ist 1007.0

Zum Einschalten des Rahmens reicht es nicht, ihn an eine Stromversorgung (Netzteil oder USB Kabel) zu hängen. Man muss erst noch von Hand einschalten. Danach ist der Rahmen aber noch nicht am USB Bus angemeldet, und das Betriebssystem - weder Linux noch Windows - kann ihn erkennen. Wenn der Rahmen am USB Kabel hängt, erscheint nach einem Moment eine Dialogbox auf dem Rahmen, mit der zwischen Massenspeicher, Mini Monitor und Bilderrahmen gewählt werden kann. Wählt man Bilderrahmen, so bleibt er weiterhin unsichtbar für den Computer, da der Rahmen sich nicht am USB Bus anmeldet. Dadurch hat der Computer keinen Zugriff auf den Rahmen.

Wählt man eine der beiden anderen Optionen, so findet die USB Anmeldung statt, und er ist mit der jeweiligen idVendor, idProduct Kennung sichtbar. Unter Windows, wenn der Samsung Frame Manager installiert ist, kann man damit zwischen Massenspeicher und Mini Monitor hin und her schalten. Das würde unter Linux auch gelingen, wenn der Control Code dafür bekannt wäre.

Wenn mir den jemand nennen könnte, wäre das schnell zu programmieren.

30

Samstag, 17. Dezember 2011, 12:58

Auf Anregung von killerhippy hier der Python Teil eines Transfergeschwindigkeits Vergleichs zwischen Python Script und C Programm.

Ich habe zwei sehr unterschiedliche Bilder im Script geladen, aufbereitet, und in einer Schleife die Daten abwechselnd zum Rahmen geschickt. Ein Paar Bilder war einfach und klein (<<16384 Bytes), ein weiteres komplex und daher gross (ca 100kB nach Schrumpfen auf 800x480). Alle Bilder angehängt. Auf dem Rahmen war nur noch ein Flackern zu sehen. Die CPU Last lag bei nur 1-2%. Hier die Daten:

Bilder_____________ BildGröße(B) _______Bilder/sek ___Gesamt Transfer MB/sec
red.jpg/blue.jpg __ 6631/2536 _________ 28 ___________ 0.46
i244,jpg/i247.jpg _ 98792/123768_____ 16 ___________ 1.93

Bei den kleinen Bildern wird sehr viel Ballast mit transferiert, da mindestens ein Chunk von 16384 Bytes übertragen werden muss. Allgemein sollten 20+ Bilder/sec möglich sein. Der USB Bus kann gut das 10fache übertragen, die CPU ebenso - der Rahmen scheint das Limit zu setzen.

Spasseshalber habe ich einen Video Clip per ffmpeg in Einzelbilder zerlegt, und versucht, diese Einzelbilder als schnelle Sequenz am Rahmen anzuzeigen. Mit keinem (!) der Bilder gelang dies, obwohl jedes in jedem Bildbetrachter korrekt angezeigt wurde. Auch diverse Permutationen der ffmpeg Parameter brachten keinen Erfolg. Erst Einlesen und Neuschreiben mit dem Python IMAGE Modul mit diesem Code resultierte in anzeigbaren Bildern:

Quellcode

1
2
3
4
import Image
filename = "bild.jpg" 
image = Image.open(filename)
image.save( "neu" + filename, "JPEG", quality=95)


Danach ist aus dem "Bilderrahmen" ein "Videorahmen" mit flackerfreien knapp 26 Bildern/sec (1.7 MB/sec) geworden. Einlesen der Bilder von einer schnellen SSD brachte keine schnellere Übertragung, was wiederum für den Rahmen als Flaschenhals spricht.

Jetzt bin ich mal auf die C Programm Ergebnisse gespannt 8) . Python Testprogram (pyframe_tspeed.txt) ebenfalls angehängt.
»ullix« hat folgende Bilder angehängt:
  • red.jpg
  • blue.jpg
  • i244.jpg
  • i247.jpg
»ullix« hat folgende Datei angehängt:

31

Montag, 23. Januar 2012, 22:32

Hallo,

habe versucht das spf87h-tool Programm zu kompilieren. Habe dazu den Code im Verzeichnis /usr/src/spf87h-tool-v0.01 abgelegt.

Bekomme aber immer die Meldung fatal error: usb.h: Datei oder Verzeichnis nicht gefunden. Habe in meiner unwissenden Verzweiflung schon eineauf der Platte gefundene
Header-Datei ins gleiche Verzeichnis kopiert hat aber auch nichts gebracht.

Was mach ich da falsch.

Gruß Sindbad6
yavdr 0.5 mit XBMC Frodo 12.2 auf: JCP MI-101, ASUS AT3N7A-I, WD10EADS, HL GSA-H31N, Hauppauge HVR-4000, Mushkin 2 x 1024 MB, über HDMI an TV: Panasonic TX-37LZD85F

32

Montag, 23. Januar 2012, 23:05

Mal wild geraten "apt-get install libusb-dev"?

cu

Mein VDR

Mein VDR
Digitainer2xBouget DVB-SDebian Squeeze (Kernel 2.6.35.3 von kernel.org)Softdevice Ausgabepluginvdr 1.6.0-3 (Extensions Patch 72) und viele Plugins von SourceMedion X10 FernbedienungSDC-Megtron Display (240x128x1) mit GraphLCD-PluginFreevo 1.9.0
Vodcatcher Helper in ein freundliches DEB verpackt, Tester Willkommen: http://dl.dropbox.com/s/705bh6ydgisfrqu/index.htmlFingerprint: 8A104A00D5031773A9F72A19BAEE135EA7860149

33

Montag, 23. Januar 2012, 23:23

Mal wild geraten "apt-get install libusb-dev"?

cu

Tja, jetzt vermisst er libusb-1.0/libusb.h

Ich bin echt Ahnungslos
yavdr 0.5 mit XBMC Frodo 12.2 auf: JCP MI-101, ASUS AT3N7A-I, WD10EADS, HL GSA-H31N, Hauppauge HVR-4000, Mushkin 2 x 1024 MB, über HDMI an TV: Panasonic TX-37LZD85F

34

Sonntag, 12. Februar 2012, 12:45

Hi,

Quellcode

1
apt-get install libusb-1.0-0-dev


Wenn etwas fehlt, libjpeg, libpng z.B., die developer Pakete nachinstallieren. Die Namen der fehlenden Pakete werden ja direkt angezeigt..

Quellcode

1
2
Edit:
Hat sich erledigt! Wer lesen kann....


Der Fehler:

Quellcode

1
Error while writing to USB device. Please check your system rights.

waren bei mir falsche Rechte der Dateien. Sie waren root.src und muessen root.root sein, bzw mit chmod angepasst werden.

Danke und Gruss...

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »blogga« (12. Februar 2012, 12:59)


35

Montag, 13. Februar 2012, 10:44

Nach den Hinweisen von blogga habe ich jetzt das spf-tool und auch playusb kompilieren können.
Für das spf-tool habe ich eine eine udev-Regel erstellt.

Jetzt fehlt mir noch ein Hinweis wie ich playusb einsetze um etwas auf dem Monitor anzuzeigen.
Irgendwie stehe ich im Wald. Anschließend steht dann wohl GraphTFT an.

Ziel ist letztendlich XBMC über den Monitor bedienen (Bilder, Musik, Wetter, etc.) zu können.

Versuche mich da schrittweise ran zu tasten.

Gruß Sindbad6
yavdr 0.5 mit XBMC Frodo 12.2 auf: JCP MI-101, ASUS AT3N7A-I, WD10EADS, HL GSA-H31N, Hauppauge HVR-4000, Mushkin 2 x 1024 MB, über HDMI an TV: Panasonic TX-37LZD85F

36

Montag, 13. Februar 2012, 22:17

Hi,

ich hab folgende /etc/udev/rules.d/11photoframe.rules

Quellcode

1
2
SUBSYSTEMS=="usb", ACTION=="add", ATTR{idVendor}=="04e8", ATTR{idProduct}=="2035", RUN+="/usr/local/bin/usbmonitor.out"
#SUBSYSTEMS=="usb", ACTION=="add", ATTR{idVendor}=="04e8", ATTR{idProduct}=="2036", RUN+="/usr/local/bin/playusb -f /dev/fb1 -i 1000 &"


Allerdings hab ich jetzt probleme playusb am yavdr0.4 zu compilen. Sind zwar nur warnungen, aber der Task haengt sich dann auf.

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
root@vdr-1:~# cd /usr/src/playusb
root@vdr-1:/usr/src/playusb# make clean
rm -rf *o playusb
root@vdr-1:/usr/src/playusb# make
gcc -Wall -O2 -funsigned-char -lrt -lusb -ljpeg -c playusb.c
gcc -Wall -O2 -funsigned-char -lrt -lusb -ljpeg -c fbgrab.c
fbgrab.c: In function ‘Write_JPG’:
fbgrab.c:269:16: warning: pointer targets in assignment differ in signedness
fbgrab.c: At top level:
playusb.h:61:12: warning: ‘num_frames’ defined but not used
fbgrab.c: In function ‘read_fb’:
fbgrab.c:154:1: warning: control reaches end of non-void function
gcc -Wall -O2 -funsigned-char -lrt -lusb -ljpeg playusb.o fbgrab.o -o playusb
playusb.o: In function `main':
playusb.c:(.text+0x7c6): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
root@vdr-1:/usr/src/playusb#


Ein Pointer wird in einer Schleife auf die aktuelle Bild-Zeile gesetzt. Ich denke dabei geht irgendwas schief..
Der Teil der Funktion Write_JPG in fbgrab.c

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
.
.
.      
JSAMPROW row_pointer[0];                                /* pointer to a single row */
.
.
.
while (cinfo.next_scanline < cinfo.image_height)
        {
        row_pointer[0]= pict->buffer + (cinfo.next_scanline * row_stride);
        ret = jpeg_write_scanlines(&cinfo, row_pointer, 1);
        }


Das Device /dev/fb1 existiert. Was ist hier falsch? Vielen Dank schon mal...

Quellcode

1
2
3
4
5
6
7
8
root@vdr-1:/usr/src/playusb# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/x86_64-linux-gnu --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)

37

Donnerstag, 18. Oktober 2012, 11:31

Erstmal Danke für euren Support mit den Programmen SPFB und PLAYUSB. Ich verwende diese schon seit längerem mit meinem yaVDR und bis jetzt hat es auch immer wunderschön funktioniert. Nach dem Upgrade auf eine SSD hab ich das System um einiges beschleunigen können, jedoch kommt es öfters vor, dass das Laden der SPFB Modulen im Skript zu lange braucht und dadurch der VDR nicht mehr starten kann. Aus diesem Grund würde ich gerne das Laden von den einzelnen SPFB Modulen schon beim Kenerlstart erledigen.

Ich habe alle nötigen Module in /etc/initramfs-tools/modules eingetragen und das spfb.ko nach /lib/modules/2.6.38-16-generic/kernel/drivers/video/ kopiert (Verzeichnis des aktuellen verwendeten Kenerls). Zusätzlich habe ich noch update-initramfs -u
-k all
ausgeführt. Nachdem System Neustart habe ich mittels lsmod alle benötigten Module bis auf das spfb Modul gefunden. modprobe -l findet das Modul spfb auch nicht. Was muss ich noch beachten, wenn ich ein eigenes Modul über diese Methode starten möchte? Reicht ein einfaches kopieren des Moduls in den Ordner nicht aus?

VDR: yaVDR0.4, AMD Athlon X2 240e, Asus M4N78-VM, Kingston HyperX Kit 2x1GB RAM, OCZ
Agility 3 60GB
SystemHDD + WD Caviar Green 2TB StorageHDD, 2x SATELCO EasyWatch PCI DVB-C, Atric Rev.5, Blu-Ray Player Samsung SH-B083L, Samsung SPF-87H, be quiet! Pure Power 350W ATX 2.3

38

Donnerstag, 14. Februar 2013, 22:11

Help, noob at work

Hallo Community

Ich versuche das spftool zu kompilieren, aber er endet mit:
collect2: Fehler: ld gab 1 als Ende-Status zurück
make: *** [spf87h-tool] Fehler 1
und macht mir nur die spf87_tool.o

Habt irgendwer eine Idee, woran das liegt?

Ich möchte diesen Monitor unbedingt verwenden können, wäre eine grosse Hilfe

39

Donnerstag, 14. Februar 2013, 22:24

Ich versuche das spftool zu kompilieren, aber er endet mit:
collect2: Fehler: ld gab 1 als Ende-Status zurück

Aber das ist doch viel zu spät, die Ursache für diesen Fehler muss vorher gestanden haben.

Gerald

HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
Samsung UE55H6470

40

Donnerstag, 14. Februar 2013, 22:28

Sorry!

Hier der ganze Text vom Terminal:
gcc -Wall -O2 -lusb-1.0 -c spf87h-tool.c
spf87h-tool.c: In Funktion »main«:
spf87h-tool.c:124:6: Warnung: Variable »actual_length« gesetzt, aber nicht verwendet [-Wunused-but-set-variable]
gcc -Wall -O2 -lusb-1.0 spf87h-tool.o -o spf87h-tool
spf87h-tool.o: In function `find_spf':
spf87h-tool.c:(.text+0x35): undefined reference to `libusb_get_device_descriptor'
spf87h-tool.c:(.text+0xfb): undefined reference to `libusb_free_device_list'
spf87h-tool.c:(.text+0x107): undefined reference to `libusb_exit'
spf87h-tool.o: In function `main':
spf87h-tool.c:(.text.startup+0x1c): undefined reference to `libusb_init'
spf87h-tool.c:(.text.startup+0x3a): undefined reference to `libusb_set_debug'
spf87h-tool.c:(.text.startup+0x4e): undefined reference to `libusb_get_device_list'
spf87h-tool.c:(.text.startup+0x7c): undefined reference to `libusb_open'
spf87h-tool.c:(.text.startup+0x9a): undefined reference to `libusb_claim_interface'
spf87h-tool.c:(.text.startup+0x119): undefined reference to `libusb_control_transfer'
spf87h-tool.c:(.text.startup+0x16a): undefined reference to `libusb_control_transfer'
spf87h-tool.c:(.text.startup+0x1b7): undefined reference to `libusb_control_transfer'
spf87h-tool.c:(.text.startup+0x1f8): undefined reference to `libusb_release_interface'
spf87h-tool.c:(.text.startup+0x204): undefined reference to `libusb_close'
spf87h-tool.c:(.text.startup+0x218): undefined reference to `libusb_free_device_list'
spf87h-tool.c:(.text.startup+0x224): undefined reference to `libusb_exit'
spf87h-tool.c:(.text.startup+0x2e1): undefined reference to `libusb_detach_kernel_driver'
spf87h-tool.c:(.text.startup+0x322): undefined reference to `libusb_claim_interface'
spf87h-tool.c:(.text.startup+0x3b9): undefined reference to `libusb_free_device_list'
spf87h-tool.c:(.text.startup+0x3c5): undefined reference to `libusb_exit'
spf87h-tool.c:(.text.startup+0x477): undefined reference to `libusb_free_device_list'
spf87h-tool.c:(.text.startup+0x483): undefined reference to `libusb_exit'
collect2: Fehler: ld gab 1 als Ende-Status zurück
make: *** [spf87h-tool] Fehler 1

Immortal Romance Spielautomat