Esden's Blog - computerworld

New Black Magic Debug Maintainer

Esden — Sat, 08 Jan 2022 00:00:00 +0000

Hi everyone!

As some of you might know Black Magic Debug was created and maintained for many years by Gareth McMullin. He has created a wonderful tool that we all use and love. You might have also noticed that Gareth did not have much time to dedicate to the project for the last few years. He asked me a while ago if I would be able to take over the project and become an official maintainer of Black Magic Debug. I did not have the necessary resources to dedicate to the project until very recently. But it is finally time, from now on I am officially taking on the position as the Black Magic Debug maintainer. :)

I want to thank Gareth for putting the faith in me and creating this amazing project. I also have to say big thanks to Uwe Bonnes who stepped in while Gareth and I were unavailable to keep the patches and Black Magic releases going.

I have a lot of plans for the Black Magic project, software/firmware and hardware wise. You might have noticed I already spent some time catching up on and cleaning the GitHub issues. It is by no means finished and probably never will be, but I hope we can keep open issues and pull requests on a better level going forward.

To resolve the issue that the native Black Magic Hardware is currently not available due to chip shortages, I am working on the new revision of the native hardware. This should make them available again and allow us for more alternative chip choices. We are adding some cool new features to the new hardware while we are at it. (more information soon) I am also working on a tool that will help users manage the Black Magic Probe firmware, opening doors to more flexibility and versatility of the project overall. (also, more information about that soon)

https://youtu.be/v1BNmTlc6FU

A small teaser of the new native Black Magic Probe hardware V2.3a

3D Printed cases for BMP V2.3a

You can also expect that we will finally get a proper CI system including HITL (Hardware In The Loop) testing. Something we are in dire need to keep the stability expectations as high as possible. I was collecting a lot of hardware over the years and I want to put it together to some good use. We will also improve the contribution process and document the APIs better, this should hopefully make addition of new targets easier.

There is one more thing that I would like to mention. In the process of changing maintainership the GitHub organization that the project is under will be changing it's name. As it is not developed by Blacksphere (Gareth's consulting company) we will be renaming the org to the project's name itself. It will serve as an umbrella for additional repositories related to the Black Magic Debug project. Don't worry GitHub should redirect the old organization names to the new one. I hope it will not cause too much disruption. We will also finally be officially retiring the SourceForge project page to avoid confusion. This means the old unused mailing lists will be disabled.

If you have questions or concerns and want to get in touch with the project you have multiple options: open an issue on github, join the 1BitSquared Discord server and talk to us in the #blackmagic channel. If it is something you would rather discuss one on one, you can also write an email to: contact at black-magic org where you will be able to reach the core developer team.

I am excited to work with you all to bring the Black Magic Debug project to the next level.

Stay safe, cheers,
Piotr Esden-Tempski

Black Magic Discovery

Esden — Mon, 29 Dec 2014 00:00:00 +0000

Hey everyone!

Today I had to fix another STM32F4 Discovery board. By fixing I mean replacing the STLink firmware with Black Magic Probe firmware. I do that on a semi regular basis but as I have not done it in a long time I did not remember the process anymore. Obviously this calls for a blog post with some step by step instructions on how to do it, so that I have a reference in the future. Also you might find it useful yourself.

First of all let's explain what we are trying to do. The objective is to replace the STLink SWD (Serial Wire Debug) firmware with Black Magic Probe firmware. The board is setup by default to use a smaller chip to run the STLink firmware to talk to the main stm32. We need to change the smaller chips firmware. The initial adjustments to the board are needed to be able to access the programming pins of the smaller chip and replace it's contents to Black Magic Probe firmware so that we can use GDB (GNU DeBugger) to program and debug the board instead of the very unstable and unreliable proprietary STLink protocol. The adjustments needed to access the small chips programming pins need to be reversed once the firmware is changed to Black Magic Probe firmware, resulting with an stm32 f4 discovery board with Black Magic Probe firmware ready to use.

For the "Fixing" process I use a genuine Black magic probe, I have one of those very early ones with a 0.1" header that is very useful in this particular case. You can also use a Black Magic Probe Mini with a PCB adapter, make an adapter cable or you can use another Discovery board that has already been "fixed".

Step 1

First step is to change the two solder jumpers on the bottom of the discovery board.

[caption id="attachment_503" align="alignnone" width="510"] Jumper modification for SWD programming.[/caption]

Remove the 0Ohm resistor/jumpers marked with red circles, and close the jumpers marked with blue circles.

Note: The easiest way to do that is to use a soldering tip, add a bunch more solder over the resistor and swipe them of. After that is done use solder wick to make sure there is no short on the "red" jumper. You can discard the 0Ohm resistors. It is much easier to just add a small blob of solder to close the "blue" jumpers, it is easy to remove them later in the process by just using some solder wick.

Step 2

Remove the SWD and slave MCU jumpers as indicated by the red circles in the photo.

[caption id="attachment_507" align="alignnone" width="576"] STM32F4 Discovery board Jumpers for updating the programmer chip firmware[/caption]

Step 3

Attach jumper wires to the Black Magic Probe header.

[caption id="attachment_509" align="alignnone" width="576"] Black Magic Probe Serial Wire Debug connections for Discovery board "fixing"[/caption]

Standard JTAG/SWD 20Pin 0.1" header

Black wire - Pin 14 (GND)
Orange wire - Pin 9 (TCLK/SWCLK)
Yellow wire - Pin 8 (TMS/SWDIO)

In case you are trying to figure out which pins these are on a standard ARM Cortex 10Pin 0.05" header. Here you go:

Standard JTAG/SWD Cortex 10Pin 0.1" header

Black wire - Pin 3, 5 or 9 (GND)
Orange wire - Pin 4 (TCLK/SWCLK)
Yellow wire - Pin 2 (TMS/SWDIO)

Step 4

Attach the Black Magic Probe to the discovery board.

[caption id="attachment_510" align="alignnone" width="576"] STM32F4 Discovery board Serial Wire Debug connection for "fixing" the on board programmer firmware[/caption]

Black wire (GND) - Pin 3 of the SWD (CN2) header
Orange wire (SWCLK) - Pin 2 of the ST-LINK/DISCOVERY (CN3) header
Yellow wire (SWDIO) - Pin 4 of the ST-LINK/DISCOVERY (CN3) header

Step 5

Now you can connect the discovery board and the Black Magic probe to your computer via USB. The order should not matter, but usually I tend to connect the usb wires to the laptop before connecting the SWD wires between the two devices, just to make sure we don't have some strange current loop that powers one or the other via IO pins, which might be problematic.

Step 6

Now we turn our attention to the software. You can obviously do these steps before you wire everything up but this is the order I followed.

The process requires a few dependencies that you should install using either apt on Linux or homebrew or macports on OS X:

Python
pyserial

In my case I use OS X and homebrew so I needed to run the following two commands:

brew install python pip install pyserial

Step 7

Download and make the an arm gcc compiler "findable". I recommend using GCC ARM Embedded as it is maintained by the ARM developers themselves and they seem to generally know what they are doing. :)

So download it from here: https://launchpad.net/gcc-arm-embedded

Then unpack it into your home directory:

[code language="text" gutter="false"] cd ~ tar xfvj ~/Downloads/gcc-arm-none-eabi-replace this with the version-mac.tar.bz2 [/code]

Then you should add the binary directory of the newly unpacked compiler package to your system. Obviously to do this you add the directory to your PATH environment variable. If you don't know what that is you should learn a bit more about your Unix/Linux basics. :)

export PATH=~/gcc-arm-none-eabi-someversion/bin:$PATH

To make this addition persistent you can also add that to your .profile, .bash_profile or .zprofile depending on the shell and setup you use.

Step 8

Download blackmagic firmware source code. You can get it at https://github.com/blacksphere/blackmagic

The easiest way is to clone the github repository, look for the small window at the center right of the github page for the git repository url. If you have a github account choose the ssh url but if you refuse to do so then you can go with the https one too. :)

If you did not learn about GIT and GitHub yet this is the perfect time to take a break from all of this here and come back after you have caught up on your homework. :D

git clone git@github.com:blacksphere/blackmagic.git

Step 9

Now let's build the firmware. This consists of three steps:

Fetch the libopencm3 submodule
Build from the toplevel so libopencm3 is built
Build the blackmagic firmware for the stlink

cd blackspheregit submodule initgit submodule updatemakecd srcmake cleanmake PROBE_HOST=stlink

Step 10

We can finally connect to the hardware we wired up before and erase the pesky stlink firmware. When the discovery boards ship, the firmware is read and write protected on the STLink chip. So to be able to overwrite the firmware we will have to unlock the chip. Thanks to Gareth there is a small python script that can do that for us. You just have to call the following command inside the src directory of the blackmagic repository and it should be able to remove the write protection:

../scripts/hexprog.py -s -d /dev/cu.usbmodemSOMESERIAL1 -r blackmagic.bin

In the case you are on Linux you can leave out the -d device parameter. For reference the -s parameter tells hexprog to use Serial Wire Debug instead of JTAG and -r tells it to unlock and erase the target chip.

If you skip any of those two parameters it will not work for you.

Step 11

Flash the bootloader. We are getting very close. To upload the blackmagic bootloader you use arm-none-eabi-gdb.

arm-none-eabi-gdb blackmagic_dfutarget extended_remote /dev/usbmodemSOMESERIAL1monitor swdp_scanattach 1loadexit

This sequence of commands attaches to the virtual gdb server that is provided by the Black Magic Probe on it's virtual serial port 1. (The second serial port is the USB to serial interface located on the back of the BMPM) We then tell the monitor (this is the BMP) to scan using Serial Wire Debug as our protocol. Next we attach to the virtual process number 1. (As we are on the embedded systems there usually should only ever be 1 process unless you run an RTOS) We load the firmware from the elf file that we passed on to gdb earlier and exit GDB.

Simple right? :D (Believe me that is definitely simpler than setting up and making OpenOCD work with Eclipse)

Tip: To make things easier for the future you can add the following to your .gdbinit file:

set target-async onset confirm offset history saveset mem inaccessible-by-default offtar ext /dev/cu.usbmodemSOMESERIAL1mon versionmon swdp_scan#mon jtag_scan att 1

Note: On Linux the cu.usbmodem device name will be /dev/ttyACM0 instead.

After setting up the .gdbinit file the upload process becomes quite a bit shorter:

arm-none-eabi-gdb blackmagicloadexit

Step 12

Upload the black magic firmware itself. Here you have two options. Either you can use the same process as before using GDB or you can use the now uploaded DFU bootloader to upload the Black Magic Probe firmware payload. Using GDB you would run the following:

arm-none-eabi-gdb blackmagictarget extended_remote /dev/cu.usbmodemSOMESERIAL1monitor swdp_scanattach 1loadexit

Alternatively you can upload the firmware using a DFU script. Before you do that though you should disconnect the genuine Black Magic Probe from your computer as you want to make sure the script flashes the Discovery board and not your BMP. To do that you will need to install python libusb as an additional dependency. But having done that you can then run the following to upload the firmware:

./scripts/stm32_mem.py blackmagic.bin

Step 13

Put everything back together. Now you just have to do four things:

Disconnect your Black Magic Probe and Discovery board from your computer as well as each other.
Remove the solder blobs you have added on the back of the board.
Add solder blobs to where you removed the resistors at the very beginning.
Put the jumpers back to where they were on the front of the Discovery board.

You are pretty much done now. If everything went well you should have your "fixed" discovery board. Follow to the one additional step below to test that.

Step 14

Plug in your Discovery board into your computer. The dual color led next to the USB connector should be solid Green. If it is blinking Green it means the bootloader is running and the board is expecting to be flashed with the firmware. This can happen if you still have the power jumper disconnected that provides power to the "slave" STM32F4 chip. This is actually very useful if you want to upgrade the Black Magic Probe firmware on your discovery board. :D

Additionally if everything went well if you are on Mac OS X a /dev/cu.usbmodemSOMESERIAL1 and /dev/cu.usbmodemSOMESERIAL3 should appear. If you are on linux you should be able to find ttyACM0 and ttyACM1 in the /dev directory.

I hope this write up is useful for you and the future me. :) I am planning to write another blog post on how to build and upload an example firmware onto the slave processor. So hold on to your hats! :)

Cheers,
Esden

P.S. Big thanks to Jack Ziesing for proofreading and introductory paragraph and sparking the work on this article. It is a great help! :)

libopencm3 Discovery

Esden — Mon, 29 Dec 2014 00:00:00 +0000

Hi everyone,

As promised in the previous post. Here is a short write up how to download, compile and upload your first example program using libopencm3 and a STM32F4 discovery board.

Very similar process will apply to any other evaluation boards that employ an STM32 microcontroller and Black Magic Probe JTAG/SWD programmer. Like for example Lisa/M, Lisa/MX, Lisa/S, Apogee and so on.

Step 1

If you did not already do that, download and install GCC ARM Embedded. You might have already done it if you were "fixing" your Discovery board.

You can download the compiler from here: https://launchpad.net/gcc-arm-embedded

Unpack it into your home directory:

cd ~
tar xfvj ~/Downloads/gcc-arm-none-eabi-replace this with the version-mac.tar.bz2

You should add the binary directory of the newly unpacked compiler package to your system. Obviously to do this you add the directory to your PATH environment variable. If you don't know what that is you should learn a bit more about your Unix/Linux basics. :)

export PATH=~/gcc-arm-none-eabi-someversion/bin:$PATH

To make this addition persistent you can also add that to your .profile, .bash_profile or .zprofile depending on the shell and setup you use.

Step 2

Download libopencm3-examples. You can find this repository at https://github.com/libopencm3/libopencm3-examples

git clone git@github.com:libopencm3/libopencm3-examples.git

Step 3

Build the libopencm3 examples. The repository contains libopencm3 as a submodule so you will have to initialize and update the submodule before you can compile the library itself as well as all the different examples.

cd libopencm3-examples
git submodule init
git submodule update
make

This will take a bit as there is a lot of examples included in that repository. In the past the examples were part of the main library itself but there became so many of them that we had to split it off. Otherwise the build and clone process just took too long.

Step 4

Prepare your environment. To make your life easier you should set up your .gdbinit configuration file. This will make the firmware upload and debug process so much easier. Just add the following lines to the .gdbinit file:

set target-async on
set confirm off
set history save
set mem inaccessible-by-default off
tar ext /dev/cu.usbmodemSOMESERIAL1
mon version
mon swdp_scan
#mon jtag_scan
att 1

Note: On linux the cu.usbmodemSOMESERIAL1 becomes ttyACM0.

For reference here is the breakdown of what the commands inside of the .gdbinit file mean:

set target-async on: Enable background execution commands.
set confirm off: This disables the really annoying "are you sure" questions. :)
set history save: This forces GDB to save the command history.
set mem inaccessible-by-default off: This is one of the most important commands here. Very often when you are trying to debug your code on a microcontroller you have to read the content of memory mapped registers. If you don't set this option the debugger will prevent you from doing so as it has no idea that this memory is actually accessible. On a PC having the option on makes total sense but on a microcontroller it is mostly a burden.
tar ext /dev/cu.usbmodemSOMESERIAL1: tell gdb to connect to Black Magic Probe
mon version: Print version of the Black Magic Probe.
mon swdp_scan: Scan for devices using SWD protocol.
att 1: Attach to the first process. On a microcontroller you will have only one process...

Step 4

Upload fancyblink example. The simplest example for the STM32F4 Discovery board is the fancyblink example. It is also very easy to upload. As long as your Discovery board is "fixed" and uses the BMP firmware.

cd examples/stm32/f4/stm32f4-discovery/fancyblink
arm-none-eabi-gdb fancyblink.elf
load
run

Now the LEDs on the Discovery board should be blinking. You can interrupt the execution of the program by pressing -C. You can continue the execution by running cont.

Here is a short reference of GDB commands that you might find useful when playing around with code:

load -> load the binary from the provided elf file. (Note: it detects if the elf file changed on the hard disk and loads a new one if available. So you don't have to quit GDB every time when you recompile your code)
run -> start the execution of your firmware
backtrace -> print the call stack trace of the current line of code being executed
make -> runs make command in the directory you started gdb. Very useful if you want to update the binary you are running really quick.
break filename:lineno -> you can add a breakpoint inside your code. GDB will stop the execution of the program as soon as the line is hit by the firmware.
step -> execute one single line of code and return back to the command line
next -> same as step but it does not enter into the functions called and skips them. Useful if you want to step over functions you know take forever and you are not interested in what they are actually doing. :)
print variablename -> print the content of a variable
print/x variablename -> print the content of a variable as HEX
list -> prints the context of the line being executed at the very moment
kill -> if used in a GDB script it will reset the MCU and exit GDB. Very useful as last command of a GDB script.

I hope this will be helpful for you.

Cheers, Esden

P.S. Big thanks to Jack Ziesing for proofreading and introductory paragraph and sparking the work on this article. It is a great help! :)

Black Magic

Esden — Fri, 13 Jul 2012 00:00:00 +0000

A few months ago I met a great guy Gareth MacMullin in the libopencm3 channel. He was working on a new Open-Source and Open-Hardware JTAG solution called Black Magic Probe(BMP). I got one of those and instantly fell in love with it.

OpenOCD is great in a sense because it supports lots of targets and probes but that is its disadvantage too. It is very often difficult to set up and tends not to work properly in many cases. The approach of BMP is quite different. Instead of the probe being quite dumb and using OpenOCD to do the JTAG magic the BMP uses a microcontroller (STM32F1) and implements a GDB server inside the controller. This solution cuts out the middleman and talks JTAG as well as the new Serial Wire Debug (SWD) protocol itself. Requiring only a working GDB on the computer.

The BMP supports several Cortex-M3 targets and more devices are being added fairly quickly. The first time I tried it with an STM32 it just worked. No command line parameters just:

arm-none-eabi-gdb some_elf_file target extended-remote /dev/ACM0 mon swdp_scan att 1 load run

It shocked me how fast the loading process was. Because it is not one of the FTDI chips and does not have to bitbang all of the JTAG protocol over USB it can run much much faster. I know there are commercial devices like JLink that have logic inside them but they cost arm and a leg if you don't want to just get the educational version of it.

One more thing comes to mind when you realize that the BMP supports SWD. You only need three pins to be able to use it GND, SWDIO and SWCLK. That decreases the required real estate on the PCB significantly. I am not sure what the status of OpenOCD support for SWD is now but it is work in progress as far as I understand. On BMP it just works.

Since I started using the BMP there were several interesting developments that Gareth added. The BMP is not only offering one serial port for the GDB extended remote interface but also a second one providing a TTL level UART interface. The BMP also supports tracing by now using the TRACESWO pin. This provides a reasonably high speed tracing. Gareth also wrote a plotter for this feature that plots the contents of traced variables in your code.

Early versions of BMP were 2.5cm X 5cm the current version called Black Magic Probe Mini (BMPM) is smaller, the same size as the FLOSS-JTAG I made a while ago, it is mere 1.5cm X 3cm, packing in all the power of the BMP what makes it great for doing embedded stuff on the go, for example in the subway.

So to wrap things up, it is a high grade, Open-Source and Open-Hardware device. For $60 this thing is a steal!

Shameless plug: On 1 BIT SQUARED store you can order the Black Magic Probe.

There are also some other distributors listed on the BMP page too. So check it out! I bet you will love it. :)

How to build arm gnu gcc toolchain for Mac OS X [Updated 8x]

Esden — Thu, 26 Feb 2009 00:00:00 +0000

Hi!

[Edit: This HOWTO is mostly outdated now because of the script summon-arm-toolchain I have created together with Uwe. You can find it here at GitHub. A short description on the usage of the script can be found in the Open-BLDC wiki.]

As I decided to use the STM32 for open-bldc and ordered an Olimex H103 evaluation board. I had to build the toolchain for it. This controller is an ARM Cortex-M3 and needs a GCC version beyond 4.3 because there the support was added.

There is a pretty good HowTo on eLua. But as I decided to use the newest versions of the tools some things changed and I decided to write my own HowTo. And here it goes!

I am using macports on my mac, so the howto is based on that. You need to install additionally gmp and mpfr. It is needed so that gcc can be compiled. I also use for most of the stuff I use stow. The toolchain cannot be installed using stow because of the softlinks it creates. You cane install it using macports too.

Sources:

Now you will need the following:

binutils: http://ftp.gnu.org/gnu/binutils/binutils-2.19.1.tar.bz2
gcc: http://gcc.cybermirror.org/releases/gcc-4.3.3/gcc-4.3.3.tar.bz2
newlib: ftp://sources.redhat.com/pub/newlib/newlib-1.17.0.tar.gz
libusb: http://sourceforge.net/project/showfiles.php?group_id=1674&package_id=1632&release_id=398442
libftdi: http://www.intra2net.com/en/developer/libftdi/download/libftdi-0.15.tar.gz
openocd: I am using svn version of openocd. The revision I tested was 1382. So to get it you need to run > svn co -R 1382 svn://svn.berlios.de/openocd/trunk openocd-svn
insight: The versions that I tested for now all had infinite loop bug. Will update that later when I found the right solution.

Compiling binutils:

I store everything that I build by myself in /opt/mine directory. I added it to my path and other relevant environment variables just as I did with /opt/local (the macports install directory). The toolchain needs its own directory. I call it /opt/mine/arm-none-eabi to distinguish it from other arm toolchains that I have on my machine.

I need to add another note here. I chose to use the arm-none-eabi target. This way the toolchain builds Version 4 EABI binaries instead of GNU EABI. I am not 100% sure what the difference is. (Please enlighten me here) But if I understand it correctly the Version 4 EABI is the ARM standarized EABI and not the GNU version of the EABI. But as stated before I am not really sure about that.

> tar xfvj binutils-2.19.1.tar.bz2 > cd binutils-2.19.1 > mkdir build > cd build > ../configure --target=arm-none-eabi --prefix=/opt/mine/arm-none-eabi --enable-interwork --enable-multilib --with-gnu-as --with-gnu-ld --disable-nls > make > sudo make install > cd ../..

Now you should also add the toolchain bin directory to your PATH so that the further steps can find the binutils binaries.

> export PATH=/opt/mine/arm-none-eabi/bin:$PATH

Building GCC bootstrap:

GCC needs the newlib to build all of it's libraries but newlib needs gcc to build. This chicken and egg problem can be solved by building GCC without libraries first, then building newlib and finally building GCC it it's full form.

> tar xfvj gcc-4.3.3.tar.bz2 > cd gcc-4.3.3 > mkdir build > cd build > ../configure --with-libiconv-prefix=/opt/local --target=arm-none-eabi --prefix=/opt/mine/arm-none-eabi --enable-interwork --enable-multilib --enable-languages="c" --with-newlib --without-headers --disable-shared --with-gnu-as --with-gnu-ld --with-gmp=/opt/local --with-mpfr=/opt/local > make all-gcc > sudo make install-gcc > cd ../..

I have to comment here on some options used. Somehow the configure of gcc is not able to find gmp and mpfr by itself. Because they are installed in nonstandard directories when you look at a linux system. That is why you have to help it by providing --with-gmp and --with-mpfr. In the case of libiconv you have to add --with-libiconv. Not adding this option does not break the configure but introduces problems in the build process.

Building newlib:

Now that we have binutils and a basic gcc install we can build newlib. This one is pretty streightforward.

[EDIT This section should be obsolete! The patch does not even apply to the newlib-1.17.0 sorry] Still you will probably need a patch that deals with makeinfo being not found by configure. I found it in a post on comp.gcc.cross-compiling.arm. But I offer the patch here for download and your conveniance.

> tar xfvz newlib-1.17.0.tar.gz > cd newlib-1.17.0 > patch -p1 -i ../newlib-1.14.0-missing-makeinfo.patch # the patch will yield a warning because it is for an older version of newlib but should apply > mkdir build > cd build > ../configure --target=arm-none-eabi --prefix=/opt/mine/arm-none-eabi --enable-interwork --enable-multilib --with-gnu-as --with-gnu-ld --disable-nls > make > sudo make install > cd ../..

Building GCC:

This should be simple now. We build the full GCC version.

> cd gcc-4.3.3/build > rm -rf * # clean up everything it makes stuff safer ^^ > ../configure --with-libiconv-prefix=/opt/local --target=arm-none-eabi --prefix=/opt/mine/arm-none-eabi --enable-interwork --enable-multilib --enable-languages="c" --with-newlib --disable-shared --with-gnu-as --with-gnu-ld --with-gmp=/opt/local --with-mpfr=/opt/local > make > sudo make install > cd ../..

Building libusb: This library and the following libftdi is needed for jtagkey-tiny support in openocd.

> tar xfvz libusb-0.1.12.tar.gz > cd libusb-0.1.12 > mkdir build > cd build > ../configure --prefix=/opt/mine/DIR/libusb-0.1.12 > make > sudo make install > sudo -s > cd /opt/mine/DIR > stow libusb-0.1.12 > exit > cd ../..

Building libftdi:

> tar xfvz libftdi-0.15.tar.gz > cd libftdi-0.15 > mkdir build > cd build > ../configure --prefix=/opt/mine/DIR/libftdi-0.15 > make > sudo make install > sudo -s > cd /opt/mine/DIR > stow libftdi-0.15 > exit > cd ../..

Building openocd:

I am using the jtagkey-tiny from Amontec, and usbprog. If you are using something else the options to configure will need enabling the other device.

> cd openocd-svn > mkdir build > cd build > ../configure --prefix=/opt/mine/DIR/openocd-svn --enable-ft2232_libftdi --enable-usbprog > make > sudo make install > sudo -s > cd /opt/mine/DIR > stow openocd-svn > exit > cd ../..

Building insight/gdb:

Well I still have some problems here. I will update the post as soon as I find a solution here.

Compiling and flashing an example program:

Openocd supplied config file for jtagkey-tiny has an error in my case. On my machine the jtagkey-tiny appears as "Amontec JTAGkey" and not "Amontec JTAGkey A". You have to edit /opt/mine/lib/openocd/interface/jtagkey-tiny.cfg and change the line ft2232_device_desc "Amontec JTAGkey A" to ft2232_device_desc "Amontec JTAGkey".

Now you can download stm32-blink.tar.bz2 that I cleaned up a bit. It is based on the example blink project from Olimex.

The example project from Olimex uses parts of the Firmware Library from ST. The documentation and the library itself can be found and downloaded here. You have to be careful though, the library has a very wierd license that is probably problematic when used in open source projects. I assume that the strange license may pose also problems when used in closed source projects too. But I am not a lawyer so do not kill me if I am wrong. :)

> tar xfvj stm32-blink.tar.bz2 > cd stm32-blink > make

Next step is to start openocd. You should start opencd in the stm32-blink directory so that later openocd can find the binary you will be uploading.

> openocd -f /opt/mine/lib/openocd/interface/jtagkey-tiny.cfg -f /opt/mine/lib/openocd/target/stm32.cfg

Now open a new terminal and run the following commands to flash the stm32-blink binary.

> telnet localhost 4444 > halt > flash write_image erase stm_h103_blink_rom.bin 0x08000000 > resume 0x08000000

Now the diode on the stm32-h103 board should start to blink happily! :)

Notes and links:

Here I gathered some additional links that may be usefull:

Disclamers:

I hope this tutorial is useful. If I made any mistakes feel free to write a comment to this post. I will try to update it if something changes and/or needs to be corrected.

Cheers Esden

Updates:

Fixed link to stm32-blink.tar.bz2
Changed links to source packages to real links.
Added newlib patch for missing makeinfo
Added some additional links. For example to the ST Firmware Library and it's documentation.
Added link to the Reference manual of STM32.
Removed the newlib patch section.

Ok ... back again

Esden — Sat, 13 Dec 2008 00:00:00 +0000

It is really time that I write something here. It is nearly one year since I last posted something here. But I was doing some things in the mean time. ^^

First of all I finished my Diploma at the University of applied sciences in Rosenheim. Now I am working at the computer science chair of Prof. Radig. The name of the chair is "Image Understanding and Knowledge-Based Systems" it somehow sounds cool. ^^

But basicly I get payed for programming Common Lisp. My work now involves getting the high level systems running on the real Robot. Till now all the high level planning stuff was only running in simulation.

In my short free time I started the ELCO Project which should become a framework for developing Lisp based software for Embedded systems. But I have to write a more elaborate article on that topic.

And the last thing for today. I just released my first shot on the schematics of a really Open source Brushless Drive Controller. You can find the eagle schematic (yes I know eagle is not open but the open source alternatives just suck!) in a git repository on GitHub.

I also can only encourage you to subscribe me on identi.ca. I am posting bit more frequently there. ^^

Cheers everyone!

Apple and their Support

Esden — Tue, 13 Feb 2007 00:00:00 +0000

After a long time finally a new entry here.

Some time ago I owned a Powerbook 15". This one had a problem with its second ram slot. It was not detected by the system. I called Apple Care but they were not willing to fix that. I really was upset about that because it was a known problem. Still the serial number of my Powerbook was not in the range Apple considered affected by that problem. >_< Now I have a MacBook Pro 17" and some days ago my battery grew to its double size. Yes just like the one in this article here. I realized that only because my touch pad button was not clicking anymore and when I put my hand near the touch pad it triggered the button. Searching the web showed the article at Gizmodo above. I looked at the back of my laptop and was shocked.

Yesterday I called Equinux and asked what can be done. They checked my Serial number and said that I should bring my laptop over. So directly after work I went there and without much asking they took my battery and said that they will replace it. (That is something that I was not expecting after my experiances with my Powerbook.)

As I was already there I pointed out a little cosmetic problem I had. The band underneath the keyboard weared off and lost its matt look just some weeks after I got my Macbook. (I will post a picture of it later.) They also said with no hesitation that they will replace the whole top if I want to. The problem I have is that I need my laptop all the time for my work so I can not leave it even for a day for fixing. So they said that they will make a appointment with me so I can come over and the technician will replace it in one hour. That is what I call service.

Now they showed me that Apple can also have a very good support as long as you have a guarantee coverage on your hardware. I can only say that I am very happy that I bought Apple Care along with the MacBook. That will save me lots of money and annoyance in the future.

Lisp Machines

Esden — Tue, 29 Aug 2006 00:00:00 +0000

Some days ago I watched some Lisp Machine Videos. These films show what it was like to use a lisp machine and code on it.

I really have to admit that I was not surprised to see what wonderful ideas the guys had back then. Current OS's still have a long way to go to incorporate (copy) the functionality you had 20 years ago in LispM Operating systems like Genera. Apple as always is on the front line of incorporating this old stuff. For example Time Machine. The new feature that will be there in Leopard (the next version of Mac OS X). The idea of easily going back in time and looking at your files was there 20 year ago.

Still as I now know Time Machine is still far away from the idea the LispM developers had. There you had a filesystem that had versioning built in. You can tell you do not save files just like that. You save patches to your files. That is somehow comparable to having SVN as your filesystem. Just a bit more sophisticated.

Sure that is not the only thing. There are tons of others. Like objects that are mouse sensitive depending on what you are doing. Accessing the displayed object structures that are behind that what you see. And many more...

I do not want to let myself get carried away too much. The condensed idea I wanted to share with you is the following. Genera is amazing. And if you think that any currently known OS is cool then you know nothing. And if you think that Java and Eclipse are cool then you live in the stone age in the matter of knowledge.

Sit down, learn lisp. It may hurt at first, but the freedom is worth it. Others had to pay their lives for freedom and you only have to learn.

Lisp Interpreter in Java Script

Esden — Mon, 17 Jul 2006 00:00:00 +0000

Today I found something pretty nice a Lisp interpreter in Java Script.

I came to it through logowiki. I found it pretty amazing that you can run the example programs you have in your wiki. So I asked google about it.

The interpreter lacks some functionality like defun, defmacro and so on but I think it would be a nice base for creating logowiki like interpreter. I have not read the source yet but I think it may be a nice way to show someone how to create a simple lisp interpreter.

Compiling Binaries with sbcl

Esden — Mon, 10 Jul 2006 00:00:00 +0000

There is one thing that you really want to have when you are creating programs. You want to create binaries. You can give them to others so that they can run them, without the hassle of compiling your programs by themselves, or you do not want them to see your sourcecode for some strange reason.

When you look at ruby, perl, python or even the all praised Java (do you hear the holy horns play? >_< ) you will see that you always need to install the appropriate one with tons of libraries so that you can run the scripts. I know I know ... I already see you running in my direction with your blades pulled out. There are compilers and packagers out there that can create binaries and you can even create a static binary that runs without the need of additional libraries.

But think for yourself are these solutions good? Is it working well?

I remember trying gcj. I had a test program of some hundred of very simple and standard java code. It was screaming very loudly "I am not ready to do that, I am too young!" perhaps it is better these days but I can not imagine that it works as it should. I also tried a perl to c converter but it was even more a mess.

As you know I am playing around with lisp, common lisp to be exact. As most people I was thinking that it will be the same way it is with the languages mentioned above. But I could not be wrong more. There are compilers and today most of the implementations do not even have an interpreter. Most of them compile the code to at least bytecode. (I know ruby does that too, and Java too ... damn do not pick out every word I say separately) But sbcl for example (my implementation of choice for now) compiles everything. In CMUCL from which SBCL was inherited still has an interpreter additional to the compiler.

I wanted to try out how it works with compiling a binary. I first thought that it will work just like with gcc or other command line batch compilers but I once more could not be wrong more. What you do is start SBCL load all libraries you need with "require" or "load" also load your program code and initialize everything you need. Then you run:

(sb-ext:save-lisp-and-die "my_binary" :executable t :toplevel 'main-program-function)

After that you have "my_binary" on your disk and you can start it on every compatible machine. What it does is saving the state of the lisp with everything that is present at the time you run the command. When you leave out the :executable you get a core file that you can use to run with sbcl -core commandline parameter. The :executable command only adds to the core file the ability to be executed by the operating system. In fact sbcl binary is just this kind of core dump that was created at compiletime of sbcl. The :toplevel keyword says the save function which function should be called the next time the core gets loaded. In most cases it probably will be the main function of your program. But when you think about it a bit more you can imagine how much power it is to be able to say what function is the main function. ;) (I know it from the lowlevel embedded programming side of the world ;) )

But now comes up the Question. It is a coredump so what does it contain? Well there it comes. It contains everything. Really everything including all libraries and the lisp compiler. So when I compile the robots game I introduced in the previous post here I get a binary of 23MB (yes megabytes). That is pretty much. Sure it does not count if you have a really big system that is 100 times bigger but still that sucks somehow. I informed myself and now I know that there is something called "headless" in the works that will enable sbcl to create coredump with an integrated dynamic linker. This will make the binary significantly smaller and when you run your program it will dynamically link the libraries it needs. Just as it should be. Next thing is from the slime world. There is a profiler in the works that will be able to even more optimize the code so that you will be able to create really small binaries.

All that is of course only SBCL other, commercial lisp implementations, like LispWorks or Allegro, already have very efficient mechanisms to create such binaries. But as long as you do not need that stuff immediately you can stay on the open source side of the world. ;)

I hope that was interesting, and also hope to get some comments. That would encourage me to write more...

VIM7 Fun

Esden — Tue, 09 May 2006 00:00:00 +0000

At work I have to use a pretty nasty Windows based development environment for a microcontroller.

You can configure it so that it starts a text editor of your liking to edit the source files. This editor gets called when you click on a file or on an error message in the compiler output. The DE also accepts a setting for parameters to the editor. There are two meta character codes. One is for the file (%F) and the second for the line the editor should jump to (%L). The problem is that it uses the same settings for the error invocation as for the normal file opening.

I wanted to use VIM7 and the new nice feature of tabs. As vim also supports remote invocation I decided that I want the DE to open the files in one central vim instance.

It took me some time to find out the correct command line setting so I want to share it with you.

gvim --servername <some_distinct_name> --remote-tab-silent +0%L %F

Now some explanations.

--servername is needed so that it always finds the correct vim window.

-- remote-tab-silent is a directive that vim should start editing the file provided by %F in a remote window in a new tab if the file is not yet being edited. The "silent" addition makes vim not yield an error if there is no vim instance running yet, and start a new instance by itself.

The +0%L is there so that when %L is there vim jumps to that line but when %L is empty it does not jump to the end of file but to the beginning. That is why the 0 is there.

Ok I hope it is useful for someone. Have fun with VIM ;)

Update: Corrected the unvisible some_distinct_name ;)

VIM7 Released

Esden — Mon, 08 May 2006 00:00:00 +0000

Finally! After years of development a new major release of my and many others favorite text editor is there. It contains many new very nice and useful features:

Spell checking support for about 50 languages
Intelligent completion for C, HTML, Ruby, Python, PHP, etc.
Tab pages, each containing multiple windows
Undo branches: never accidentally lose text again
Vim script supports Lists and Dictionaries (similar to Python)
Vim script profiling
Improved Unicode support
Highlighting of cursor line, cursor column and matching braces
Translated manual pages support.
Internal grep; works on all platforms, searches compressed files
Browsing remote directories, zip and tar archives
Printing multi-byte text

Grab it here!

V for Vendetta

Esden — Fri, 17 Mar 2006 00:00:00 +0000

Hello everyone. It has been a very long time since I posted last time. My life was very hasty in the last time. But now I have something that I must share with all the people that want to take the time to read it.

I just saw the new filmy by the makers of Matrix. It was called "V for Vendetta". I do not want to write a critique of the film. I only want to say that it is a must see and take the message of the film as a starting point for some reflections.

The main message for me was that if we do not take care we could end up in a state where "People are afraid of their governments." We see many changes taking place that most of us do not see. Data retention, tracking, RFID... and so on.

The problem is that taking a side in the discussion if it is OK or not is also a problem already. If I say in my blog that I am on either side the internet will never forget that. And I may get in trouble in the future. So I will not take any side. At least not here. The reader should take a side by him/her self.

The biggest problem I see is that most of the People around us do not know about this changes. Most of them are not interested if the changes are made or not. Most of them say that it does not affect them. I think (and here I take a side) that it is a problem. I know that most people are not interested in politics. I can not say that I am a person that is politically active or really interested. I am in no party and I read news only as much as it is necessary to know if there are very heavy things happening. But one thing I know is that the changes our government is making are affecting us all and we all should open our eyes and think on which side we are. Not taking a side is the same as agreeing with the side that won. I took a side and will look for ways to express them in a way that will not get me in trouble in the future. I will be happy to hear any tips to how do that.

Rushing makes it ugly?

Esden — Sun, 15 Jan 2006 00:00:00 +0000

Slowly some more images of the new intel Mac's are spreading over the internet. Like for example kodawarisan.com.

There is a nice comparison of the old iMac G5 and the new Intel iMac.

You really see that it was made in a rush. The inside is not so pretty like in the predecessor. I hope that when Apple finally finishes the switch to Intel they will take the time to get not only the outside, of the machines, beautiful, as always, but also the inside.

I really hope that Apple will not lower their quality because of the switch to Intel. I know that not many people care about the insides. But if a product is not only beautiful, easy to use and ergonomic on the outside but also on the inside it really shows the quality. So once more I pray that Apple gets back on with the expectations we have.

Macintel wishes

Esden — Wed, 11 Jan 2006 00:00:00 +0000

Yesterday Steve announced new macs at Mac World Expo. And they have Intel inside. The brand new Core Duo! They are a dream!

I can't wait to get my hands on the Powerbook successor called Macbook Pro. It is a dream! Anyone willing to give me money?

Take a look at the beauty:

You can see more here.

They also released a new iMac with Core Duo inside. Also amazing but I need a portable upgrade.

I want to win in Lotto! ;)

Pixelpost

Esden — Mon, 03 Oct 2005 00:00:00 +0000

As you already know I have installed a photoblog on my site. I use Pixelpost for that. It is a pretty nice and simple system having nearly everything you need.

The problem is that this software is very crappy written. I installed it and tried to upload an image. Everything went ok only that the thumbnail has not been created for the image. I spent one hour debugging only to find out that it is failing because I have no jpeg support in gd2 php plugin. I do really not understand why people are not doing right error handling. At least the install script could have checked that! The calls to these functions are muted (not yelding anything on an error). I really could kill someone for that.

Spending another two hours on bugfixing the code I finally acheved that I do not get 20 error entries in my apache logs on a link click. I will try to collect all my fixes and post them to the pixelpost developers in the next days. But for that I have to spend another evening getting the code really clean because my fixes are pretty hacky for now. I really wanted that thing running.

I also added another WordPress plugin to integrate the latest and one random thumbnail image on my blog site. You find the plugin here. It worked without any hacks or tweaks. That is how I like a software to be. ;)

Lock bumping

Esden — Thu, 25 Aug 2005 00:00:00 +0000

Yesterday on HackADay there was a post linking to lock bumping. A very interesting technique for opening most of the current door locks.

It is a security vulnerability that is so severe because it is so terribly simple that it looks nearly like magic. A guy inserts a self made key into a lock, hits it with the head of a screwdriver and the lock pops open. Having only 10 most common bump keys you can open about 90% of the current door locks.

You can see a full video about lock bumping on the Toool home page here recorded on WTH this year. There is also a list of locks that are not vulnerable to the bumping attack.

I really encourage you to check if your door lock is vulnerable and get a new one if you can. The only real problem is that there are not many good lock under 100Eur level. But everyone knows how much security is important for him.

Security discussions

Esden — Thu, 25 Aug 2005 00:00:00 +0000

I just had a discussion with my father and with my granny about security issues ignated by the previous post.

My father and my granny say that one should not spread the information about a vulnerability and the way it may be exploited. One only should say that there is one and that one should change something and what to change.

I think in the contrary that when I do not tell how to exploit a big security hole no one will give it trust. Everyone will say that it is only a hoax and not truth because fixing the potential security hole is very expensive (to fix the security hole from the previous post you need to spend 100Eur or more).

I ask you for comments and statements about that. Also links to pages dealing with this problematic.

Catching up

Esden — Wed, 24 Aug 2005 00:00:00 +0000

Since the morning today I am working on getting all the images I have online. I want to do it before I start reposting my blog entries that are on my laptop. It is really not so easy as it seems. The images I get from my camera are all way too big for web so I have to downsize them. Sadly iPhoto does not have (or I am blind) an easy batch option for resizing images. I got a program called Downsize for that. I really ask myself why all that useful little stuff has to cost money. 20$ here 20$ there ... every little tool costs money. I am a poor student I do not have the money to pay every little tool I get and that nags suck badly and test time outs even more. I would prefer if the programs were free and there were donation buttons on their pages. I am really sure that the time I start working and have some pennies left I will donate money to every vendor of a useful program I use that is free and has a donation button. You may hit me on that later ;)

Ok I finish uploading the images and then I start to add all the blog posts that accumulated here on my disk ;)

Visit to Gdansk

Esden — Thu, 18 Aug 2005 00:00:00 +0000

Today my parents, my grandmother, my brother and I have visited Gdansk. It is a very beautiful city lying at the northern coast of Poland. I have visited some churches and marked called after a saint: "Dominican Market" my brother and I have bought two coats with Poland written on it's backs. Very nice stuff. (very warm ;) )

I am currently working on deBlog all the time. Work is progressing very slowly because every several minutes someone wants me to do something or, what is more common, I fall asleep. That are that damn climatic changes. I really ask myself if I ever get that thing finished if I continue to progress with my work like that.

I am making a lot of pictures here. I will upload them some time when I have better internet connection then here. I am currently connected to the I-Net line of my uncle and aunt. For some strange reason the provider allows full bandwidth only to single mac addresses that are registered. My mac address is not registered yet so I have only 5kb down and something around this upload. I hope now you can understand why I will not upload my pictures ;)

I hope to have better network in Warsaw. I will leave in that direction on Tuesday and my Grandmother has DSL Hardline now so I may have a better connection there ;)

I think that is all for today.... cu ;)

Leaving for Poland

Esden — Sat, 13 Aug 2005 00:00:00 +0000

Today about 15:30 I left Ingolstadt for a trip to Poland. My current final destination is Gdynia at the coast of Poland. I have about 5 hours driving behind me and my head aches a bit. I hope that is over after I cached some hours of sleep.

Thanks to Blindcoder I do not have to drive the whole way to Gdynia in one peace but can make a stop in Berlin from where I am writing this entry now. I really missed a GPS navigation program or device. I did not have a detailed map of Berlin and leaving Ingolstadt I did not have the address of Blindy.

I searched the net a bit to find some Mac OS X software that can show me maps at least but did not find anything for now. It would be really great if it would be able to use GPS data too. Blindy has a usb GPS mouse that he offered me but that will not help until I find some software that can work with that.

I will really have to think about buying a TomTom or so if I do not find anything. Please let me know if you find or know some OS X GPS "navigation" software.

Now I go sleeping my head is bursting ;)

Pallas is back on!

Esden — Thu, 11 Aug 2005 00:00:00 +0000

That was a hard day yesterday. I woke up in the morning to find out that the server my blog is on is down.

I talked to a friend of mine that also has his servers hosted at Hetzner and got the information that the provider wrote an e-mail some days ago that they will add UPS to the server room and that the admins have to stop their machines due to a power down caused by the change.

I am not the admin of the server but a friend of me that left to Turkmekistan (I hope that it is written that way) last weekend. So I did not have that information.

After calling my friend and getting username and password of the Hetzner robot I called the technician of our provider. He checked our machine and realized that the hardware was broken and he will change it. It took some minutes and he called back saying that the hardware is changed but that rock is not finding the network card.

I booted to the rescue system and took a lot of time to check what was wrong and recompile the kernel with tulip drivers that were missing.

After a reboot (my adrenaline was at 150% during the reboot (we do not have an automatic reset only a manual that takes a lot of time to be triggered) (we need a hardware reset to start the rescue system)) everything was back to normal.

That was the story of pallas aka www.esden.net ... the pure adrenaline ;)

Sitecom USB to Serial on Mac OS X

Esden — Thu, 11 Aug 2005 00:00:00 +0000

The day before yesterday I have bought a Sitecom USB to Serial cable (UC-104). The common problem with such cables is that there are no drivers from the producer for Mac OS X. The good thing is that most of these cables use a Prolific chip. Prolific is offering a driver for cables based on their chip on their site.

When I connected the Sitecom cable "About this Mac" reported that it is a Prolific but the driver did not load. I figured out that it is the Vendor Id and Product Id that were not matching.

I had to edit /System/Library/Extentions/ProlificUsbSerial.kext/Info.plist and change the vendor and product Id's apropriately. (You can do that with every cable that has a prolific chip in it)

And after that I had to run kextload /System/Library/Extentions/ProlificUsbSerial.kext . And imagine what was the biggest problem I had. Yes exactly that I forgot to run kextload >_<

But now it works and through my post it is hopefully helpfull for someone that googles for this cable and mac ;)

(if it was usefull for you write a comment! I will be very happy about it ;) )

Lightspace

Esden — Wed, 20 Jul 2005 00:00:00 +0000

Looking through pages writing about the OLED Keyboard I have found something very nice.

I have seen something made by some students at MIT before but this one is a commercial pendant to it. An interactive blinking floor and wall. It was made by Lightspacecorp and you can see some videos here.

I really have to admit that it is a nice thing something in the style of the lighting dancefloors known from the 80's disco. I really would like to see that in some club nearby so I could dance my ass off on it ;)

OLED Keyboard updated!

Esden — Mon, 18 Jul 2005 00:00:00 +0000

Good news everyone!

From the new FAQ on the Optimus keyboard homepage:

It's in initial stage of production

We hope it will be released in 2006

It will cost less than a good mobile phone

It will be real

It will be OS-independent (at least it can work in some default state with any OS)

It will support any language or layout

Each key could be programmed to produce any sequence

It will be an open-source keyboard, SDK will be available

Some day it will be split ('ergonomic')

It will most likely use OLED technology (e-paper is sooo slow)

It will feature a key-saver

Keys will use animation when needed

I snipped out some uninteresting stuff (see their page if you still want to read them).

The most important thing is that it will get real! Weehoo! I have to save money to buy it in 2006 ;) The open source thing is also veeery nice ;) The other things too. ;)

I am already looking forward to that shiny lightning keyboard!!!

An Oled Keyboard

Esden — Thu, 14 Jul 2005 00:00:00 +0000

Fascinating! Through Slashdot in this article I have found the keyboard of my dreams!

In every key there is an oled display that shows the current function this key has. I was thinking about something like that some time ago. I should have patented it :/

I only hope that some day someone will produce such a keyboard!

You really need Unittesting!

Esden — Sun, 10 Jul 2005 00:00:00 +0000

Some days before I wrote about how important Unittesting is and thanks to Uwe's Blog i got another proof.

That reminds me of writing the diff code for Diagnostics. The tests were fundamental in gaining a bit of trust in the quality of the code I have written. They triggered one bug after another... that was already in the code that I based mine on (the original code had no Unittesting or anything in the style). I only can shake my head about people not realizing how important that is.

Apropos that some days ago I told someone about Unittesting his response was really ridiculous: "writing that tests is real bloat I really do not have time to run the tests after changing one line code". Read the article then you will understand why you will _take_ the time to run the tests! ;)

Objective C

Esden — Thu, 07 Jul 2005 00:00:00 +0000

Da ich endlich mal was in XCode fuer Cocoa coden will habe ich heute angefangen bisschen auf der Developer Seite von Apple zu lesen. Da gibt es eine ganz nette Einfuehrung ins Objective C.

Diese Sprache ist C mit Zusatz von Smalltalk so das es objektorientiert wird. Ich finde es ganz nett.

Ich bin gespannt wie es sich dann anfuehlt wenn man es dann letztenendes programmiert. Ich habe schon das entsprechende Projekt dafuer naemlich ein Blog Schreibprogramm ala ecto. ;)

IPod Wood Mod

Esden — Wed, 06 Jul 2005 00:00:00 +0000

Ich bin gestern durch Slashdot auf einen super geilen iPod mod gestossen. Der Wood mod. Das tollste daran ist das es mit der Hand gemacht wurde. Eine tolle Arbeit muss ich sagen.

Es gibt aber trotzdem paar Sachen anzustreichen. Ich finde dadurch das es so dick lackiert ist sieht es zumindest auf den Photos wie aus Plastik aus. Obwohl wenn ich mir vorstelle wie es in Wirklichkeit aussehen kann denke ich das es schon in Ordnung ist.

Zweitens ist die Verdeckung vom Clickwheel so ausgebaeult. ich finde da haette man die Teile so anpassen sollen das es eine glatte Ebene ergibt so wie es bei dem Orginal iPod der fall ist. Denn so verleiht es einen klobigen Look und bricht mit der Sauberkeit des Orginaldesigns. Finde es aber ok das das Clickwheel aus einem anderen Holz ist als das Frontpannel. Das sieht ganz gut aus.

Alles im ganzen eine ueberwaeltigende Arbeit wie man es an den unzaehligen "Wow" und "Wooot" Kommentaren erkennen kann.

Da kommen schon gleich weitere Ideen wie man THC vielleicht Designen koennte ;)

Rebooting the Universe

Esden — Tue, 05 Jul 2005 00:00:00 +0000

Da ich momentan mein komplettes Webseiten Verzeichnis umraeume und neu strukturier bin ich auf was etwas was ich mal geschriben habe geschrieben habe.

Ein Vorschlag wie es aussehen koennte wenn man das Universum rebooten wuerde. Ihr koennt es euch hier durchlesen.

Wenn jemand von euch Verbesserungsvorschlaege hat darf sie logischerweise mitteilen. ;)

Coden ohne Diagnostics

Esden — Mon, 04 Jul 2005 00:00:00 +0000

Soo ... ich bin jetzt total am ende. Es ist verdammt spaet ich sollte Schlafen da in drei Stunden ist wieder Uni.

Ich habe mir dieses ecto geholt wie ihr vorhin lesen konntet. Nun ein ganz nettes ding wenn es funktionieren wuerde. Ich habe einen bug wie schon geschrieben behoben der es nicht erlaubte ueberhaupt was zu machen. Das ding schafft es aber immer noch nicht kategorien von den Posts richtig zu setzen.

Da kommen wir direkt zu dem was ich hier ansprechen wollte. Ich habe viele Stunden damit verbracht Serendipity so hinzukriegen das es mit ecto sprechen kann. Es ist einmal ecto das nicht richtig das XMLRPC Protokoll implementiert und Serendipity das es auch nicht richtig tut. Aber das ist nicht das schlimmste. Ich wuerde alles ziemlich schnell zum laufen bringen wenn man Serendipity vernuemftig debuggen koennte. Es faehlt vernuemftiges logging. Ich kann keine richtigen debug Ausgaben produzieren. Alles muss man per hand irgendwo in eine Datei machen.

Es gibt noch ein Problem. Das ding ist nicht richtig getestet. Warum machen die leute keine TESTCASES? Verdammtnochmal! Warum testen die ihre software nicht! Wie zum kuckuck kann man software entwickeln ohne richtiges logging und testing? Kann mir das jemand erklaeren?

Jetzt habe ich lust wirklich mein eigenes Blog System zu schreiben mit einem vernuemftigen Mac OS X, Windows und Linux Client. Das kann doch nicht eingehen das jeder macht was er will. Testet die software mit einem Blog system und meint das alles in bester ordnung ist. Genauso umgekehrt. Leute schreiben Blog Systeme und testen die mit einem Client und meinen das alles in ordnung ist. Dann halten sich alle nicht richtig an die Standards die wunderbar in RFC's geschrieben sind. Wobei die RFC auch wieder nicht alles richtig definieren. Wie zum beispiel sollen die kategorien verworfen werden wenn man zu editPost Funktionsaufruf keine kategorien mitgibt?

TESTET euren scheiss!!! Schreibt TESTCASES!!! Macht multilevel LOGGING!!! Ihr macht euch selbst und anderen ein gefallen damit.

Durch diese geschichte wurde ich wieder davon ueberzeugt das OpenSource Software von Kiddies die keine ahnung haben geschrieben wird. Von Anfaengern die meinen das wenn man drauf los coded alles gut wird! GNAAARF!

Ich habe mommentan echt lust eine Kettensaege zu nehmen und auf irgendeine PHP Con zu gehen!

Soo es reicht von dem Rumgeschreihe.

Schoenen guten Tag wuensche ich euch allen!

Probleme mit ecto und serendipity

Esden — Mon, 04 Jul 2005 00:00:00 +0000

Nun ... durch das ganze Rumgespiele mit ecto und XML-RPC von Serendipity habe ich diesen schrei Post vorhin Geloescht.

Edit: Nun wie man sieht habe ich den post wiedergefunden ... naja ;-)

Ich schreibe jetzt deshalb alles neu bissel ueberarbeitet und nicht mehr so frustriert. ;-)

Ich habe ziemlich lange nach einem guten Programm gesucht mit dem ich offline Blog Eintraege bearbeiten kann um sie dann hochzuladen. Ich habe MacJurnal ausprobiert das einfach zu viel bietet an Sachen die ich nicht brauche. Ausserdem war es von der Bedienung nicht richtig angenehm weil es uhrspruenglich dazu gedacht war private Tagebuecher zu schreiben und nicht als Blog Editor.

Ich habe auch iBlog ausprobiert. Es ist zwar frei aber dafuer kann es nur zu blogger hochladen und es gibt keine moeglichkeit einen anderen Server auszuwaehlen.

Als letztes bin ich dann bei ecto steckengeblieben. Es hat ein super Benutzerinterface, kann mehrere Server verwalten und mehrere Blogs. Es unterstuetzt auch mehrere Blog Protokolle zum hochladen und bearbeiten der Posts. Leider Implementiert es die Protokolle meiner meinung nach nicht richtig. Nachdem ich Serendipity gepatcht hatte war ich in der lage ueberhaupt hochzuladen und auch Posts zu synchronisieren.

Leider war ich bis jetzt nicht in der lage es hinzukriegen das wenn ich einen neuen Post mache das er keinen Draft zusaetzlich noch dazu erstellt und das er die Kategorie nicht setzt. Es liegt hier wohl nicht an ecto sondern an serendipity. Ich muss jetzt immer nachdem ich einen post hochgeladen habe nochmal den Post bearbeiten die Kategorie nochmal setzen und dann updaten. Wie gesagt ich bin mir hier in dem fall nicht sicher wer falsch arbeitet weil in dem RFC ueber metaWeblog Protokoll ist nicht genau spezifiziert was passieren sollte wenn man editPost sendet ohne Kategorien fuer den Post mitzuschicken. ecto geht davon aus das die Kategorien nicht angeruehrt werden und Serendipity meint die Loeschen zu muessen. :-(

Nun ich wuerde gerne jetzt mein eigenes Blog System und einen Blog Client schreiben. Aber wenn ich bedenke wieviel Zeit es mich kosten wuerde es richtig zu machen vergeht mir auch wieder die Lust.

Noch eine weitere frage draengt sich dann noch auf. Wenn ich mir den code von Serendipity anschaue. Warum gibt es da kein Logging? Und warum keine Testcases? Man sollte doch seine Software testen und debuggen koennen!? Es ist echt schwer mit dem ding umzugehen und drinnen Faehler zu suchen wenn sowas nicht drinnen existiert

Und ich wiederhole noch eine aussage aus meinem vorrigen und leider geloeschten Post:

Leute TESTET euren scheiss! Schreibt TESTCASES! Benutzt multilevel LOGGING! Ihr macht euch und den anderen einen riesen gefallen!

Wenn ihr meint das es zu viel zeit kosstet dann lasst es ganz oder schliesst euch einem anderen Projekt an und fuehrt es bei denen ein! Und wenn die anderen meinen das es nur stress ist oder aehnliches FORKT deren Projekte! Die qualitaet wird letztenendes ueber Featurism eh gewinnen!!!

Nun ... ich werde mir jetzt ein Blog System aussuchen und versuchen es zumindest bisschen auf vordermann zu bringen. Oder ich rede noch mit paar Freunden von mir und wir fangen wirklich ein eigenes Blog System zu bauen ;-)

Homebrew Game Console

Esden — Sat, 02 Jul 2005 00:00:00 +0000

Soo gehen wir ueber zum naechsten Thema. Ich habe mir gestern vor dem schlafen gehen paar Gedanken gemacht. Da ist mir eingefallen das ich mal schauen koennte ob es jetzt doch endlich ein THC aehnliches Projekt gibt. (Zur erklaerung THC bedeutet "The Handheld Circuit" und ist ein Projekt von mir eine Open source Spiele Console zu bauen) Nun stellt euch vor ich wurde fuendig.

In dem Forum von Game Park 32 Extreme. Da gab es einen Thread wo jemand vorgeschlagen hat die Game Park 32 in Eigenregie nachzubauen mit einem schnelleren Prozessor. Da haben die leute sehr positiv drauf angesprochen und jetzt gibt es eine Webseite dazu http://ninja.gp32x.de/. Nun ich habe mir deren erste Layouts angeschaut und war nicht sehr begeistert muss ich sagen. Die Leitungen gehen total durcheinander und haben verschiedene Laengen. Das ist ein Problem, vorallem wenn die Leitungen eine Verbindung zwischen dem Prozessor und dem Ram sind der mit 133MHz angesteuert wird. Aber vielleicht haben die Glueck und es wird funktionieren. Ich wuensche es denen. Es gab noch paar weitere Faehler im Layout wie zum Beispiel waren die Vias zu nah an Loetpunkten (man hat dann Probleme mit der Hitzeverteilung und es ist schwer das zeug maschinell zu loeten) und die Leitungen sind teilweise so alsob jemand die per hand gezeichniett hette. Da freut sich kein Platinen Hersteller darueber ;-)

Naechstes problem ist das die sich fuer Chips mit FBGA(Ball Grid Array) Gehaeusen entschieden haben. Das problem dabei ist das man nicht die Chips per Hand loeten kann (OK mit viel Glueck und viel zeit kann man mit einer Heizpistole es vielleicht schaffen aber das ist mit wenig spass verbunden und man kann leicht den Chip dabei vernichten) das ist ein wirkliches Problem wenn mann die Hardware noch entwickelt. Ein weiteres noch Groesseres Problem ist das man nicht an die anschluesse des Chips drannkommt wenn man noch am debuggen ist. (Ein Oszi ist bei Hardware Debugging ein muss! Glaubt mir!) Ok genug geschimpft.

Ich wuensche den Jungs trotzdem viel erfolg. Die haben ein halbes Jahr zeit. Wenn die bis dahin was cooles auf die beine gestellt haben dann schliesse ich mich denen vielleicht an ansonnsten bin ich da vorraussichtlich wieder bei meiner Firma wo ich mein letztes Praktikum gemacht habe und THC wird fertig auf die beine gestellt. (Zumindest ein Prototyp aber ich glaube das ist in einem halben Jahr machbar ;-)

Soo ... ich glaube das reicht fuers erste. Ich werde vielleicht noch was nachtragen. Aber jetzt gehe ich weiter die Unterlagen fuer Englisch Pruefung lesen ;-)