Esden's Blog - projects

New Black Magic Debug Maintainer

2022-01-08T00:00:00+00:00

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

My Streaming Setup and Electronics Tools Collection

2020-05-11T00:00:00+00:00

Hello everyone!

As many of you ask about the tools I am using for twitch streams as well as what electronics related tools I am using. I decided it was time to put together a blog post for that. I will likely keep updating this specific post when my streaming setup evolves or I need to add more content. This blog post is derived and updated version of the Gist that I posted a while ago.

This post is currently reflecting the gear I am using in May 2020. If you think anything is missing from this list or it is not up to date any more. Feel free to ping me and I will do my best to update the list! :)

Computer

Currently I use a scratch built PC for streaming, here is the list of the major components:

AMD RYZEN 7 3700X 8-Core
Gigabyte X570 Motherboard
64GB of RAM
Gigabyte Radeon RX 5600 XT GPU
EVGA SuperNova 650 G3 modular power supply
Noctua NH-U14S 140mm SSO2-Bearing CPU cooler
Fractal Design Meshify C Black Compact Mid Tower case
Two 1080p Dell monitors I had since years

For the complete build and the exact parts used you can find the NewEgg build here: https://newegg.io/a1664311

Cameras

Face Cam: Logitech C920
Desk Cam: Lumix G7
- Mounted on: Manfrotto 244RC Variable Friction Magic Arm
- Clamp for the arm: Manfrotto 035RL Super Clamp
Microscope Cam: AiHOME HDMI C-Mount Camera

Lighting

Capture Devices

For Desktop Cam: Elgato Cam Link 4K
For Microscope Cam: Magewell USB Capture HDMI Gen2 USB 3.0
For Audio: SYBA USB Stereo Sound Adapter

Audio

Lapel Microphone: Sennheiser EW 100 G3

Software

Main Streaming software: OBS
Linux Browser view used for overlays and plugins
Free Plugins/overlays from Streamlabs
AlertBox: Displays alerts of new followers, subscribers, bit donations and more
ChatBox: Displays the twitch chat messages as video overlay
Cloudbot: Provides commands like `!uptime` and automatically sends out an invite to the Discord server.
Key and Mouse visualizer: TrayKeys
Text Editor: Sublime Text
ToDo List Sublime Text Plugin: PlainTasks
PCB Design Software: KiCad
- Plugin: InteractiveHtmlBom
FPGA Tools:
- Binary Distribution and build script: Open Tool Forge
- Synthesis: Yosys
- Place and Route: nextpnr
- Database and Programmer (iCE40): icestorm
- Database (ECP5): prjtrellis
- Simulator: iverilog
- Simulator: Verilator
- Signal Trace Viewer: GTKWave
Logic Analyzer framework/software: Sigrok/Pulseview

Other Gear

Microscope: AmScope 7X-45X Simul-Focal
Microscope Camera Lens: OMAX 0.5X C Mount Reduction Lens
I also got a focus adjustment barrell, but I can't find the source for it... TODO
Light Ring: AmScope LED Light Ring
Soldering Iron: JBC T210-A
- Soldering Tips: C245-029, C245-064
Hot Air Rework Station: AOYUE 852A
Reflow Oven: T-962A with all mods
HotPlate: Akozon 200x200mm
PreHeater: Coffee Cup Warmer
PCB Tab Route Tab Clipper: Hakko CHP DP-20-N Depaneling Tool
Multimeter: Fluke 115
- Multimeter Probes: Probemaster 8000
Oscilloscope: Tektronix TDS2014B
Logic analyzers:
- 1BitSquared BitMagic-basic
- A Sigrok Compatible "old" Saleae Logic 16 clone. (until BitMagic-pro is done)
Vise: Stickvise
- PTFE Jaws
Tweezers:
- Angled: Erem E7SA
- Straight: Erem E3SA
RoadRunner Wiring Pencil

1BitSquared and other stuff

iCEBreaker FPGA related products
- USA
- Germany
- CrowdSupply
- Mouser
Black Magic Probe
- USA
- Germany
- Adafruit
BitMagic-basic Logic Analyzer
- USA
- Germany

If you like what you see and would like to support the streams and development of new open source devices, but you already have all the 1BitSquared hardware you need, you can support me through Patreon and/or Twitch subscriptions.

You can reach me through twitter and on our 1BitSquared Discord server. I hope this list is useful.

Cheers,
Piotr

Black Magic Discovery

2014-12-29T00:00:00+00:00

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

2014-12-29T00:00:00+00:00

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! :)

Lisa/S, SuperbitRF, 1 BIT SQUARED

2014-04-30T00:00:00+00:00

Hi everyone,

Again it was a while since I posted something here. I just wanted to write a quick update on what I've been up to lately.

I am working very hard on Lisa/S and SuperbitRF. The goal of the project is to develop the smallest and lightest possible UAV controller system without compromising functionality.

The Lisa/S board is only 20mm x 20mm and weighs about 3g with a lot of integrated sensors.

3 Axis Gyroscope
3 Axis Accelerometer
3 Axis Magnetometer (Compass)
Barometer (Altimeter)
GPS Receiver

Just like Lisa/M it's bigger sister. Lisa/S is powered by the STM32F103 ARM 32bit microcontroller. Providing quite a lot of processing power for your UAV needs. On top of it all the board has 4 MOSFET solid state switches. They make it possible to use the board directly on the tiny brushed motor quadcopters, nano helicopters and fixed wing airplanes. I am quite excited how much I managed to put onto that tiny footprint. Usually much bigger boards don't even include a GPS receiver on the board.

Another feature of Lisa/S that I think is worth mentioning is that it has a CYRF footprint.

CYRF is a module that I developed as part of the system. It contains the CYRF6936 2.5GHz transceiver chip. It is connected to the MCU on Lisa/S through SPI. The particular transceiver is the one at the heart of all the Spektrum transmitter and receiver systems and many others like Walkera Devo. It is very exciting because we have direct access to that chip from the autopilot and can implement compatibility to a lot of 2.4GHz RC gear available out there.

Our current software implements support for some Spektrum RC transmitters and as a bonus we can simultaneously connect to a laptop using the USBRF dongle. This removes the need for having two radios on your vehicle thus saving weight.

All of these items are currently available for pre-order in the 1 BIT SQUARED shop. We are working on finalizing the production process of the first batch of Lisa/S, CYRF and USBRF. We are projecting they will be available in the shop by the end of May. We have put a lot of effort into making these boards, if you are interested you can read more about it in the 1 BIT SQUARED blog.

Last but not least 1 BIT SQUARED is my own company that I founded early last year. I want to develop and produce hardware and software that I am excited about and would like to share with others that are interested in the field of airborne robotics. If you like open hardware and software and want to support me directly the shop is the most direct and easiest way to do so.

Cheers, Esden

Quadshot - an aerobatic blend of RC quadrocopters and airplanes

2011-09-15T00:00:00+00:00

Hi everyone,

As you probably notice I am very busy lately. Together with some friends we were working on the Quadshot an aerobatic blend between a quadrocopter and an airplane.

It takes off and lands vertically like a quadrocopter as well as it can fly forward like an airplane using its wing to add additional lift extending flight time.

We submitted the project to Kickstarter and we are very happy to see that we got such a great response. The Kickstarter funding runs for another three days and if you pledge you can get a Quadshot at a discounted price as a reward.

At it's heart Quadshot is using the avionics and software framework of Paparazzi. We developed the additional necessary controls for Quadshot and released them. So Quadshot has Open-Hardware electronics and Open-Source firmware making it a great platform for research and hacking.

Having an autopilot makes it also very easy to fly for a beginner RC pilot.

I hope to find some more time in the future to get into more details about Quadshot. But till then check out the following links:

Cheers Esden

Open-BLDC and the CLogic story

2011-05-15T00:00:00+00:00

[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

FLOSS-JTAG V1.0 Released and Available

2011-02-22T00:00:00+00:00

Hey everyone,

As you might know some time ago I have developed a small JTAG adapter based on the FT2232H chip. I gave it the name FLOSS-JTAG as the idea was that it should be absolutely OpenSource and OpenHardware.

You can find the project at GitHub and some more info at it's random projects wiki page.

FLOSS-JTAG not only has the high speed 24MHz FT2232H chip (there are some designs based on my idea that are using a low speed version of the same chip). It provides the new standard 0.05" pitch 10 pin Cortex JTAG header as well as a TTL level serial interface on it's second interface.

I am glad to announce that I have reached the V1.0 with it. All necessary files to make your own are in the GitHub repository. But if you don't want to go through the pains of ordering PCB, sourcing parts, assembling QFN SMD packages you can also purchase it in the Joby Robotics online shop.

At Joby Robotics you get a cable assembly to connect the FLOSS-JTAG to a target. This allows you to debug and connect to targets that are difficult to reach otherwise. You also will get a cortex connector to old standard 20pin 0.1" pitch connector adapter.

The adapter is small and will make it also easier to debug targets that are difficult to reach.

You can get precrimped Molex Picoblade wires in 10 different colors at Joby Robotics too. This way you can easily build a UART cable that connects FLOSS-JTAG to a device.

I am very happy that FLOSS-JTAG is finally easily accessible to anyone who needs it.

FLOSS-JTAG works perfectly together with Openocd and Summon-ARM-Toolchain.

Cheers Esden

Open-BLDC Documentation

2010-08-19T00:00:00+00:00

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

2010-08-05T00:00:00+00:00

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. ;)

Floss-JTAG V0.1 Assembly and V0.2 boards.

2010-01-01T00:00:00+00:00

Because I wanted to have a small JTAG adapter with additional UART port and a different (smaller) connector then what is available out there, I have decided to make a JTAG adapter. I chose the FT2232 USB adapter chip. This guy is pretty nice because it has a special engine inside that is supporting many different protocols. One of them is JTAG. I have released what I made as always on GitHub under the CC-BY-SA 3.0 license. There is no software needed on the adapter side so no software included. All you need is OpenOCD. It now even has a config file dedicated for Floss-JTAG. Calling for example:

#> openocd -f interface/flossjtag.cfg -f board/open-bldc.cfg

will connect to Open-BLDC using the Floss-JTAG adapter.

Building Floss-JTAG I learned a nice lesson. Always check your footprints 10x before you send the gerber files to the manufacturer!!! I had to customize the footprint for the FT2232 chip and made a mistake. The pads were not long enough so the pins had only 0.1mm overlap area. It was a real pain to solder that. I assembled 3 of Floss-JTAG using this design. Sadly only two are working.

Because of that mistake I immediately corrected the board layout and sent it out. I got the boards today. I hope that there is no other mistake hidden somewhere. :) Attached are the images of V0.1 assembly and of the V0.2 boards.

[gallery]

Open-BLDC V0.1 Fully Assembled

2009-08-08T00:00:00+00:00

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!

2009-08-07T00:00:00+00:00

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

2009-08-05T00:00:00+00:00

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

2009-07-24T00:00:00+00:00

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

2009-07-24T00:00:00+00:00

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

2009-07-01T00:00:00+00:00

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

2009-06-29T00:00:00+00:00

[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

2009-05-10T00:00:00+00:00

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

2009-05-07T00:00:00+00:00

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

2009-05-02T00:00:00+00:00

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! :)

Breadboard Adapters

2009-03-20T00:00:00+00:00

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

2009-03-15T00:00:00+00:00

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]

2009-02-26T00:00:00+00:00

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

2009-02-16T00:00:00+00:00

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

2008-12-18T00:00:00+00:00

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

2008-12-13T00:00:00+00:00

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!

BL-Ctrl and Serial Converter assembled

2007-07-10T00:00:00+00:00

Finally after some problems I was able to assemble three BL-Ctrl and the serial converter.

Why I have not built four BL-Ctrl is because I broke one Atmega microcontroller while assembling the PCBs.

Next step will be to test the BL-Ctrl modules. To do that I still need some things. First I need some possibility to connect my 12V power supply to the modules and second I need multipin connectors on the BL-Ctrl modules where I can connect the serial converter.

I will look for the parts I need at Reichelt and order them. During the assembly of the modules I realized that I miss some tools so I will order them too.

At least I did one step towards my own Mikrokopter. ;)

Programming the BL-Ctrl'ers

2007-07-10T00:00:00+00:00

Some days ago I was able to program my BL-Cntrlers using PonyProg.

I had some problems doing this because I do not posess a machine with a builtin Serial interface and Windows. The problem is that the programmer uses a bitbang protocol on the serial port with very stirct timing constrains so I can not use a Serial to USB converter. First time I tried to program the controllers I tried to use the laptop of a friend but it seems that because it has frequency scaling the timings were not right, so I had to use a windows machine at my university.

It seems that everything works so far. The programmer said that the download was successful and the LEDs light up.

Later I also tried to program the controlers using avrdude under Linux. I built up a linux machine from some spare parts that were lying around my room. Sadly it is not working. avrdude says that the device is not responding. I have to try some other linux machine with builtin serial device to see if the problem is because of the very old hardware.

Next step will be to get some brushless motors and build up the fourth controller. I was thinking about getting four Robbe ROXXY2824-34. I heard that they often have problems so I will have to buy more then four to make sure that I get 4 working ones.

Still I will have to wait some time until I start working at my diploma thesis company. Before that I have no money to purchase them.

But still I am very happy that programming was a success what means that I did not screw anything up during the assembly (at least for now). Another small step towards my own mikrokopter. ;)

The Mikrokopter PCBs not here yet

2007-06-17T00:00:00+00:00

Sadly I had to realize that the guys selling the PCBs are currently on vacation. I should have read their homepage more carefully.

But the positive thing is that they will be back on monday the 19th so they will perhaps ship them tomorrow. Can't wait to get them and start building.

I will need some kind of tweezers for soldiering the parts. Hopefully I will be able to organize them before the PCBs reach me.

BL-Ctrl and Serial converter parts

2007-06-14T00:00:00+00:00

Today a DHL guy stood in front of my door and left a package full of parts for the BL-Controllers and serial converter.

I still wait for the PCBs but according to PayPal the payment is through, so I should get them in the next days too. Hopefully I can start to assemble everything on this weekend.

Mikrokopter

2007-06-12T00:00:00+00:00

Long time no post...

Some weeks ago a friend of mine showed me these incredible machines at mikrokopter. I was so amazed about these small flying machines that I got myself the first parts for building such a small flying machine myself.

Because I have nearly no money I split the purchases in small pieces. First of all I got myself four brushless motor controller pcbs and an Atmel programmer pcb from the mikrokopter shop and the nessesary parts.

The next steps will be getting following parts:

One brushless engine to test the controlers
Flight-Control pcb with all parts (that will be a pretty big chunk)
A reciever and a remote to test the flight-ctrl
A frame
The remaining engines
And finally the rotors

Then I should have a complete and flying mikrokopter. I will probably stretch the purchaices over many months while I progress with assembling, testing and earning nessesary money.

Wish me luck with that project. ;)

ROCK Linux 3 Released

2006-07-27T00:00:00+00:00

Finally after many months of hard work ROCK Linux got a version bump to 3 and has many new and updated things to offer.

You can read the Changelog or simply download a Crystal build ISO or the sources.

Now you have to try it and start contributing. No?

Objective C

2005-07-07T00:00:00+00:00

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. ;)

Gallery

2005-07-05T00:00:00+00:00

Ich habe alles was in meinem alten www Verzeichnis war endlich mal aufgeraeumt. Sehr vieles habe ich in den Muell geworfen und einieges wiedergefunden. Wie zum Beispiel ein log vom rebooten des Universums (siehe voriger Blog Eintrag) oder wie Rotkaepchen von Informatikern gesehen wird. Dazu noch ein Skript mit dem man anhand von den Parametern seines Rechners die dazugehoerende "Schwanzlaenge" berechnen kann und ein gkrellm Theme das ich mal gemacht hatte. Was man alles so findet wenn man mal aufraeumt ;)

Da ich auch noch unheimlich viele Bilder da hatte habe ich mich kurzerhand entschlossen eine Gallery dafuer zu machen. Die braucht noch bischen massieren bis die huebsch wird und sich mit meinem Blog zusammenfuegt aber zumindest sind schon alle Bilder drinnen. Es war schoen mal wieder die ganz alten sich anzuschauen.

Das war fast so wie einen ganz alten Schrank auszuraeumen und wieder in Ordnung zu bringen. Da kommen so richtig Erinnerungen wieder hoch.

Diff Algorithmus und C++ lernerei

2005-07-02T00:00:00+00:00

Ok jetzt weiter zum angenehmeren. Die letzte Zeit habe ich viel programmiert fuer ein Nachfolgeprojekt von Syneight naemlich Diagnostics. Fuer dieses ding habe ich eine klasse geschrieben die diff implementiert. Es war sehr interessant vorallem weil ich mich dann durch mehrere Paper durchwuehlen musste bis ich den richtigen Algorithmus gefunden habe. Letztenendes bin ich bei LCS(Largest Common Subsequence) basierenden Algorithmus geblieben da er ziemlich gut dokumentiert war und mit Codebeispielen versehen. Er hat zwar eine Komplexitaet von O(n) aber es geht schon. Es gibt noch andere Algorithmen wie zum beispiel einen der auf Shortest Path basiert und eine Komplexitaet von O(log(n)) hat. Vielleicht werde ich irgendwann den austauschen.

Nun was ich eigentlich sagen wollte. Ich habe diese Klasse implementiert und an den Projektleiter geschickt. Ich habe kurze zeit danach eine E-Mail zurueckgekriegt mit einer ewigen liste was ich falsch gemacht habe. Ich war positiv ueberrascht denn ich bin davon ausgegangen das ich eine kurze E-Mail bekomme wo drinnen steht "Dass ist scheisse, mache es nochmal. Und ersetze mit und lese dir Folgendes Buch durch " oder aehnliches. Nein ich habe eine ausfuehrliche Erklaerung bekommen was und wieso ich falsch gemacht hatte. Ihr glaubt kaum wie sehr ich mich darueber gefreut habe. Vielleicht werde ich in spaeteren Blogs auf die Sachen die ich Falsch gemacht habe eingehen damit ihr auch davon was habt. Nun nachdem ich die entsprechenden Korrekturen eingebaut habe habe ich wieder ne lange mail gekriegt was man besser machen kann. Es ging so bis jetzt mehrmals hin und her. Mommentan bin ich am umbauen auf Iteratoren (hier muss ich anmerken das ich im uhrspruenglichen Code keine Iteratoren benutzt habe weil ich mit denen nicht per du war und wollte mir nicht eine weitere Faehlerquelle hinzufuegen.) Ich hoffe das bald der Code so weit ist das man den so stehen lassen kann ;-) (ja ich weiss Traeumen ist schoen)

THC Design

2005-07-02T00:00:00+00:00

Ich habe heute noch eine Zeichnung gemacht von dem wie ich mir vorstelle das THC mal aussehen koennte mit einem Gehaeuse. Nun ich weiss Gehaeuse ist eigentlich das letzte worueber man sich bei so etwas Gedanken machen sollte. Trotzdem habe ich bisschen Getraeumt und gleichzeitig ueberlegt wo die ganzen Anschluesse gehen sollten.

Gleich nachdem ich das fertig hatte wusste ich das ich einen Scanner brauche. Ich muss mal schauen wie ich billig an einen USB Scanner komme. Bis dahin muss ich mich wohl mit meiner Digitalkamera und und Handykamera zufriedenstellen. ;-)

Ich schaue mal gleich ob ich ein Photo von dem Bild hinkriege. Ok sehr gut ... auf dem letzten Saeufzer der Batterie in meinem Photoapparat habe ich ein Bild hingekriegt. (Ich muss mal neue Batterien besorgen.) Ich stelle es hier mal rein in der Orginalaufloesung weil sonnst kann man nichts davon erkennen.

Ich habe mir gedacht ich lehne mich an das Design von I-Pod an (ich finde es sieht super aus ich liebe naemlich designs die unkompliziert sind von der Linie was Ergonomie angeht ... nun das ist nicht mein ding :-P ) Wenn jemand von euch einen besseren Vorschlag hat darf mir natuerlich was schicken. Die E-Mail Adresse ist einfach esden at dieser Domainname ;-)

Unten will ich ein Erweiterungsport machen auf dem USB und paar weitere Leitungen rausgefuehrt sind die vom Prozessor noch frei sind. Deshalb werde ich wahrscheinlich den USB Port noch wegtun.

Soo ich glaube das reicht erstmal. Ich schreibe vielleicht morgen noch weiter ;-)