Andu Goes West

WPF: boolean to visibility converter

2009-05-07T05:36:00.001-07:00

Hi Folks,

recently I had the pleasure to remove home-brewn converters named VisibilityOfBoolean and VisibilityOfChecked and started using System.Windows.Controls.BooleanToVisibilityConverter instead.

Example of usage in XAML, experienced reader fills in the details:

<BooleanToVisibilityConverter key="VisibilityOfBool" />

and later:

Visibility="{Binding ElementName=checkboxVisible, Path=IsChecked, Converter={StaticResource VisibilityOfBool}}"

Easy as a pie. I only wish there was an equally easy way to invert a boolean value!

Windows Presentation Foundation - a fresh breeze in user interface programming

2009-04-28T01:51:00.000-07:00

It has been very refreshing to get used to write user interfaces in a markup-language (XAML) and program the behind-the-scenes behaviour in another file (C# code).

I am experimenting with the following style, which has not been possible with most of the previous user interface technologies:
1. In the C# code, expose all the data required by user interface as dependency properties. In addition, avoid setting properties of the user interface controls directly.
2. In the XAML file, bind the properties of the controls to the dependency properties declared in the C# code.
3. Hint: style triggers and converters can be used to implement dynamic user interface.

So far it seems to work fine. The C# code is pretty much independent of the user interface and one can extend the user interface without tinkering with the code.

Mechanical stuff

2008-04-27T12:06:00.000-07:00

Today we (me + brother + uncle) replaced an engine on my car with another one. The present engine was damaged because of a problem between the chair and the steering wheel.

It was refreshening experience to use wrenches and screwdrivers after a pause of many years... Especially cumbersome was to remember the correct turning direction.

EVK1100: OLED display refresh rate over SPI

2008-02-23T07:20:00.000-08:00

A nice 128x128 OLED display have been collecting dust in my drawer - but not anymore! Since the sparkling fun site has collected all documentations including driver datasheet and sample code, it was easy. To make it even easier I opted for serial connection, shorting BS1 and BS2 on the carrier board to ground and connecting to port SPI1 as follows:
* D0 - SCK .
* D1 - MOSI.
* D/C# - LED2 (silkscreen says LED3) on EVK1100.
* CS - CS[3] aka PA20.
* RESET# - LED3 (silkscreen says LED4) on EVK1100.

OLED display running a demo drawing random circles:

The carrier board - it helped a lot on prototyping by including a boost converter required for OLED display and providing coarse enough connector area.

Demos are all good and nice, but the real question is what is the refresh rate of this beauty?

Theoretical maximum framerate while writing directly to display RAM is calculated as follows:
* frame size in pixels = 132*132 = 17424 pixels.
* frame size in bits = (3*8)*(size in pixels) = 418 176 bits.
* SPI speed = 15 Mbps.
* framerate = 15 000 000 (bits per second) / 418 176 (bits per frame) = 35.9 frames per second.

A very simple test was made which gradually increased background intensity in 64 steps - from white to black and the time to display 640 frames was measured to be 20.8 seconds. This corresponds to 30.7 frames per second, which is only slightly below theoretical maximum. Considering it was achieved with simple polling SPI it is not bad at all.

Combined with second framebuffer (using 51 kilobytes SDRAM out of 32 768 available) this OLED makes a beautiful display unit.

EVK1100: adding a stepper motor

2008-02-15T07:07:00.000-08:00

Added stepper motor driver to the EVK1100 prototyping area.

Connections were made as follows:
* VCC to USB VCC
* separated 78L05 output from the board and connected logic VCC to 3.3V VCC
* STP - LED1
* DIR - LED2

Steps like a charm!

It was a good idea to connect stepper to the LED-s as it allowed visually watch the inputs to the stepper motor driver. However, for normal speeds the blinking frequency of LED1 was too high for a human eye to recognize.

EVK1100: SPI @ 15 Mbaud.

2008-02-14T13:55:00.000-08:00

It's good to see you after long time... especially with good news.

In the meantime I have been playing with EVK1100, an AVR32 development kit from Atmel. See for yourself at the Atmel EVK1100 website, the list of features is quite long... I have to admit, this is a truly wonderful beast with the exception that almost all the pins are in use.

My goal is to connect it to a Micron MTM9001, which is a 1280x1024 monochromatic CMOS image sensor and get at least 40 rows from it at 15 fps. In other words, I want to see these two mated:

The image sensor has parallel interface with the allowed clock range 1...50MHz, however, the microcontroller is a absent of fast parallel peripherials and I am not exactly fond of digging through a few hundred thousand interrupts each second. Fortunately, the small number of rows permits use of one of the many serial interfaces on board provided that the transfer rate is at least 12 Mbaud. This speed easily rules out traditional USART-s and I am left with either SPI or SSC (serial synchronous interface), of which I prefer SPI. Ethernet would be even faster, but let's not be overly clever. All of these built-in peripherials are connected to DMA and thus the CPU is free to save the world or perform SETI (whichever is required first) during video capture.

Thus, the first concern is whether SPI is able to perform at the required speed. Datasheet simply states that SPI can be clocked at speeds up to the PBA (Peripherial Bus). Given that my PBA clock is 30 MHz, it would be more than plenty. However, life has given me one or two lessons about the value of these pesky little facts in the datasheets and I have to admit I am not in a position to be teached one more time. Thus I set out to find if the SPI can be really used at the required speeds.

Speed test requires two SPI interfaces, in other words, both of EVK1100. These two are connected as follows:
* SPI0/slave - can be reached from the connector; it is not connected to any on-board peripherials. Let me note that the screen silk has MISO/SCK swapped, watch out.
* SPI1/master - connected to SD/MMC socket, LCD, on-board AT45 data flash.
Obviously the Peripherial DMA is required.

For the sending end I created 1024 elements buffer, filled with consequental numbers in the range 0...1023. This buffer is quite small and fits nicely into SRAM, thus ensuring maximum possible transfer speed.

The receiving buffer was placed in the SDRAM, since it consisted of 300 "frames", each of size 32000 elements.

I first tried at 1 000 000 Mbaud, since it seemed like a 'safe' speed. As predicted, everything worked seamlessly. Second try was at half the PBA clock, 15 000 000 Mbaud and again, success.

In order to cut this chain of successes, I tried at the maximum speed possible, 30 000 000 Mbaud and observered lightning fast transfer and indeed, the verifying step failed at the first byte.

Lessons learned:
* SPI operation in master and slave modes.
* Peripherial DMA.
* Last but not least, SPI is suitable for connecting image sensor.

The camera to SPI interface is now in the works. Since it takes some time, I have time to learn how to use the USB for communication with PC and why not use it to send some pretty images to the PC?

Quickies

2007-07-12T12:08:00.000-07:00

From now on my preference will be operas, cinemas and theatres, since they are less crowded, less noisy, food is better and everything is cheaper than in the teenager-oriented beer parties.

The ATmega16 board I have worked with many weeks is almost coming together. We have the stepper nicely running, light intensity regulation works fine and the reflex sensor is on the right level (installed reflector on the rotating platform). Customer shall be happy again!

Production

2007-07-07T05:00:00.000-07:00

We will keep separate room for production. I spent three hours assembling all the equipment and tools required for optics assembly. If some were lost, it would have taken even more time.

We will complete the assembly instructions. The need was verified by redoing calibration again and again because of minor errors. A nice checklist would have saved a lot of time.

Microstepping

2007-07-05T08:02:00.001-07:00

Microstepping lets steppers work much faster and more reliably, not to mention smoother ride :P

The TCA3727 (looks like it will be obsolete shortly) has the following nice diagram explaining microstepping currents.

Stepping table is as follows:

#define I10 _BV(STEPPER_I10_PIN)
#define I11 _BV(STEPPER_I11_PIN)
#define PH1 _BV(STEPPER_PH1_PIN)
#define I20 _BV(STEPPER_I20_PIN)
#define I21 _BV(STEPPER_I21_PIN)
#define PH2 _BV(STEPPER_PH2_PIN)

static const u08
stepper_steps[] PROGMEM =  {
 I10 | I11 |   0 | PH2 |   0 |   0,  // 0
   0 | I11 | PH1 | PH2 |   0 |   0,  // 1
 I10 |   0 | PH1 | PH2 |   0 |   0,  // 2
   0 |   0 | PH1 | PH2 |   0 |   0,  // 3
   0 |   0 | PH1 | PH2 | I20 |   0,  // 4
   0 |   0 | PH1 | PH2 |   0 | I21,  // 5
   0 |   0 | PH1 | PH2 | I20 | I21,  // 6
   0 |   0 | PH1 |   0 |   0 | I21,  // 7
   0 |   0 | PH1 |   0 | I20 |   0,  // 8
   0 |   0 | PH1 |   0 |   0 |   0,  // 9
 I10 |   0 | PH1 |   0 |   0 |   0,  // 10
   0 | I11 | PH1 |   0 |   0 |   0,  // 11
 I10 | I11 | PH1 |   0 |   0 |   0,  // 12
   0 | I11 |   0 |   0 |   0 |   0,  // 13
 I10 |   0 |   0 |   0 |   0 |   0,  // 14
   0 |   0 |   0 |   0 |   0 |   0,  // 15
   0 |   0 |   0 |   0 | I20 |   0,  // 16
   0 |   0 |   0 |   0 |   0 | I21,  // 17
   0 |   0 |   0 |   0 | I20 | I21,  // 18
   0 |   0 |   0 | PH2 |   0 | I21,  // 19
   0 |   0 |   0 | PH2 | I20 |   0,  // 20
   0 |   0 |   0 | PH2 |   0 |   0,  // 21
 I10 |   0 |   0 | PH2 |   0 |   0,  // 22
   0 | I11 |   0 | PH2 |   0 |   0  // 23
};

#undef I10
#undef I11
#undef PH1
#undef I20
#undef I21
#undef PH2

When doing it step-by-step, some steps seem to be less "powerful" than others. It doesn't run _very_ smoothly on higher speeds. Perhaps some tweaking with step timings is neede in order to achieve really smooth operation.

Bugger lost it :)

2007-07-05T05:33:00.000-07:00

Got this bugger to work. Turned out that the debugging output interfered with the timing of communications.

The mitutoyo cable was misconnected, thus I reconnected it and presto - all works fine!

Harvard Architecture Lesson

2007-07-04T22:58:00.000-07:00

AVR has Harvard architecture. The program and data memory are totally separate entities. However, pointers to program memory have the same type as pointers to data memory.

This solved my yesterdays mysterious printouts. I was passing "const char*" to a function that was expecting "const prog_char *".

Farewell

2007-06-30T01:27:00.000-07:00

I managed to finish firmware yesterday. Good!

Yesterday afternoon I had a long farewell lunch at the airport with our guest from France. He is a rather smart guy, who had been staying at the Institute for a month trying frantically to use our main product for real and succeeeding in that. Despite all the problems; including starting working week later than planned. I always felt that we were not treating him nicely because we had been busy doing other thing and not going out for lunch or giving him too little support using our products. However, much to my surprise he said that compared to his previous stay in German (three months) we were very friendly and supportive. In fact, he invited me to visit France and I promised to do so.

Beforehand I was very reluctant to spend some extra time, but now it looks like time well spent. Time spent with our clients is rarely time wasted.

2007-06-29T08:22:00.001-07:00

Today I still have my hands at the same firmware I had on Monday. The spec is four pages long and I made an improvement today, which will be implemented tomorrow - FIVE DAYS LATER.

It is time to improve my spec-writing skills and reap the benefits of thinking before diving straight into the code.

One-liner (almost) CRC.

2007-06-28T02:52:00.000-07:00

Dallas iButton 8-bit CRC calculation.
Source: http://www.maxim-ic.com/appnotes.cfm/appnote_number/27
Polynomial: x^8 + x^5 + x^4 + 1 (0x8C)
Initial value: 0x00

uint8_t
_crc_ibutton_update(uint8_t crc, uint8_t data)
{
 uint8_t i;
 crc = crc ^ data;
 for (i = 0; i < 8; ++i) {
  crc = (crc << 1) ^ ((crc & 0x01) * 0x8C);
 }
 return crc;
}

64 bits and timers on AVR

2007-06-28T01:24:00.002-07:00

Inclusion of 64-bit multiplication and division increases code size by 10 kilobytes on an AVR ATmega8. Reworked the formula to avoid uint64_t-s.

Timer-based stepper movement is just great. Compared to _delay_1 or _delay_ms it offers following benefits:

Frees CPU up for other tasks.
Delay lengths are can be easily specified in milli- or microseconds.

It's not hard. I prepare a list of 'actions' to execute beforehand and set the timer top as follows:

/** Set up timer 1 (16-bit), frequency = F_CPU/(timertop+1). */
#define setup_timer1(timertop) do {        \
 OCR1A  = (timertop); /* set top */      \
 /*  Mode 4 - CTC with Prescaler 1 */      \
 TCCR1B = (1<<WGM12)|(1<<CS10);        \
 TCNT1 = 0; /* reset counter */        \
 TIMSK |= (1<<OCIE1A); /* enable output-compare int */  \
} while (0)

/**
 * Calculate timertop for setup_timer1.
 */
static uint16_t
timertop_of( const uint16_t length,
    const uint16_t time_ms)
{
 const uint16_t timertop = (((uint32_t)time_ms) * (F_CPU/100) / 10) / length - 1;
 return timertop;
}

/** Current action index. */
static int8_t action_index = -1;
/** Actions are executed from back to front. */
static ACTION actions[5];

The interrupt service routine chews through the list of actions:

SIGNAL(SIG_OUTPUT_COMPARE1A)
{
 if (action_index>=0) {
  ACTION* act = &actions[action_index];
  move_1_step(act->step_direction);
  if (--(act->countdown) == 0) {
   --action_index;
  }
 }
}

The experienced reader can fill out the details...

ARM power consumption

2007-06-27T07:36:00.000-07:00

ARM7TDMI core takes at least 15mA when running on 3.6864 MHz. AT91SAM7S256.