Testing the H-bridge.

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

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

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

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.

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

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.

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!