Details

Erstellt: 25. September 2010

Zuletzt aktualisiert: 29. August 2012

Zugriffe: 6436

Hier folgt ein kleiner Test von USB-Sticks und einer älteren SATA-Festplatte im mit USB 3.0 Adapter.

Testumgebung

• Dell Dimension 9200 mit USB 2.0
• USB 3.0 PCIe Karte von Exsys EX-11092

Testobjekte

• Corsair Flash Voyager GT 16G
• Kingston DataTraveler Ultimate 3.0 16GB
• NoName USB-Stick 2GB
• WDC WD12 00BEVS-22LAT0 120GB (im Fantec USB 3.0 Gehäuse)

Testaufbau

• USB 2.0 wurde am vorderen USB Port getestet. Sonst war vorne nichts angeschlossen.
  (Hinweis: Wenn andere USB-Geräte am selben Hub angeschlossen sind, werden die Geschwindigkeiten um bis zu 30 % verfälscht.)
• USB 3.0 mit der Exsys-Karte und USB 3.0-Verlängerungskabel mit 3 Metern Länge.

Testergebnisse

Fazit

Corsair:

Mein bisheriger Corsair ist zwar sehr schnell bei großen Dateien, ist aber bei kleinen Blockgrößen sehr langsam.
Das merkt man auch im täglichen Gebrauch. Videos oder MP3 schreiben geht schnell, mit Portable-Thunderbird ist der Zugriff sehr lahm.

DataTraveler:

Er ist sehr sehr schnell bei großen Dateien und sehr schnell bei kleinen Dateien.
Er funktioniert bei meinem System ohne das Y-Kabel, welches für den höheren Strombedarf beigelegt war, sowohl am Computer direkt am Port als auch über einen Belkin Hub.

Er wird entsprechend der Geschwindigkeit sehr warm.

Details

Erstellt: 07. Juni 2010

Zuletzt aktualisiert: 29. August 2012

Zugriffe: 5968

Ramdisk

Damit der Standby-Modus auch genutzt werden kann, sollte nicht unnötig mit der Festplatte gearbeitet werden.
Das Script XXX legt dazu eine Ramdisk an. Es werden die Log-Dateien kopiert und der Originalpfad auf die Ramdisk umgebogen.

mkdir /mnt/ram
mke2fs /dev/ram1
mount /dev/ram1 /mnt/ram

mkdir /mnt/ram/logs
cp /mnt/MDA_DATA/logs/ /mnt/ram/logs/

mkdir /mnt/ram/bin
cp qnaplog /mnt/ram/bin/qnaplog

ACHTUNG: Da die Ramdisk beim Reboot verloren geht, sind natürlich auch die aktuellen Log-Dateien weg. Da diese aber nicht wichtig sind, ist das mir egal.

Eclipse und Qnap

Irgendwie gibt es Probleme, wenn ein Projekt auf dem Qnap angelegt wird. Aus einem C++-Projekt wird nach einem erneuten öffnen dann ein normales Projekt.

Es erscheint in der Datei ".project" folgendes:

	<?xml version="1.0" encoding="UTF-8"?>
	<projectDescription>
	<name>lcd4linux-0.10.1-RC2</name>
	<comment></comment>
	<projects>
	</projects>
	<buildSpec>
	</buildSpec>
	<natures>
	</natures>
	</projectDescription>
	

anstatt das erwartete:

	<?xml version="1.0" encoding="UTF-8"?>
	<projectDescription>
	<name>lcd4linux-0.10.1-RC2</name>
	<comment></comment>
	<projects>
	</projects>
	<buildSpec>
	</buildSpec>
	<natures>
		<nature>org.eclipse.cdt.core.cnature</nature>
		<nature>org.eclipse.cdt.make.core.makeNature</nature>
		<nature>org.eclipse.cdt.make.core.ScannerConfigNature</nature>
		<nature>org.eclipse.cdt.core.ccnature</nature>
	</natures>
	</projectDescription>
	

Genannte Marken oder Produktnamen sind Warenzeichen oder eingetragene Warenzeichen der jeweiligen Eigentümer.

Details

Erstellt: 07. Juni 2010

Zuletzt aktualisiert: 30. August 2012

Zugriffe: 10960

Ein kleines Status-Display am Qnap ist eine schöne Sache.

Benutzt wurde der Sourcecode von serdisplib und
Die Sourcen basieren auf 'Serdisplib' Version 1.97.8 und 'lcd4linux' Version 0.10-RC2. Die Abhängigkeiten sind 'libgd' für Grafiken und 'libusb' für den Treiber.

Beide Packete wurden erweitert (siehe später unter Patch), auf dem Qnap compiliert und anschließend die Packages für IPKG erzeugt.

Beispiele für den Aufruf sind unter '/opt/doc/serdisplib' zu finden. Einfach mal das Testprogramm 'testserdisplib' aufrufen.
Evt. wird hier eine fehlende Libusb angemeckert. Dies habe ich folgendermaßen umgangen:

        - die Datei 'ld.so.conf' im Verzeichnis '/etc' um eine Zeile mit /opt/lib erweitern und speichern
        - anschließend 'ldconfig' aufrufen

Hierdurch kennt das System dann den zusätzlichen Pfad für die Libraries.
Die Dateien werden nach einem Reboot wieder durch die Originale ersetzt. Daher rufe ich beim Neustart immer ein entsprechendes Script auf.

Änderungen und compilieren von Serdisplib

Diese Anleitung bezieht sich auf Version 1.97.8.

Bei ./configure kam die Fehlermeldung:

        checking how to run the C preprocessor... /lib/cpp
        configure: error: C preprocessor "/lib/cpp" fails sanity check

Nach langem Recherchieren, war ich der Meinung, dass eigentlich schon alles auf dem Qnap installiert ist. Daher habe ich die Checks in der Datei "configure" einfach übersprungen. (Vorher die Datei sichern!)
In meiner configure waren die Checks an diesen Stellen:

        # Double quotes because CPP needs to be expanded
        for CPP in "$CC -E" "$CC -E -traditional-cpp" "/lib/cpp"
        do
                ac_preproc_ok=: false

Ich habe dann einfach die Zeilen mit

        ac_preproc_ok=: false

durch

        ac_preproc_ok=:

ersetzt.

Wenn nur der gcc 3.xx installiert ist, wird noch die Datei syslimits.h gefordert. Diese habe ich aus einem Package des gcc 4.xx und in das Verzeichnis

        /opt/lib/gcc/arm-none-linux-gnuabi/3.4.4/include

kopiert. Die Datei ist hier.

Evt. wird noch ein Problem mit der libpthread.so.0 gemeldet.
Hier habe ich einfach den Symlink geändert und auf /lib/libpthread-0.10.so zeigen lassen.

Evt. wird noch eine fehlende Libusb angemeckert. Dies habe ich folgendermaßen umgangen:

        die Datei 'ld.so.conf' im Verzeichnis '/etc' um eine Zeile mit /opt/lib erweitern und speichern
        anschließend 'ldconfig' aufrufen

Hierdurch kennt das System dann den zusätzlichen Pfad für die Libraries.
==> Die Dateien werden nach einem Reboot wieder durch die Originale ersetzt. Daher rufe ich beim Neustart immer ein entsprechendes Script auf.

Beim compilieren von serdisplib wurden folgende Schritte durchgeführt:

        ./configure --enable-libusb --with-lm4 --with-alphacool
        make

Auch wenn im Netz steht, dass libusb nicht angegeben werden muss; dies stimmt nicht. In 'configure' ist es standardmäßig deaktiviert.

Mit dieser Standard-Library funktioniert das Alphacool einwandfrei.

Nur das L4M132C funktioniert nicht mit dem original Serdisplib auf dem Qnap. Hier wird auf das HID Device zurückgegriffen, da unter Linux wohl die Libusb nicht mit Cypress-Chips zusammen arbeiten soll.
Auf meinem Qnap gibt es aber ein Problem mit dem HID Queue (etc.). Dieser läuft wohl beim Ansprechen des Displays immer über.
Daher habe ich die Sourcen von 'serdisplib' etwas verändert, damit wieder Libusb als Treiber für das L4M132C benutzt werden kann.
Zusätzlich ist für den Display-Bug des L4M132C eine Kommunikations-Wiederholung eingebaut worden. Siehe weiter unten.
Die geänderten Sourcen können hier heruntergeladen werden

Anschließend:

./configure --enable-libusb --with-lm4 --with-alphacool
make

Erweiterungen und compilieren von lcd4linux

Diese Anleitung bezieht sich auf Version 0.10-RC2.

Zum compilieren von lcd4linux müssen die Headerdateien von serdisplib (im Verzeichnis include/serdisplib) in das Verzeichnis /opt/include/serdisplib kopiert werden.

Bei ./configure kann entweder Fehlermeldung "Segmentation fault" oder auch diverse Sonderzeichen (z.B. %) angemeckert werden.
Bei "Segmentation fault" waren es Einschränkungen der Programme egrep, fgrep, grep.
Bei den Sonderzeichen waren es Einschränkungen des Programms sed.

Diese Programme habe ich durch vollwertige aus dem IPKG-Packages ersetzt.

Anschließend:

./configure
make

Die Änderungen an lcd4linux betreffen ein neues Plugin.
Das Plugin qnaplog liest den letzten Eintrag aus der conn.log oder vent.log per sqlite3 aus.

Mehr Beschreibungen dazu auf der Seite von

Zusätzlich ist für den Display-Bug des L4M132C eine Fehlererweiterung zum serdisplib eingebaut worden. Siehe weiter unten.

Die geänderten Sourcen können hier heruntergeladen werden

Die Funktion wurde für folgende Displays getestet:

Probleme mit L4M132C

Das L4M132C lief bisher mit lcd4linux max. 2 Tage durch. Das Display stürtze immer wieder ab (teilweise bunte horizontale Striche im Display), und musste dann ab- und angesteckt werden.
Es scheint an der Softwareversion des Display zu liegen (Pufferüberlauf o.ä.); da selbst ein Reboot vom Qnap das Display nicht neu erweckt. Es muss immer ab- und angesteckt werden.

Hier habe ich inzwischen einen Workaround mit Hardware- und Softwareänderungen.
Die Hardware besteht aus einem Watchdog-Baustein MAX1232. Dieser wird bei einem normal laufenden Display regelmäßig getriggert.

Stürzt es mal wieder ab, kommt nur noch ein Rechtecksignal mit ca. 794Hz. Durch den einfachen Tiefpass kommt am MAx kein Triggersignal mehr an und es wird nach ca. 1.2 Sekunden ein Reset für das Display ausgelöst.
Kann ich manchmal beobachten wenn ich danebensitze.

Die erweiterte Software serdisplib und lcd4linux versucht bei Kommunikationsfehlern (wenn gerade ein Neustart vom Display läuft) mehrmals wieder die Verbindung aufzunehmen. Dieses klappt fast immer. Vielleicht alle vier Monate muss ich per Hand die Software lcd4linux neustarten.

Software-Änderungen

Die geänderten Sourcen für serdisplib können hier heruntergeladen werden

Umbau L4M132C

     
Der MAX1232 wurde hier verkehrt herum aufgeklebt; also mit der Beschriftung nach unten.

Die anderen freigekratzten Pins sollten nicht irritieren. Dies war zum messen notwendig.

*1

Ich habe den entsprechenden Pin mit dem benötigten Triggerpuls durch langes ausprobieren heraus bekommen.
Dazu habe ich am funtionierenden Display alle PIN-Zustände des Prozessors mit einem Oszilloskop gemessen und alle Pins mit Impulsen aufgeschrieben.
Dann habe ich das Display mit sehr vielen Befehlen gestresst, bis es abgestürzt ist.
Jetzt nochmal alle PIN-Zustände des Prozessors gemessen.
Der Pin, der keine Impulse mehr geliefert hat war mein Favorit. In meinem Fall Pin 6 des Prozessors.

Nachtrag vom 2011.04.09

Der 1k Widerstand war falsch angegeben. Es muss ein 10k Widerstand sein.

Nachtrag vom 2011.04.14

Der 100nF Kondensator bildet mit dem 10k Widerstand einen Tiefpass. Mit meinem Display (Hardware V3.0 vom April 2009) funktioniert diese Kombination einwandfrei.

Bei anderen Displays ist es eventuell notwendig den Widerstand geringfügig zu verändern, bis das Display normal startet.

Weitere Fotos

Die USB Verbindung zum Display wurde direkt vom Frontstecker abgenommen. Dieser kann dann aber nicht mehr extern benutzt werden.




Durch das Blitzlicht ist hier das Innenleben zu erkennen. Eigentlich ist die Scheibe dunkelblau.

Genannte Marken oder Produktnamen sind Warenzeichen oder eingetragene Warenzeichen der jeweiligen Eigentümer.

Details

Erstellt: 06. Juni 2010

Zuletzt aktualisiert: 29. August 2012

Zugriffe: 17514

Ich wollte das Notebook/, welches bei mir als Webcam-Server dient über eine Solaranlage versorgen. Aus Effizienzgründen sollte die Versorgung direkt aus den 12V bis 13,8V des Akkus kommen. Es wird zuviel Leistung verschenkt wenn erst mit einem DC-AC Wandler auf 230V hochgeregelt wird, um daran das Original-Netzteil zu betreiben.
Dazu habe ich mir bei Reichelt das Universalnetzteil f. Notebook/s & PDAs, 12 -13,8V "NTS 70" (auf dem Netzteil steht "Vanson SDR-70W") besorgt. Die Spannung habe ich auf 19V eingestellt. Es kann ca. 3,9A liefern. Das ist etwas mehr als das Dell Netzteil und ist somit ausreichend.

Einen kleinen Hacken hat das ganze. Das Dell D600 Notebook/ hat einen speziellen Stecker mit drei Kontakten.
Das Notebook/ kann zwar über die beiden Versorgungspins mit 19.5V betrieben werden, aber der Akku wird nicht geladen.
Die Ladefunktion funktioniert nur mit einem original Dell-Netzteil. Dieses identifiziert sich über den Datenpin beim Notebook/ als Original. Weitere Informationen sind hier verfügbar.

Äussere Wandung ist GND, innere Wandung ist 19.5V, mittlerer Pin ist spezieller Datenpin.

Da ich das Notebook/ sowohl mit dem Dell-Netzteil als auch mit dem DC-DC-Wandler betreiben wollte, habe ich den Baustein (DS 2501) für die Identifizierung des Dell-Netzteils ausgebaut.
Es ist ein 1-Wire-Datenbaustein mit 512 Bytes.

ACHTUNG! Vor dem Eingriff in das Gerät immer erst den Netzstecker ziehen. VDE Bestimmungen beachten!

Bei nachfolgenden Schritten geht auf jeden Fall die Garantie verloren!

Um das Netzteil auseinander zu nehmen, müssen die beiden Halbschalen vorsichtig getrennt werden. Dazu habe ich einen Dremel mit einer dünnen Schleifscheibe verwendet. Vorsicht bei mittleren Vertiefung. Hier ist kein Abschirmblech vorhanden und Bauteile könnten beschädigt werden.

Das untere Abschirmblech hat auf der linken Seite zwei Lötungen.

Auf der Oberseite die beiden Schrauben lösen.


Der Baustein DS2501 ist hier zu finden. Die entsprechenden Lötpins sind markiert.


Das Niedervoltkabel vom Dell-Netzteil wurde vor dem Ferritkern abgeschnitten.


Das aufgetrennte Kabel hat folgende Belegung.

GND und 19.5V werden mit der Hohlstecker-Einbaubuchse verlötet.
Pin1 vom DS2501 wird mit GND verbunden, Pin2 mit den mitteleren Kabel vom abschnittenen Kabelende. Pin3 kann abschnitten werden, da er keine Funktion hat.




Das ganze mit Schrumpfschlauch überziehen.

Der fertige Adapter.


Inbetriebnahme mit Notebook/.