WPF: boolean to visibility converter

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

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

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

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

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.

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

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!