Tools for Art and Microcomputers

Using a STM32 based board for Arduino Development

2009-09-12T01:12:00.003+02:00

Exploring ways to enhance Arduino while still keeping the ease and experience.

This is work in progress, more details, updates and pictures coming soon. But the basic stuff works as described today.

Using Arduino boards and the Arduino GUI is a simple and fast way to develop embedded applications. There are predefined functions for input and output, serial communications and timing, many example sketches and the user does not have to worry about low level initialisation, interrupt vectors and timer configurations. On the other hand, ATMega 168 chips have limited resources, it is an 8 bit chip and not very fast.
Modern Cortex-M3 chips like the STM32 are fast, have much more RAM and flash and they have powerful and well documented debugging subsystems using JTAG tools, but starting to program these chips can be a huge step.

So here is my project to use a slightly modified, but from the users point standard Arduino IDE, standard Arduino sketches and run them on a powerful 32 bit Cortex-M3 (STM32) chip. The process of writing sketches, uploading them and then running them is exactly the same as for ordinary Arduino development. It is just that the processor board we use is not an Arduino. And you can use it all for your old Arduino boards also.

More complicated sketches that uses lowlevel access to the ATMega chip must be rewritten for this new platform.

The components we need:

Hardware.
Modified Arduino IDE.
Library code for this chip and board configuration.
Toolchain to compile and build code for a Cortex-M3 processor
An uplader that is used to program the chip.

The software setup has been developed and tested under Linux.

Hardware

The board I use is an ET-STAMP-STM32, a chip carrier module that brings out all chip i/o lines but not much more. I bought it for $24.90 from Futurlec (ET STM32 Stamp). It is mounted on a breadboard together with a 3.3V power supply, a serial USB adapter, a LED and some extra stuff for experimentation lika a potentiometer connected to an analog input and a push button.

The FTDI USB is only used to supply 5V to the small 3.3V regulator board. It can also be connected to UART2 or UART3.
The board is at the moment running a sketch that read the analog voltage from the potentiometer and adjusts the LED blink frequency:

volatile unsigned int count=-1;
int ledPin = 44;  // STM32_P103 Board - PC12
int dly;
int analogChn = 10;  // Analog channel 10 is PC0 = pin 32

void setup()
{
  pinMode(ledPin, OUTPUT);      // sets the digital pin as output }
  Serial.begin(115200);         // opens serial port, 31250bps (MIDI speed)
  Serial.write("\n\n   ***   Hello from Arduino 32   ***\n");
}

void loop()
{
  int k;
  count++;
  dly = analogRead(10)/2+20;
  digitalWrite(ledPin, HIGH);   // sets the LED off
  delay(dly);                  // waits for a second
  digitalWrite(ledPin, LOW);    // sets the LED on
  dly = analogRead(10)/2+20;
  delay(dly);                  // waits for a second  
  if (count%100 ==0)
  {
    Serial.print(count);    
    Serial.write("\n");
  }   
}

So you can see that the sketch is a totally standard Arduino sketch.

Modified Arduino IDE.

The Arduino IDE is modified in order to be able to build code with the ARM toolchain. The modified files and some new files that are added can be found at http://github.com/mlu/arduino-stm32/tree/master . These files must be placed in the source tree for Arduino 0017, and then the IDE must be rebuilt.

Library code for this chip and board configuration.

The special code for this chip and board are found under hardware/stm32 and to use this you just have to select the board "STM32 Arduino32" in the Tools menu in the IDE.

Toolchain to compile and build code for a Cortex-M3 processor

I use the Codesourcery G++ Lite Edition for ARM, EABI version, that can be downloaded from the Codesourcery website (Codesourcery G++ Lite ).
Install this and make sure that the top bin directory containing "arm-none-eabi-gcc" and the rest of the cross compilation binaries are in the path.

Uploader

I have written a small uploader, using similar command line arguments as avrdude, that uploads the compiled and linked sketches to the processor.
The code and also a compiled binary that runs under Fedora 10 are included in the files at github.com/mlu/arduino-stm32.

Almost ready to rock

The first thing to notice is that the pin numberings are different

Arduino sketch             Board
digital pin number 0..15    pin PA0 .. PA15
analog pin number 0..7      pin PA0 .. PA7
analog pin number 8,9       pin PB0,PB1
analog pin number 10..15    pin PC0 .. PC5

Pins 9 and 10 (PA9 and PA10) are used by USART1 and are connected to the RS232 level shifter for the serial port and should not be used.

We must also manually switch the board between bootloader mode and normal run mode with the blue switch, and also do all resets manually with the reset switch.

Testing Blink

Blink uses the LED on pin number 13, This corresponds to pin PA13 so we add a LED and a 220 ohm serial resistor to PA13. Connect a serial adapter to the board and select the corresponding serial port in the Arduino IDE.
Load the Example/Digital/Blink sketch and select board type "STM32 Arduino 32". Set the board in bootloader mode by depressing the blue button, the green bootloader LED lights up, and reset the board. Now it should be possible to simply upload the sketch :), go back to normal run mode with the blue button and reboot with the reset button.

Now this is new and quite untested code so many things could go wrong when trying to do this on a computer with a different setup.

More to follow, especially with reader feedback

Debugging on the Cortex-A8, System Components

2009-09-05T16:09:00.034+02:00

Cortex-A8 for dummies, part 1

I have been working on the Cortex-A8 subsystem for OpenOCD for some time this summer. This is great fun, when there is enough time, but also takes a lot of work. It is a complicated system and the documentation is large, spread over several big TRM's and sometimes hard to grasp. So here comes the "Cortex-A8 Debugging for Dummies" version 0.0. This first post looks at the main components involved and the access methods.

You can also take a look at OpenOCD for the BeagleBoard at
http://elinux.org/BeagleBoardOpenOCD

The new members of the ARM family of processor cores, the Cortex-M3 and the Cortex-A8, share some features but in many fundamental ways they are not similar. They both support the Thumb2 instruction set and they both use the ARM Debug Interface v5 for debugging and direct access to the core debug units and the AHP and APB buses. Cortex-M3 processors also use the NVIC interrupt controller for handling peripheral interrupts. This makes debugging easier and interrupt handling more consistent when using processors from different suppliers. Cortex-A8 processor have implementation defined handling of external interrupts.

Architecturally there are big differences. The Cortex-M3 uses the ARMv7M profile with a very simplified set of processor modes and a reduced set of shadow registers. Cortex-M3 can only run Thumb2 code. This is in contrast to the Cortex-A8 that can run ARM, Thumb and ThumbEE instructions, and where the architecture is a variant of the standard ARM architecture seen in ARM7, ARM9 and ARM11 cores.

System Components

Here is a simplified picture of a Cortex-A8 system, based on the Texas Instrument OMAP3530 Applications Processor, used in the BeagleBoard. There are four main components involved in our picture of the system:

Debug Access Port, connects an external debugger through JTAG or SW, serial wire, to our system. The DAP can have one or several Access Ports, AP, that connects to different parts of the system.
MPU, Microprocessor Unit Subsystem. Here we find the processor core, core registers, system coprocessor CP15, Memory Management Unit, L1 and L2 Cache.
A Core Debug Unit that can pass data and instructions directly to the processor core, and also halt and resume the processor. This is connected to the AP through a local memory bus, an Advanced Peripheral Bus, APB.
External high speed bus, this is the L3 bus and it is an implementation of the Advanced High Speed Bus, AHB, specified by ARM. Peripheral components and memory are connected to this bus.

Main Components for Core Debug System with one APB and one AHB MEMAP

In this example we have two access ports, both of them access system resources by a local memory address space, so called memory mapped access ports or MEMAP. The access ports are marked with the type of bus it is connected to. The APB-AP is connected to the debug resources without going through the system AHB bus. Each MEMAP have a access port number to identify it in the DAP. For the OMAP3530 processor the AHB-AP is number 0 and the APB-AP is number 1.

A debug program like OpenOCD connects through JTAG to the DAP, and all communications are passed through an access port into the system. When using OpenOCD we can select which access port to use with the command:

>dap apsel n

Here n is 0 or 1 for a system with two AP's. After selecting a MEMAP we can access the memory space of the AP with the memory display word, mdw, and memory write word, mww, commands:

>dap apsel 1
>mdw 0x80000000
>dap apsel 0
>mdw 0x80000000
>mww 0x80000000 0x12ab34cd
>mdw 0x80000000

If there is no memory at the specified address or if the access is prohibited by the security manager a "Sticky Error" is generated by the AP and reported by OpenOCD. We can get more information about the type of resources a MEMAP is connected to by using the command

>dap info n

This information is encoded by the AP in a so called ROM Table. The details of how to identify system resources from a ROM Table will be explained in a later post.

The APB AP, with MEMAP access port number 1, is reported as "MEMTYPE system memory not present. Dedicated debug bus."This indicates that only CoreSight components and other debug resources identified in the ROMTABLE for this AP are accessible. Memory and memory mapped peripheral control registers are not available.

The ADP v5 Debug Port is described in ARM IHI 0031A (ARM Debug Interface v5).

AHB and APB buses are described in ARM IHI 0011A (AMBA Specification Rev. 2.0).

The Debug Unit, the debug registers, MPU and the cache systems are described in ARM DDI 0344H (Cortex-A8 TRM).

The system overview and relation between the components can also bee sen in OMAP35x Technical Reference Manual (spruf98b.pdf) Figure 1-1. Interconnect Overview.

Core and Memory Access

The core is accessed through the APB MEMAP using the communications registers in the debug unit DTRRX, DTRTX and ITR.

Access to the full memory address range of the system can be done through the AHB AP to the L3 bus and is controlled by the security and access restrictions that are active in the system. This access always uses physical memory addresses (PA). There is risk for cache coherency problems when accessing memory this way, for volatile resources like I/O registers the problem should be less. This access can be done while the MPU Core is running.

When MMU is active all memory addresses in the core like PC, LR and data pointers are virtual addresses and must be translated to physical addresses before accessing them through the AHB AP.

Another way to access memory and memory mapped resources from the debug port is through the MPU using LDR and STR instructions written to the ITR and data in the DCC registers, DTRRX and DTRTX. [Cortex_A8 TRM, sec 12.11.6]. This access will go through the Cache and Memory Management Units of the Cortex_A8 and thus use virtual addressing when this is activated.

Strategies

For configuring systems at start up, such as setting memory controller parameters, clocks and PLL registers, memory access through the AHB access port is good. This should also work well for writing to flash memories.

For debugging code running on the MPU, the APB and access through the MPU core probably should be used, since this method avoids problems with virtual to physical address translations and also helps avoid cache coherency problems.

A debug system should implement both access methods and some method to choose which one to use.

Acknowledgements

Many thanks to Dirk Behme for proof reading and helpful comments.

MIDI7S - a flexible USB - MIDI interface

2009-07-31T01:02:00.003+02:00

MIDI7S - a flexible USB - MIDI interface

This page is work in progress and will be updated with more precise documentation when that is available.

System Components

Processor board

The AT91SAM7S64 processor has 3 uarts that can be used as MIDI ports and a USB interface. The Olimex SAM7-P64 board also has header for most uP pins, power supply and mmc card connector. This makes it a cheap and powerful platform for a USB MIDI system.

This processor is a bit old, but it is still a nice processor and I had this board and did not use for anything else. Today I would probably use something like a Olimex STM32-P103 board or design my own board for a STM32F103 processor.

MIDI interface board

MIDI out is driven directly from the microprocessor uart tx pin. Only one 220Ohm resistor is used , there should be two according to reference implementations. When driving MIDI from a 3.3 V source 2x70 Ohm is probably the best, for a typical VF of 1.5V and series resistance of 220 Ohms in the receiver this gives I=(3.3-1.5)/360 = 5mA. The short curcuit current, 47 mA is a little bit high but not exceptional.
MIDI in uses 6N137 optoisolators

MIDI 1 IN / OUT

MIDI 2 IN / OUT

Schematic (one channel):

Board layout (one channel)

The actual construction was built on a strip-board

DOG-ME Display board

This a 2x20 character LCD display using serial communications

Communication Interfaces

USBMIDI

The USBMIDI configuration uses two logical USB MIDI Cables connected to the physical MIDI ports

/* MIDI IN JACK 1 receives data from the USB interface Ep 1 */

/* MIDI IN JACK 2 receives data from the serial uartmidi[0] */
/* MIDI OUT JACK 3 transmits data to the USB interface Ep 82 */
/* MIDI OUT JACK 4 transmits data to the serial uartmidi[0] */
/* MIDI OUT JACK 8 transmits data to the serial uartmidi[1] */

The sending of USB MIDI data through MIDI OUT JACK 3 using USB IN endpoint Ep82 needs work for buffering and handling of many small write requests

Serial MIDI

The serial MIDI interfaces are connected to USART0 and DEBUGUSART. USART1 is connected to a RS232 level shifter an can be used for "standard" serial communications.

Dog-ME Display interface (SPI 3.3V)

PA13 MOSI
PA14 SPCK
PA30 IRQ1/NPCS2 DOG_LCD_SELECT_PIN
PA31 NPCS1/PCK2 DOG_LCD_RS_PIN

Code

The code is written in C++ using a minimal profile for small embedded systems, no dynamic object creation, no exceptions.

USB MIDI device descriptor

http://www.usb.org/developers/devclass_docs/midi10.pdf

USB MIDI device descriptors as C code, corresponding header file

Transmission buffers

All uart communications uses buffered DMA transactions

spi to the display should also use DMA but with a DLYBCT of 50 giving a character spacing of approximatly 33us, the serial:: transmission logic can be reused (subclassed) here.

The AT91SAM7 variable chipselects and chipselect decode mode together with 32 bit DMA SPI transmissions allows us to control both data bits and the RS line with automatic transfers to the Dog-Me display.

Testing

The system has been used as an USB to MIDI inteface betwen a Linux computer and a U220 synth module. The usb midi ports are autodetected and added as Alsa MIDI ports. Some USB communication gliches has been observed, but not frequent and not yet reproducible. Loopback tests with a standard MIDI cable connected from MIDI out to MIDI in works well.

Round trip times on PC running Linux, Fedora 10, PC(Alsa MIDI)->USB MIDI IN->MIDI OUT->MIDI IN->USB MIDI OUT->PC are 1.5 - 3 ms (/home/lundin/delad/arbete/mikrop/usbmidi/miditest.c) with processing times up to 130uS using single message pings (090531 r357)
Direct echo within the module , no serial MIDI, gives times of .8 to 2 ms

Future

With the basic USB and MIDI communications working, it is possible to expand the capabilities of the system.

The analog and digital inputs can be used to generate MIDI events from different sensors and there is spare processor capacity for MIDI processing.

TWI EEPROM For settings

Control panel

I/O Extender

MIDI file player

Sensor to midi event generation

Using Python and XML for parsing USB descriptor structures to C

2008-08-08T03:14:00.008+02:00

This project consists of a Python script that parses an XML description of USB descriptors and generates C code structures that can be included in a C firmware program for a USB device. This tool is primarily intended for developers of USB devices on embedded platforms. The XML representation of the descriptors gives a good view of the structure and the Python parser generates correct bDescriptorType values, bLength values and calculates total lengths. For elements with a variable number of child elements, such as bNumEndpoints in the Interface descriptor, the correct value is inferred from the XML structure. Most elements have a default value that is inserted in the generated C data structure. Symbolic values can be used for field values through XML entities defined in a DTD.

Related work

This project is part of a set of tools written in Python to simplify work with embedded development and USB. Most of the development work is done under Linux. Other components in this effort are:

usbmodule: A Python module that wraps libusb and gives raw access to USB devices, with experimental thread code to download and buffer incoming data before the application requests it, this works (for me) but it is unstructured, uncleaned and probable a bit buggy. This is similar to PyUSB http://pyusb.berlios.de/ , I have not had time to really check out this project, perhaps we should merge ....

A python GUI application for firmware downloads to embedded systems, first written to program Parallax Javelin systems from Linux, then extended to talk to serial monitors on LPC2xxx and AT91SAM7 arm processors. Today it is mostly used for SPI flashing of Atmel AVR8 processors using an FT232 interface in bitbang mode (this is where the USB from Python is used)

Example

An example XML representation of a device dsecriptor

<USB_Device_Descriptor name="devDescriptor" bcdUSB="0110" bDeviceClass="0" bDeviceSubclass="0" bDeviceProtocol="0" idVendor="EB03" idProduct="2463" bcdDevice="0000" iManufacturer="1" iProduct="2" iSerialNumber="3" bNumConfigs="1"/>

and the output in C code format that is generated

const char devDescriptor [] = {
// Device Descriptor
/* 0 */ 0x12, //bLength
/* 1 */ 0x1, //bDescriptorType
/* 2 */ 0x10, //bcdUSB
/* 2 */ 0x1,
/* 4 */ 0x0, //bDeviceClass
/* 5 */ 0x0, //bDeviceSubclass
/* 6 */ 0x0, //bDeviceProtocol
/* 7 */ 0x8, //bMaxPacketSize0
/* 8 */ 0x3, //idVendor
/* 8 */ 0xeb,
/* 10 */ 0x63, //idProduct
/* 10 */ 0x24,
/* 12 */ 0x0, //bcdDevice
/* 12 */ 0x0,
/* 14 */ 0x1, //iManufacturer
/* 15 */ 0x2, //iProduct
/* 16 */ 0x3, //iSerialNumber
/* 17 */ 0x1 //bNumConfigs
};

Status

Currently the tool can generate what looks as correct C code structures, with examples from USB specification. The output has not been tested and used as descriptor structures in actual USB firmware. The Python code can be run as a simple command line tool. There is a lack of documentation for the XML tags and attributes used. Future work devoted to this will depend on the testing and also interest from third parties-

Future work

Use the output from this tool as descriptors for a MIDI interface implemented on an AT91SAM7S development board. Use the output from this tool as descriptors for a HID device implemented on an AT91SAM7S development board connected to . This document/page will also be updated and made more complete depending on external feedback.

Contact

Magnus Lundin If you are interested in this project contact me at: lundin at mlu dot mine dot nu

Welcome

2008-08-08T02:49:00.002+02:00

Hi there, and welcome to all who are interested in Art and Microcomputers

And in the power to create your own designs.

A new blog !!!
I am not sure the world needs so many more blogs. But I will use this space to discuss some of my ideas on tools used in connection with art and microprocessors.

Hopefully I will also get some feedback from you out there, passionate users of microprocessors and connected hardware in artistic projects.

Some background:
I have a background as a programmer, mathematician and also as a dancer. I have done projects in this field since around 1991 when I worked on computer choreography tools with the Kacor group (Stockholm) . Since then I have done computer control for dance performance music, when that was still mostly done by swapping casette tapes and for the last ten years I have mostly worked with choreographer Åsa Unander-Scharin at Scen och Sinnesproduktion and produced some mechatronic installations with her, notably Orpheus and Petrushka .

This work has evolved from purely software to a very mixed mixed bag of software, hardware and firmware. During this process I have used and also constructed a wide array of tools. Some of this might be interesting to YOU ?

So, a new blog ... we will see

Yes I do have a "regular" job at the side to pay rent and other expenses.