Esden's Blog - open-brushless-drive-controller

Open-BLDC and the CLogic story

Esden — Sun, 15 May 2011 00:00:00 +0000

[embed]https://www.flickr.com/photos/esden/5188383797/in/album-72157625281995565/[/embed]

Hi,

It was again a while since my last post, but as always I was quite busy. :)

The last news about Open-BLDC was about its V0.3 iteration. A lot has changed and happened since then. I was realizing that I am getting more and more inquires where people were asking about obldc being able to control very different sizes of motors, ranging from 12V and 10A up to 48V and 200A.

This requirement does not really ask for different logic and controls but it definitely asks for many different power stages. Open-BLDC was designed to be modular from the beginning but still to accomodate that kind of a power range it would be necessary to design and create quite a big lineup of hardware.

Around that time I had the opportunity to take a look inside a dead motor controller from Castle Creations just to realize that these guys seem to know what they are doing and that they went with a modular design too. To make a long story short I decided that it will be better to buy one of their of the shelf motor controllers and retrofit them with my logic. That is how CLogic was born.

As it seems other manufacturers are selling ESCs that have the same interface between the logic and the power stage too. Tekin for example. But my guess is that they are just OEM of castle themselves. But who knows. :)

Turingy also came out with an ESC that seems to have the same interface, the Turingy dlux. I ordered a few of them to take a look for myself and see if CLogic will fit in there. That would be a great source of cheep power stages. :)

CLogic has most of the functionality the Open-BLDC v0.3 had. Because of the size constrains I had to get rid of the dedicated i2c and PPM connectors, but I added isolation on the CAN interface that should provide additional safety when used on a 50V and bigger systems. The i2c and PPM interfaces are still available either over the new AUX connector or through the UART interface connector.

The new AUX connector gives the possibility of easily connecting encoders or hal sensors for sensored operation. So the interfaces stay very flexible with added flexibility due to the big variety of power stages you can use, while being very very compact.

Sure some people complained "The power stages are not Open-Source!!!", yes that is true. Also these systems start at a higher power and weight class than some of you would want to operate them. That is why there is CPico Power. It is a very small, low power and a hopefully cheep power stage that we are putting together for those who want it all fully open! So no worries. :)

I think that wraps up the news about the new direction Open-BLDC is going. I hope you like it. I am looking forward to your comments.

Cheers Esden

Open-BLDC V0.3 Hardware Based Closed Loop Control

Esden — Sun, 19 Sep 2010 00:00:00 +0000

Hi,

Good news everyone!

After again a way too long time some new news! I finally implemented hardware based commutation detection and the associated closed loop controller.

That was quite a run because of a cascade of timing and timer problems. And a very nasty compiler bug. But now it works and very well on top of that. Woohoo o/ But see for yourself in the video.

The video also shows the new implementation of the startup routine. It uses now a separate software timer. It was made possible by using SysTick as timer base and implementing the timer in software. This way it is easy to add new timers that don't need to be very time precise, as it is the case in startup, or ignite as I like to call it. :) The old implementation was using timer overflows of the commutation timer that led to nasty speed jumps while starting up and made the startup unreliable.

Next step, put Open-BLDC on a plane! :)

As always you are welcome to drop by in #open-bldc channel on freenode if you have questions or just want to hang around to follow the cutting edge development. :)

Open-BLDC Documentation

Esden — Thu, 19 Aug 2010 00:00:00 +0000

Today was a big documentation day for Open-BLDC.

As Tobi is learning about Open-BLDC to be able to help me with development I really felt the lack of documentation. So together with him we wrote down how the ignition system currently works. Also I added a getting started page describing how to build the firmware.

Last but not least (that took me most of yesterday) I finally managed to add doxygen generation to the firmware code. It is even being automatically generated out of the git repository and making it available on http://doc.open-bldc.org.

There is still a lot that can be told about the system, but I think we are on the right path. The documentation should grow now significantly when I am not the only person working on the code. :)

Open-BLDC v0.3

Esden — Thu, 05 Aug 2010 00:00:00 +0000

Hey everyone!

Just a short update so that you don't think that I have disappeared completely. :)

Lately I am really busy so that is why my updates here are very rare. I have moved to California few months ago to work full time on Open-BLDC and Paparazzi. Although Open-BLDC got quite a bunch of attention there is still a lot to do, and this project is still not in a state where it is possible to put the controller on a vehicle and fly with it. :(

There is some good and bad news. I got the sampling based commutation detection running pretty good. There is an issue with it. Because you can sample the BEMF only once a PWM cycle the resolution prevents turning the motor very fast without adding some kind of an estimator or at least a PLL. So currently only 4000RPM with a 7pole pare motor are possible. :(

That is why I started working on Open-BLDC v0.3 hardware. It is assembled now and you can look at some pictures here. It has a comparator integrated into the power driver board to make commutation detection really easy and have something usable _NOW_. I also found out that using many small mosfet's is much more efficient then using single big ones. The gate capacitance is lower, the heat dissipation is easier, the on resistance is tiny. The only question is if they will distribute the power evenly between the switches. That is still something that has to be tested. But the power stage board looks really pretty with all those tiny fets on it. There are many more other smaller and bigger improvements that would be too much for such a small post.

I am currently bringing up one subsystem after another. I had to change some of the connections to the STM32 which means that I have to change the low level drivers and it is always a pain to do.

Anyways, there is progress and Open-BLDC is not dead! I am working on it. And I am sorry for not keeping you guys more up to date. As always I will try to be better about that. ;)

Open-BLDC V0.1 Fully Assembled

Esden — Sat, 08 Aug 2009 00:00:00 +0000

I finished soldering Open-BLDC V0.1 boards and took some pictures while doing so.

After connecting it to the power everything seems to work properly and nothing is burning. That is really good news.

One little thing that is bothering me. The board draws 60mA, what is a value that I expected. The 5V linear regulator gets really warm. I am not sure if that will be a problem or not. But I did not find any other problems or screwups yet, even the big MOSFETs can be soldered using a simple soldering iron. It takes some time though, because the board and the MOSFETs are monstrous heatsinks.

More news coming up as soon as I start playing around with the software. [gallery]

Open-BLDC V0.1 is alive!

Esden — Fri, 07 Aug 2009 00:00:00 +0000

I assembled the basic STM32 circuitry of Open-BLDC and it works. I also made a video showing the logic board and blinking around. I know it is a bit pointless but I love blinking LED's! ;) I wrote the software using libopenstm32.

Have fun:

Video on Youtube and here the same video on Vimeo.

While assembling Uwe and I made some photographs that I don't want to hold off either.

[gallery]

Open-BLDC V0.1 boards are here

Esden — Wed, 05 Aug 2009 00:00:00 +0000

Good news everyone! The Open-BLDC boards are on my table. If you ask me they look gorgeous. :) But decide for yourself ...

Cheers Esden [gallery]

Open-Source and Open-Hardware Multicopter platform

Esden — Fri, 24 Jul 2009 00:00:00 +0000

Over the last two weeks many things happened. I found out that there is a really open-source and open-hardware quadrocopter project in the wild. It is called booz and is part of the paparazzi project. Code and schematics just as board layouts are under the GPLv2 or later license. That is really awesome news.

This project is intended for research and universities so the boards are using BGA parts that are difficult to solder for a mere mortal, and there is some lack in documentation. That is why some other people and me started a project called openmulticopter. The basic idea is to create and maintain a completely open-source quadrocopter/multicopter platform for everyone. As a multicopter does not consist only of the control electronics but also contains parts like remote control receiver, brushless motor controllers, a frame, and so on, we tried to combine many open-source parts that are already out there. Just take a look into the wiki for more details.

Some highlights of open-source components that we have chosen so far are:

booz (the core of the platform)
libopenstm32 (firmware library for STM32 microcontrollers)
RCOPEN24 (a 2.4GHz remote control system)
open-bldc (brushless motor controllers)

We also formulated a mission statement that can be found in the openmulticopter wiki.

There is still a lot of work in front of us, but I am really happy with the progress we are making. If you are interested in contributing just drop into the #openmulticopter IRC channel on Freenode, or write an email to the mailing list.

PWM Schemes/Fieldvector Control

Esden — Fri, 24 Jul 2009 00:00:00 +0000

Some time ago I announced the Open-BLDC project in the Mikrokopter Forum, the post, that you can find here inspired a very interesting Discussion. One of the topics were PWM Schemes and why one should think about them. The most important reason is efficiency. Most controllers to use H_PWM_L_ON or H_ON_L_PWM schemes. An alternative is PWM_ON_PWM scheme which prevents currents through freewheeling diodes connected in parallel to the MOSFET's. The freewheeling diodes have higher losses then a MOSFET. I am really asking myself why it is not used. One reason I can think of is that this scheme has 12 steps instead of 6 and therefore is more difficult to implement and BEMF measurement for commutation detection may be more complicated.

Another approach to the efficiency question may be using fieldvector control. This involves a sinusoidal pwm scheme and current measurement on the phases. Using that way of control should decrease torque ripples which are typical the other schemes mentioned above. It also involves a lot more work on the firmware side.

I started building a rig for testing the efficiency of the different schemes. It involves a harddisk platter connected to the motor and two harddisk magnets. At the end I will have a eddy current break and can measure how much current is needed to achieve a specific rotation speed. I hope that this way I will be able to make a more or less scientific comparison of control approaches.

If you have a motor controller I would be really happy if you could take an oscilloscope and record the voltages on the phases. I am really interested what control schemes others use.

Open-BLDC mockup

Esden — Wed, 01 Jul 2009 00:00:00 +0000

Hi!

As you already know I have layouted the Open-BLDC boards. I was not sure if everything fits mechanically. So I took some cardboard and created a mechanical mockup. It really looks good! It is darn stable (even though it is only cardboard and not FR4) and the screws fit snugly. I think we are getting really near to a state where I can order some boards.

You can take a look at some images attached to this post.

Have fun! :)

[gallery link="file"]

Open-BLDC SMD prototype and final prototypes

Esden — Mon, 29 Jun 2009 00:00:00 +0000

[caption id="attachment_252" align="alignright" width="150" caption="Open-BLDC SMD Prototype"][/caption]

It has been again a long time since the last post. (I have the feeling to repeat myself here)

There have been some news on the Open-BLDC front. I have been on Motodrone two weeks ago. Because I took the plane to get there I realized that it will be too difficult to take the breadboard prototype with me. So on a short notice I soldered together a smaller version using smd parts. As an extra feature this prototype includes Allegro hall based current sensors. These will enable us to investigate vector control (aka. field-oriented control).

At first it worked perfectly. Sadly after some tests I burned two of the three bridge drivers. I only had one spare to replace, so I could not work on the software for long. Today I got replacement bridge drivers. Now I should have enough spare ones to compensate for more burning. ;) So no news on the vector control front yet.

[caption id="attachment_255" align="alignright" width="150" caption="Open-BLDC Logic Board V0.1"][/caption]

[caption id="attachment_257" align="alignright" width="150" caption="Open-BLDC Powerstage V0.1"][/caption]

But I was not lazy while waiting for the replacement parts. I finalized the circuit and routed the logic board and powerstage. The powerstage was more or less straight forward but I am not very happy about the size and dimensions. I just am not sure if it is fittable on a standard Quadrocopter. Still it should be good enough as first etched prototype.

A much bigger challenge was the logic board. I somehow came up with this crazy idea to constrain the size of it to 45mm X 20mm. Still after many many hours of struggling with that puzzle I managed to squeeze all parts and wires into 45.5mm X 21mm! Yes you are right I am pretty proud of myself. I am still a routing beginner so the result seems to be good for me. :)

Now I have to wait so some other people review the work I did to try decreasing the amout of possible bugs in this boards. (If you like you can clone the repository here and check the stuff out, and give feedback on the mailinglist. (please subscribe before posting! :/ )) When I feel confident enough I will order some boards for testing and we can finally concentrate more on the software. :)

Open-BLDC PWM Schemes

Esden — Sun, 10 May 2009 00:00:00 +0000

Only a short note. I made a video showing all the different PWM Schemes Open-BLDC supports. Have fun watching:

Cheers Esden

Open-BLDC Sensorless Commutation Detection

Esden — Thu, 07 May 2009 00:00:00 +0000

Hi!

As promised I made some videos. First one is showing the maiden run of a motor connected to the breadboard prototype of Open-BLDC.

(There is also a Vimeo version: Maiden Run of Open-BLDC from Piotr Esden-Tempski on Vimeo)

Yes the motor sounds like a truck. The reason is that I am making forced commutation (not detecting the right time to commutate but do it in fixed time) and the PWM duty cycle is higher then it should be. This way the motor is just jumping between the magnets and has a lot of vibrations.

The second video is a demo of sensorless commutation detection.

(There is also a Vimeo version: Open-BLDC Sensorless Commutation Detection Test from Piotr Esden-Tempski on Vimeo)

We are using a novel way without a virtual crosspoint. (you can read it up in this paper) We do it even a little bit differently then described in the paper, there are no comparators and latches. What we do is condition the signal to be in the range of 0V to 3.3V and sample it with the ADC at the right times. This is probably the simplest way to do something like this in the STM32. One can now play around with the data that the ADC delivers. I think there is a lot of stuff that can be done using such an approach.

In the video you may also wonder why it is so loud. Well the PC fan that I just forced onto the rotor is not really the best payload, also it is not balanced well and the bearings in the motor are not the best anymore because of the unbalanced load. ^^ I am also using the simplest and worst PWM scheme that I know of. The so called H PWM L ON scheme.

"H PWM L ON" PWM scheme. Click on the Image to see other PWM schemes.

You can also see in the video that the motor is pretty robust to external disturbances when running in the commutation detection closed loop. Still I am sure that it can be improved. (If you are interested the sourcecode running this can be seen here)

If I am not mistaken then only current measurement is missing in the circuitry. When that is done then I can design the first etched prototype of Open-BLDC. WOOO! :)

Cheers Esden

P.S. If you have any comments/ideas feel free to write them in the comment section. ^^

Open-BLDC status report

Esden — Sat, 02 May 2009 00:00:00 +0000

Hi!

It has been a pretty long time since my last post. But do not worry there is happening a lot "behind the scenes". Well not so much behind them because I commit everything I do to the github repository (http://github.com/esden/open-bldc). If you want to follow the progress you can also subscribe to the commit mailinglist and/or the discussion mailinglist. Feel free to write on the mailinglist if you have any questions or just catch me on #uavp channel on the freenode network. (I think that are enough channels of communication :) )

Ok back to the topic. Last week I was able to turn a bldc motor the first time using the bread board prototype of the power stage, the STM32 Olimex H103 evaluation board and firmware that you can find in the repository. The basic PWM scheme that is used by most controllers is implemented and works pretty well. I am also trying out other PWM schemes that may improve efficiency. You may ask why I am doing it now and not after I made a real hardware prototype of the system. The answer is pretty simple. I have to see if and how it is possible, to make sensorless commutation detection, when using different PWM schemes. I had to realize that the schemes have a big influence on the signals that can be captured.

As soon as I have more results I will make a video showing the current state and how the controller behaves when using different approaches. So stay tuned!

Cheers, and I hope hearing from you too in the comments! :)

IR2110 based power stage circuit

Esden — Tue, 24 Mar 2009 00:00:00 +0000

[caption id="attachment_201" align="alignright" width="150" caption="Circuit"][/caption] I started to build up the Open-BLDC circuit on a breadboard. Then a problem occurred. The low side works as it should but the high side just did not. After several hours of trying and reading the data sheet of IR2110 I gave up and asked Federico again for help. After some time we found an application note AN-978 from International Rectifier. This explained everything. You need to select very carefully the Boot capacitor. This is the one between VB and VS pins of IR2110. It is providing the charge for the gate of the high side MOSFET when you turn it on.

For testing you can take a big capacitor, so that when you manually switch on the high side you see something happen. I took a 330uF capacitor and it is enough to turn the high side MOSFET on for about 30 seconds. Still you have to be careful because the capacitor only gets charged when the low side MOSFET is turned on. So after turning on the power the capacitor is not charged and you have to turn the low side MOSFET on first, then turn it off again and finally switch the high side on.

In the final design one should probably select the right bootstrap capacitor. The equation for calculating that value is described on page 6 of the International Rectifier application note AN-978.

You can probably get rid of the capacitor and the diode if you connect VCC directly to VB. The problem you get then is that when the current on VS gets higher then 12V you get a problem. But I may be mistaken. Correct me if I am wrong.

Conclusion: read the damn application notes and I still have problems with understanding the electrical engineer talk! :)

I hope this helps someone. You can see my circuit for one half bridge attached to this post. And a picture of my breadboard.

I use the two LEDs to see what happens with the MOSFETs. They are glowing a little when both sides are off. The one connected to 12V is switching off when the high side is on and the one connected to GND switches off when the low side is on. I love LEDs! :)

Cheers Esden [gallery]

Breadboard Adapters

Esden — Fri, 20 Mar 2009 00:00:00 +0000

I am currently working on building a breadboard prototype of Open-BLDC. I will write about that in more detail in a separate post. I had a problem there. The Olimex STM32 board has two dual in line connectors that just don't fit on a breadboard. There are some adapters that you can buy for money, for example from Number Six. But that would cost me too much time and money.

So I decided to build my own adapters with parts that I had ling around and a prototype board that I got from Uwe. (Thanks Uwe I will buy one and give you a replacement as soon as possible!) It was a lot of fun building the adapters. They are really easy to make!

Step 1 Just cut out piece of prototype board with the length you need and four holes wide.

Step 2 Solder a dual in line connector to the copper side of the board. Just don't push the connector completely into the holes so that you can reach the copper with your soldering iron.

Step 3 Solder two single line pin connectors on the other side of the board, right and left of the dual connector.

Step 4 This is a bit tricky. You can use some wire to connect the pins of the DIL (Dual In Line) with the single line connectors. But I found out it is much easier just to put a bit more solder between the pins and let them connect. You may have to try one or two times. Having some desoldering wick around is a good thing if you happen to solder together wrong pins. ^^

Step 5 Profit! ;)

I appended some images you may consider more or less useful. I should make one more adapter to document the build process. :/ I am sure there will be such an opportunity soon.

Cheers Esden

[gallery]

Selecting parts for Open-BLDC power stage prototype

Esden — Sun, 15 Mar 2009 00:00:00 +0000

The other day I ordered parts to build the first prototype of Open-BLDC on a breadboard. It is a bit different animal then the board designs I already have because it needs legged parts.

The main problem is to find the right MOSFETs and driver chips for this application. As I have no electrical engineering background I did not really understand the values that were listed in the data sheets. I asked an electrical engineering friend and he helped me with locating the most important values. Thanks Federico!

MOSFET Values

I realized that the most important values for MOSFETs are:

Drain to source voltage
Gate to source voltage
Continuous drain current
Input/Output capacitance (turn on/off time)

The MOSFET I selected is not perfect but should do for this first prototype. It is the IRF1010N from International Rectifier.

Drain to source voltage In my case as I am using the standard three cell LiPo batteries used in models. I need something above 12V. The smallest ones are 20V but the one I could get from Reichelt was 55V. That is still OK.

Gate to source voltage For example the high side MOSFET has 12V attached to source. When the gate is driven low, the voltage difference between gate and source are 12V. In many cases that is a problem. Because when you charge your battery full the voltage difference gets even bigger or even worse when you try to use a battery with 4 cells instead of 3. Most MOSFET that I found have only 12V specified as gate to source voltage. It still probably works with more because of tolerances but still it is probably not good. The MOSFET I am now using for the prototype has ±20V in the specification. That should work.

Continuous drain current This one will get more important in the future. It is telling how much current the MOSFET can put through. For the prototype that is more or less a functional test of the circuit it does not matter so much. But in the future when I want the controller to support up to 20A continuous current this one will get very important. The IRF1010N is specified for 85A at 25ºC and 60A at 100ºC. So this values are meant for applications where you have a heat sink attached to the MOSFET's. I will try to avoid using heat sink. I could calculate the exact number but the rule of thumb is that one should take 1/10th of the value. This means that with this MOSFET I will be able to run at about 6A to 8A. As the lab power supply, I have access to and will use for the prototype, can only deliver 2A that should be more then enough. There are several other values that are connected to this one. Like drain to source on resistence, thermal resistence, power dissipation aso. One can use them to calculate the exact amount of current the part can put through. But I think it is too early to make all the calculations yet.

Input/Output capacitance (turn on/off time) This is a set of values that tell how fast the MOSFET can be switched on and off. It will also get more important in the future when selecting the right MOSFET for the final design. For now the 76ns rise and 40ns fall times should be enough. They will probably get even lower because I am using a dedicated half bridge driver chip.

Half Bridge Driver

I did a lot less research here. Thankfully there are not as many half bridge drivers out there as there are MOSFETs. The one I selected is the IR2110. It would be a bit big for the final design because of the additional leads. But it should be OK for this prototype. The problem I had here is that I have 3.3V digital input from the microcontroller and I want to drive the MOSFETs with 12V. As it seems the other drivers that I considered don't recommend that. That is why I had to choose this one. I hope that I will find something that is smaller and still supports the 3.3V input.

Conclusion

Selecting parts is a very tiresome endeavor. The shops only have a subset of the parts that are available out there. I wanted to order all parts from one shop that is somewhere in Germany. I could probably get better parts ordering from Digikey but it would cost more. For the next stage of Open-BLDC development I will have to select better parts. But first I how a feasible circuit should look like. That is why I am going for the breadboard test first.

If you find any mistakes or I misunderstood something here feel free to tell me.

Cheers Esden

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.

Open-BLDC MK

Esden — Mon, 16 Feb 2009 00:00:00 +0000

In the last few weeks I was working on an alternative firmware for the Mikrokopter Brushless Motor Controllers. The main goal is (as always) to create a firmware that is under the terms of a known and proven Open Source License. In this case it is GPLv3. (I am thinking about relicensing it under some BSD like license, but I am not sure yet.)

The code is available at GitHub here. There is still a lot work to do, but the motor is starting and turning as it should. Well nearly. I have some slight problems with the startup code, that needs some further tuning. Also when you break the motor it does not always detect that no more commutations take place and freezes the motor in one place. I think that I still have some problems with the commutation detection and the debounce.

The next goal is to make it possible to change the commutation timing corresponding to the commutation detection. That means that it is possible to do the commutation slightly before or after the commutation detection. For that it is necessary to capture the time between detected commutations and according to that trigger the commutation cycles. I hope that the 8bit timer that I have available is enough. The only 16bit timer of the Atmega8 is occupied by PWM generation and I am not sure if I can use it for the timings too. :/ (needs more reading ^^)

I have to make a video of the running drive soon so I can show it to you ^^

For now it is all. Take a look at the Open-BLDC site for more info and links to some interesting resources I found about brushless sensor less drive controller techniques. ^^

Cheers Esden

Updated: Open-BLDC and open source Quadrocopters

Esden — Thu, 18 Dec 2008 00:00:00 +0000

Hi ho everyone!

Today I will write a bit about a "little" project I started recently. It is called Open-BLDC.

As I was writing my Diploma thesis I got involved with the Quadrocopter Community. There are some different projects and companies producing, selling and developing these small alternatives to helicopters. I really love these things.

There is only one really open source Quadrocopter, namely UAVP. The source is GPL but as far as I know you can not get any hardware anymore. The board schematics is somewhere in the repository. But still it is no more under active development and the code is pretty outdated compared to other projects like Mikrokopter.

Talking of Mikrokopter, it is an amazing project with a really amazingly big community. The problem I see there is the License. It is some strange proprietary license. I don't want to get into the legal stuff here but it just feels wrong. Read it yourself for example here (sorry that it is only in german, it is not my fault ^^). The other thing that disturbs me is that you only get the ready product. You can not follow the development because the development branches of the code are not available to the public, so getting involved is very difficult. (yes I know there are branches of the code of other people in the repository that are doing their changes ... but still) (I will for sure get bashed for calling Mikrokopter not properly open source ... try to convince me ^^)

There is another project that grew out of UAVP, called NG-UAVP. The guys are working hard since 1.5 Years on their hardware and software. And as I asked them, they will probably release their source under GPL and the hardware under CC-NC. That would be awesome!!! But they want to have something really working and stable before the first release. Hopefully they will release it soon and stick to that licenses. (yes it is not completely sure :( )

Anyways. I really would like to have a completely open source project from the license to the way to develop everything. One thing that is a basic part in the current Quadrocopters are Brushless DC Motor controllers. There is no open source one anywhere. So hoping that UAVP-NG gets released under GPL I decided I should start with the controllers. If NG-UAVP fails to release under a proper license and organize the development so that everyone can contribute I will move from here to the IMU and controller.

Enough said. I started up the free version of Eagle (another missing thing in the open source is a really usable pcb cad software) and created a first shot at the schematics. After that I uploaded it to GitHub (and another place where open source is lacking, a good web interface to GIT, I really would prefer to have the interface installed on my own server). Not long time after that MarcusBec from the #uavp channel on Freenode took a look at it and told me that many things were just bullshit, and what I should do to make the design better. I am very thankful for that! So I already have one very major contributor to the project! That is how Opensource works. ^^

Now it seems that the schematics make somewhat sense. The controller pretty high end, using drivers for the P-MOSFETS and three rows of them. The microcontroller is an Atmega168 which makes a lot of space for code. Three interfaces are available for now, PPM (standard interface used in modelling), Serial and I2C. In the future I plan to add Can-bus too, for more robot centric applications. Currently I am working at making a PCB design, and hope I get it somewhat useful.

I am still looking for feedback and ideas. Check out the repository at http://github.com/esden/open-bldc and take a look at it. Perhaps you find something wrong and/or worth cleaning up. If you just have questions, don't hesitate to contact me too! It is Open Source after all!!! :)

Cheers Esden

Update: I got informed that my information about UAVP was wrong. The boards of the original project are still available from http://lipoly.de/ and http://www.quadroufo.com/. The source is also still under active development also by its main developer Wolfgang. So it may be a viable basis to work on for a really open source quadrocopter after all. But thankfully is open-bldc still no wasted time, because there is still none, at least to my knowledge, open source bldc useful for quadrocopters out there. Sorry for the mistake here I will research my information better next time!

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!