Embedded Spare Time

Starting construction of H-bridge module.

2011-06-29T22:27:00.004+02:00

I got the components from ELFA and Lawicel a few days ago. The first step was to set up the LM2574-based step-down converter, supposed to deliver a stable 12V supply to the HIP4081, on a breadboard. The schottky diode which is part of the circuit had pins so thick, I had to sandpaper them down to be able to push them into the breadboard holes... :)

I had no batteries at hand that could deliver the 24V I plan to use for the finished Segway clone construction, so I had to borrow a battery from my lawn trimmer, providing 21V. The circuit proved to work fine, at least on a quick minimal load test.

More components ordered.

2011-06-23T23:51:00.002+02:00

Next step is to design a powerful H-bridge that can drive larger DC motors that can actually drive a full-scale Segway clone. Yesterday I ordered a bunch of components, most notably:

1 HIP4081AIP H-bridge driver IC.
4 IRFZ44N N-channel MOSFET transistor, capable of controlling 49 amps at 55 volts.
1 LM2574N-12 step-down switch regulator to provide the 12 volts required by the HIP4081AIP, from a 24-28 volt power supply (sealed lead-acid batteries).

My plan is to build a prototype motor driver on a breadboard and try it out for smaller currents, measuring timing and voltage levels on eg. the MOSFET gates. When it all seems to work, I will design a PCB capable of handling the full 25-40 amps required by larger motors.

One source of inspiration (an open-source, open-hardware motor driver):

http://www.robotpower.com/products/osmc_info.html

Balancing robot starts to work.

2011-06-23T23:44:00.002+02:00

After a little Arduino sketch hacking the robot is now balancing. It works pretty well on carpets, not so well on wooden floors, probably due to small friction. Carpets seem to reduce oscillations in the control algorithm.

Testing the H-bridge.

2011-05-10T22:20:00.005+02:00

I assembled the motors, wheels and electronics in a rather ugly way, but hopefully it will be enough to test all concepts. Behold:

I hacked some Arduino sketches to test the H-bridge. It seems to work fine, but I'm a little worried about the dead band around zero percent PWM duty cycle. Hopefully it doesn't matter, or I can compensate for it in software.

IMU Measurements

2011-04-22T22:20:00.006+02:00

Just got the components from Sparkfun now, and started experimenting, initially with the Arduino and the IMU. I was impressed by how easy it was to get started with the development environment. I hooked up the IMU's XACCEL output to the A0 input of the Arduino Pro Mini and basically just adapted to AnalogInOutSerial example to output the raw accelerometer value, together with two averaging functions. These were dumped to a file and I fed them into gnuplot to get a hint of how a low-pass filter would perform. This is how it looks:

Red line is the unfiltered input from the accelerometer. Green is filtered using a weighted average algorithm. So is the blue line, but it takes very little of the the fresh input into consideration.

New project

2011-04-15T22:14:00.003+02:00

Time for a new project, just like most of them it will probably not be finished in less than 3 or so years. However; the intention this time is to learn a little more about the following things:

Electronics, especially handling analog sensors such as gyros and accelerometers
Motor drivers, based on H bridges and MOSFETs
The Arduino platform (and thus, the AVR-based ATmega328 µC)
Mechanical constructions
Control theory and basic digital implementations of control loops

I have always been impressed by the Segway and my first aim is to build a small and simple clone of it based on an Arduino, a couple of gearmotors and wheels from Pololu, an IMU (Inertial Measurement Unit), a motor driver and some other stuff, mostly aquired from http://www.sparkfun.com/.

Today, the first components arrived (from Sweden-based http://www.lawicel-shop.se/):

Debugging serial device driver with the Jyetech oscilloscope

2010-02-13T22:01:00.004+01:00

It's really fun to actually use the home-soldered oscilloscope for something real. In this case I watch the 9600 bps traffic from my STM32 dev board:

And then, a closeup of the oscilloscope screen:

IPC considerations.

2010-02-12T17:36:00.003+01:00

My kernel currently has one message inbox for each process. I am thinking of letting each process have as many inboxes as it desires (possibly limited to 32). That way, a process can have one inbox for high priority messages received from eg. an interrupt handler and another inbox for application IPC.

I ran into these thoughts when writing the USART device driver. I want to have one process in charge for the communication. Sending a message to it transmits the message contents over the wire. However, the process in charge needs to be aware of if the serial port data register is empty. The interrupt handler could, when it has sent the last byte of a message, send a message to the process in charge of communication, to it's "device driver" inbox.

This should be analog to a solution where reading from an inbox can be done, specifying what message types are wanted. The benefit of this solution is that the kernel always returns the first message in the queue, increasing performance. The drawback is that the number of selectable message types (when receiving) will be limited.

DIY Oscilloscope

2010-01-31T14:02:00.004+01:00

A friend of mine convinced me to buy a kit to build a simple oscilloscope. At first, I thought it would not be very useful because the analog bandwidth is not more than 1 MHz. On the other hand, most of the times I have needed an oscilloscope, it has been to debug simple and slow data lines, such as SPI and RS232, so I decided to give it a chance. It was a real challenge to solder, because there were a lot of really small surface mount components (mostly capacitors and resistors) to solder. After a few evenings of soldering I was ready to try it out.

Here are a few pictures. First of all I measured the oscilloscope's built-in 500 Hz test signal:

Second, I measured the 9600 bps serial output from my HP48SX calculator. You can see that the output is not proper RS232 signal levels. I guess this is a way to save battery power on the calculator:

After a little testing, I am really impressed by the oscilloscope, especially as it was priced just over 500 swedish kronor (less than $80). It was also fun and interesting to solder all the small parts!

Serial port insanity.

2010-01-17T20:39:00.009+01:00

After oceans of time I am back again. The kernel now implements the following system calls:

rtos_yield (yield to another process)
rtos_allocate (allocate a 64 byte message buffer from the buffer collection)
rtos_transmit (hand over a message to another process)
rtos_accept (accept a message from another process)
rtos_dispose (dispose of a buffer)
rtos_delay (delay a specified number of system ticks)

The final names are yet to be decided. I also implemented support for the Cortex-M3 SysTick timer (which is mandatory in all Cortex-M3 based chips). It's exception handler increases the system tick counter and releases processes that have blocked themselves using rtos_delay.

I also started implementing support for USART2 in the STM32. That is because this USART is connected to the RS232 DSUB connector on the STM32-P103 dev board I use. To start with, I hooked the port up to my laptop using a RS232-USB adapter, trying a number of different serial port sniffer/terminal programs to see the dev board output. With little success! After a few hours, I grabbed my old HP 48SX calculator, which has an RS232 port on it. A few simple commands allow me to configure the serial port settings and then everything worked perfectly fine!

To set up USART2 for just using the transmitter, you have to do the following:


  /* Enable PCLK1 (USART2 is on APB1). */
  *STM32_RCC_APB1ENR |= (0x1 << 17); /* USART2EN - Enable USART2 clock. */

  /* Enable PCLK2 (GPIOA is used by USART2). */
  *STM32_RCC_APB2ENR |= (1 << 2); /* IOPAEN - Enable GPIOA clock. */
  
  /* Set up the PA2 pin for alternate function push/pull. This is the
     TX pin for USART2. */
  *STM32_GPIOA_CRL =
     (2 << 10) | /* CNF2  - Alternate function output push/pull. */
     (1 << 8);   /* MODE2 - Output mode, max 10 MHz. */

  /* Set up the Baud Rate Register for 9600 bps. See RM0008, chapter
     24.3.4. The value to be programmed in the BRR should be 234.375.
     DIV_Mantissa=234 DIV_Fraction=6. */
  *STM32_USART2_BRR = (234 << 4) | 6; /* 9600 bps */ 

  /* After-reset default values for other registers are suitable for an
     8-N-1 setup without enabled interrupts and DMA. */
  
  /* Enable the USART and the transmitter. */
  *STM32_USART2_CR1 = (1 << 13) | (1 << 3);

As I mentioned, I did not set up the receiver as this code is just a simple test to output characters over a serial line. Most of the lines are pretty self-explanatory I think, but there are a few thing worth noting. First, you have to enable clocking not only of the USART, but also for the corresponding GPIO port (in this case GPIOA). Second, when setting up the baud rate register, the fraction value is 16 times the fraction (0.375) i.e. 6. This is the value to be used when the clock frequency used for APB1 is 36 MHz (which is the maximum allowed frequency for APB1, and half the system clock). Do not forget to set up the APB1 clock prescaler!

Some things have happened.

2009-09-10T21:19:00.016+02:00

I have to apologize for the very bad update ratio on the blog. Hopefully someone will return to it anyway!

Since my last post, some 3 months ago, the kernel now implements 5 different system calls. These are:

yield
allocate a buffer
transmit a buffer to another process
receive a buffer from some other process
dispose of a buffer

The kernel is now a very simple message passing based one. It also handles different priorities, so that at every moment, the highest-prioritized ready process will run. Processes can now be written in C, as system call library functions are provided.

A couple of months ago, someone asked about a description of the entire process from booting up to scheduling. I will attempt to describe a few important steps:

First of all, the kernel and applications only run from RAM. Some basic support for running from ROM is implemented in the kernel and in the BSP (startup routines). There should not really need to be a lot of differences between these two cases and support for running from ROM will be there in time.

The way I run the system right now is using OpenOCD and GDB to download an elf file to the board. The elf file contains the monolith consisting of the kernel, the BSP and the application, everything linked to run from RAM. After downloading, I reset the board and let it run.

The first thing that happens is that the CPU is reset, which means that it will use the default exception vector location (which is at address 0x00000000, i.e. in flash) to find the reset routine. I have (once and for all) put a small assembly routine in flash, which is pointed out by the reset vector. This routine reads the desired reset vector from RAM (at 0x20000004), the initial main stack pointer (at 0x20000000) and simply jumps to the boot routine pointed out by the address in 0x20000004, which is the BSP startup. This bootstrapping assembly routine is not part of the OS, nor the BSP.

The BSP startup routine first of all sets up the STM32 clocks, so that the CPU core runs at 72 MHz (SYSCLK) which is generated from an 8 MHz external crystal which is multiplied by 9 using a PLL. AHB and APB2 clocks are also set up properly.

After setting up all clocks, the BSS segment is cleared. The area to be cleared is obtained by getting the addresses of the _bss_start and _bss_end symbols. These symbols are defined in the linker command file which is supplied by the BSP.

Next, by writing to the NVIC_VTOR register, the exception table location is moved to RAM (where it already is loaded). The GPIO module is set up to allow flashing the status LED.

After that, the BSP is almost finished setting up the board. There is one more thing to consider before handing over to the kernel.

All kernel setup processes (kernel initialization, process creation) must run from handler mode. I'll get back to the reason for that later. The default CPU mode after reset is thread mode, and the only way to switch to handler mode is through an exception. Therefore, the BSP writes the address of the kernel startup routine,
to the SVC (system call) vector in RAM and triggers it by issuing an svc instruction. This results in a switch to handler mode and a jump to the kernel.

The kernel startup routine clears the kernel pool area, then calls a hook which the application is supposed to implement. This hook function should do a number of rtos_create_process calls. This call allows the application to specify a process entry point, a priority and a stack size. For each call, a PCB is created in the kernel pool area, as well as a stack. The PCB is sorted into a readylist. After all these calls, the kernel is ready to start the highest prioritized process.

I mentioned earlier that the kernel startup must run from handler mode. The reason for this is that when the first process is scheduled, it will be started in the same way as if it was resumed after preemption. Therefore, for each created process, the architecture specific code is called to prepare the process stack in a way such that returning to the process and resuming it actually starts the process from the first instruction and with an empty stack.

When an application issues a system call, this is done by putting the syscall id (an integer, ranging from 0 to 4) in register r12 (done by an inline assembly routine). The scratch registers r0-r3 are transparently sent from the function call to the svc exception handler. The exception handler uses r12 as an offset into a jump table. Then a jump is taken to the system call implementation.

No interrupt handling is implemented yet, i.e. I haven't had to deal with critical regions in the kernel yet. It is still to be decided for instance what exception priority levels will be used for the SVC call in relation to other exceptions (interrupts from peripherals).

There is yet some more to be written about for instance context switching using the PendSV exception. I'll return to that later!

Flash a LED!

2009-06-10T09:04:00.004+02:00

Yesterday, I configured GPIO port C to be able to flash the status LED. I now have two processes yielding to each other. One of them turns on the LED, the other turns it off. Here is one of them. It writes to the GPIO C BSRR (bit set/reset register) to set port C bit 12 high, which turns the LED off.


    .global CM3_proc0
    .thumb_func

CM3_proc0:
    ldr    r1,    =0x40011010 @ PORT C BSRR register.
    mov    r2,    0x00001000  @ Set bit 12.
    str    r2,    [r1]
    mov    r0,    0x1         @ Yield system call.
    svc                       @ Perform the system call.
    mov    r0,    0x800000    @ Delay loop.
loop0:
    sub    r0,    0x1
    cmp    r0,    0x0
    bne    loop0
    b      CM3_proc0

A Fablab opens up in Malmö!

2009-05-26T08:07:00.004+02:00

A couple of days ago I read about the Fablab opening up soon in Malmö in the southern part of Sweden. I am really happy about this. At least a couple of my sparetime electronic projects have ended up as a PCB without a box or any mechanics at all. For instance, my MP3 player looks like this:

When I designed the PCB, I was planning to design and build a box afterwards, but I realize I'll never get down to actually doing that, drilling and sawing acrylic plastic is just too cumbersome. With a fablab, I will be able to design and mill my own boxes and mechanics without an enormous budget.

Be sure to check in http://www.fablab.se/.

First successful context switch!

2009-05-13T14:36:00.004+02:00

A couple of days ago, I ran my first fully working context switches. I have two small test processes that actually just yield to each other:

/* Test processes. */
__attribute__ ((naked)) static void proc0()
{
  for (;;)
  {
     asm("mov r0, 0x1\n\t"
         "svc\n\t");
  }
}

__attribute__ ((naked)) static void proc1()
{
  for (;;)
  {
     asm("mov r0, 0x1\n\t"
         "svc\n\t");
  }
}

The code is really an ugly mix of C and assembly, and it seems like the __attribute__ ((naked)) thing completely fools gdb as well. If i put a breakpoint on one of these two functions gdb does not put it on the first instruction, as you would probably want it to. Instead, it puts it one instruction after the first instruction. My guess is that gdb believes the first instruction to be a preamble for setting up the stack frame. But we don't have any stack frames here, due to the special attribute used. The workaround is to put a breakpoint on the address of the first instruction.

The processes put 1 in r0, which means call the yield system call, which in turns causes the simple scheduler to switch to the other process.

A few shots of the development board.

2009-05-07T06:42:00.006+02:00

Yesterday, I took a few pictures of the development board and the OCD module I use.

This is the STM32-P103 from Olimex. It features an STM32F103RBT6 µC from ST Microelectronics. It is based on the Cortex M3 architecture from ARM. The 32-bit CPU runs at up to 72 MHz. Equipped with 128 KiB of flash and 20 KiB of SRAM, it should be enough for many fun projects:

A view from the bottom side, showing the SD/MMC card connector:

The ARM-USB-OCD adapter that I use to hook the board up to my Linux laptop:

stmdb, ldmdb, stmfd etc...

2009-05-04T10:33:00.002+02:00

It seems that I am getting quite close to my first working context switch right now. As recommended for RTOS:es on Cortex-M3, my context switches actually takes place in the PendSV handler which looks like this:

    .global    CM3_handler_pendsv
    .thumb_func
    .extern current_pcb
    .extern new_pcb
CM3_handler_pendsv:
    mrs    r12,   PSP          @ Get PSP for current process.
    stmfd  r12!,  {r4-r11}     @ Save remaining registers.
    ldr    r0,    =current_pcb @ r0 = &current_pcb.
    ldr    r0,    [r0]         @ r0 = current_pcb 
    str    r12,   [r0, 8]      @ Update SP in PCB.
    ldr    r0,    =new_pcb     @ r0 = &new_pcb
    ldr    r0,    [r0]         @ r0 = new_pcb 
    ldr    r12,   [r0, 8]      @ r12 = SP for new process.
    ldmfd  r12!,  {r4-r11}     @ Restore r4-r11 for new process.
    msr    PSP,   r12          @ Update SP for new process.
    ldr    lr,    =0xfffffffd  @ Use process stack when returning.
    bx     lr                  @ Return to new process.

Make sure to use the proper variants of the stm and ldm instructions.The fd suffix stands for full descending which means that the stack pointer decreases before data is written to the stack using it. Therefore, the stack is always full ie. the stack pointer always points at valid data. When reading from the stack, the stack pointer increases after the reading operation.

Fighting the GNU as assembler (contd.)

2009-04-28T10:07:00.007+02:00

Okay, yesterday I tested the RTOS prototype with the exception vectors put in an assembly language file instead. It did not work quite as expected...

To begin with, I should tell you that my code is linked to be run from the embedded SRAM in the STM32. This is because I think it is prettier to not have to erase and reprogram the flash all the time. On the other hand, the Cortex-M3 always has it's exception vectors placed at 0x0 out of reset, and that is within the flash area. That means that following a reset, the CPU will always start executing from the reset vector at 0x4. It is possible to relocate the exception vectors to 0x20000000 (SRAM) by modifying the vector table offset register once you're running and thereby pointing out your own vectors placed in SRAM.

To be able to practically run my code from SRAM I implemented a minimal bootstrap routine that I put into the flash area:

static void reset();

unsigned int *vectors[2] __attribute__ ((section(".vectors"))) = {
(unsigned int *)     0, /* No stack used. */
(unsigned int *)     reset
};

__attribute__ ((naked)) static void reset()
{
/* We enter here, running as privileged in thread mode. TRM 2.2.
  We use SP_main. TRM 2.2.1 and 5.4.
  NVIC interrupts disabled. NMI and Hard Fault disabled. TRM 5.9. */

/* Remap vectors to 0x20000000.
  Read stack top and entry point from
  user's RAM-based vectors. Jump to
  entry point. */
asm("mov r0, #0x20000000\n\t"
   "ldr r1, =0xE000ED08\n\t"
   "str r0, [r1]\n\t"
   "ldr sp, [r0]\n\t"
   "ldr pc, [r0, #4]");
}

TRM refers to the Cortex-M3 Technical Reference Manual. The reset routine reads the initial stack pointer and SRAM-based boot routine address from the user's exception vector at 0x20000000. It set the vector table offset register and jumps to the user's reset routine. This way, it appears like the board boots from SRAM.

So first, load your code including your exception vectors to SRAM, then issue a system reset to the board.

The problem I ran into yesterday was when performing an svc (system call). The CPU properly jumped to my exception handler:

  .global  CM3_handler_svc
.extern  portable_syscall
CM3_handler_svc:
bl  portable_syscall
bx  lr

Problem was that when executing the first instruction (the bl), an exception occured. I noticed that the T-bit in the xPSR register was cleared when taking the svc exception. Executing instructions in the Cortex-M3 with the T-bit (thumb mode) cleared is not allowed. The fix was to add the pseudo-op .thumb_func before the exception handler code. That way, the exception table entry corresponding to svc sets the LSB of the jump address and the T-bit gets set when running the svc handler. Haven't tested this yet, but it should work.

Fighting the GNU as assembler.

2009-04-27T11:17:00.009+02:00

For my RTOS experiments, I need vectors to be nicely linked into the binary, which I download to the Cortex M3 target, being an STM32 development board from Olimex.

To start with, I used to put exception vectors in the C source file, in the following way:


/* Vector Table */
unsigned int *vectors[12]
__attribute__ ((section(".vectors")))= {
  (unsigned int *)     START_STACK_TOP,
  (unsigned int *)     boot_rtos,
  (unsigned int *)     0x00000000,
  (unsigned int *)     0x00000000,
  (unsigned int *)     0x00000000,
  (unsigned int *)     0x00000000,
  (unsigned int *)     0x00000000,
  (unsigned int *)     0x00000000,
  (unsigned int *)     0x00000000,
  (unsigned int *)     0x00000000,
  (unsigned int *)     0x00000000,
  (unsigned int *)     CM3_SVC
};

That way, I tell gcc to put the array of vectors in the .vectors section. As I use OpenOCD to communicate with the board, using the ARM-USB-OCD, I can download the executable directly from gdb, using the "load" command.

However, I would like to have the vectors defined in an assembly language source file, together with a few of my Cortex M3 specific routines (such as system call handling etc). Therefore I tried to put the vectors in the .s file:

    .section        .vectors,"aw"
    .global    CM3_vectors
    .extern    boot_rtos
CM3_vectors:
        .word   START_STACK_TOP
        .word   boot_rtos
        .word   0
        .word   0
        .word   0
        .word   0
        .word   0
        .word   0
        .word   0
        .word   0
        .word   0
        .word   CM3_handler_svc
        .word   0
        .word   0
        .word   CM3_handler_pendsv

However, I initially did not use the "aw" attribute to the .section operator. This resulted in the vectors area being considered a debug symbol when using nm. Therefore, gdb did not download it to the board.

Using the -S flag to gcc, I could examine the assembly output from gcc and that way find out that I should use the "aw" attribute. Apparently GNU as does not apply any default attributes on a section called .vectors.

First entry...

2009-04-27T10:12:00.000+02:00

Hello!

I intend to write a few lines now and then about my electronics projects. Hopefully, it will be of interest to someone! :-)