[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:

• STM32 Reference Manual
• STM32 Firmware Library and it’s Documentation
• Olimex STM32-H103 Board Site

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.

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!

So I did it and now it seems that all examples are working. Ok … the varray example is not working. It somehow is not willing to compile for me and I am too lazy to look into this problem. (perhaps next time)

You can get it here.

Have fun!

Most examples seem to work. The ones that do not work need a more complicated fixing. But the API should run correctly. (I hope so ™)

You can get the first version here.

I will try to continue testing and fixing the bindings. I i do so there will probably be also a repository for it. Who knows … ^^

I have tested it with sbcl 1.0.12 on a Leopard driven MacBook Pro.

Have fun

P.S. Greetings from 24c3 ^^

P.P.S … I made a screenshot that is attempting to proove that it is really working: shot

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.

Because of an idea I have, that is not yet ripe for decision, I was trying to get a graphics library that is portable and has a Common Lisp binding. Finally I got stuck on opengl and cl-opengl binding. I had a hard time getting it to run on Mac OS X so I tried it on Linux first where it worked out of the box. It is pretty nice even if making a mistake sometimes kills your lisp.

To install cl-opengl you need a Common Lisp implementation (I use sbcl), cffi (I used cffi 0.9.1), an opengl library (I used the one shipping with Mac OS X) and GLUT (I used OpenGLUT but more on that later).

First I tried to get cl-opengl running with the native Mac OS X GLUT implementation but it did not work. I found information on the cl-opengl list that you need FreeGLUT. The problem with FreeGLUT is that it does not compile on Mac because of some joistick problems.

So… get the source tarball of OpenGLUT.

Untar it and run “CPPFLAGS=”-I/usr/X11R6/include” ./configure”. You need the CPPFLAGS variable because otherwise the build system will not find the right opengl headers.

Now run make and make install. In my case I added the option –prefix=/opt/mine to configure to not taint the running system with self compiled stuff.

Finally you should end up with OpenGLUT libraries.

Now download cl-opengl (probably using darcs “darcs get http://www.common-lisp.net/project/cl-opengl/darcs/cl-opengl/”)

Link the .asd files to your sbcl systems directory:
# ln -s ~/cl-opengl/*.asd ~/.sbcl/systems

The problem with OpenGLUT is that it uses X11 to create windows. So you have to start the Mac OS X X11 server and start sbcl in the xterm within X11.
After starting sbcl you can run at the repl the following:
* (asdf:operate ‘asdf:load-op ‘cl-glut-examples)

That should compile and load the cl-opengl cl-glut and cl-glu bindings and also cl-glut-examples.

Now you should be able to test it running:
* (cl-glut-examples:gears)

on the sbcl repl.

Conclusion:

cl-opengl binding is really nice. It still needs work so that it catches all errors that may occur. Doing something unpredicted with opengl may cause your lisp process to crash.
It also requires at least FreeGLUT that is not willing to compile on Mac OS X but that is understandable because GLUT itself misses some features that are required to create really dynamic applications what is what you want. OpenGLUT does compile on Mac OS X but seems to be pretty old (2005 last release) and just like FreeGLUT requires X11. That is really nasty. I do not want X11 :(

It is usable it is pretty nice but there still is a lot to do! I will for sure dive more into that stuff and try to fix at least some of the problems I found.

But nonetheless thanks OpenGLUT and cl-opengl guys for your fine work! Now I can finally create some nice graphical stuff! Woot!

One more thing… the cl-glut-examples:gears demo gives the following frame rates on my MacBook Pro:
23857 frames in 5.0 seconds = 4771.400 FPS
24407 frames in 5.0 seconds = 4881.400 FPS
24316 frames in 5.0 seconds = 4863.200 FPS
24293 frames in 5.0 seconds = 4858.600 FPS

I think it is amazing! Tell me what framerates you get! ;)

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.

Still there are some points you should be careful about. First of all the image you want to flash has to be for R8C or M16C respectively. The problem is that the addresses contained in the images have different order (endianes) depending on the chip. The sample srecord image contained in the tarball from Fischl is for _M16C_ and _NOT_ R8C.

Next thing is you should try to use a real hardware serial interface if you get problems with a serial to usb converter. We found out that even if the converter contains a prolific usb to serial chip it does not mean that it will work. We have two cables here and we know that Sitecom works.

We will probably write a patch for the flasher program containing some additional documentation and some checks and timeouts. The checks should validate the addresses one wants to flash are valid for the chip, and the program should timeout if it does not get data back from the chip during flashing. At least that is our TODO.

More information to come. ;)

[Update] Added some links.

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.

I heard from a friend that I missed ecls in my last post. He said that it is possible to compile Lisp to C with it and then you can crosscompile the resulting C source to any architecture you like. But that simply does not feel right. That is only a hack. You miss the things you want the most (beside Lisp itself) REPL and with it the integrated inspector and debugger just like the profiler and tracer. Also you miss binary upload of functions. Think for yourself. If you do not have that things does development with lisp feel like it should? If you ask me it does not.

So I searched further. I knew that there was someone who developed the triple L, Mars and Venus. I did not know what it exactly was but I knew that it was a lisp development environment for embedded systems.

Looking more in depth in to that, I had to realize that the only thing that exists is the paper L – A Common Lisp for Embedded Systems (pdf format is here) by Rodney A. Brooks and Charles Rosenberg. This paper is telling a beautiful story about a development system that would be the thing one would like to have. But you can not get it anywhere! On the page of Charles Rosenberg you find the pointer that the company IS Robots (that was developing L, Mars and Venus) is now iRobot (yes the Roomba guys). Searching their site does not say anything about lisp though.

The only other person bringing iRobot together with Lisp is Lemindor I have not read all his posts yet but he does not really say anything that helps me neither.

I also asked about the topic in #lisp on freenode but it seems that the overall opinion is that everyone is brewing his own Lisp if he/her wants to use lisp on embedded system.

That is really bad news. I was hoping that there will be something I will be able to base on. The only solution that I see now is to take some common lisp implementation and port it to some embedded system. And when it works start changing it and splitting in parts so that it fits development on embedded systems. (you do not really want the compiler on your embedded system normally an interpreter is enough)

That somehow sounds pretty big and heavy. :(

The second solution would be to start with a small Lisp implementation by oneself. When you read Paul Graham’s article Roots of Lisp you get the feeling that it can not be that hard. But still I think that is probably a false feeling. But if I had the power and money to hire some people that are bright enough I think I would attack that. I even know some people that are bright and that would be able to create such thing but none of them would want to invest their time in such a project when they do not get money for that. So there is high possibility that Lisp on embedded systems will remain a dream. :(