One new trick for an old dog

Well... There is no much trick in the ten pin 0.05" (1.27mm) ARM JTAG/SWD connector, but it is definitely new for "an old dog" - LPC2103.
A few weeks ago I received several small 0.85 x 1.26" (23 x 32mm) LPC210x header boards from BatchPCB. OpenOCD version 0.3.1 with FTDI2232 based adapter does work with LPC2103 on the board via new tiny JTAG connector. However, the OpenOCD configuration file needs minor adjustment since the connector has no TRST pin. So the reset configuration should include srst_only to let the OpenOCD know that TRST is not available.

CMSIS 2.0 Alpha

New Alpha version of CMSIS except adding Cortex-M4 support has replaced implementation of single assembly instruction functions by making them inline and moving code to dedicated header files (core_cmFunc.h and core_cmInstr.h) in CoreSupport folder. Thanks ARM! Now I can utilize original CMSIS code in my projects instead of coping functions with modified names to an additional header file. Nevertheless, the definition of __INLINE for GCC compiler still does not enforce actual inlining of the code as I described in the previous post. Well. I hope it will be fixed in the final release.

Using CMSIS with GCC

My interest in ARM Cortex-M3 based micros recently turned into some practical exercises with STM32-H103, GCC and Cortex Microcontroller Software Interface Standard (CMSIS) library. CMSIS is a useful set of definitions of Cortex-M0/M3 core architecture registers, data structures and interfaces to access core resources of a Cortex-M0/M3 based microcontroller. However, if you use GCC with CMSIS (v1.2.0 or v1.3.0) the definition of __INLINE macro provided in core_cm3.h and core_cm0.h:

#define __INLINE inline

does not force the compiler to actually inline the body of a function defined with __INLINE attribute. To tell GCC to inline the define should be:

#define __INLINE __attribute__((always_inline)) inline

Furthermore, __get_xxx, __set_xxx, __LDREX, __STREX groups of a single assembly line functions implemented as a regular functions as oppose to inline functions. Change of these functions to inline style allowed two times improvement of the performance of certain fragments of my code.

My take on SST

My search of some sort of OS suitable for N1's on-board computer based on LPC2103 lead me to an article "Build a Super Simple Tasker" (SST). The article describes a "run-to-completion (RTC) prioritized, fully preemptive, deterministic real-time kernel". Although I like the simplicity of the idea I think that tight coupling between an event and its target task in SST implementation (see Listing 3) reduces flexibility of the kernel. The Observer pattern is commonly utilized by event propagation frameworks including frameworks designed by Mother Nature. Additionally, an Observer pattern based design would allow to create and destroy tasks during an application run time. With these thoughts in mind, I decided to put together my own implementation of the idea. Since the coding has been completed I am using this implementation in two unrelated projects and should confirm that RTC tasks fit pretty nicely into FSM oriented designs and single event queue implementation of the Observer pattern provides nice to have extra flexibility with minimal impact on performance.

Number one

Number one (N1) is a robot which actually runs on a mobile phone. N1 has two parts: body and brain. The body consists of slightly modified chassis of N0 and tiny ARM® based computer which acts as brain spinal cord (BSC). N1 brain, located on a mobile phone and implemented as a Java ME program, connects to its BSC through Bluetooth®. There are some further technical details and photos on the robot's home page as well as a video which shows N1 equipped with infrared distance sensor in action.

5V for a target from OpenOCD USB Adapter

I recently bought OpenOCD USB Adapter. The adapter arrived as a kit which comprises of the assembled adapter board, two IDC male connectors (ten and twenty pins) and one D-type 9 pin male connector.

One feature which is missing in this adapter from my point of view is an option to power up a target from USB. A USB port can provide up to 500 mA. The adapter should not consume more then 250 mA according to FT2232D datasheet. This would leave approximately 250 mA for a target board. For example, Olimex LPC2103 prototype header board would consume about a hundred mA.

Fortunately, there is a place on the adapter board for four pin header right behind D-type serial connector. Two pins in the center are serial's TTL TX and RX and pins on both sides are Ground and +5V straight from USB's Vbus. (Note, there is no ferrite bead on the adapter board.) I assembled a little board with MOSFET (FDN302P) to control power output. I used schematic of "Bus Powered Circuit with Power Control" (Figure 12) from FT2232D datasheet. The most challenging for me was to solder a wire to PWREN# pin (41) of FT2232D. The chip comes in the LQFP-48 package with leads on a 0.5mm pitch. Finally, since I do not need standard serial interface and only two pins in the second row of the serial connector are utilized, I decided to put a two pin polarized header in the first row to serve as a power connector for a target.
Well... As it turned out when OpenOCD (see update below about version 0.2.0) initializes interface FT2232 pulls PWREN# pin to high level for several hundred mS. This switches power off for the target. Meanwhile, OpenOCD attempts to communicate to the powered off target. I had to add a one second delay in openocd.c between jtag_interface_init and jtag_init calls to make the modification work.

UPDATE: OpenOCD version 0.2.0 seems to fix the issue above. I was able to flash and debug code on Olimex STM32-H103 board powered from the JTAG adapter.