Jacobs UNIblog

ST STM32F4-Discovery mit Eclipse und gdb unter Mac OS X

admin — Sat, 10 Mar 2012 19:37:00 +0000

Hallo

heute gibt es mal einen längeren Artikel. Da ich auf der Embedded World 2012 einiges an Anschauungsmaterial bekommen habe, wollte ich mich weiter damit auseinandersetzen.

Eines der Objekte war das STM32F4-Discovery Board von ST Microelectronics. Diese liefern auch eine große Anzahl von Entwicklerwerkzeugen (Altium – TASKING VX-Toolset, Atollic – TRUEStudio, IAR – Embedded Workbench for ARM (EWARM), Keil – MDK-ARM, CrossTools – CrossWorks) mit, welche sich jedoch mit Ausnahme von Crossworks nur unter Windows nutzen lassen. Letztere ist jedoch nur für eine Anwendung von 30 Tagen kostenlos nutzbar.

Da ich jedoch unter Mac OS X (10.7 ‘Lion’ aktuell) arbeite, möchte ich darunter nativ arbeiten, was sich als ein großes Problem rausstellte. Aus diesem Grund habe ich mir ein wenig Zeit genommen um mir nach vielen Hindernissen eine lauffähige Kombination aus mehreren Tool zu einer kompletten Entwicklungsumgebung zusammen zu stellen.

Diese besteht aus:

Eclipse 3.7 ‘Indigo’, einer, wenn nicht DER IDE schlechthin. Dazu werden die C Development Tools (CDT) benötigt. Diese bekommt man entweder per “Help” > “Install New Software” wenn man Eclipse bereits installiert hat, oder aber lädt sie sich als Komplettpaket HIER runter.
summon-arm-toolchain – Einer GNU Toolchain für Crossdevelopment von ARM Systemen
stlink – einer Bibliothek für die Verbindung zwischen PC und dem STM32F4 Board

Außerdem werden folgende Tools benötigt:

XCode – die IDE von Apple, welche so ganz nebenbei alle Tools wie den GCC und MAKE usw. auf dem Mac installiert. XCode bekommt man im App Store oder unter https://developer.apple.com/technologies/tools/kostenlos.
Fink/Homebrew/MacPorts – dies ist eine Art Paketverwaltung für UNIX/Linux Tools, durch welche sich eben diese recht einfach auf dem aktuellen Mac System einrichten lassen. Ich persönliche habe MacPorts verwendet und werde mich in der Anleitung auch nur darauf beziehen. Für andere Systeme muss eventuell das ein oder andere Command angepasst werden.
git – ein Versionscontrollsystemclient

Einrichtung

Vorbedingungen

Zuerst muss Xcode installiert werden. Dazu muss dieses einfach nur von Apple heruntergeladen werden und die Package Datei installiert werden. Einfacher geht dies über den App Store. Nach der Installation befinden sich alle Tools zum Compilieren auf dem System.

Als nächstes müssen die MacPorts installiert werden. Einen Installer dazu bekommt man unter http://www.macports.org/install.php. Nach der Einrichtung öffnet man ein Terminal (Im Finder > Anwendungen > Dienstprogramme > Terminal oder ein anderes beliebiges Terminal, ich verwende iTerm 2) und installiert weitere Abhängigkeiten mit folgendem Befehl:

sudo port install gmp mpfr libmpc libusb git-core wget

Je nachdem welche weiteren Abhängigkeiten diese Pakete mit sich bringen, werden auch noch weitere Pakete installiert. Dies kann daher auch eine Weile dauern, bis alles installiert ist. Hierbei wird gleichzeitig der git Client installiert, welchen wir nun benötigen.

summon-arm-toolchain – Achtung nur für Mac OS

Wurde alles compiliert und installiert können wir nun die GNU Toolchain installieren. Damit werden automatisch folgende Pakete installiert:

binutils – Grundlage
gcc-arm – der Cross-Compiler für ARM Prozessoren
gdb-arm – der Gross-GDB-Debugger
newlib – die Standard-C-Library für embedded devices

Ich empfehle, diese nicht direkt in die Systemverzeichnisse zu installieren, da man so schnell den Überblick über seine installierten Toolchains verlieren kann. Ich habe mir in meinem Arbeitsverzeichnis (/Users/jack77) einen Ordner “Dev” angelegt, in welchen ich alles installiert habe. Erstellen beispielsweise über die Konsole:

cd ~

mkdir Dev

cd Dev

Jetzt holen wir uns zuerst den Toolchaininstaller von Github:

git clone -b patch-1  git://github.com/jack77er/summon-arm-toolchain.git

Das Ergebnis dazu sollte so aussehen:

Jacob-Maxas-MacBook-Pro:Dev jack77$ git clone -b patch-1 git://github.com/jack77er/summon-arm-toolchain.git
Cloning into summon-arm-toolchain...
remote: Counting objects: 315, done.
remote: Compressing objects: 100% (198/198), done.
remote: Total 315 (delta 148), reused 264 (delta 113)
Receiving objects: 100% (315/315), 60.98 KiB, done.
Resolving deltas: 100% (148/148), done.
Jacob-Maxas-MacBook-Pro:Dev jack77$ ls
summon-arm-toolchain

Nun installieren wir die Toolchain in unseren Dev Ordner bzw. in einen Unterordner sat. Dabei ist die Variable PREFIX noch an euren Unterordner anzupassen!

./summon-arm-toolchain/summon-arm-toolchain PREFIX=/Users/jack77/Dev/sat

Der Installer lädt sich nun alle benötigten Quellen runter und compiliert diese. Damit kann man seinen Rechner dann getrost 30 min rechnen lassen. Wichtig: Die Toolchain ist aktuell nur für Cortex-M3 Kerne optimiert und nutzt daher nicht die FPU des Cortex-M4. Ich arbeite dran.

stlink

Entweder man wartet bis die Toolchain fertig ist, oder man arbeitet jetzt parallel weiter. Steht einem frei.

Als nächstes wird die stlink Bibliothek installiert. Diese erlaubt es uns Binarys auf das Board zu flashen, als auch das Debuggen mittels GDB Server. Dazu holen wir uns zunächst die Quellen von Github:

git clone git://github.com/texane/stlink.git

Das Ergebnis sollte so aussehen

Cloning into stlink...
remote: Counting objects: 3528, done.
remote: Compressing objects: 100% (1246/1246), done.
remote: Total 3528 (delta 2282), reused 3436 (delta 2199)
Receiving objects: 100% (3528/3528), 12.62 MiB | 366 KiB/s, done.
Resolving deltas: 100% (2282/2282), done.
Jacob-Maxas-MacBook-Pro:Dev jack77$ ls
sat stlink summon-arm-toolchain

Jetzt compilieren wir das Paket:

cd stlink

LIBRARY_PATH=/opt/local/lib C_INCLUDE_PATH=/opt/local/include make CONFIG_USE_LIBSG=0

Das Ergebnis sieht so aus:

building src/stlink-usb.c into stlink-usb.o
cc `pkg-config --cflags libusb-1.0` -g -DDEBUG=1 -std=gnu99 -Wall -Wextra -c src/stlink-usb.c -o stlink-usb.o
done compiling
building src/stlink-sg.c into stlink-sg.o
cc `pkg-config --cflags libusb-1.0` -g -DDEBUG=1 -std=gnu99 -Wall -Wextra -c src/stlink-sg.c -o stlink-sg.o
done compiling
building src/uglylogging.c into uglylogging.o
cc `pkg-config --cflags libusb-1.0` -g -DDEBUG=1 -std=gnu99 -Wall -Wextra -c src/uglylogging.c -o uglylogging.o
done compiling
objs are stlink-common.o stlink-usb.o stlink-sg.o uglylogging.o
ar -cr libstlink.a stlink-common.o stlink-usb.o stlink-sg.o uglylogging.o
done making library
make -C flash
cc -g -DDEBUG -std=gnu99 -Wall -Wextra -I../src `pkg-config --cflags libusb-1.0` -c main.c -o main.o
cc -g -DDEBUG -std=gnu99 -Wall -Wextra -I../src `pkg-config --cflags libusb-1.0` -o st-flash main.o -L.. -lstlink `pkg-config --libs libusb-1.0`
make -C gdbserver CONFIG_USE_LIBSG="0"
cc -g -Wall -Werror -std=gnu99 -I../src `pkg-config --cflags libusb-1.0` -c -o gdb-remote.o gdb-remote.c
cc -g -Wall -Werror -std=gnu99 -I../src `pkg-config --cflags libusb-1.0` -c -o gdb-server.o gdb-server.c
cc -o st-util gdb-remote.o gdb-server.o ../libstlink.a -L.. -lstlink `pkg-config --libs libusb-1.0`
building src/test_usb.c into test_usb.o
cc `pkg-config --cflags libusb-1.0` -g -DDEBUG=1 -std=gnu99 -Wall -Wextra -c src/test_usb.c -o test_usb.o
done compiling
building test_usb
cc test_usb.o -L. -lstlink `pkg-config --libs libusb-1.0` -o test_usb
done linking
building src/test_sg.c into test_sg.o
cc `pkg-config --cflags libusb-1.0` -g -DDEBUG=1 -std=gnu99 -Wall -Wextra -c src/test_sg.c -o test_sg.o
src/test_sg.c:35: warning: unused parameter ‘argv’
done compiling
building test_sg
cc test_sg.o -L. -lstlink `pkg-config --libs libusb-1.0` -o test_sg
Jacob-Maxas-MacBook-Pro:stlink jack77$

und sollte recht schnell abgeschlossen sein. Jetzt können wir zum ersten mal testen, ob unser Board korrekt erkannt wurde. Dazu verbinden wir es mit dem Mini-USB am PC und sehen standardmäßig die Demoanwendung auf dem Board mit den 4 LEDs um den MEMS Sensor. Jetzt starten wir den gdbserver. Dieser hällt das laufende Programm an.

./gdbserver/st-util

Die Ausgabe dazu:

2012-03-10T14:13:42 INFO src/stlink-usb.c: -- exit_dfu_mode
2012-03-10T14:13:42 INFO src/stlink-common.c: Loading device parameters....
2012-03-10T14:13:42 INFO src/stlink-common.c: Device connected is: F4 device, id 0x20006411
2012-03-10T14:13:42 INFO src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
Chip ID is 00000413, Core ID is 2ba01477.
KARL - should read back as 0x03, not 60 02 00 00
init watchpoints
Listening at *:4242...

Wie wir sehen, startete der Server korrekt und lauscht lokal auf den Port 4242 – merken wir uns das. Sollte die Ausgabe anders lauten oder nur sehr sehr langsam erfolgen, so hilft ein ab und wieder anstecken des Boards gelegentlich. Unser gdbserver ist somit lauffähig.

Neben dem gdbserver liefert stlink auch einen Flasher für Binarys mit. Dieses liegt im Ordner flash und arbeitet wie folgt:

./flash/st-flash write binary.bin 0x08000000

Dabei gibt binary.bin die zu schreibende Firmware an und 0×08000000 ist die Startadresse des Programmspeichers (Flash) des Microcontrollers. Wichtig ist, dass nicht die *.elf Datei verwendet wird, da diese Debugeinträge beinhaltet, welche in einer Firmware nichts zu suchen haben.

TODO: blink gdb test

Eclipse mit GDB

Jetzt haben wir schonmal eine Toolchain und einen Debug-Server. Fehlt nur noch die IDE – “nur noch”. Das hat sich bisher als größtes Hindernis rausgestellt.

Nachdem Eclipse runter geladen, installiert und gestartet wurde, werden nun einige zusätzliche Plugins benötigt. Diese werden über den Eclipse internen Installer eingebunden. Zu finden unter ”Help” > “Install New Software”

CDT (Sofern nicht vorhanden):

Auswahl unter “Work with…” > ”Indigo – http://download.eclipse.org/releases/indigo” (abhängig von aktueller Eclipse Version)
Unter “Programming Languages” folgende 3 Elemente auswählen: “C/C++ Development Tools”, “C/C++ Development Tools SDK” und “Autotools support for CDT (Incubation)”
Next > Lizenz akzeptieren > Finish > IDE neustarten

GNU ARM Eclipse:

Wieder im Installer: Auf den “Add…” Button oben rechts klicken und im Feld “Name” beispielsweise “gnuarmeclipse” und unter Location “http://gnuarmeclipse.sourceforge.net/updates” eintragen. “OK” drücken
Sollte unter “Work with…” nicht bereits “gnuarmeclipse” ausgewählt sein, so bitte auswählen.
Das Paket “CDT GNU Cross Development Tools” auswählen
Next > Lizenz akzeptieren > Finish > IDE neustarten

CDT Juno:

Wieder im Installer: Auf “Available Software Sites” klicken (sieht aus wie ein Link) und im “type filter text” Suchfeld oben “CDT” eintippen.
den Haken bei “CDT Juno” machen und mit “OK” bestätigen
Unter “Work With..” wieder “CDT Juno” auswählen, sofern nötig.
Die Auswahl wie in dem Bild machen:
Next > Lizenz akzeptieren > Finish > IDE neustarten

Zylin Embedded Debugger:

Wieder im Installer: Auf den “Add…” Button oben rechts klicken und im Feld “Name” beispielsweise “Zylin” und unter Location “http://opensource.zylin.com/zylincdt” eintragen. “OK” drücken
Sollte unter “Work with…” nicht bereits “Zylin” ausgewählt sein, so bitte auswählen.
Das Paket “Zylin Embedded CDT ” auswählen
Next > Lizenz akzeptieren > Finish > IDE neustarten

Projekt erstellen

So jetzt sollten alle benötigten Pakete installiert sein. Jetzt benötigen wir die STM32F4 Bibliothek von ST, welche man unter diesem Link herunterladen kann. Diese beinhaltet alle Quellen, welche man braucht um das Board und die uC Peripherie anzusprechen. Nach dem Download entpackt ihr diese am Besten in den Dev Ordner. Jetzt können wir ein Projekt erstellen. Ich habe mir dazu einen Eclipse Workspace in meinem Dev Ordner mit der Bezeichnung “stm32f4discovery” angelegt. Dieser muss bekanntlich beim start von Eclipse ausgewählt werden.

Zuerst muss jedoch die PATH Variable angepasst werden, in dem wir die Toolchainbinarys dieser hinzufügen. Dazu in “Eclipse” > “Preferences” dann im Baum “C/C++” > “Build” > “Enviroment” auf den “Add” Button > im neuen Dialog unter “Name” “PATH” eintragen und als Value “/Users/jack77/Dev/sat/bin:${PATH}”, wobei ihr eventuell euren Pfad zur Summon Toolchain anpassen müsst. Das ist der Pfad, der als PREFIX Parameter weiter oben (rot markiert) angegeben wurde. Unter der Tabelle den Tick bei “Append variables to native enviroment” setzen und mit “OK” bestätigen und schließen.

Nachdem erstellen wir unter “File” > “New” > “Other” > “C Project” ein neues Projekt. Weiter mit “Next”. Gebt eurem Projekt einen schönen Namen wie “Test” . Ich habe mich für “STM32F4DiscoveryTemplate” entschieden. Unter “Project Type” wählt ihr “ARM Cross Target Application” > “Empty Project” aus und unter “Toolchains” die “ARM Mac OS X GCC (Summon)”. ”Next” > “Finish”.

Als nächstes müssen die externen Quellen der STM32F4 Bibliothek eingebunden werden. Dazu: Rechtsklick auf den Projektordner im “Project Explorer” > “Properties”. Links im Baum “C/C++ General” > “Path and Symbols”. Jetzt werden 3 Orte in den Workspace eingelinkt. Dazu solltet ihr den Ordner merken, in welchen ihr die Bibliothek entpackt habt. Wir starten im Reiter “Includes”. Über den “Add…” Button rechts könnt ihr neue Verzeichnisse hinzufügen. Je nachdem wo ihr das Zeug hin entpackt habt (Ich nenn den Ordner mal $BIB$) müssen folgende Verzeichnisse hinzugefügt werden:

$BIB$/Libraries/CMSIS/Device/ST/STM32F4xx/Include
$BIB$/Libraries/CMSIS/Include
$BIB$/Libraries/STM32F4xx_StdPeriph_Driver/inc

Zudem sollte der Projektordner auch hinzugefügt werden. Bei allen Ordnern kann im Hinzufügen-Dialog der Haken bei “Add to all languages” und “Add to all configurations” gesetzt werden. Somit wird der Pfad dem GCC und dem Assembler beigebracht. Wurde die PATH Variable korrekt gegeben, befinden sich noch 4 weitere Einträge hier:

So sollte das Ergebnis aussehen.

Sollte die PATH Variable falsch gesetzt sein, so muss diese wie oben beschreiben angepasst werden und die Pfade im Include manuell hinzugefügt werden.

Als nächstes wird zum Reiter “Source Location” gewechselt. Hier werden jetzt die Quelldateien für die Peripherie angegeben. Dazu auf “Link Folder” klicken und den Ordner $BIB$/Libraries/STM32F4xx_StdPeriph_Driver/src angeben. Der Name ist beliebig. Zusätzlich muss noch der Projektordner hinzugefügt werden.

Jetzt sollten alle Quellen und Header Dateien eingebunden sein. Kümmern wir uns nun um den GCC. Wieder in den Projekteigenschaften (Rechtsklick aufs Projekt im ”Project Explorer” > “Properties”) “C/C++ Build” > “Settings”. Der Einfachheit halber habe ich von allen Einstellungen einen Screenshot gemacht.

Wenn ihr bei euch alles wie in den Bildern eingestellt habt, sollte der GCC konfiguriert sein. Kommen wir nun zum Debugger.

Eclipse GDB

Wir machen nun zwei Sachen. Zum einen starten wir den gdbserver vom stlink Package aus Eclipse aus und verbinden uns daraufhin mit dem gdb darauf.

In Eclipse im Menü “Run” > “External Tools” > “External Tool Configuraion” klicken. Im neuen Dialog ein neuen Eintrag unter “Program” erstellen (durch doppelklick darauf). Diesen nennen wir beispielsweise “STLink GDB Server”. Als Location geben wir den Pfad zum stlink gdb binary an. Bei mir ist das “/Users/jack77/Dev/stlink/gdbserver/st-util”. Als “Working Directory gebt ihr das an:

${workspace_loc}/${project_path}

Unter dem Reiter “Common” könnt ihr jetzt noch den Eintrag als Favorit setzen. Von jetzt an kann der gdbserver von Eclipse aus gestartet werden. Als nächstes richtigen wir den gdb client ein.

Hier benötigen wir jetzt Zylin. Öffnet im Eclipse Menü “Run” > “Debug Configuration”. Links im Baum befindet sich ein Eintrag “Zylin Embedded debug (native)”. Diesem fügen wir einen Eintrag hinzu mit folgender Konfiguration (siehe Bilder).

Unter “Commands” muss folgendes eingetragen werden:

target extended-remote localhost:4242
file Debug/STM32F4DiscoveryTemplate.elf
load
break main
kill
run

Das solls gewesen sein. Jetzt könnt ihr eure Programme erstellen. Wichtig ist noch, dass die Debug Binary angepasst werden muss (rot markiert). Diese muss sowohl im “Main” Reiter angepasst werden, als auch im “Commands” Init Feld.

Zu guter Letzt müssen noch 3 Dateien in das Projektverzeichnis kopiert werden:

$BIB$/Project/STM32F4xx_StdPeriph_Templates/TrueSTUDIO/STM324xG_EVAL/stm32_flash.ld
$BIB$/Libraries/CMSIS/Device/ST/STM32F4xx/Source/Templates/system_stm32f4xx.c
$BIB$/Libraries/CMSIS/Device/ST/STM32F4xx/Source/Templates/TrueSTUDIO/startup_stm32f4xx.s

Die letzte Datei (startup_stm32f4xx.s) bedarf noch 2 Modifikationen. Zum einen muss die Endung von .s auf .S (groß geschrieben) geändert werden. Zum anderen muss die Zeile 99 auskomentiert werden:

/* Call static constructors */
//    bl __libc_init_array

Ich hoffe ich konnte helfen. Anbei habe ich mal meinen Workspace mit einer Demoanwendung (bischen LED gebklinke). Bitte beachtet, dass bestimmte Pfade angepasst werden müssen.

Workspace zum Download

vorcompilierte stlink (Mac OS X 10.7.3, libusb-1.0)

vorcompilierte summon-arm-toolchain (Mac OS X 10.7.3)

Für die compilierten Bibliotheken gibt es keine Garantie auf Funktion oder Haftung.

Jacob

Links:

Problem mit MAKE unter Windows 64 Bit

admin — Thu, 09 Feb 2012 16:35:59 +0000

Sollte euch beim Compilieren durch die GNU Toolchain oder deren Alternative Yagarto unter einem 64 Bit Windows System folgender Fehler auffallen:

make: Interrupt/Exception caught (code = 0xc00000fd, addr = 0x425073)

dann liegt das daran, dass Make mit Leerzeichen innerhalb der PATH Variable nicht klar kommt. Es gibt dabei 3 Lösungsansätze:

Installation der Toolchain in ein Verzeichnis ohne Leerzeichen im Pfad
Installation einer 64 Bit Version von Make (Link)
Ändern der Pfadvariable, dass die sogenannten Shorted Dirs verwendet werden. Dies stammt noch aus der DOS Zeit. Dabei werden Verzeichnisse nur bis zum 7 Zeichen angegeben und darauffolgend eine Tilde und die Position des Ordner. So wird aus “C:/Programm Files” ein “C:/Progamm~1″.

Gruß Jacob

P.S. Ich habe die erste Variante verwendet.

WebGL in Google Chrome freischalten

admin — Sun, 05 Feb 2012 11:03:09 +0000

Hallo

ich habe gestern ein wenig mit meinem Chrome rumexperimentiert und ein nettes Feature gefunden: Unter der Adresse chrome://flags/ können experimentelle Einstellungen aktiviert werden. Darunter auch eine WebGL Implementierung.

Gruß Jacob

Ein Jahr geht zu Ende…

admin — Tue, 20 Dec 2011 16:40:28 +0000

… und ich verabschiede mich ins meine Weihnachtszeit Ich wünsche allen Besuchern ein frohes Fest und einen gelungenen Start in 2012.

Gruß Jacob

Klassik Radio Livestream

admin — Wed, 30 Nov 2011 11:01:38 +0000

Auf der Suche nach einem Livestream für meinen Lieblingsarbeitssender Klassik Radio bin ich leider im Netz nicht fündig geworden. Also habe ich mir mal den Quelltext von deren Webradio angeschaut und die Streams einzeln rausgesucht. Und da sind sie:

Klassik Radio - http://edge.live.mp3.mdn.newmedia.nacamar.net/klassikradio128/livestream.mp3
Klassik Radio Lounge - http://edge.live.mp3.mdn.newmedia.nacamar.net/klassikradiolounge128/livestream.mp3
Klassik Radio Movie - http://edge.live.mp3.mdn.newmedia.nacamar.net/klassikradiomovie128/livestream.mp3
Klassik Radio Opera - http://edge.live.mp3.mdn.newmedia.nacamar.net/klassikradioopera128/livestream.mp3

Erfreulicherweise senden sie sogar in 128 kbit/s Wenn Ihr die Stream z.B. in iTunes hinzufügen möchtet, müsst ihr einfach nur im Menü “Erweitert” -> “Stream öffnen” anklicken und den Link in das Textfeld einfügen und bestätigen. Et voila

Edit: Auf Nachfrage hin: Nacamar sendet neben den 128 kbit Streams auch als 96 kbit Stream. Dazu muss in der Adresse einfach in alle URLs die 128 durch eine 96 ersetzt werden.

Edit #2: Aus den Kommentaren (Danke dafür): Im WMP 12 unter Win 7 einfach ALT drücken und unter DATEI > URL öffnen hinzufügen.

Jacob

Flattr

admin — Tue, 29 Nov 2011 09:47:26 +0000

Nachdem ich schon länger mal darüber nachgedacht habe, hier einen solchen Button einzubauen starte ich heute einfach mal ein Experiment und will sehen, ob es was bringt hier sowas zu nutzen. Wem Flattr nichts sagt, der kann sich in den einschlägigen Seiten im Netz darüber informieren. Vielleicht bringt es ja ein bisschen was

Gruß Jacob

Bitte!

admin — Tue, 06 Sep 2011 05:57:44 +0000

So liebe Leute. Da ich euch hier versuche ständig auf dem Laufenden zu halten was Lösungen und Co betrifft bitte ich euch heute mal mir etwas zu helfen: Mir gehts darum, dass ich meinen Dropboxspace etwas vergrößern möchte. Was Ihr dafür machen müsst? Meldet euch einfach über meinen Referr Link ( http://www.dropbox.com/referrals/NTE4NTgyNzA5 ) bei dem Dienst an. Dort habt ihr 2GB kostenlosen Webspace den ihr ganz einfach in euer Dateisystem einbinden könnt, egal welches OS Ihr nutzt. Ich halte so immer alle meine Dokumente zusammen und hab gleichzeitig nen Backup in der Cloud.

Also hier nochmal der Link: http://www.dropbox.com/referrals/NTE4NTgyNzA5 (bitte über den Referral anmelden, sonst bringts mir nichts)

Kleines Update: falls mir noch einer was gutes tun möchte: Meine Amazon Wishlist

Danke schonmal

Jacob

Semesterende

admin — Tue, 12 Jul 2011 07:28:09 +0000

Und schonwieder geht ein Semester seinem Ende entgegen und die Prüfungszeit steht in den Startlöchern. Solltet Ihr meinen, dass hier irgendwelche Dokumente fehlen dann bitte ich euch mir diese zuzusenden, damit ich diese allen zur Verfügung stellen kann.

Gruß Jacob

NTFS-3G unter den aktuellen MacBooks Pro

admin — Wed, 25 May 2011 21:42:50 +0000

Ich wollte heute auf meinem aktuellen Gerät (8.1, i7) MacFUSE und NTFS-3G installieren, was mir folgende Fehlermeldung gab:

20.05.11 15:53:30 kernel kxld[com.google.filesystems.fusefs]: The following symbols are unresolved for this kext:
20.05.11 15:53:30 kernel kxld[com.google.filesystems.fusefs]: _OSRuntimeFinalizeCPP
20.05.11 15:53:30 kernel kxld[com.google.filesystems.fusefs]: _OSRuntimeInitializeCPP
20.05.11 15:53:30 kernel Can’t load kext com.google.filesystems.fusefs – link failed.
20.05.11 15:53:30 kernel Failed to load executable for kext com.google.filesystems.fusefs.
20.05.11 15:53:30 kernel Kext com.google.filesystems.fusefs failed to load (0xdc008016).
20.05.11 15:53:30 kernel Failed to load kext com.google.filesystems.fusefs (error 0xdc008016).

Ein wenig Recherche später fand ich herraus, dass es sich hierbei um einen Bug in der aktuellen Version von MacFUSE (2.1.9) handelt, da die dortigen libs schon gegen OSX 10.7 verlinkt zu seinen scheinen. Geholfen hat mir der Deveintrag auf dem Changelog. Es wird geraten, die MacFUSE Version des NTFS-3G projektes zu verwenden, welche es hier gibt: http://www.tuxera.com/mac/macfuse-core-10.5-2.1.9.dmg

Gruß Jacob

Update 12.02.2012:

Da das MacFUSE Projekt seit mehr als 2 Jahren keine Updates mehr bietet wurde ein Fork entwickelt und unter dem Namen OSXFuse weiterentwickelt. Zu finden ist das Projekt samt Installation unter http://osxfuse.github.com/

Server

admin — Sun, 22 May 2011 20:59:50 +0000

Hallo Leute

am Freitag Nachmittag hat sich mein Server mit seinem kaputten RAM selber ins Jenseits befördert. Daher war übers Wochenende die Seite nicht erreichbar. Ich habe nun einen anderen Server bekommen und hoffe, alles neu eingerichtet bekommen zu haben. Glücklicherweise hatte ich noch ein recht aktuelles Backup der Daten. Allein der Reimport ins neue System hat ein paar Fehler in der Datenbank mit Umlauten hervorgebracht. An sonsten sollte alles wieder laufen. Sollte euch noch ein Fehler auffallen so bitte ich euch, mir eine Nachricht zukommen zu lassen.

Gruß Jacob