The only problem with these motor controllers is, that the shipped software is Win32 only. The Link dongle as such, is simple USBRs232 converter with some microcontroller. The maximum transfer speed is 9600Bauds.

I have been playing with the Superbrain controller for some time, and decided to sniff every transaction there is. All my knowledge has been put into single project that aims to be replacement for stock software – Tgypytool – as I call it.

This tool can be downloaded from github http://github.com/robots/Tgypytool.

What is supported:
- configuration read/write
- log read/clear
- log settings (no access to this feature so far)
- fw write (not tested yet)

The configuration is stored in text file, all available options are in the .py file. I suggest you first read out your config, and modify it. All values are stored as: parameter=value, each on its own line.

Log reading has been implemented. These devices store up to 8 run logs. Everytime log is downloaded, tgypytool splits the downloaded data into corresponding runs.

Another tool included is graphing tool. This tool should read downloaded log data and plot graphs of voltage, current, rpm, etc. I have yet to figure out how these values are calculated.

I have also included small README that includes small howto.

The playing with SuperBrains is not over, I have done little reverse engineering on the firmware – stay tuned for future post :-)

In meantime, while I was gathering information. I received a LCD screen from a broken notebook. 17inch TFT LCD screen with resolution of 1024×768 and 18bit colors. Calculated refresh rate 60 Hz. This looked like great opportunity to learn something new, and to create something cool. I decided to use the LCD as ZX spectrum display.

As for the hardware part I had this SparkFun’s Spartan 3 breakout board. 500k gate FPGA that should be big enough most home made projects. This board as such is without any external RAM and Flash ROM, except for the SPI Flash.

I needed to design RAM board that goes with the FPGA breakout board. One of the cheapest SRAM available from Farnell is AS7C3256 – 32kx8 10ns SRAM. I decided to go with 2 chips. 64k doesn’t seem much these days, but is plenty for ZX Spectrum. 64k is the size of Z80 address space.

The IO board was inspired by ZXgate’s zxio board. The original design was using through-hole parts and contained one Reset button, Composite out (B/W only), PS/2 keyboard and Tape connection. I have redesigned it to SMD parts and also added speaker, 2 LEDs and NMI button.

The last board contains LVDS transmitter from TI – SN65LVDS84. This is the key component that sends data to my TFT LCD panel. I am not sure (and not experienced enough) whether the FPGA would be able to drive the LVDS on its own.

If someone is interested in the board designs I have them in eagle format,

The ZXgate project ran by it’s own without any major modifications. I just didn’t like the idea of having external ROM for the Spectrum. I have placed the ROM code in the BRAM of the FPGA, and preloaded the BRAM with the correct data.

After deploying of the VHDL I saw Sinclair copyright. Really great feeling If you ask :-). But the computer behaved strangely – it died after ~5 seconds. After reprogramming of the FPGA same behavior repeated. It turned out to be result of my fight with the FpgaPlanner tool and I forgot to enable pull-ups on the buttons – duh.

Next step was to add the LCD panel controller. The LCD controller is pretty straight-forward once you understand what “DE-mode” is. It turns out that current LCDs don’t need two H/V sync signals and have just one signal – Data Enable. You still need to over-scan the screen by ~300pixels horizontally and ~100lines vertically, but over-scanning means to just keep clock running. DE signal it high only when pixel data is sent to the screen (low when off-screen).

Nice thing about 1024×768 screen is that ZX spectrum’s screen (256×192) fits there 4 times. So each pixel is displayed as 4×4 dot. The border is not displayed on the LCD, as it does not display anything valuable, except for the loading curtain.

The whole screen generator consists of 2 counters – horizontal and vertical and some logic that copies data from the Vram to screen. Both counters are used in address generation. Actual data is transfered even when off-screen, but the LCD panel ignores them.

I have replaced the VRAM and ARAM (video and attribute ram) with Dual port RAM. This way the ZX spectrum works uninterrupted and my display routine works on it’s own.
The result looks something like this:

The FPGA board with the extension boards attached:

There are still many improvements to be done. I plan to store some applications to the SPI Flash that holds FPGA configuration. The FPGA needs about 250k bytes for it’s configuration and the SPI Flash size is ~2MB. Lot of space wasted.
I might reuse the loading menu from SpecyBoot. This project aims to add Ethernet connection to spectrum and uses nice menu to browse the network repository. Of course I will not add network logic to the FPGA as I want the system to be portable.
If you are interested watch for updates, I will post updated when some time is left.

ISE project can be downloaded HERE
Missing ROMs HERE
I am really not sure by the licenses. If there is something wrong with sharing source I should not have, please contact me, and I will remove the offending material asap.

First of all, you need to be sure that you compiled newlib with something like (MALLOC_PROVIDED being the important here)

make CFLAGS_FOR_TARGET="-msoft-float -DMALLOC_PROVIDED" CCASFLAGS="-msoft-float -DMALLOC_PROVIDED"

By doing this you tell newlib that you are going to provide malloc and friends (that includes: free, realloc, calloc)

Go ahead and fetch the sources of FreeRTOS from HERE. Unpack them. Examples are taking the most of space in the package. Most of them are ready to compile (if you have the correct compiler/IDE)

Next thing you need is a “glue” that tells newlib to use the allocator of FreeRTOS. I suggest that you use heap2.c allocator. (allocator heap1.c is too simple for this use. Heap3.c uses external library, which could have been malloc from newlib, if it were working right :) )

The glue can be downloaded here: alloc.c.
It implements functions like _malloc_r, _free_r, etc. (R standing for reentrant?) All of these functions are straight-forward, except realloc, that needs to copy some memory. I have not done very extensive testing on this. The state is now “Works-For-ME”, so far I have tested sprintf function while testing gcc to support soft-float. The sprintf probably uses only malloc and free.
If you have any suggestions, patches, please comment.

I have created project that runs on Olimex’s stm32-103stk using FreeRTOS. The project includes:

• Makefile (to help putting everything together – not my work)
• SPI Master driver (using DMA transfers, and locking support)
• Simple menu for the LCD.
• Nokia 3310 LCD driver (again not my work, but heavily modified to support my SPI driver)

If anyone is interested just leave a comment, I will put together some releasable version :)
Update: I have created git repository with my projects HERE.

Some notes about newlib:
Don’t use [s|vs|...]printf if you are dealing with integers only. Use *iprintf versions instead, these don’t include printing of floating point, reduce size of final code, and should be faster – they use static buffer instead of allocating one.

Things you will need:
- Buspirate
- Computer with OpenOCD installed
- target with JTAG
- luck :)

The Buspirate can be bought various sources, like Seeed studio or SparkFun. You will need version v2go or v3. (There is a slight change in the pinout). You will also need to update your BP to v4 bootloader and upload fairly new firmware (v4.2 nightly build).
I will not go through the bootloader updating process, you can find tutorial HERE.
The firmware you want to download is HERE.

You will also need some cable to connect BP to the target. Again that depends on the version of BP you have. For v2go (the one I own) is the pinout HERE. You don’t need to connect the “WHITE” cable at all.

The second part is OpenOCD software. There is a patch for version 0.3.0-rc0, and there is a patch for the development branch in git. The first patch works, but has some bugs that were fixed in the later one. I suggest that you checkout the development branch and apply my patch.
Download the patch attached to THIS post.
Go ahead and clone the git repository and apply the patch you’ve downloaded:
Update: There is no need to patch. The patch is included in the git reprository.

git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd

I assume that you have “standard” development kit: gcc, make, autotools, etc. Running the next few commands should produce usable version of OpenOCD

./bootstrap
./configure --enable-buspirate --enable-maintainer-mode
make
sudo make install

You need to enable maintainer mode, or else it will fail while making documentation. You can also add more interfaces, if you own more.

Next step is creating the correct configuration file. The confiuration file contains interface specification and target specification.
The interface is buspirate, of course. If defaults are Ok, you can just use

source [find interface/buspirate.cfg]

More advance way is to copy the content of the buspirate.cfg file and change it to needs.

interface buspirate
buspirate_port /dev/ttyUSB0
buspirate_speed normal # or fast
#buspirate_vreg 0 # or 1
#buspirate_mode normal # or open-drain
#buspirate_pullup 0 # or 1

These commands should be self explanatory. Fast speed mode switches the UART speed to 1Mbit upon connecting to BP, some BP revisions might not work, if this happens please report!
Next you need to add your target configuration. I use STM32 cpu.

source [find target/stm32.cfg]

This tells OpenOCD what TAPs are on the JTAG chain, and OpenOCD scans if the IDs match.
After you are done with the configuration file, save it, and run openocd in the same directory. If there is no fatal error, OpenOCD listens on 4444 port. Use telnet to connect to it, you will get simple console to send commands to OpenOCD.

Go get the sources of GDB and OpenOCD from:

ftp://sourceware.org/pub/gdb/releases/

We used OpenOCD version 0.3.0-rc0, and GDB version 7.0.1. Go build the GDB, and install it with the rest of the toolchain.

cd gdb-7.0.1/
mkdir build
cd build
../configure --target=$ARMTARGET --prefix=$TOOLPATH
make
sudo make install


OpenOCD is pretty straight forward as well. Except you need to specify which JTAG adapters you want to use. You should check the “configure help” to see all available. We own Wiggler and Usbprog, so we are enabling those.

openocd-0.3.0-rc0
cd openocd
mkdir build
cd build
../configure --enable-parport --enable-usbprog --prefix=$TOOLPATH
make
sudo make install


Now that we have complete toolchain, we need to create OpenOCD configuration file. The idea with OpenOCD is, that you have separate configuration file for every project/every board configuration.

The setup we are going show uses Olimex STM32-103STK board with Wiggler clone adapter.

Everytime you start OpenOCD it looks for openocd.cfg file. This file should contain information on what interface you are using, speed, port, etc, and target(s) specification.
Default settings for many interfaces come with OpenOCD. If you are using some standard setup, you should be able to find your config here:

$TOOLPATH/share/openocd/scripts/interface

You also need to be sure to include target file. Target files specify TAP(s) that are provided, some constrains like RAM size, Flash size. Also if you have some good known evaluation board.
If you cannot find the right target file, look in similarly named files, Most of these targets are same (in JTAG sense).

Our configuration looks like this:

interface parport
parport_port 0
parport_cable wiggler
jtag_speed 0
source [find board/olimex_stm32_h103.cfg]


This configures the wiggler to use /dev/parport0 in maximal speed mode. And adds the olimex board configuration.
In this file you can also define procedures that could save you a lot of time. For example to flash and restart STM32 cpu you need to issue 3-4 commands. These procedures are written in lightweight TCL language. TCL Crash course will give you overview of this language.


proc flash_load {file} {
halt
poll off
stm32x mass_erase 0
sleep 500
flash write_image $file elf
poll on
}

Disabling the poll mode will save you some bandwidth while flashing, thus saving some time. The difference is not noticeable on high-speed interfaces, so you can omit these commands.

Now that we have everything setup, we can fire up the OpenOCD. If you have entered everything correctly you should see that OpenOCD has identified the TAPs correctly. If not check your JTAG connection and retry.

Update: I have found out that for some ARM processors (namely Cortex-M3) I had to issue “reset halt” command, otherwise I got many errors.
Using this command line helps:
openocd -f openocd.cfg -c "init" -c "halt" -c "reset halt"

Once it’s up and running OpenOCD listens on 2 ports by default:
- 3333 for GDB connection.
- 4444 for telnet connection.

Connecting with telnet to localhost:4444 will give you command line where you can control OpenOCD directly. Help command will print all the known commands.

For the GDB to be able to use the OpenOCD, you need to tell it, where to find the remote target. Easiest way to do so, is to create file named “.gdbinit” in the directory of your project.
In this file you want to specify following:

file stm32.elf
target remote localhost:3333
monitor soft_reset_halt

First line tells GDB where to find the elf for symbols. Second line specifies that the target is remote and sitting on port 3333. The third line executes “soft_reset_halt” command on the monitor.
The monitor in this case is OpenOCD. Using the monitor command you can execute any command of the OpenOCD and the output will appear in the GDB. For complete list of commands see the help command.

I won’t go much deeper into using GDB, as there are many other nice tutorials out there :).

Of course you need some compiler to develop application for this processor. Standard way of compilation for gcc will lead to very much usable toolchain, until you want to do something with floating point.

Cortex-M3 does not come with FPU, nor any kind of floating point support (VFP, NEON, …). Only support is through Soft-float. Which means that floating instructions are emulated in software, this adds some more code, but maintains compatibility.
There is a small drawback for the vanilla GCC – the code containing any kind of floating operation will cause “Bus Failure” exception.
I have spent many hours googling for the right options for GCC and friends. And came up with conclusion that arm-elf GCC target does not support thumb2 instructions, and the soft-float support is kinda broken due to backward compatibility.

Here are the steps to create GCC with Thumb2 and soft-float support. Please understand what each step does, as there might be a typo in the paths, etc.

First of all you need to download the sources of binutils, gcc, and newlib.

wget http://ftp.gnu.org/gnu/binutils/binutils-2.20.tar.bz2
wget ftp://ftp.gwdg.de/pub/misc/gcc/releases/gcc-4.4.3/gcc-4.4.3.tar.bz2
wget ftp://sources.redhat.com/pub/newlib/newlib-1.18.0.tar.gz


Export some variables used throughout the howto:

export TOOLPATH=/usr/local/cross-arm
export ARMTARGET=arm-softfloat-elf


TOOLPATH will be the destination directory. ARMTARGET is the prefix for the gcc, this also selects the internal target for gcc. Do not change the target unless you know what you are doing.

Next step is to create the binutils (as, ld, …). The release 2.20 does contain bug! Some curly braces are missing in tc-arm file. This is a known bug, and patch is available.

tar xvf binutils-2.20
# patch tc_arm.c with http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/config/tc-arm.c.diff?r1=1.407&r2=1.408&cvsroot=src&f=h
cd binutils-2.20/
mkdir build
cd build
../configure --target=$ARMTARGET --prefix=$TOOLPATH --enable-interwork --enable-multilib --with-gnu-as --with-gnu-ld --disable-nls
make all
sudo make install
export PATH=${TOOLPATH}/bin:$PATH
cd ../../


Option “interwork” is needed when compiling mixed arm/thumb code. “Multilib” is needed to support arm, thumb, thumb2 at the same time.

Now we need the basic gcc (no libs yet). Unpack the source.

tar xvf gcc-4.4.3.tar.bz2
cd gcc-4.4.3/


This is the most hackish part. You need to edit few files in the gcc sources. First one is “gcc/config/arm/elf.h”.
Edit in your favourite editor, and find “#define SUBTARGET_ASM_FLOAT_SPEC”. Change the few line macro to something like this:

#define SUBTARGET_ASM_FLOAT_SPEC "%{mapcs-float:-mfloat} \
%{mhard-float:-mfpu=fpa} \
%{!mhard-float:-mfpu=softfpa}"
#endif


Patching the “elf” target is next. This patch was found on some mailing list. I have not used the patch program to apply it, instead I’ve edited the file manually, and removed those comments. This will enable the thumb2 multilib.


--- proddev/vendor/gcc/current/gcc/config/arm/t-arm-elf    2009/02/03 23:22:05    2923
+++ proddev/vendor/gcc/current/gcc/config/arm/t-arm-elf    2009/02/04 18:33:29    2924
@@ -11,15 +11,15 @@
MULTILIB_EXCEPTIONS  =
MULTILIB_MATCHES     =

# MULTILIB_OPTIONS    += mcpu=ep9312
# MULTILIB_DIRNAMES   += ep9312


Finally we can build the basic gcc.

mkdir build
cd build
../configure --target=$ARMTARGET --prefix=$TOOLPATH --enable-interwork --enable-multilib --enable-languages="c,c++" --with-newlib --without-headers --disable-shared --with-gnu-as --with-gnu-ld --with-float=soft
make all-gcc
sudo make install-gcc

This will take some time. You can add “-j2″ parameter to make, if you have more processor machine.

Unpack the newlib:

tar xvf newlib-1.18.0.tar.gz
cd newlib-1.18.0

Tell the configure to exclude few libraries, from build process. Edit configure.ac, and look for:

arm-*-elf* | strongarm-*-elf* | xscale-*-elf* | arm*-*-eabi* )


And add “target-libgloss” to the “noconfigdirs” variable. In the end it should look like this:

arm-*-elf* | strongarm-*-elf* | xscale-*-elf* | arm*-*-eabi* )
noconfigdirs="$noconfigdirs target-libffi target-qthreads target-libgloss"
libgloss_dir=arm
;;


Save the modified file and execute autoconf. This will rebuild the configure script. Continue the build process.


mkdir build
cd build
../configure --target=$ARMTARGET --prefix=$TOOLPATH --enable-interwork --disable-newlib-supplied-syscalls --with-gnu-ld --with-gnu-as --disable-shared --with-float=soft
make CFLAGS_FOR_TARGET="-msoft-float" CCASFLAGS="-msoft-float"


The make line is kinda tricky. I had some trouble using the internal malloc along with FreeRTOS. Realizing that FreeRTOS has own manager I used following:

make CFLAGS_FOR_TARGET="-msoft-float -DMALLOC_PROVIDED" CCASFLAGS="-msoft-float -DMALLOC_PROVIDED"

The MALLOC_PROVIDED option tells newlib that we have malloc and free. This needs some glue that I will discuss later.

To install the newlib, you cannot use sudo. This will fail on ranlib not being available. You will need root terminal to do this. E.g:

sudo bash
export PATH=/usr/local/cross-arm/bin:$PATH
make install
exit
cd ../../


Now finish the gcc compiling (libgcc, libstdc++, …)

cd gcc-4.4.2/build
make CFLAGS="-msoft-float" CXXFLAGS="-msoft-float" LIBCXXFLAGS="-msoft-float" all
sudo make install

I’m not sure whether the “-msoft-float” option is really necessary. But it works with them in place.

Now you should end up with gcc toolchain, that supports C and C++ languages, ARM, Thumb, Thumb2 instructions, and uses soft-float emulation.

Just don’t forget to add it to your path everytime you want to compile something

export PATH=/usr/local/cross-arm/bin:$PATH


In next part, I am going to show how to setup OpenOCD and GDB for arm processors.

I hope that some (all?) posts will be useful in some way. Stay tuned :)