Pete Brown's Blog (POKE 53280,0)

Maker Geek Roundup 007 for 2/8/2012

Pete Brown — Thu, 09 Feb 2012 03:04:34 GMT

The Maker Geek Roundup aggregates information of interest to makers everywhere. Topics include .NET Micro Framework, CNC, 3d Printing, Robotics, Microsoft Robotics Studio, Electronics, General Maker stuff, and more. If you have something interesting you've done or have run across, or you blog regularly on the topics included here, please send me the URL and brief description via the contact link.

Windows Client Developer Roundup 087 for 2/9/2012

Pete Brown — Thu, 09 Feb 2012 02:44:11 GMT

The Windows Client Developer Roundup aggregates information of interest to Windows Client Developers, including WinRT XAML, WPF, Silverlight, Visual C++, XNA, Expression Blend, Surface, Windows 7, Windows Phone, Visual Studio, WCF RIA Services and more. Sometimes I even include a little jQuery and HTML5. If you have something interesting you've done or have run across, or you blog regularly on the topics included here, please send me the URL and brief description via the contact link.

Note that I've started breaking the Netduino, Electronics, Robotics, Synthesizer and similar content into a new roundup series called the Maker Geek Roundup.

Oh and you'll get Windows 8 Consumer Preview on February 29. Get ready to code (and design) :)

Windows 8 and WinRT/Metro General

Improving power efficiency for applications (Sharif Farag and Ben Srour)

XAML Technologies (Silverlight, WPF, WinRT Metro XAML)

Bad Entropy: MVVM and Multiple Selection - Part IV - DataGrid (Bad Entropy)
Overwriting the default WebRequest used by WebClient (Morten Nielsen)
Building A Multi-Touch Photo Viewer Control (Morten Nielsen)
DOT NET TRICKS: Optimizing INPC Objects against memory leaks using WeakEvents (Abhishek Sur)
- Also see my post on weak events.
Using the Live SDK in Windows 8 XAML/C# Metro Applications - Michael Crump (Michael Crump)
Reading and Writing text files in Windows 8 Metro (Morten Nielsen)
A Simple Pattern for Creating Re-useable UserControls in WPF / Silverlight (Colin Eberhardt)

DirectX Technologies (DirectX, XNA, WinRT DirectX, GPU and Game Programming)

The Starter2D and Starter3D tutorials now on the Marketplace (Dark Genesis)
Large Scale Terrain Rendering (Coding4Fun)

C++ and Native Development

C# to C++ - A Somewhat Short Guide (Bob Taco Industries)
C++11 Conformance Survey (Vikas Bhatia)
The Microsoft C++ Compiler Turns 20! (Visual C++ Blog)
C++ AMP Open Specification (Soma)
GoingNative 2012: All Sessions are now available On-Demand! (Channel 9)

Visual Studio and .NET General

Bring Some Game To Your Code! (Visual Studio Blog)

NUI (Kinect, Surface, More)

Kinect for Windows - Details of API Changes from Beta2 to v1.0 (C#/VB) (Rob Relyea)
Microsoft® Surface® 2.0 SDK and Runtime Update (Luis Cabrera)
Interactive Portfolio (Kinect Hacks)

Off-Topic Fun

The Karate Rap (YouTube)

I leave you with only the one "off-topic" item today, because after watching that, nothing else will ever suffice. Ever.

Creating Big Silverlight Windows and Getting Monitor Resolutions and Positions with PInvoke

Pete Brown — Wed, 08 Feb 2012 03:59:11 GMT

While doing the (long!) tech review for Silverlight 5 in Action, my friend and former coworker Tom McKearney mentioned that we should put together some code to make handling windows across multiple monitors a reasonable task in Silverlight 5. Then, on a mailing list, I recently saw the question:

Hi all -- I'm wondering if there is a maximum window size for Silverlight documented anywhere. For example if I had hardware that could support a 3x3 or 3x4 grid of 1920x1080 displays, can I make an SL5 OOB window that big? Can I make individual items in the window that big? Can I get hardware acceleration on all of it? Does the 3D API have any different limits than XAML? Or maybe Silverlight has no specific limit, but it's up to the hardware?

Curious about that, I decided to try it myself, and combine this with what Tom had requested. I don't have a 3x3 array of screens that size, however. It really is a serious number of pixels.

Cost of screens aside, most people don't have the video hardware to be able to run 6 displays. ATI has some displayport cards which will do that, but otherwise you're looking at a minimum of three video cards and a variety of connections. You're also looking at a shedload of video memory.

What I do have is a pair of 30" displays each running at 2560x1600. That's quite a bit smaller, but still much larger than most people have. It ends up being a bit less than half the requested pixels. I do get almost the right width, but the height is lacking.

I wouldn't want 3x3 of the HD res screens (too much bevel) unless they were big old TV-style ones and you were doing relatively low-res graphics. 3x3 of the 2560x1600 though? *drool*

In any case, my two combined are still quite a bit larger than the typical HD res 1920x1080 screen people have, with its 2,073,600 pixels, and is a valid test of creating big windows in Silverlight.

My displays are also oriented a little differently than you may expect:

That means that logical 0,0 is in the middle of the combined display. We'll need to know that for later.

Creating the Window

If you want to learn how to create out-of-browser windows in Silverlight 5, see my post here.

The first test is to see if I can create a window that fits the dimensions of my two screens. All sizes here will be hard-coded.

XAML

<UserControl x:Class="PeteBrown.SilverlightBigWindow.MainPage"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

    mc:Ignorable="d"

    d:DesignHeight="175

             " d:DesignWidth="800">



    <Grid x:Name="LayoutRoot" Background="White">

        <ListBox x:Name="DisplayList"

                 Margin="126,12,12,12">

            <ListBox.ItemTemplate>

                <DataTemplate>

                    <Grid>

                        <Grid.ColumnDefinitions>

                            <ColumnDefinition Width="150" />

                            <ColumnDefinition Width="50" />

                            <ColumnDefinition Width="150" />

                            <ColumnDefinition Width="150" />

                            <ColumnDefinition Width="75" />

                            <ColumnDefinition Width="75" />

                        </Grid.ColumnDefinitions>



                        <TextBlock Grid.Column="0"

                                   Text="{Binding MonitorName}" />

                        <TextBlock Grid.Column="1"

                                   Text="{Binding IsPrimary}" />

                        <TextBlock Grid.Column="2"

                                   Text="{Binding MonitorArea}" />

                        <TextBlock Grid.Column="3"

                                   Text="{Binding WorkArea}" />

                        <TextBlock Grid.Column="4"

                                   Text="{Binding Width}" />

                        <TextBlock Grid.Column="5"

                                   Text="{Binding Height}" />





                    </Grid>

                </DataTemplate>

            </ListBox.ItemTemplate>

        </ListBox>

     

     

        <Button Content="Open Full"

                Height="23"

                HorizontalAlignment="Left"

                Margin="12,12,0,0"

                Name="OpenWindow"

                VerticalAlignment="Top"

                Width="108"

                Click="OpenWindow_Click" />

        <Button Content="Open Primary"

                Height="23"

                HorizontalAlignment="Left"

                Margin="12,41,0,0"

                Name="OpenPrimary"

                VerticalAlignment="Top"

                Width="108"

                Click="OpenPrimary_Click" />

        <Button Content="Open Secondary"

                Height="23"

                HorizontalAlignment="Left"

                Margin="12,70,0,0"

                Name="OpenSecondary"

                VerticalAlignment="Top"

                Width="108"

                Click="OpenSecondary_Click" />

    </Grid>

</UserControl>

C# code

private void OpenWindow_Click(object sender, RoutedEventArgs e)

{

    Window w = new Window();



    w.Width = 5120;

    w.Height = 1600;



    w.Show();

}



private void OpenPrimary_Click(object sender, RoutedEventArgs e)

{

}



private void OpenSecondary_Click(object sender, RoutedEventArgs e)

{

}

This will allow me to click a button and have it open a giant window on the screen. The window has no content, so it'll appear as a plain white empty window.

Run it (remember, must be elevated trust out-of-browser app) and what do you see? No problem. One giant white window which fits across my screen.

The problem is, however, that it starts in the middle of my displays instead of over at the far left. I had to drag it to the far left to get it to take up the whole set of displays. How do we figure out how to position and size the window?

Positioning and Sizing the Window

On my setup, the monitor to the left is all in negative space. So, to move the window to the far left, I need to move it to -2560. Then we can open the window and then tell it to move to the top left, or to take up just a single display.

private void OpenWindow_Click(object sender, RoutedEventArgs e)

{

    Window w = new Window();



    w.Width = 5120;

    w.Height = 1600;



    w.Left = -2560;

    w.Top = 0;

    w.Show();

}



private void OpenPrimary_Click(object sender, RoutedEventArgs e)

{

    Window w = new Window();



    w.Width = 2560;

    w.Height = 1600;





    w.Left = 0;

    w.Top = 0;

    w.Show();

}



private void OpenSecondary_Click(object sender, RoutedEventArgs e)

{

    Window w = new Window();



    w.Width = 2560;

    w.Height = 1600;



    w.WindowStyle = WindowStyle.None;



    w.WindowState = WindowState.Maximized;



    w.Left = -2560;

    w.Top = 0;

    w.Show();

}

Ok, so we've verified that it can be done. Now we need to make it work for arbitrary resolutions and monitor configurations. Before we do that, though, did you notice that the sizing was off a bit? Both the width and height appear to be off by the measurements of the window chrome. It turns out this happens whether or not you're using custom chrome. I've reported a bug to the team and they're investigating, so for now we're going to have to ignore the size issues. If you work around the sizing in your own code, stick it in an conditional compilation block or something so you can easily change it if/when the bug is fixed.

Getting Display Informatin Using PInvoke

We're running in elevated OOB mode anyway, so as long as you only care about Windows, you can also throw in some P/Invoke. The main functions we're interested in are EnumDisplayMonitors and GetMonitorInfo.

The PInvoke.net example was enough to get me started, but it lacked a few necessary steps. Of course, it also needed some changes to work with Silverlight.

The first addition is the DisplayInfo class. We'll use this to hold information about a single monitor.

namespace PeteBrown.SilverlightBigWindow

{

    public class DisplayInfo

    {

        public string MonitorName { get; internal set; }

        public Win32Rect MonitorArea { get; internal set; }

        public Win32Rect WorkArea { get; internal set; }

        public int Width { get; internal set; }

        public int Height { get; internal set; }

        public bool IsPrimary { get; internal set; }

    }

}

Next, I need a way to populate this class. Here's where all the PInvoke action happens.

using System;

using System.Runtime.InteropServices;

using System.Collections.ObjectModel;



namespace PeteBrown.SilverlightBigWindow

{



    [StructLayout(LayoutKind.Sequential)]

    public struct Win32Rect

    {

        public int Left { get; set; }

        public int Top { get; set; }

        public int Right { get; set; }

        public int Bottom { get; set; }



        public override string ToString()

        {

            return string.Format("{0}, {1}, {2}, {3}", Left, Top, Right, Bottom);

        }

    }



    [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Auto)]

    internal struct MonitorInfoEx

    {

        public int Size;

        public Win32Rect Monitor;

        public Win32Rect WorkArea;

        public uint Flags;

        [MarshalAs(UnmanagedType.ByValTStr, SizeConst = DisplayManager.DeviceNameCharacterCount)]

        public string DeviceName;



        public void Init()

        {

            this.Size = 40 + 2 * DisplayManager.DeviceNameCharacterCount;

            this.DeviceName = string.Empty;

        }

    }



 

    public class DisplayManager

    {

        // size of a device name string

        internal const int DeviceNameCharacterCount = 32;





        private delegate bool MonitorEnumProcDelegate(IntPtr hMonitor, IntPtr hdcMonitor, ref Win32Rect lprcMonitor, uint dwData);



        [DllImport("user32.dll")]

        private static extern bool EnumDisplayMonitors(IntPtr hdc, IntPtr lprcClip, MonitorEnumProcDelegate lpfnEnum, uint dwData);



        [DllImport("user32.dll", CharSet = CharSet.Auto)]

        private static extern bool GetMonitorInfo(IntPtr hMonitor, ref MonitorInfoEx lpmi);



        private static ObservableCollection<DisplayInfo> _displays = new ObservableCollection<DisplayInfo>();

        public static ObservableCollection<DisplayInfo> Displays

        {

            get { return _displays; }

        }





        public static void LoadDisplays()

        {

            EnumDisplayMonitors(IntPtr.Zero, IntPtr.Zero, MonitorEnumProc, 0);

        }



        [AllowReversePInvokeCalls]

        internal static bool MonitorEnumProc(IntPtr hMonitor, IntPtr hdcMonitor, ref Win32Rect lprcMonitor, uint dwData)

        {

            var monitor = new MonitorInfoEx();

            monitor.Init();



            bool success = GetMonitorInfo(hMonitor, ref monitor);



            if (success)

            {

                var display = new DisplayInfo();



                display.MonitorName = monitor.DeviceName;



                display.Width = monitor.Monitor.Right - monitor.Monitor.Left;

                display.Height = monitor.Monitor.Bottom - monitor.Monitor.Top;



                display.MonitorArea = monitor.Monitor;

                display.WorkArea = monitor.WorkArea;

                display.IsPrimary = (monitor.Flags > 0);



                _displays.Add(display);

            }



            return true;

        }

    }

}

This code calls EnumDisplayMonitors to enumerate the monitors on the system. For each monitor found, I then call GetMonitorInfo to pull back the details. From that call, I create a DisplayInfo class and populate it, ready to be used by the rest of the Silverlight application. The list of DisplayInfo classes is stored in a class-scope collection.

Note the "AllowReversePInvokeCalls" attribute on MonitorEnumProc. That attribute is required for any callbacks. It also means we couldn't use a simple anonymous delegate for the callback, as those can't have attributes.

Finally, a short call in MainPage.xaml and we're able to get the display sizes

public MainPage()

{

    InitializeComponent();



    DisplayManager.LoadDisplays();



    DisplayList.ItemsSource = DisplayManager.Displays;

}

Run the application. On my screen, it looks like this:

Ok, so now we know how to position a display using hard-coded values, and how to get the display list from windows. Now, to combine the two to help with sizing and positioning.

Positioning and Sizing the Window

Positioning the window can be tricky. There are any number of ways that monitors can be configured. Here are just a few interesting (and common) ones, in addition to the ones mentioned above:

If you look at the teal and the green examples, you can see where a rectangular pixel mapping puts some logical pixels out into never-never land. On systems like that, a single window spanning all displays is not particularly practical. In any case, most multi-display configurations are two, or at most, three displays because that's all you can typically drive from a single typical video card.

As an aside, I've run with all four examples shown above, plus a few extras. My current layout is 2x 30" displays side by side with primary on right and secondary on left, plus a 23" display on top of the primary. The 23" display is connected to a different computer, however, and shared using Input Director, so it doesn't factor into this discussion.

With just the two displays I have, it's easy to test a number of different scenarios simply by changing resolution and monitor position in display settings. First, some code to position the window on a specific screen.

Position Window on Primary Display

A PC can have only one primary display. Conveniently, the display is called out as such via the API.

private void PositionWindowOnSingleScreen(DisplayInfo screen, Window window, bool SizeToScreen = true, bool maximize = false)

{

    window.Left = screen.MonitorArea.Left;

    window.Top = screen.MonitorArea.Top;



    if (SizeToScreen)

    {

        window.Width = screen.Width;

        window.Height = screen.Height;

    }



    if (maximize)

        window.WindowState = WindowState.Maximized;

}





private void OpenPrimary_Click(object sender, RoutedEventArgs e)

{

    if (DisplayManager.Displays.Count > 0)

    {

        // find primary display

        DisplayInfo info = (from DisplayInfo di in DisplayManager.Displays

                            where di.IsPrimary

                            select di).FirstOrDefault();



        if (info != null)

        {

            Window w = new Window();



            PositionWindowOnSingleScreen(info, w, true, false);



            w.Show();

        }

        else

        {

            MessageBox.Show("No primary display. I suppose you won't see this message.");

        }

    }

    else

    {

        MessageBox.Show("Display list not yet loaded.");

    }



}

This example uses a little LINQ to find the primary screen and then a separate function to position the window on that screen. I can't think of a case where you'd have no primary display, but I check for it anyway.

Position Window on Secondary Display

Primary is cool. You can do that without any API calls. Secondary is normally a little more work, but I have you covered.

You can, of course, have more than one secondary display. In my case, I have only one, so I'm going to position this window in the first secondary display I have.

private void OpenSecondary_Click(object sender, RoutedEventArgs e)

{

    if (DisplayManager.Displays.Count > 0)

    {

        // find first secondary display

        DisplayInfo info = (from DisplayInfo di in DisplayManager.Displays

                            where !di.IsPrimary

                            select di).FirstOrDefault();



        if (info != null)

        {

            Window w = new Window();



            PositionWindowOnSingleScreen(info, w, true, false);



            w.Show();

        }

        else

        {

            MessageBox.Show("No secondary display available.");

        }

    }

    else

    {

        MessageBox.Show("Display list not yet loaded.");

    }

}

In this case, all I needed to change was the error message and add a little bang in the where clause of the LINQ query.

Make a window take up all Display Space

This goes specifically to the 3x3 screen scenario. As I mentioned, we'll need to assume rectangular window space here, as anything else is going to be pretty application-specific.

private void OpenWindow_Click(object sender, RoutedEventArgs e)

{

    if (DisplayManager.Displays.Count > 0)

    {

        Window w = new Window();



        w.Left = (from DisplayInfo di in DisplayManager.Displays

                  select di.MonitorArea.Left).Min();



        w.Top = (from DisplayInfo di in DisplayManager.Displays

                 select di.MonitorArea.Top).Min();



        w.Width = (from DisplayInfo di in DisplayManager.Displays

                   select di.Width).Sum();



        w.Height = (from DisplayInfo di in DisplayManager.Displays

                    select di.Height).Sum();



        w.Show();

    }

    else

    {

        MessageBox.Show("Display list not yet loaded.");

    }

}

Because we're assuming a reasonably logical rectangle, I can simply take the minimum left and top values and use that to position the window, and then sum the height and width values in order to size the window.

As an aside, Silverlight had no issues opening this window on my machine. I'm not sure I'd recommend stretching a video across it, though.

Well, actually, I can't let that lie out there like that. Let's try it. Add this code right after the w.Height setting and before the w.Show() line

MediaElement video = new MediaElement();

video.Width = w.Width;

video.Height = w.Height;

video.Source = new Uri("/pub/sl5iA/NetduinoRobot_SmallM.wmv", UriKind.Absolute);

video.Stretch = Stretch.UniformToFill;

video.AutoPlay = true;



w.Content = video;

I stretch the video so it takes up all space (UniformToFill) and clips the video so the aspect ratio stays correct. It works, and works well, If the the video was high enough resolution, it would even look good.

Sweet! Big video. That's almost like IMax or UHDTV :)

Position Main Window on a Named Display

This is particularly useful if you're restoring windows when starting up a new session. You could store the display device name and then do some checks on startup and if the device name and resolution are still valid (they could have swapped displays, bought new ones, got rid of one, etc.) position the window on that display. If not, position it on the main display.

In this case, I'm simply going to position the main Silverlight window on to the display you click on in the ListBox. The code is simple enough. First, add a button to the MainPage, under the other buttons.

<Button Content="Move to Selected"

        Height="23"

        HorizontalAlignment="Left"

        Margin="12,115,0,0"

        Name="MoveToSelectedButton"

        VerticalAlignment="Top"

        Width="108"

        Click="MoveToSelectedButton_Click" />

Next, the event handler and work function in the code-behind. There are many ways I could have done this (especially using SelectedItem), but I specifically want to show using the device name. I know it's extra work, but I'm doing it on-purpose; the value you store upon exiting is not going to be an object instance, it's going to be a screen device name string.

private void MoveMainWindowToSelectedDisplay()

{

    // see comments in blog post as to why I went with strings

    string deviceName = ((DisplayInfo)DisplayList.SelectedItem).MonitorName;



    DisplayInfo display = (from DisplayInfo di in DisplayManager.Displays

                            where di.MonitorName.ToLower() == deviceName.ToLower()

                            select di).FirstOrDefault();



    var mainWindow = Application.Current.MainWindow;



    // center on the display



    mainWindow.Left = display.MonitorArea.Left + (display.Width - mainWindow.Width) / 2;

    mainWindow.Top = display.MonitorArea.Top + (display.Height - mainWindow.Height) / 2;



}



private void MoveToSelectedButton_Click(object sender, RoutedEventArgs e)

{

    if (DisplayList.SelectedItem != null)

    {

        MoveMainWindowToSelectedDisplay();

    }

    else

    {

        MessageBox.Show("Please select a screen from the list");

    }

}

The code moves the window to the selected monitor and then centers in that monitor. Some additional checking to make sure the window isn't wider than that monitor would be a good idea.

Summary

The intent of this post was to give you the foundation you'll need in order to do window manipulation in Silverlight. Once you start doing multi-monitor window manipulation, you probably have a good idea of what you want to do with it. I'll leave it up to you to take this code and run with it to suit your specific application needs.

The Commodore 64 Emulator: Emulating Pointers in a sandbox when the real thing is not allowed

Pete Brown — Tue, 07 Feb 2012 00:02:46 GMT

Late last week, I cracked open the Commodore 64 emulator code once again, in preparation to post it. However, I had to have a change made to the source control on CodePlex, so I had a few days to make some changes. So far, it's shaping up quite nicely:

I went back to the latest version of the Frodo C64 emulator source code and decided to port some of their changes over to this version. Frodo is written in C and C++, and makes very heavy use of pointers (and not always safe use of them, as there was at least one logical overrun). In the previous version, I had replaced pointers with array manipulation, but I did it in a way that resulted in an awful lot of array copies floating around. The arrays were small, so this wasn't a big deal memory-wise, but the copies all took time in an otherwise time-critical application.

Silverlight doesn't support pointers or unsafe code. Of course, in elevated trust mode, with a not-really-supported hack, you can have pointers in Silverlight. However, I wanted to stay away from that for now as it only works in Silverlight 5, only on Windows, and won't port to any other sandboxed XAML platforms.

So, I decided to finish what I started and build out some decent almost-pointerish safe analogs in Silverlight. It was a fairly large amount of effort, but I thought it might also be interesting to read about here.

How Pointers Work

If you've never written any C/C++ code, there's a better than zero chance that you haven't done any explicit pointer manipulation in your own code. That's not a bad thing, really, as the typical business application (and many other types) simply doesn't need to do pointer arithmetic. It's not worth the inherent danger for the small performance increase. That said, an understanding of how pointers work is fundamental computer science, and is important for all developers to know.

It's only when you have to do a lot of memory walking in a performance-critical application that you run into this. Programming for microcontrollers like the AVR is a great way to refresh your memory as to how pointers work and what they bring to the table.

A pointer is an address in memory and an associated type size. For example, if we have some fictional 6 byte memory chunk and declare a pointer to a byte, we end up with something like this (bonus points if you can figure out the significance of the 5 bytes starting at 0x01):

In this case, our byte pointer points to the 8 bits starting at the address 0x01. You can then manipulate memory using pointer arithmetic:

byte* p = 0x01;    // declare pointer to memory address 0x01



*p = 0x30;         // changes value at 0x01 to 0x30 from 0x78



*(p+3) = 0x00;     // changes value at 0x04 to 0x00 from 0x7A



while (p < 0x06)   // clear rest of memory

  *p++ = 0x00;

This is very fast because there really is no indirection. You're telling the compiler exactly what address to manipulate - it doesn't have to look anything up.

The size of the pointer variable has to do with the architecture of the system and its addressing scheme (8 bit, 16 bit, 32 bit, 64 bit), as well as compiler options you select. (In the case of the Commodore 64, it's all 8 bit.).

You're not limited to the smallest memory unit size, though. If you wanted to declare a pointer to a 16 bit integer, you'd get this (assuming "short" is 16 bits on your system):

Now, depending on the endian-ness of your system, the resulting 16 bit number may be 0x7879 (big endian) or 0x7978 (little endian).

It starts to get really powerful when you consider that a pointer to a structure could also be considered a pointer to a number of bytes. That allows you to, for example, read a bunch of bytes from a disk, look at the first couple bytes to figure out what you have, and then cast the remaining X bytes as the pointer a directory structure or something. The original C++ C64 emulator code does a ton of that.

How pointers are used in Frodo

In addition to pointers to structures in byte buffers, frodo does a lot of string parsing using pointers. In particular, the 1541 drive emulation code uses this for command parsing. In that code, the first character is often some command identifier, the next is a delimiter (like a colon) and then some number of comma-separated values.

In our normal pointer-less code, we'd typically parse the string and then make copies for each of the individual components. Another way to deal with it is to simply provide pointers to each of the sections therefore avoiding making copies of memory. That's typically how the Frodo code works.

In my first version of the code, I used array indexes to simulate this. However, that code got incredibly nasty to work with. I needed another solution.

The Simulated Pointer

You can simulate pointers by simply passing around arrays, making copies, or even using array indexes. But, as I mentioned, that code tends to get pretty messy as you have lots of dependent variables. Instead, I needed a way to encapsulate all of this and provide pointer-like functionality to handle the majority of the cases.

The primary goal of this effort is to make it easy to have code which is close to 1:1 with its C++ counterparts. For example, if the C++ code increments a pointer and then assigns a value, I want to be able to do something similar without having to worry about which array the pointer points to, or what index value is. The code won't be 1:1, but I want it as close as possible.
Another goal of this effort is to minimize the number of times I copy arrays around. Primarily this is for performance reasons as the emulator code needs to loop at least one million times a second (1MHz). Minimizing array copies and object instances helps keep GC under control as well.
A non-goal of this effort is efficient use of actual memory. In fact, my pointer structures use more memory than a pointer just to simulate a pointer. I'm ok with that.
Another non-goal is the ability to cast a pointer to a structure or other complex type. I'd love to do that, but that's not sandbox-friendly and it's not going to happen that way in this code.

The C64 code has a number of places where it has memory allocated in chunks. The most obvious is the main memory of the system (64K), but there's also 2K in the VIC-1541 drive. Beyond those, there are several chunks of ROM code which get loaded up and then mapped into various address locations (cartridges too). In the emulator code, these are just large arrays of bytes.

If you ever had to simulate an operating system in college, you've done this before.

Here's an example of two pointers "A" and "B". Pointer A points to address 0x01 in the memory array. Pointer B points to address 0x05.

The code to create these looks something like this:

SystemRam ram = new SystemRam();



var a = new RamBytePointer(ram, 0x00);

var b = new RamBytePointer(ram, 0x05);

The RamBytePointer structure represents the pointer. It has a member Value which can be used to get/set the value at that position. It also has a number of other helper methods to do things like copy values from arrays, comparisons with other pointers, etc. Note that the pointer structure takes a reference to the memory it is allowed to manipulate. A real pointer has pretty much free run of memory, so you need to keep the RAM pretty broadly defined if you need that flexibility.

Here's the current version of the structure. It doesn't do quite everything I want yet (for example, nothing with comparisons between pointers, for example), but it does a fair bit.

using System.Diagnostics;

using System.Text;

using System;



namespace PeteBrown.C64.Core.Memory

{

    public struct RamBytePointer

    {

        public RamBytePointer(RamBase memory, int address)

            : this(memory)

        {

            _address = address;

        }



        public RamBytePointer(RamBase memory)

        {

            _memory = memory;

            _address = 0;

        }





        private RamBase _memory;

        private RamBase Memory

        {

            [DebuggerStepThrough]

            get { return _memory; }

            [DebuggerStepThrough]

            set { _memory = value; }

        }



        private int _address;

        public int Address

        {

            [DebuggerStepThrough]

            get { return _address; }

            [DebuggerStepThrough]

            set { _address = value; }

        }



        public byte this[int offset]

        {

            [DebuggerStepThrough]

            get { return _memory[_address + offset]; }

            [DebuggerStepThrough]

            set { _memory[_address + offset] = value; }

        }



        public byte Value

        {

            [DebuggerStepThrough]

            get { return _memory[_address]; }

            [DebuggerStepThrough]

            set { _memory[_address] = value; }

        }



        public byte[] GetValues(int length)

        {

            return _memory.Read(_address, length);

        }



        public void SetValues(byte[] values)

        {

            _memory.Write(_address, values);

        }





        public void CopyFrom(byte[] values, bool incrementPointer)

        {

            for (int i = 0; i < values.Length; i++)

            {

                _memory[_address + i] = values[i];

            }



            if (incrementPointer)

                _address += values.Length;

        }



        public void CopyFrom(char[] characters, bool incrementPointer)

        {

            for (int i = 0; i < characters.Length; i++)

            {

                _memory[_address + i] = (byte)characters[i];

            }



            if (incrementPointer)

                _address += characters.Length;

        }



        public void CopyFrom(string characters, bool incrementPointer)

        {

            for (int i = 0; i < characters.Length; i++)

            {

                _memory[_address + i] = (byte)characters[i];

            }



            if (incrementPointer)

                _address += characters.Length;

        }



        public RamBytePointer NewPointerAtOffset(int offset)

        {

            return new RamBytePointer(_memory, _address + offset);

        }





        public static RamBytePointer operator +(RamBytePointer p, int offset)

        {

            return new RamBytePointer(p.Memory, p.Address + offset);

        }





        public static RamBytePointer operator -(RamBytePointer p, int offset)

        {

            return new RamBytePointer(p.Memory, p.Address - offset);

        }





        public static RamBytePointer operator ++(RamBytePointer p)

        {

            p.Address += 1;



            return p;

        }



        public static RamBytePointer operator --(RamBytePointer p)

        {

            p.Address -= 1;



            return p;

        }





        public int IndexOf(byte value, int count)

        {

            return _memory.IndexOf(value, 0, count);

        }



        public int IndexOf(char value, int count)

        {

            return _memory.IndexOf(value, 0, count);

        }



        public bool Contains(char value, int count)

        {

            return _memory.Contains(value, 0, count);

        }



        public bool Contains(byte value, int count)

        {

            return _memory.Contains(value, 0, count);

        }





        public string ToString(int startIndex, int length)

        {

            StringBuilder builder = new StringBuilder();



            for (int i = startIndex; i < length; i++)

            {

                builder.Append((char)_memory[i]);

            }



            return builder.ToString();

        }



    }

}

The memory array itself is always created and maintained outside of this class. It must be valid when the pointer is created.

Operator overloading and Offsets

Of interest is the operator overloading. This allows me to do things like p++ or p += 1 in order to modify the address that the pointer is pointing to. That's an important part of keeping the C# code as similar as possible to the C++ code. However, it doesn't allow everything the C++ code allows. For example, I can't do the exact equivalent of this code:

*(p + 5) = 0x05;

*(p - 7) = 0x0A;

If I try to do the equivalent of that, the compiler will barf at me as it needs an actual LValue on the left side. Instead, code like that must use something like this:

p[5] = 0x05;

p[-7] = 0x0A;

The code is similar enough that I'm happy with it, although developers new to the code may raise a few eyebrows at the p[-7] version.

Converting Strings

Because much of the C++ code treats characters and bytes as interchangeable (something you can't really do with arrays in C# on Windows), I also have a few overloads that can take characters or bytes. This helps clean up the consuming code so it doesn't have so many casts.

I have helper functions in there to copy from strings. This helps me easily translate code such as this:

*p++ = 'B';

*p++ = 'L';

*p++ = 'O';

*p++ = 'C';

*p++ = 'K';

*p++ = 'S';

*p++ = ' ';

*p++ = 'F';

*p++ = 'R';

*p++ = 'E';

*p++ = 'E';

*p++ = '.';

Into a nice single-liner like p.CopyFrom("BLOCKS FREE.", true);

A Structure, not a Class

Note that this is a structure, not a class. Why? Having it as a structure lets me make copies easily. It's common practice in C/C++ code to have a pointer passed into a function, and then make a copy of it to increment yourself. For example:

void DoSomething (byte * baseAddress)

{

    byte * p = baseAddress;



    while (p++ != 0x0A)

        ...

}

In this example C++ function, p starts off at the same address as "baseAddress", but then increments it. The value for baseAddress must be left alone.

Reference types like class in C# are themselves pointers. So, due to the level of indirection this has, we'd end up modifying the original value:

class RamBytePointer { ... }



void DoSomething (RamBytePointer baseAddress)

{

    RamBytePointer p = baseAddress;



    p += 5;



    Debug.WriteLine(p.Address);

    Debug.WriteLine(baseAddress.Address);

}



// ---------------------------------------



struct RamBytePointer { ... }



void DoSomething (RamBytePointer baseAddress)

{

    RamBytePointer p = baseAddress;



    p += 5;



    Debug.WriteLine(p.Address);

    Debug.WriteLine(baseAddress.Address);

}

The first example doesn't work like pointers in C++ at all. Incrementing p also increments baseAddress. The second example, however, works as we would expect because p is a copy of baseAddress, not a reference to it.

The downside of using a struct is there's no inheritance. So, I instead put a fair bit of the potentially reusable code into the memory classes instead, and simply call that from the pointer class.

Summary

Simulating pointers in pointer-free sandboxed platforms is a bit unorthodox, but can make translating code easier.

This isn't something you're likely to need to do in your own code, but it an interesting exercise in any case. There's no downloadable source code yet, as I'm still refining this implementation. You'll be able to get a version of these classes in the SilverlightC64 code when I post it in the next week or less. It's taking longer to swap out all this code than I had intended :)

If you've ever had to do anything like this in your own code, I'd love to hear about it.

Event Handler Memory Leaks, Unwiring Events, and the WeakEventManager in WPF 4.5

Pete Brown — Wed, 01 Feb 2012 04:27:14 GMT

Many developers don't realize that a common source of memory leaks in .NET applications is the event handler. WPF 4.5 includes built-in support for weak events to help us do the right thing and not eat up all the available memory.

The Problem

Events are ubiquitous in .NET. When you add an event handler using the EventName += <my event handler delegate> syntax, the event source acquires a reference to the listener. This situation is a circular reference, as the listener had a reference to the source to begin with.

These references are "strong references". That is, they are actual pointers to resources.

In the .NET framework, circular references aren't usually a problem. If the set of objects can't be traced back to the root object in the application, they are garbage collected. That's great, but in this case, due to the references from the event source to the event listener, as long as the event source is reachable, the listener will also stay around, as the event source can be traced back to a valid object root.

This can be a real problem if the event source is long-lived, as is the case with things like application configuration objects, or other static or singleton objects. Event handlers are often on the UI side of things, so the listener can be a resource and memory heavy Window object.

Take this scenario: Over the course of an application's lifetime, the user opens and closes document windows. The document windows each have a reference to some other object: it could be the parent window, it could be a static configuration class, it could be a shared singleton data provider somewhere up the chain. The important thing is that the windows are listening to an event from that object: CollectionChanged, some custom DataLoaded or other event.

Now, when the parent window (and your code) releases all reference to the window instance, the event source still has a reference to them. And, because the event source also has a reference from the application (implicit if it's static - man that lifetime gets ugly), the windows stay around:

No GC or disposal for those window instances. Windows tend to have a lot of resources tied up just to paint (control templates, controles themselves, data even) so they're not cheap resources. It gets even nastier, though. If those instances have references to, say, individual ViewModel instances, and those ViewModels have references to a cache of data, you can end up with pretty enormous memory leaks. Open up enough windows and, eventually, your app will run out of resources.

Basis for Comparison

Before we look at the problem, here's a profile of the application opening 200 windows, closing the 200 windows, and then forcing a GC. I did this three and then closed the app. Each window allocates a bunch of memory in an array just to give it a payload. The window code looks like this:

public partial class TestChildWindow : Window

{

    long[] _memoryHog;



    public TestChildWindow()

    {

        InitializeComponent();



        Random rnd = new Random();



        string imageName = "Assets/image" + rnd.Next(1, 9) + ".jpg";

        NeatoImage.Source = new BitmapImage(new Uri(imageName, UriKind.Relative));



        _memoryHog = new long[1024];



        Unloaded += new RoutedEventHandler(TestChildWindow_Unloaded);

    }



    void TestChildWindow_Unloaded(object sender, RoutedEventArgs e)

    {

    }

}

In the upcoming examples, the TestChildWindow will have a reference to the SettingsManager. This is a stub class meant to represent pretty much any long-lived instance in your application.

namespace WpfWeakEventManager

{

    class SettingsManager

    {

        public event EventHandler SettingsChanged;



        private static SettingsManager _current;

        public static SettingsManager Current

        {

            get

            {

                if (_current == null)

                    _current = new SettingsManager();



                return _current;

            }

        }

    }

}

Finally, the Main Window has three buttons that I used to test the application. The first opens 200 windows. The second closes all windows (except the main one) being tracked by the application. The third forces a GC collection. It also has a listbox to show diagnostic information when I'm not running with an attached debugger.

namespace WpfWeakEventManager

{

    /// <summary>

    /// Interaction logic for MainWindow.xaml

    /// </summary>

    public partial class MainWindow : Window

    {

        private SettingsManager _current;



        public MainWindow()

        {

            InitializeComponent();



            // make sure SettingsManager is referenced outside

            // just the child windows. Normally this would happen

            // just do to general use of the class. Forcing it here.



            _current = SettingsManager.Current;

        }



        private void OpenWindowsButton_Click(object sender, RoutedEventArgs e)

        {

            int openedCount = 0;

            DebugList.Items.Add("Total Memory Before Opening Windows: " + GC.GetTotalMemory(true));



            for (int i = 0; i < 200; i++)

            {

                var window = new TestChildWindow();

                window.Show();

                openedCount++;

            }



            DebugList.Items.Add("Opened " + openedCount + " windows.");

            DebugList.Items.Add("Total Memory After Opening Windows: " + GC.GetTotalMemory(true));

        }



        private void CloseWindowsButton_Click(object sender, RoutedEventArgs e)

        {

            int closedCount = 0;

            foreach (Window window in Application.Current.Windows)

            {

                if (window != this)

                {

                    window.Close();

                    closedCount++;

                }

            }



            DebugList.Items.Add("Closed " + closedCount + " windows.");

            DebugList.Items.Add("App has " + Application.Current.Windows.Count + " window(s) it's holding on to.");

        }



        private void CollectButton_Click(object sender, RoutedEventArgs e)

        {

            GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced);

            //GC.Collect();

        }

    }

}

I experimented with a few variations on GC.Collect and some of the other notifications before the code that is here. A plain old GC.Collection will likely work just as well in any case.

Here's what the window looks like after I opened 200 windows and then closed them and then opened another 200. 200 windows is actually a lot of windows, as it turns out, but if you consider an application where your user opens up 1 customer record every 5 minutes (for a phone support person, this is conservative), over the course of an 8 hour day, that could be as many as 160 forms, and that's assuming they close the application every day when they leave.

Now I needed to find a good way to track memory usage. The profiler in Visual Studio is really good for finding performance bottlenecks, but not really meant for the real-time memory usage graphing I wanted to do. So, I downloaded the 10 day trial of .NET Memory Profiler (an app I used a lot back when I was consulting) and had it capture data while I performed the above actions.

In this graph, the pink line is the active memory in use in bytes, the green line is the number of root references. (note: none of the memory graphs include memory from on-window images. I ran without the cute images, but I left the code in the form and the images in the screenshot just because)

Remember, this is without any of the circular reference problems discussed so far. Now, let's take a look at the same actions when I have an event handler wired up in the constructor of the window.

Notice something about that graph? Yep. Memory just isn't being returned. It's leaking, and the root references keep on climbing. The only difference between this profiled version and the previous was that I added the SettingsManager event handler wireup in the constructor:

public partial class TestChildWindow : Window

{

    long[] _memoryHog;



    public TestChildWindow()

    {

        InitializeComponent();



        Random rnd = new Random();



        string imageName = "Assets/image" + rnd.Next(1, 9) + ".jpg";

        NeatoImage.Source = new BitmapImage(new Uri(imageName, UriKind.Relative));



        _memoryHog = new long[1024];



        SettingsManager.Current.SettingsChanged += Current_SettingsChanged;



        Unloaded += new RoutedEventHandler(TestChildWindow_Unloaded);

    }



    void Current_SettingsChanged(object sender, EventArgs e)

    {

        // do something

    }



    void TestChildWindow_Unloaded(object sender, RoutedEventArgs e)

    {

    }

}

The Unloaded handler is empty, but it is wired up. The key change here is the SettingsManager.Current.SettingsChanged wire-up.

There are a multitude of considerations in this example, but let's deal with just the topic of this post: the event handlers.

Solution 1: Unwire Your Event Handlers

This generally doesn't work if you use anonymous delegates (one reason to be careful about using them with objects that live outside the scope of a single method), but in cases where you have a real event handler method, unhooking them when you're done with them is definitely a best practice.

You can remove event handlers in Dispose methods, or in the case of a window, in the Unload event handler. That's what I did here. The code is a simple change:

void TestChildWindow_Unloaded(object sender, RoutedEventArgs e)

{

    SettingsManager.Current.SettingsChanged -= Current_SettingsChanged;

}

All I did was remove the event handler inside the Unloaded handler. Take a look at the impact it had on memory:

That's much better. The root references and memory both drop when I hit the "collect" button. Compare this to the previous example where the memory never went down. As to the differences between this graph and the first one, chalk it up to sample timing and my own non-deterministic button pushing.

So, that's a great approach. In fact, if you can do this, you should do this. It's simple and highly effective.

For other situations, perhaps where you don't control all the code, or when unwiring events is difficult or inconvenient, there's the Weak Event Pattern.

Solution 2: Weak Events

It's not always possible or practical to unwire event handlers. Actually, let me rephrase that: sometimes the level of effort and thought that needs to go into *where* you put event handler unwiring is more than developers have time to put into the app. :)

Enter the Weak Event Pattern

The concept of a Weak Event is nothing new. Many others have created their own various weak event solutions for use with WPF. Previous versions of .NET and WPF included the WeakEventManager, but required you to derive your own class and implement IWeakEventListener interfaces. That was a fair bit of work for developers who just need to get stuff done. The real news here is that WPF 4.5 includes the generic WeakEventManager type to make it easier for you to implement the weak event pattern in your own code, without all the other ceremony. You can still derive from WeakEventManager (if you can do the work, it's actually a good practice due to the performance benefits you'll get from it via having actual events and not reflection look-ups), but the new generic class makes it easy enough so that there's no excuse *not* to do it.

Here's the memory usage of the application using Weak Events

And here's the code change. I removed the code to unwire the event, and did the event wireup using WeakEventManager rather than regular old events.

namespace WpfWeakEventManager

{

    /// <summary>

    /// Interaction logic for TestChildWindow.xaml

    /// </summary>

    public partial class TestChildWindow : Window

    {

        long[] _memoryHog;



        public TestChildWindow()

        {

            InitializeComponent();



            Random rnd = new Random();



            string imageName = "Assets/image" + rnd.Next(1, 9) + ".jpg";

            NeatoImage.Source = new BitmapImage(new Uri(imageName, UriKind.Relative));



            _memoryHog = new long[1024];



            // this version wires up an event handler which causes a hard reference

            // and, unless it is unwired, a memory leak

//            SettingsManager.Current.SettingsChanged += Current_SettingsChanged;



            // unwire the event handler. This is a good practice for avoiding leaks

//            Unloaded += new RoutedEventHandler(TestChildWindow_Unloaded);



            // this version avoids memory leaks without requiring you to

            // unwire the event.

            WeakEventManager<SettingsManager, EventArgs>

                .AddHandler(SettingsManager.Current,

                            "SettingsChanged",

                            Current_SettingsChanged);

        }



        void Current_SettingsChanged(object sender, EventArgs e)

        {

            // do something

        }



        void TestChildWindow_Unloaded(object sender, RoutedEventArgs e)

        {

//            SettingsManager.Current.SettingsChanged -= Current_SettingsChanged;

        }

    }

}

This new WeakEventManager is much easier to use than anything we had before. You take a hit for relying on reflection to resolve the event name, but in all but the most performance-sensitive cases (where you probably wouldn't bother with events anyway), it's going to be worth it.

Summary

Event handlers and long-lived objects can be the source of memory leaks in any .NET application. Whenever you can, you should unwire your event handlers to help avoid these leaks. When that is impractical, the Weak Event Pattern using the WPF 4.5 WeakEventManager<TObject, TArgs> is a great way to help save you from the grief of memory leaks without requiring all the ceremony we had with the regular WeakEventManager and IWeakEventListener in the previous versions.

Now there's no excuse to have leaky event handlers.

The .NET Gadgeteer Diaper Alarm Part 1 (Moisture Sensor)

Pete Brown — Mon, 30 Jan 2012 22:22:37 GMT

During the .NET Microframework and .NET Gadgeteer code camp talk that Andrew Duthie and I gave several weeks back, we tossed around the idea of using the Gadgeteer and a moisture sensor to alert parents of, ahhhh, soggy diaper issues.

Shortly before the holidays, in the mail, I got a package of goodies from Microsoft Research. That package included one of these moisture sensors from Seeed Studio. These are meant for checking to see how wet soil is, but I figure one man's diaper is another man's soil, so, I can't resist. Must…prototype…solution.

WARNING: Science in Progress. Also: diaper jokes.

First Iteration

I didn't have any of that handy inoffensive blue liquid available (the stuff they use to represent *any* bodily fluid on commercials; pretty sure that's how Smurfs are grown), so lacking any actual babies (my kids are all potty trained now. Yay!) I'm using plain old water. The real thing is a bit more conductive, so you may need to vary some values I use. Also, I'm dealing with liquids only in this post. You're on your own with anything more…substantial, but I might recommend some sort of scale, or for the newborns, perhaps a blast detector held on with this.

Hardware

I'm using the Moisture Module from Seeed Studio. (You can also purchase it through GHI as they have a partnership.) This module returns back an analog voltage that is proportional to how wet the area is. As mentioned, it's is really meant to be used in soil, to tell you if you need to water your plants, so we'll have to finagle a few things to make it work here.

It's wired to socket 9 on my Gadgeteer board. That's one of the two analog sockets on the GHI Electronics Spider. I had one of the extra long ribbon cables which was perfect for this. You don't want the rest of your modules anywhere near what we're doing here. Also, this probably works best with babies who are relatively sedentary, preferably sleeping. Otherwise, you'll end up with a miniature Borg running around the house trailing some sort of dangling box of electronic goodies.

Warning: I'm reasonably certain that none of this is actually baby-proof.

Yee Old Test Subject

Next, I need something to test in. No, don't go there as my wife would not appreciate getting that kind of laundry from me, not even in the name of science. I'm pretty sure I could get my almost-6 year old son to cooperate if I offered LEGO or something as a reward, but that'd also get me on the naughty list. Lacking other creative solutions, I'm just going to use a small plate and a paper towel to see how this all works.

I'll wet the towel, and wait until the moisture starts to hit the sensor. Then I can adjust for sensitivity. The idea is not to make the sensor swim, but to get an idea of how we the towel needs to be for this to work. Remember, the sensor is designed to be stuck in soil, not placed down on a towel.

Software

Be sure to download the latest Gadgeteer SDK and driver package. The latest rev (as of this month) includes support for all the GHI and Seeed modules on the market, including this one. Once you'd done that, it's time to create a new project. Open up Visual Studio and create a new .NET Gadgeteer Project. I named mine DiaperMonitor.

Next, add the main board, if it's not already there. By default, mine came up with the FEZ Hydra, presumably because that's the last one I used. I simply removed that and dragged on a FEZ Spider from the list of main boards in the toolbox.

Next, I added a Seeed.MoistureSensor module. You can either connect it automatically, or pick the port yourself and drag the connection to create the link. I have the moisture sensor on socket 9 as shown here. I also added one of the brand new GHI LED7R modules just to give us something interesting to light up.

If you don't have one of the new LED7R, you can use any LED module and simply change the code we'll use for the light up.

Le Code

The first iteration of code is simply going to check the moisture level, and light up the LED7R when the moisture level makes it over a certain threshold. On the Gadgeteer, you don't want to have a tight loop running from the ProgramStarted method - doing so would prevent other event handlers from running.

The code for the sensor is really simple. If you look at the sensor itself, it appears to simply send a voltage down one side of the tongs and checks for conductivity with the other side. The driver uses a digital output for sending and an analog input for receiving. I was actually surprised to find a through-hole NPN transistor (it's a TO-932 package 2N2222 amplifier marked 2N2222 H331) in there, as almost everything else gadgeteer-related uses surface mount components (including the two resistors on the board), but I know the 2N2222 itself is difficult (impossible?) to find in an SMT package.

I'm far from an electronics expert, but my guess is that one side of the fork sends the regular (apx) 3.3v signal from pin 3 into the dirt/diaper. The other side will get a very faint amount of voltage transferred through the medium which it then amplifies with the transistor in order to make it meaningful to the microcontroller.

So, instead of using a polling loop, I kick off a timer to handle polling the sensor. The timer is set to poll once per second and compare the returned value to the minimum moisture level. If the level is passed, then the LED7R animates once and then stays on. After changing the diaper, you reset the Gadgeteer to restart the program. Inelegant, but simple.

using System;

using System.Threading;

using Microsoft.SPOT;

using Microsoft.SPOT.Presentation;

using Microsoft.SPOT.Presentation.Controls;

using Microsoft.SPOT.Presentation.Media;

using Microsoft.SPOT.Touch;



using Gadgeteer.Networking;

using GT = Gadgeteer;

using GTM = Gadgeteer.Modules;

using Gadgeteer.Modules.Seeed;

using Gadgeteer.Modules.GHIElectronics;



namespace DiaperMonitor

{

    public partial class Program

    {

        private GT.Timer _pollingTimer;

        private int minimumBadMoistureLevel = 200;

   

        void ProgramStarted()

        {

            Debug.Print("Program Started");



            _pollingTimer = new GT.Timer(1000);

            _pollingTimer.Tick += OnPollingTimerTick;



            _pollingTimer.Start();

        }



        void OnPollingTimerTick(GT.Timer timer)

        {

            int moisture = moistureSensor.GetMoistureReading();



            Debug.Print(moisture.ToString());



            if (moisture > minimumBadMoistureLevel)

            {

                AlertParents();



                timer.Stop();

            }

        }



        private void AlertParents()

        {

            lED7R.Animate(10, true, true, true);

        }

    }

}

This approach is nice, but doesn't do another loud or obvious. You'd have to keep looking in the room and checking for the lights. Chances are, the baby's own internal alarm would start sounding before you noticed the lights. In addition, this doesn't allow for any configuration of level, so on a hot summer night (thank's to Sammy Hagar, that song is now stuck in my head), there may be a general level of damp which doesn't quite meet the bar for a burst dam.

So we have two problems: one is configuration, the second is for meaningful alerts. Let's look at configuration first.

Second Iteration - Configuration

The next step is to configure that alert level. You can leave it as a fixed value in code, or you can configure it via any number of other external inputs. One approach would be to use a potentiometer to set a threshold. Another would be to sample the current value and say that value is the "normal" value and anything well above it would be the "wet" value.

Either approach would require some input device, like a button, to enable the timer and possibly to sample the data.

First, I need to know what the possible values are. I couldn't find any documentation, so I simply went to the Gadgeteer codeplex site and looked at the source code. As I suspected, the sensor is an extremely simple wrapper around the analog input class. It returns a value in the range of 0 to 1600, as evidenced by this code:

/// <summary>

/// Gets the current moisture reading.

/// </summary>

/// <returns>An integer value, where 0 is fully dry and 1000 (or greater) is completely wet. </returns>

public int GetMoistureReading()

{

    return (int) (analogInput.ReadProportion() * 1600.0);

}

It also has a nice comment which isn't surfaced in the compiled version I have, so I assume that's a somewhat later rev. (Actually, I just looked in the Object Browser and there it is. I wonder why intellisense wasn't showing it? Odd.) In any case, it's useful to know you can always go and inspect the source if you have any question about how something is working at the Gadgeteer module driver level.

So what can we do with that information? Well, let's look at the potentiometer approach.

Potentiometer approach

One thing most MCUs don't have is a large number of analog inputs. In order for a MCU to enable analog input, it has to have a digital to analog converter channel available. Most MCUs which have on-board ADC support either 10 bit or 12 bit analog conversion. The specs for the EMX module used by the Gadgeteer show that it has 7 10 bit analog inputs total. The FEZ Spider surfaces six of them, but only on two sockets. So, unless you have a multi-input devices that can use the 3 pins on a type A socket (or you create a breakout of some sort), you really end up being able to take input from only two analog modules. That leaves us with our diaper sensor and a potentiometer.

For this, I added a potentiometer module to the other analog socket: socket 10. The pot is going to be used to configure the minimum level at which we'll set off the diaper alarm. In addition, I added a button module that we'll use to arm the device.

The new code refactors a few things. Explanation after the listing.

using System;

using System.Threading;

using Microsoft.SPOT;

using Microsoft.SPOT.Presentation;

using Microsoft.SPOT.Presentation.Controls;

using Microsoft.SPOT.Presentation.Media;

using Microsoft.SPOT.Touch;



using Gadgeteer.Networking;

using GT = Gadgeteer;

using GTM = Gadgeteer.Modules;

using Gadgeteer.Modules.Seeed;

using Gadgeteer.Modules.GHIElectronics;



namespace DiaperMonitor

{

    public partial class Program

    {

        private GT.Timer _pollingTimer;



        private const int MoistureLevelRangeLow = 50;

        private const int MoistureLevelRangeHigh = 800;

        private int _minimumBadMoistureLevel = 200;

   

        void ProgramStarted()

        {

            Debug.Print("Program Started");



            button.ButtonPressed += button_ButtonPressed;

        }



        void button_ButtonPressed(Button sender, Button.ButtonState state)

        {

            Debug.Print("Button Pressed");



            if (_armed)

            {

                Disarm();



                // animate counter-clockwise and turn off

                lED7R.Animate(10, false, true, false);

            }

            else

            {

                Arm();

                lED7R.Animate(10, true, false, false);

            }

        }



        private void SetTriggerLevel()

        {

            // read from the pot

            double pot = potentiometer.ReadPotentiometerPercentage();



            // calculate the moisture level based on the bounds

            _minimumBadMoistureLevel = MoistureLevelRangeLow +

                (int)(pot * (MoistureLevelRangeHigh - MoistureLevelRangeLow));



            Debug.Print("Minimum trigger level: " + _minimumBadMoistureLevel);

        }



        bool _armed = false;

        private void Arm()

        {

            SetTriggerLevel();



            // start the timer

            _pollingTimer = new GT.Timer(1000);

            _pollingTimer.Tick += OnPollingTimerTick;



            _pollingTimer.Start();



            _armed = true;



            Debug.Print("Armed.");

        }



        private void Disarm()

        {

            // stop the timer

            _pollingTimer.Stop();

            _pollingTimer.Tick -= OnPollingTimerTick;



            _armed = false;



            Debug.Print("Disarmed.");

        }





        // event handler for the timer that polls the moisture sensor

        void OnPollingTimerTick(GT.Timer timer)

        {

            int moisture = moistureSensor.GetMoistureReading();



            Debug.Print(moisture.ToString());



            if (moisture > _minimumBadMoistureLevel)

            {

                AlertParents();



                Disarm();

            }

        }



        // do all the obnoxious alert stuff in here

        private void AlertParents()

        {

            Debug.Print("Diaper Alert!");



            // animate clockwise and leave on

            lED7R.Animate(10, true, true, true);

        }

    }

}

The new workflow is this:

Set the potentiometer to some minimum trigger level. There's no readout or anything at the moment, so you'd just have to eyeball it.
Once the pot is set, click the button to arm the diaper alert. The LEDs will cycle and you know it's armed.
Wet the diaper (not you, personally, I hope)
Diaper alert and then the system disarms.

When disarming the alarm, to avoid leaks, I remove the event handler. When arming, I wire it back up. In our particular example, this doesn't buy you anything, but if you were to pull this code out into another class, it almost certainly would save you from eating up all the memory on the device over time.

This new workflow is pretty good, but the diaper alert leaves something to be desired. You'd have to get in there to notice the LEDs (in a dark room they'd be ok), but there's nothing to really grab your attention. Clearly we can't have a piercing piezo siren or something, as that would wake up baby before the wet does.

What other options do we have?

Well, how about an alert that is sent to a remote device?

That's the topic of the next post :)

Summary

Ok, that was fun :)

For most of us, this is probably not how we'll use the Gadgeteer. Kids generally have pretty good built-in wet diaper alarms as it is. However, you can use this sensor for just about anything from plant moisture detection to water leak detection to more. More importantly, this post shows how to use an analog sensor of any type, including how to configure the range and some other useful NETMF tips.

The n00b filter: Bad UX at its Finest in Eagle PCB

Pete Brown — Fri, 27 Jan 2012 02:55:54 GMT

Speaking of UX…

I finally decided to download and learn to use the industry-standard PCB and schematic layout software: Eagle. I've tried a bunch of others, and quite frankly, got tired of always using "also ran" software. The majority of the info on the web is for Eagle. It certainly doesn't have the best UI or the best workflow, but it has absolutely the most amount of information and the best support from PCB manufacturers. It's the industry standard, and like most industry-leading technical software (ever use industry-leading 3d modeling software? Gak!), it has some crazy issues.

Here's the workflow. First, while working on the Schematic, you click this "Add" toolbar button

Next, you're shown a screen with the libraries on the left, and the selected part on the right. You can browse the libraries here, but it is not something I went into with the intent of using it to manage library entries.

I wanted to add the component, but I wasn't sure which button to press. Silly me, thought maybe "drop" meant to "drop it on the schematic" because, for whatever reason, "OK" didn't seem right.

Wrong.

"Drop", without so much as a confirmation MessageBox removes the library from the parts libraries on your computer. Yeah, so now I need to go find the library which contains every type of diode, because, umm, I deleted it.

At first, I thought I actually deleted it, but it turns out Eagle marks it to make it not show up in the Add dialog. I'm still going to finish this post anyway, because the brick was already passed painfully through the orifice when the library just went *poof* off the list.

To restore it, you have to go into their separate Control Panel application (hint: if your app has a "control panel" app, there's an issue). That's better than having to reinstall the product, or download the library from RapidItsNotReallyATrojanWeSwearShare.com, but it's not entirely intuitive.

This type of feature can only be called a n00b filter, although I'm sure there's a more technical UX antipattern name for it, probably one which includes a four-letter word or two.

I have a lot of experience in software. I rarely need to be hand-held, and the last time I took a class to learn how to use a piece of software was to be a Novell 4 CNA in the mid 90s, and I took that class *after* I had already set up the network. I almost never read manuals, and use "Help" in apps maybe 5 times a year total, and only because I'm trying new stuff all the time. All I'm trying to say here, is I'm not afraid of software, and I very rarely do something which destroys work or accidentally does a format c:\ or anything.

Seriously. No confirmation. It's a button on the "Add Component" screen.

No wonder users hate us.

Maker Geek Roundup 006 for 1/25/2012

Pete Brown — Wed, 25 Jan 2012 19:08:25 GMT

3d Printing and CAD/CAM/CNC

Working 3D printed helicopter blades (Ultimaker)
Slic3r is Nicer - Part 3 - How low can you go? (RichRap)
RhinoCAM 2012 to Release February 6, 2012 (Rhino News)
The 3D Printing Troubadours of Pocket Factory! (Thingiverse)
Circuit Milling With Roland iModela, Now Available on Arduino Store (Arduino Blog)

.NET Gadgeteer

Take a break: Arduino DaisyLink module for Gadgeteer (Valentin Ivanov)
Devhammer's Garage (Info on the IR LED module Andrew created) (G. Andrew Duthie)

.NET Micro Framework General (Netduino, GHI FEZ, etc.)

PIX-6T4 - The PIX-6T4 Game Console (Fabien Royer, Bertrand LeRoy)
New NETMF Book out for v4.1 and v4.2 (Colin Miller)
Text-To-Speech for .NET Micro Framework (Marco Minerva)
XML Configuration Files for .NET Micro Framework Applications (English) (Marco Minerva)
Using a light transistor sensor and a led to create a detector (Laurent Ellerbach)

Arduino

Control An LCD with a 595 Shift Register (Arduino Blog)

Other Micro Controllers (PIC, AVR, ARM and more)

EasyPIC PRO v7 is released! (MikroElektronika)
Breakout board for the 44pin QFN ATxmega microcontroller (Dangerous Prototypes)

General Electronics and Hardware Hacking

Making Momentary Buttons Breadboard Friendly (Software and Sawdust)
555 LED Pulsing Breathing Circuit (Circuit Zone)
A Curiously Low Noise Amplifier (Citizen Scientists League)
1.5V FM Broadcast Transmitter (Circuit Zone)
The phone box (Dangerous Prototypes)
LED brightness controller with 64 taps (Electronics Lab)

Robotics and Robotics Studio

Brrd Brain Board: More progress & less zigzags (RobotGrrl)

Clocks

Tutorial: Build a manifold clock for $10 (Hack a Day)

Synthesizers, MIDI and Electronic Instruments

Meng Qi's Wicki-Hayden MIDI Controller (Highly Liquid)
Trojan Chorus: Pinata as MIDI Controller (Highly Liquid)

Photography

DIY: Small Circular Softboxes (DIY Photography)
Super High Speed Footage Of A 60D Exposure Cycle (DIY Photography)
Using A Double Flash Bracket To Add Modeling light To Your Setup (DIY Photography)

General Maker

Tweet Sweet (Brando)
Software for web controlled home automation (Johan von Konow)

Retro Computing and Commodore!

Retro Game Fair, The Netherlands (MOS6502)
C64anabalt (C64) (2011) (RGCD)
Commodore Inside! (MOS6502)
Hydra Castle Labyrinth (PC) (RGCD)

Misc Geek

Open Letter to Nickelodeon, Re: SpongeBob's Pineapple under the Sea (Vi Hart)
Cyberpunk style Workstation is Pretty Sexy (This 8 bit Life)
Amazing Legend of Zelda Zora Armor Cosplay (This 8 bit Life)

Just Awesome

You'll either thank me, or burn my house down for this one. Either way, those brain cells aren't coming back. (YouTube)

Now, more than ever, you need a designer

Pete Brown — Wed, 25 Jan 2012 06:52:53 GMT

Before joining Microsoft, I was a consultant, primarily building desktop applications using a variety of MS technologies. During my last couple years there, Silverlight was a large part of that both for full apps and as parts of larger web sites. Prior to that, it was WPF, Windows Forms, VB, HTML and even SharePoint.

tl;dr: The point of this long post is not to show you examples of good design or pick apart existing designs. I'm not really qualified to do that. However, I can point out the need for design and give you some small amount of ammunition when presenting this to your own management. Visual and UX Design matters, even for internal apps, often far more than architecture or the other things we focus on. You'll be more efficient with a designer on-team, who you can iterate with. The world is evolving and we need to keep up. Go hire one now.

tl;dr the tl;dr: Hire a UX/Interaction designer.

The company I worked at wouldn't hire a UX/Visual designer. Why? Because they felt they could never sell the benefit of good UX and visual design to customers, and couldn't keep a designer busy 100% of the time. The problem was, without a portfolio of well-designed UI and sites, it became self-fulfilling. I had contended that if they hired one, they'd be amazed at just how busy that person would end up being. Quite frankly, they just didn't see the value.

It got to the point that when I walked into my management's office, they'd be like "You're not going to tell us to hire a designer again, are you?"

You may even be thinking the same thing, this post may see like Déjà vu if you've followed my blog for a few years :) I took a more conservative approach to the problem in that 2010 post. Basically saying the same types of things Scott Hanselman recently pointed out in his Skip Intro post: don't over do it, and don't use things just because they're there. In that post, I argued that if you want to just keep making the same old battleship gray applications, you don't *need* a designer. However, I still think you can benefit from one in your projects regardless. So, I'm going to backtrack a little bit and deliver a more absolute form of the message: yes, you need a designer. Whether it is HTML/JS/CSS, or XAML/C#/VB, or something else, you should have design talent on staff.

For a bit, we toyed around with the idea of partnering with an outside firm. The problem was, there was too much of a "hand off" approach to the design. Without having the design talent on-staff, you couldn't iterate during the project. The design was passed in at the beginning and then slowly destroyed by the developers (or people like me who had good UX but horrible Graphics design skills) over time.

I likened it to other disciplines, like partnering with a firm just to design the database. Sure, design it all up-front and then make the project live with that throughout the rest of the lifecycle. No one found that to be a sane idea, but still couldn't see the parallel with UX and Graphics design.

Now, in their defense, the company primarily worked on large-scale transaction processing systems. However, the business had slowly evolved to include more commercial work, and more intranet and internet sites for these same customers. Also, in their defense, our customers felt the same way. They wanted really great UX and graphics, but somehow felt those things simply fell from the sky. They didn't want to pay for designers on projects either. They were still stuck in the team makeup and ideas that worked for mainframe applications and, as in most cases, haven't moved on.

One thing the enterprise development community in general has been slower to adopt is the idea that you really do need visual and UX design talent on staff. Application success or failure rarely comes from architecture, or reuse, or whether or not you use stored procedures or which ORM you use. Those are things we do to meet other, more internal, goals, most of which users don't care about in the least, many of which offer more perceived benefit than actual real project benefit. As Scott mentioned in another post, users don't care if you use Web Sockets. Sure, if you really botch the architecture, the app may be unusable, but beyond that, your investment is better spent elsewhere.

Knowing Your Limits

Yesterday, Scott Hanselman blogged about the emerging trend to throw a dog's breakfast of features into HTML5/CSS3/JS sites. He and I chatted about it for a little, and felt I should write something up here as well. Go read his post as well.

It's natural for developers to push the boundaries when a new technology comes out. That's how we learn. That's fine for demo sites in developer echo chambers and compos, but don't do it in front of actual users. It's too easy to have your app look and perform like a Pirate's idea of wealth: all money and no style. Scott has links to a few examples of that in his post. There are a couple other good ones in the comments.

How did we get to this point? Why do so many still not even realize we're here?

Modern Development

First, a little history:

I don't wear a suit to work. In fact, I work from home, so what I wear barely counts as clothing some days. I also don't sit in front of a highly non-ergonomic greenscreen device, trying to remember arcane codes (ok, well I do when I'm messing around with microcontrollers or old computers). Why? Because the world has moved on from that. Gradually over the years, more and more UX thought has been given to applications.

When applications were just command-line affairs, the only UX you really had to worry about was how hard the transaction codes were to remember. Most of the UX was the huge three-ring binder manual or the multiple volume boxed sets with textured cloth covers. Users often spent as much time in that as interacting with the screen, especially during their first X months. Graphics were Escher prints you hung on the wall. Computers were supposed to be hard, for some unknown reason. Engineering ruled the experience, and we didn't know any better.
When they became full-screen character mode applications (Curses, anyone? No? How about the windowing libraries for DOS TurboC/C++ apps? IBM 3270? No? Pah. Youngsters.) there was more UX to worry about, but the layout and workflow choices were still so limited as to make it easier for a dev with a good eye to come up with something decent. Graphics were things scientists used for data visualization. Design was for companies making physical products customers had to hold in their hands. An entire industry was built around plastic-coated cardboard keyboard templates to help you remember all the keyboard shortcuts required to navigate important applications, especially for DOS. I blame WordPerfect.
When apps became battleship gray forms over data (white 2d forms first), UX consisted mainly of making sure you had a decent tab order and "fit as much as possible" on a single screen. Navigation often resembled those character mode applications we were upgrading/scraping/rewriting because our users didn't know any better, and we didn't know how to show them something else and prove it would be more efficient and/or easier. Things started to go south here. Graphics were for games and maybe 16x16 16 color icons. Animation was for music videos.
- Early on, apps were even just black and white instead of gray. But when the gray "3d" chiseled look started coming into vogue late in Win 3.11's lifetime (there was a special common controls library just for it), developers went nuts and had apps that looked like Mayan pyramids. Borders within borders within borders. Uuuuugly. And I did it too. It was new. It was exciting, and it was abused.
When the web started making inroads into application development, UX became further complicated. First, the workflow options for early web apps really blew. Many apps had two buttons "Submit" and "Reset" and a big form above them. Validation and all other processing mostly took place server-side. Sometimes, we got clever, and sent all the data through an iframe to avoid a full page refresh. We made excuses because that's how all the other apps were working, and we didn't take much inspiration from branded experiences. However, at least they often looked nicer than those battleship gray apps. That made a real impression on people. Hmm. Graphics. Colors. Whitespace. Animation was for dancing hamsters or Pixar.
And then the proliferation of consumer-oriented smart phones and tablets with great UX, driven in no small part by Apple, really brought UX and visual design to the front. It's not because the platform had a great API or something (I've never worked on it, but I hear the platform, from a programming and design standpoint is … interesting), but because it attracted a lot of designer types. It's no accident that companies like Apple and Microsoft chose design firms to create the first showcase prototypes of their new UI technologies. Now, even inside the enterprise, many customers expect this level of UX in their own applications. Graphics, colors, whitespace, touch, animation, easing and more all become important parts of the visual design, and it's very easy to get it wrong unless you have a talent for design.
- Your users now and in the future are ones brought up on this crop of highly visual applications. What do you think they will have for expectations?

But now we're stuck, because we have the tools to do whatever we want, but haven't evolved the teams to effectively make use if them.

We've had tools and platforms to build these types of apps for some time. Flash has been around forever, Silverlight since 2007, and finally, HTML5/CSS3 and its support in browsers is mostly catching up to where FutureSplash was in 1996. The capabilities are there, we just need to use them for good.

It's not just for consumer-oriented apps, either. As companies consolidate their development staff, expose more things outside the firewall, or work to support a large number of internal users, the line between consumer and enterprise development continues to thin.

For grins, here are some apps I wrote in the 90s and early 2000-ish, where I happened to have saved some screen shots (I really wished I had saved more, especially the dBase/FoxPro apps I wrote for DOS and the VB3-6 and PowerBuilder ones for Windows 3.11). The first one was written for DOS entirely in Borland C++ (including the database) the others were, as I recall, .NET 1.0 beta versions of VB4 apps I wrote earlier. in the first one, I mainly just had to worry about tab order. In the second, the users were most comfortable with filling out an online version of the paper form (in fact, they'd have the paper form in front of them while doing this). The third was using the typical "Make it look like Outlook" model of the time.

That version actually looked quite a bit better on a giant 15" CRT, perched high enough up to count as neck-stretching exercise. :)

Like so many other developers, I simply copied prevalent design trends of the time (how many devs have you talked to back in the day who said they were trying to make their app look like Outlook or Visual Studio/Visual Basic?). I got away with it, but you can see that it doesn't 100% work. I force fit some things due to the limited palette of visual design patterns at my disposal. Bonus points: battleship gray.

Is it Customer-Facing?

I've heard many people say that they'll only invest in UX for customer-facing stuff. But who is the customer?

It depends on how you define your customer. For many IT shops, the customer works for the same company. For sales apps, many times the field laptop/tablet application is seen by both a sales person and the customer. Many of the same things you'd do in a consumer application apply to these same customers, but because they're forced to use your app, they don't get the same attention to UX that external true consumer apps do.

Here's a list of some common types of applications being built today, or in the near future. Tell me where UX doesn't matter? Which is customer-facing?

Call center apps inside an organization
The departmental day-to-day work application at your company
Consumer touch-oriented apps on phones and tablets
Consumer apps on the desktop
Enterprise shrink-wrapped products for the desktop
Your intranet site
That forms-over-data application everyone in the company uses
Time and expense reporting systems
Your one-off shell script to update a bunch of database tables

Ok, so I through the shell script in there just to have something where you could get away without UX. Of course, there's often some design put in there too. Did you take a moment to set up different command line arguments? UX, just no pretty graphics :)

How many times have you heard "Sorry, the computer is really slow today" when you talk to someone at a call center? Typically this is because it takes forever to accomplish anything on their crappy apps. Sometimes, of course, they have a 9600bps serial connection from wherever they are to wherever the data is, but most of the time it's just a crap UI that takes forever to help you, or they've forgotten how to do a certain thing in the UI because it's so non-intuitive. I've seen these apps up close. I've seen the massive amount of training that people have to go through to learn them. Some of the most horrendous UX I've ever seen was in an in-house call center application to take outage reports at a power company - one of their most critical ways to help customers. Are they not worth better UX?

UX is important for all those applications. The more the application gets used, the more good or bad UX comes into play. It's not just about selling the application and getting 5 stars, it's also about making others more efficient and making their lives a little less hellish. Making them feel good while using it is a nice bonus.

Most developers, let's not kid ourselves, are simply not well-equipped to make good UX decisions. They're too embedded in the software, and too aware of the underlying code and architecture changes that a change in UX would require so they push back, or don't even consider the things that really should be done. Or they build the system back-to-front and the UI, by necessity, resembles the data structures they used throughout the app. Oh, and changing the UX of an application is one of those things that becomes becomes far more expensive as you wait. UX is the entire workflow of the application. It touches just about everything.

What about graphics? In companies, "Designer" often encompasses both UX and Visual/Graphics design. Often, good UX designers also have a decent visual design background as well, just as developers often have more than one related skill.

Just go Find Some Free Icons

That's something I heard over and over, and you probably hear it too. "Go find some clipart" or "go find a free icon set". Ugh. Invariably, the icon set would only have 1/3 of the required icons, and the remaining ones would have to magically appear. I was able to do that (Axialis Icon Designer saw a lot of me back then), not anywhere near as well as the original designer, but well enough. There were many other applications I saw which had different icons from various sets, with incompatible styles, all mashed together on the same toolbar.

The same thing applies to site themes, css, and more. "Just go find a template" is almost as bad as "go find some free icons".

There are more choices today, but you still end up with those toolbars (or pages, or whatever) where half the icons look good, and the other half show some bad image with a three letter acronym over it.

They all have splash screens though, and with clip art. Maybe even from MS Word. :)

In some cases, the UI starts to resemble that PTA fund raising newsletter sent home with your kid, or that office baby shower announcement :)

When I did work on the graphics and visual design of applications a decade or more ago, I had to do it while hiding in the corner. I had a customer PM come over and tell me "don't let anyone see you drawing pictures". Clearly the visual design and icons and other elements "just appeared" from nowhere. The effort was not respected, but the outcome was expected.

The problem here is not that developers don't know their limits (most do), but that management doesn't see the UX/Graphics Designer role as useful. It's not seen as a science, it's art. And just like in public schools, it's art that gets cut first.

An introduction to Interaction Design should be a required subject for all Computer Science and MIS majors. Not because I would expect them to learn to be great at it, but because they need good solid exposure to it so they know something's possible, even if they don't have the required skills/talent. They'll see there's more science to it than they thought. In fact, Psychology backgrounds often help in UX design. It helps that most Psychology majors are otherwise unemployed :)

Like I said to Scott "The more freedom and power you have, the more you need someone to tell you what not to do." You need this person on your team.

Who is On Your Team?

If you are on a team larger than two people, I bet you have a project manager, a dedicated DBA/database designer (or someone who doubles as DBA and database designer while also coding queries and services and whatnot), a front-end programmer, a back-end programmer, and maybe even a tester. Maybe you have an analyst or two, although those seem to be getting scarce. Larger teams tend to have more finely grained roles.

These are all seen as specialized skills. Not everyone is great at designing databases. Not everyone is equally skilled at creating good services and APIs. Not everyone can line up fields on a form. With web apps, the division tends to be even stronger due to the different languages and platforms in use in the different tiers or sections of the application. Inside the development community we, and our managers, understand these limitations and try to work within them.

But most importantly, not everyone can take a problem and visualize an appropriate workflow and user experience, low-cost prototype it, test it with the users, and make the changes required to make the best UX the project budget will support. It's a specialized skill like any other.

And like any other part of a software project, you don't want to just do it at the end. No lipstick on a pig. Get a designer involved form the beginning, and include them in your iteration plan. You'll be amazed at what you can accomplish.

How have your battles gone on this front? Have you been able to convince management about the importance of UX/Interaction/Visual design? If so, how did you go about it? What worked? What didn't?

Arduino The Documentary

Pete Brown — Tue, 24 Jan 2012 04:48:51 GMT

For anyone interested in open source microcontroller development, or why boards are named with *duino type names, this 1/2 hour documentary is a great watch.

http://vimeo.com/18539129

Arduino.TheDocumentary.2010.English explains the origin of the Arduino in a relatively non-technical interview-based documentary style, with interviews for people involved in the creation, as well as key partners and users.

Spanish version is also available.

My First Real PIX-6T4 Game: Sixty4Racer

Pete Brown — Sun, 22 Jan 2012 13:34:30 GMT

After assembling my Netduino-powered PIX-6T4, I wanted to go and write a simple game. This post describes the construction of that game, including all source code.

Concept

When you have 64 monochrome red pixels, you need to keep the graphics simple. I decided on a game inspired by the classic Atari River Raid game. This is essentially a vertical scrolling game where you need to dodge obstacles with your boat. Variations included things like Spy Hunter on the C64 and many many others. Most of those games also involved shooting and enemies, but that's a but more complex than you can reasonably do on this board. I won't enable moving walls like Laser Gates, but I'll leave things open enough not to make it impossible to do that in the future.

The game had to be small enough that I could figure out the API, and then design, code, and blog about it in a single evening after my kids went to bed The PIX-6T4 is fun, but I have way too many projects on my backlog to be able to devote any significant time to it (here's a taste: a ShapeOko CNC mill, an AVR MIDI->CV Converter, the final touches on the MIDI Thru Box, several MFOS Synth Modules, Several Gadgeteer Board Concepts, a Win8 XAML book, chapters to review in my Silverlight 5 book, and much much more). In fact, that was one of the big selling points of this device: simple gameplay and quick to develop for. Combined with the great library Fabien designed, and my past experience with Netduino and, more specifically, C#, and this should be an evening project.

GamePlay

A simple dodge'em racing game. Levels get progressively longer and faster until you crash. And you will crash. And burn. And die.

The joystick lets you control moving your single pixel vehicle either left or right. You can't move in any other direction.

Progression

Most good games increase in difficulty as you progress through the game. I decided that for this one, both the number of screens in the level and the overall speed would both increase as you progress through the game.

Goals

The goal is simple: not die. The longer you last, the more levels you'll make it through, and the more you'll be able to brag to your friends.

Screen Design

Back in the 80s, in 7th grade, I used to design single-color sprites for the commodore 64. The sprites themselves were 3 bytes wide, with each pixel represented as a single bit in the byte. I used to define them on graph paper, but alas, the notebooks I filled with sprites and BASIC listings have long since disappeared.

I used to create my own fonts (programmable characters) as well. Those were done in a similar way, but on 8x8 graphs, eight bytes total for each character. Some pretty amazing games were created just with character graphics (the amazing Below the Root on the C64, as I recall, was one of them. You can see it played here.). That model is what we have to work with on the PIX-6T4, but showing the equivalent of one character at a time.

Here's an image from the Commodore 64 Programmer's Reference Manual

You can see there how the letter A is formed by the bit patterns for the eight bytes. I'm going to use a similar approach for the level design here. I'll create the "blocks" that make up the play area and then chain them together to create a playable game field.

Here here are the initial screens I created, using notepad. The only criteria I had was to make sure the middle two spots were open at the start and end of each screen. Zeroes are safe areas, ones are walls/shore/hard-deadly-smashy-things.

The more variation in screens you add, the more challenging and interesting the game can be. So, I'll be sure to leave the design open enough to allow for other screens to be easily added.

I don't need to limit myself to 8 bytes high, but I did anyway, as that will let you do things like use 8x8 pixel font editors to design the screens. In fact, here are the same levels (with a couple slight modifications), plus a bunch more, done using the pixel font editor. I got a little carried away :)

The first entry is the start screen, the second is the end screen. All the ones after that are random ones which can be shown at any point during play. There are several "break" screens in there. That is, screens that aren't particularly difficult. And then there are a number of hair-pullers, and ones with dead-ends too :) Black is wall, white is passable space.

Thanks to Fabien for pointing out this tool in the source code. It's so much easier to visualize the design when using the font editor, plus you get to export the bytes automatically. Speaking of export, here's what the tool generated for me:



// Font: ScreensSource.pf



unsigned char font[2048] =

{

    0xC7, 0xC3, 0x83, 0x83, 0x81, 0x00, 0x00, 0x00,    // Char 000 (.)

    0x00, 0x00, 0x81, 0x81, 0xC3, 0xC3, 0xE7, 0xE7,    // Char 001 (.)

    0xE3, 0xCF, 0x87, 0xCF, 0x81, 0xF3, 0xC3, 0x87,    // Char 002 (.)

    0x87, 0xC1, 0xF1, 0xF9, 0xE1, 0x87, 0xC3, 0x81,    // Char 003 (.)

    0x81, 0xE7, 0x81, 0x99, 0x99, 0x81, 0xE7, 0xC3,    // Char 004 (.)

    0xE7, 0xE7, 0xF1, 0xC1, 0xCF, 0xE3, 0xF7, 0xE7,    // Char 005 (.)

    0xE7, 0xE7, 0xE7, 0xE7, 0xE7, 0xE7, 0xE7, 0xE7,    // Char 006 (.)

    0xE3, 0xF9, 0xFC, 0xFE, 0xFC, 0xF9, 0xF3, 0xE7,    // Char 007 (.)

    0xE7, 0xE7, 0xEF, 0xE7, 0xF7, 0xE7, 0xEF, 0xE7,    // Char 008 (.)

    0xC3, 0xFB, 0xE1, 0xEF, 0xC1, 0xFB, 0x83, 0xE7,    // Char 009 (.)

    0xE7, 0xC1, 0x81, 0xF9, 0xC0, 0x81, 0x9F, 0x87,    // Char 010 (.)

    0xE7, 0xC3, 0x00, 0x7E, 0x00, 0xE7, 0xE7, 0x81,    // Char 011 (.)

    0xE7, 0x81, 0x18, 0x7E, 0x3C, 0x99, 0xC3, 0xE7,    // Char 012 (.)

    0x00, 0x18, 0x3C, 0x3C, 0x3C, 0x3C, 0x18, 0x00,    // Char 013 (.)

    0xC3, 0x89, 0x24, 0xB5, 0xA5, 0x2C, 0x81, 0xC3,    // Char 014 (.)

    0x86, 0x3C, 0x5A, 0x66, 0x3C, 0x28, 0x82, 0xC6,    // Char 015 (.)

    0x81, 0x00, 0x66, 0x66, 0x00, 0x99, 0x81, 0xA5,    // Char 016 (.)

    0xE7, 0xC3, 0xDF, 0x83, 0xF7, 0xA1, 0x8D, 0xE7,    // Char 017 (.)

    0xC3, 0x81, 0x00, 0x18, 0x18, 0x00, 0x81, 0xC3,    // Char 018 (.)

    0xE7, 0xC3, 0x99, 0x38, 0x1C, 0x99, 0xC3, 0xE7,    // Char 019 (.)

    0x04, 0x49, 0x02, 0x10, 0x4A, 0x00, 0x44, 0x20,    // Char 020 (.)

    0xA7, 0x2D, 0x6A, 0x2D, 0x26, 0x55, 0x56, 0x27,    // Char 021 (.)

    0xE7, 0xF7, 0xE7, 0xF7, 0xC3, 0xDB, 0xC3, 0xE7,    // Char 022 (.)

    0xE3, 0xCB, 0x9B, 0x3B, 0x89, 0x3D, 0x9D, 0xC5,    // Char 023 (.)

    0xE7, 0xC3, 0x99, 0xBD, 0x99, 0xC3, 0xE7, 0xE7,    // Char 024 (.)

    0xC3, 0xCF, 0xC3, 0xF3, 0xC7, 0xE3, 0xCF, 0xC7,    // Char 025 (.)

    0x65, 0xB6, 0x55, 0xB6, 0x65, 0xAA, 0x6D, 0xA7,    // Char 026 (.)

    0xE7, 0xC3, 0xE3, 0xF1, 0xF8, 0xF3, 0xC7, 0xE7,    // Char 027 (.)

    0xE4, 0xF4, 0xF4, 0xF4, 0xE4, 0x69, 0x0B, 0xA7,    // Char 028 (.)

    0x00, 0x18, 0x66, 0x5A, 0x5A, 0x66, 0x18, 0x00,    // Char 029 (.)

    0xA5, 0x91, 0x93, 0x97, 0x93, 0xCB, 0xE3, 0xE7,    // Char 030 (.)

    0x00, 0xDB, 0xC3, 0xE7, 0xE7, 0xC3, 0x99, 0x00,    // Char 031 (.)

    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,    // Char 032 ( )

    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,    // Char 033 (!)

    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,    // Char 034 (")

    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,    // Char 035 (#)

    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,    // Char 036 ($)

    ...

    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00     // Char 255 (.)

};

I then just needed to prune it to remove the stuff I wasn't using, and make it work in my app. The font designer certainly took a lot of the work out of it, though. The end-result can be seen in the code listing for the Screens class.

With that in place, it was time to actually start creating the game.

First Iteration: Creating the scrolling playfield

I called my project PeteBrown.Sixty4Racer. Just as in the previous post, I copied over the Program.cs file from another project and used that as the start. Please read my previous post to see what references you need and whatnot.

The first class I created was the one that manages the creation of the screens.

The Screens Class

The Screens class is responsible for storing all the known screens, and then assembling them into a level when requested. It knows how large the screens are, and how large a single level's full set of screens is.

using System;

using Microsoft.SPOT;

using netduino.helpers.Imaging;



namespace PeteBrown.Sixty4Racer

{

    class Screens

    {

        // Font: ScreensSource.pf

        private const int ScreenCount = 32;

        private const int ScreenHeight = 8;

        private readonly byte[] _screenBytes = new byte[ScreenCount * ScreenHeight]

        {

            0xC7, 0xC3, 0x83, 0x83, 0x81, 0x00, 0x00, 0x00,    // Start Screen

            0x00, 0x00, 0x81, 0x81, 0xC3, 0xC3, 0xE7, 0xE7,    // Stop Screen

            0xE3, 0xCF, 0x87, 0xCF, 0x81, 0xF3, 0xC3, 0x87,    // Char 002 (.)

            0x87, 0xC1, 0xF1, 0xF9, 0xE1, 0x87, 0xC3, 0x81,    // Char 003 (.)

            0x81, 0xE7, 0x81, 0x99, 0x99, 0x81, 0xE7, 0xC3,    // Char 004 (.)

            0xE7, 0xE7, 0xF1, 0xC1, 0xCF, 0xE3, 0xF7, 0xE7,    // Char 005 (.)

            0xE7, 0xE7, 0xE7, 0xE7, 0xE7, 0xE7, 0xE7, 0xE7,    // Char 006 (.)

            0xE3, 0xF9, 0xFC, 0xFE, 0xFC, 0xF9, 0xF3, 0xE7,    // Char 007 (.)

            0xE7, 0xE7, 0xEF, 0xE7, 0xF7, 0xE7, 0xEF, 0xE7,    // Char 008 (.)

            0xC3, 0xFB, 0xE1, 0xEF, 0xC1, 0xFB, 0x83, 0xE7,    // Char 009 (.)

            0xE7, 0xC1, 0x81, 0xF9, 0xC0, 0x81, 0x9F, 0x87,    // Char 010 (.)

            0xE7, 0xC3, 0x00, 0x7E, 0x00, 0xE7, 0xE7, 0x81,    // Char 011 (.)

            0xE7, 0x81, 0x18, 0x7E, 0x3C, 0x99, 0xC3, 0xE7,    // Char 012 (.)

            0x00, 0x18, 0x3C, 0x3C, 0x3C, 0x3C, 0x18, 0x00,    // Char 013 (.)

            0xC3, 0x89, 0x24, 0xB5, 0xA5, 0x2C, 0x81, 0xC3,    // Char 014 (.)

            0x86, 0x3C, 0x5A, 0x66, 0x3C, 0x28, 0x82, 0xC6,    // Char 015 (.)

            0x81, 0x00, 0x66, 0x66, 0x00, 0x99, 0x81, 0xA5,    // Char 016 (.)

            0xE7, 0xC3, 0xDF, 0x83, 0xF7, 0xA1, 0x8D, 0xE7,    // Char 017 (.)

            0xC3, 0x81, 0x00, 0x18, 0x18, 0x00, 0x81, 0xC3,    // Char 018 (.)

            0xE7, 0xC3, 0x99, 0x38, 0x1C, 0x99, 0xC3, 0xE7,    // Char 019 (.)

            0x04, 0x49, 0x02, 0x10, 0x4A, 0x00, 0x44, 0x20,    // Char 020 (.)

            0xA7, 0x2D, 0x6A, 0x2D, 0x26, 0x55, 0x56, 0x27,    // Char 021 (.)

            0xE7, 0xF7, 0xE7, 0xF7, 0xC3, 0xDB, 0xC3, 0xE7,    // Char 022 (.)

            0xE3, 0xCB, 0x9B, 0x3B, 0x89, 0x3D, 0x9D, 0xC5,    // Char 023 (.)

            0xE7, 0xC3, 0x99, 0xBD, 0x99, 0xC3, 0xE7, 0xE7,    // Char 024 (.)

            0xC3, 0xCF, 0xC3, 0xF3, 0xC7, 0xE3, 0xCF, 0xC7,    // Char 025 (.)

            0x65, 0xB6, 0x55, 0xB6, 0x65, 0xAA, 0x6D, 0xA7,    // Char 026 (.)

            0xE7, 0xC3, 0xE3, 0xF1, 0xF8, 0xF3, 0xC7, 0xE7,    // Char 027 (.)

            0xE4, 0xF4, 0xF4, 0xF4, 0xE4, 0x69, 0x0B, 0xA7,    // Char 028 (.)

            0x00, 0x18, 0x66, 0x5A, 0x5A, 0x66, 0x18, 0x00,    // Char 029 (.)

            0xA5, 0x91, 0x93, 0x97, 0x93, 0xCB, 0xE3, 0xE7,    // Char 030 (.)

            0x00, 0xDB, 0xC3, 0xE7, 0xE7, 0xC3, 0x99, 0x00    // Char 031 (.)

        };



        private RacerGame _parentGame;



        public Screens(RacerGame parentGame)

        {

            _parentGame = parentGame;

        }





        public int GetLevelScreenCount(int level)

        {

            return level * 6 + 2;

        }



        public int GetLevelPixelHeight(int level)

        {

            return GetLevelScreenCount(level) * ScreenHeight;

        }



        public Composition GetLevelComposition(int level)

        {

            int levelScreenCount = GetLevelScreenCount(level);



            byte[] bytes = new byte[ScreenHeight * levelScreenCount];



            int b = 0;

            int startIndex = 0;



            for (int i = 0; i < levelScreenCount; i++)

            {

                if (i == 0)

                {

                    // finish screen. This is the second screen in the array

                    startIndex = ScreenHeight;

                }

                else if (i == levelScreenCount - 1)

                {

                    // start screen. First screen in the array

                    startIndex = 0;

                }

                else

                {

                    // regular random screen

                    int selectedScreen = _parentGame.Random.Next(ScreenCount - 2) + 2;



                    startIndex = ScreenHeight * selectedScreen;

                }



                for (int a = startIndex; a < startIndex + ScreenHeight; a++, b++)

                {

                    bytes[b] = _screenBytes[a];

                }

            }



            return new Composition(bytes, 8, levelScreenCount * ScreenHeight);

        }



    }

}

The class has the primary function GetLevelComposition which builds the background bitmap used to populate all the little red LEDs. The Composition class is one of the netduino helper classes in the PIX-6T4 library.

The next class is the main game class.

The RacerGame class

The RacerGame class is responsible for all the game-specific logic. It handles scrolling the level, displaying messages, and (eventually), moving the player around the screen and handling collision detection. In this first iteration, all it does is display the level number and then scroll the level at the appropriate speed. The first level may seem to scroll painfully slow, but trust me, throw a player pixel in there and you'll change your mind.

using System;

using Microsoft.SPOT;

using netduino.helpers.Fun;

using netduino.helpers.Imaging;

using System.Threading;



namespace PeteBrown.Sixty4Racer

{

    class RacerGame : Game

    {

        private Screens _screens;



        public RacerGame(ConsoleHardwareConfig config)

            : base(config)

        {

            _screens = new Screens(this);



            DisplayDelay = 25;

        }



        protected override void OnGameEnd()

        {

        }





        protected override void OnGameStart()

        {

            base.OnGameStart();

        }



 

        private int _currentLevel = 0;

        private float _currentlevelSpeedIncrement = 0f;

        private float _exactScrollPosition = 0.0f;



        private int CurrentWorldLine

        {

            get { return (int)_exactScrollPosition; }

        }



        private void InitializeLevel()

        {

            World = _screens.GetLevelComposition(_currentLevel);

            _exactScrollPosition = _screens.GetLevelPixelHeight(_currentLevel) - 1;

            _currentlevelSpeedIncrement = 0.02f * (float)_currentLevel; // tweak this to change speed

        }



        private void CompleteLevel()

        {

            // TODO: Play some music



            Thread.Sleep(1500);

            ScrollMessage(" Level Up!");

        }



        private void IntroduceLevel()

        {

            // show the level number

            Hardware.Matrix.Display(SmallChars.ToBitmap(_currentLevel / 10, _currentLevel % 10));

            Thread.Sleep(1000);

        }



        private bool _firstTime = true;

        public override void Loop()

        {

            if (CurrentWorldLine == 0 || _firstTime)

            {

                if (!_firstTime)

                {

                    CompleteLevel();

                }



                // Next Level

                _currentLevel++;

                InitializeLevel();

                IntroduceLevel();



                _firstTime = false;

            }

            else

            {

                _exactScrollPosition -= _currentlevelSpeedIncrement;

            }



            // draw the frame

            Hardware.Matrix.Display(World.GetFrame(0, CurrentWorldLine));

        }

    }

}

The RacerGame class knows a level is complete when the top row of pixels is the first row of pixels in the level. Remember, since we're scrolling the screen down, we're moving from the bottom to the top of the rows of pixels. Get to the top, and the level is done.

Minor But Fatal Bitmap Class Bug

The GetFrame method in the version of the source code I used has an incorrect check. Where it says if (x >= 0 && x + FrameSize < Width) it should say if (x >= 0 && x + FrameSize <= Width). Notice the <= instead of <. The incorrect check means that any bitmaps that are exactly 8 pixels wide, like the one here, simply won't display. This bug may be fixed in the source you get, but you'll want to double-check. I'm just glad I had the source to refer to (and fix!). Isn't OSS great? :)

When the level is complete, you get the scrolling "Level Up!" message. Click the joystick button and you're good to try the next level.

Now is a good time to run the game and see what it looks like. You should see a vertically scrolling playfield, but no player just yet.

Second Iteration: Adding in the player

The PIX-6T4 libraries have built-in the concept of a PlayerMissile. This is a single pixel on the playfield. It may move, so it has X and Y speed. You can show or hide it, so it has Visibility. And most importantly, it has collision detection with other PlayerMissile instances. For our game, we're not going to use that, since we're looking for collision detection with the background. So, a little manual detection is in order.

Bitmap Class Bugs

While coding this game, I found a few more bugs in the Bitmap class. I've alerted Fabien, so you should see an updated set of source code soon. The first bug is that the GetPixel and SetPixel methods do some incorrect bounds checking up front. Y is checked against width rather than height, and the opposite happens with X. We're going to use GetPixel in a moment, so fixing this is important.

Here's the updated RacerGame class

using System;

using Microsoft.SPOT;

using netduino.helpers.Fun;

using netduino.helpers.Imaging;

using System.Threading;



namespace PeteBrown.Sixty4Racer

{

    class RacerGame : Game

    {

        private Screens _screens;

        private PlayerMissile _ship;



        public RacerGame(ConsoleHardwareConfig config)

            : base(config)

        {

            _screens = new Screens(this);



            DisplayDelay = 25;

        }



        protected override void OnGameEnd()

        {

            ScrollMessage(" Game Over");

        }





        protected override void OnGameStart()

        {

            base.OnGameStart();



            _ship = new PlayerMissile()

                {

                    Name = "ship",

                    IsEnemy = false,

                    X = 3,

                    IsVisible = true,

                    VerticalSpeed = 0,

                };



            ScrollMessage(" Sixty4Racer!");

        }



 

        private int _currentLevel = 0;

        private float _currentlevelSpeedIncrement = 0f;

        private const float BaseShipSpeed = 0.25f;           // speed ship moves across the screen

        private float _exactScrollPosition = 0.0f;



        private int CurrentWorldLine

        {

            get { return (int)_exactScrollPosition; }

        }



        private void InitializeLevel()

        {

            World = _screens.GetLevelComposition(_currentLevel);

            World.AddMissile(_ship);



            _exactScrollPosition = _screens.GetLevelPixelHeight(_currentLevel) - 1;

            _currentlevelSpeedIncrement = 0.02f * (float)_currentLevel; // tweak this to change speed



            _ship.Y = CurrentWorldLine + 7; // always be on bottom line

            _ship.X = 3;

        }



        private void CompleteLevel()

        {

            // TODO: Play some music



            Thread.Sleep(1500);

            ScrollMessage(" Level Up!");

        }



        private void IntroduceLevel()

        {

            // show the level number

            Hardware.Matrix.Display(SmallChars.ToBitmap(_currentLevel / 10, _currentLevel % 10));

            Thread.Sleep(1000);

        }



        private bool CheckForCollision()

        {

            return World.Background.GetPixel(_ship.X, _ship.Y);

        }



        private bool _firstTime = true;

        public override void Loop()

        {

            _ship.HorizontalSpeed = (float)Hardware.JoystickLeft.XDirection * BaseShipSpeed;

            _ship.Move();



            if (_ship.X < 0) _ship.X = 0;

            if (_ship.X > 7) _ship.X = 7;



            if (CurrentWorldLine == 0 || _firstTime)

            {

                if (!_firstTime)

                {

                    CompleteLevel();

                }



                // Next Level

                _currentLevel++;

                InitializeLevel();

                IntroduceLevel();



                _firstTime = false;

            }

            else

            {

                _exactScrollPosition -= _currentlevelSpeedIncrement;



                _ship.Y = CurrentWorldLine + 7; // always be on bottom line

            }



            // draw the frame

            Hardware.Matrix.Display(World.GetFrame(0, CurrentWorldLine));



            if (CheckForCollision())

            {

                // game over

                Stop();

            }

        }

    }

}

This version of the source adds in the player pixel

I represent the "This Game is Too Damn Hard" Party

At this point, after adding the player and collision detection, I realized just how hard this game is! If you want to make it easier, I suggest editing the levels to make them a little more open, like a minimum of two pixels wide for any path, and no sudden moves left or right. You may even want to segment the level array into easy/medium/hard, and then change the mix of screens from level to level.

With all that in place, now is another great time to try out the game. It has all the main functionality at this point; anything else is just polish.

Third Iteration: Polishing

The first thing I realized was that it was really hard to make out the player pixel in the sea of red. That's to be expected on a monochrome display at 8x8 resolution. The approach I came up with to make it a bit easier is to simply flicker the player pixel. Each time the game loop executes, I toggle the visibility of the ship PlayerMissile to give it a nice seizure-inducing flicker.

public override void Loop()

{

    _ship.HorizontalSpeed = (float)Hardware.JoystickLeft.XDirection * BaseShipSpeed;

    _ship.Move();



    // make the ship blink so we can see it

    _ship.IsVisible = !_ship.IsVisible;



    if (_ship.X < 0) _ship.X = 0;

    if (_ship.X > 7) _ship.X = 7;



    if (CurrentWorldLine == 0 || _firstTime)

    {

        if (!_firstTime)

        {

            CompleteLevel();

        }



        // Next Level

        _currentLevel++;

        InitializeLevel();

        IntroduceLevel();



        _firstTime = false;

    }

    else

    {

        _exactScrollPosition -= _currentlevelSpeedIncrement;



        _ship.Y = CurrentWorldLine + 7; // always be on bottom line

    }



    // draw the frame

    Hardware.Matrix.Display(World.GetFrame(0, CurrentWorldLine));



    if (CheckForCollision())

    {

        // game over

        Stop();

    }

}

Sound Effects

The next thing this needed was some sound effects. When you move left or right a full pixel, it would be helpful to play a little blip. Maybe that's annoying? Nah! Let's do it.

This is really easy to do. I simply keep track of the last position the ship moved to. If the new position is different from the old one, I call the Beep function to make a noise. The actual implementation here results in an extra blip on startup, but I'm cool with that :)

private void Blip()

{

    Beep(200, 30);

}



private bool _firstTime = true;

private int _oldShipX = 0;

public override void Loop()

{

    _ship.HorizontalSpeed = (float)Hardware.JoystickLeft.XDirection * BaseShipSpeed;

    _ship.Move();



    if (_ship.X != _oldShipX)

    {

        Blip();

        _oldShipX = _ship.X;

    }





    // make the ship blink so we can see it

    _ship.IsVisible = !_ship.IsVisible;



    ...



}

Next, we need to do a little bit of exploding when you hit the wall. And yes, you will hit the wall.

The Explosion Sprite

The final thing was to add a little bit of an explosion when the player hits the wall. I designed the sprite data using the same PixelFont editor.

I then copied just those 8 x 8 bytes of data into the initializer for the sprite class. Here's the Sprite class itself (without the initializer code).

using System;

using Microsoft.SPOT;



namespace PeteBrown.Sixty4Racer

{

    class Sprite

    {

        private readonly byte[] _frames;

        private const int Width = 8;

        private const int Height = 8;

        private int _frameCount;



        public Sprite (byte[] frames)

        {

            _frames = frames;



            _frameCount = _frames.Length / Height;

        }



        public int FrameCount

        {

            get { return _frameCount; }

        }



        public int CurrentFrame

        {

            get { return _currentFrame; }

        }



        public void Reset()

        {

            _currentFrame = 0;

        }



        private int _currentFrame = 0;

        public byte[] GetNextFrame()

        {

            return GetFrame(_currentFrame++);

        }



        public byte[] GetFrame(int index)

        {

            if (index >= FrameCount)

                throw new IndexOutOfRangeException("Index must be less than " + FrameCount);



            byte[] b = new byte[Height];



            for (int i = 0; i < Height; i++)

            {

                b[i] = _frames[index * Height + i];

            }



            return b;

        }

    }

}

(The initialization code will be in the next listing.)

Next, I added in a little music. How about some Sad Trombone when you die? Sounds good to me. By looking at the Pac Man music example, and the source code for the RttlSong class, I was able to figure out how to build a string of notes to play the sad trombone sound asynchronously while the explosion happens. Rub it in!

Sprite _explosion = new Sprite(new byte[]

    {

        0x00, 0x00, 0x00, 0x18, 0x18, 0x00, 0x00, 0x00,

        0x00, 0x00, 0x18, 0x24, 0x24, 0x18, 0x00, 0x00,

        0x08, 0x3C, 0x72, 0x5B, 0xDE, 0x62, 0x3C, 0x08,

        0x3C, 0xD2, 0xAD, 0xFE, 0x5F, 0xF5, 0x56, 0x28,

        0x00, 0x3C, 0x56, 0x7A, 0x6E, 0x72, 0x3C, 0x00,

        0x00, 0x00, 0x18, 0x3C, 0x3C, 0x18, 0x00, 0x00,

        0x00, 0x00, 0x00, 0x18, 0x18, 0x00, 0x00, 0x00,

        0x00, 0x00, 0x00, 0x08, 0x10, 0x00, 0x00, 0x00

    });



protected override void OnGameEnd()

{

    var song = new RttlSong("SadTrombone:d=4,o=4,b=40:32d4,32c#4,32c4,4b3");

    var thread = song.Play(Hardware.Speaker, true);



    for (int i = 0; i < _explosion.FrameCount; i++)

    {

        Hardware.Matrix.Display(_explosion.GetNextFrame());

        Thread.Sleep(200);

    }



    ScrollMessage(" Game Over");

}

You can go further, of course, but I'm going to wrap it up at that.

Final Steps

The final things to do are to create the manifest file and bitmap which will be used on the SD card. I'll need to check with Fabien to see what the exact format of the .bin file is, but I suspect it's just the 8 bytes of data formatted like all the other bitmap data in this application. I'm also not sure if he has a nice little app to write that data out, or convert from a bitmap, or something else. I ended up just using a hex editor to recreate the pattern from one of the images I created in the font editor.

The assembly itself needs to be loaded from the SD card as a .pe file, as Fabien explains in his blog post on dynamically loading assemblies from an SD card. Be sure to comment out the #define dev before your final compile. Make sure you take the .pet file from the LE (little endian) folder, not the BE (big endian) folder. The files look identical other than byte order, but the BE version will not work.

I then created a cartridge.txt manifest file for my game. The contents of that consist of a single line:



assembly:file=PeteBrown.Sixty4Racer.pe;name=PeteBrown.Sixty4Racer;version=1.0.0.0;class=PeteBrown.Sixty4Racer.Program;method=Run

They must be in a folder with the same name as the root file name for the image. So, these go in a PeteBrown.Sixty4Racer folder.

Finally, don't forget to reflash the PIX-6T4 with the main ConsoleBootLoader application from your solution.

After that, pop the SD card into the PIX-6T4 and have a blast!

What You Can Do

This came is completely free and open source. While I'd love credit for the initial work, it's not a requirement. Go ahead and do whatever you'd like with the source and have a blast :)

Here's a video of the game in action.

PIX-6T4 Netduino Mini Game

Assembling the PIX-6T4 Netduino-powered Hand-Held Game System

Pete Brown — Sat, 21 Jan 2012 07:12:51 GMT

I recently picked up a PIX-6T4 build by Fabien Royer (with games by Fabien Royer and Bertrand Le Roy). This is a 64 pixel, two joystick/button, monophonic sound hand-held game device based around the Netduino Mini from Secret Labs. You create games in C# using Visual studio.

Disclaimer: I work for Microsoft and I enjoy working in the .NET Micro Framework as well as C++ on other microcontrollers. I purchased this product on my own, at full price; this is not a sample or review unit. Presumably, I got the same package of goodies everyone else gets.

Unboxing

The kit came in a regular USPS shipping box inside which were four bags. Two bags had components, and two had joysticks.

Everything was well-packed in ESD safe bags. The two joysticks were in their original as-delivered bags.

What's inside?

What the Kit Includes

The kit includes just about everything you need to assemble a working PIX-6T4 handheld game console. The PCB, of course, as well as a nice laser-cut acrylic bottom.

It can be powered by a 9v battery or a regular 9v power supply. When using a battery, you solder a barrel jack on the battery lead to make it easy to switch between the two.

The entire thing is open source hardware and software from the Netduino all the way up to the full kit and the software to run it.

What it doesn't Include

A USB to Serial converter. Many people with Netduino minis already have one of these cables. You can get them cheap online, or (worst case) get one at Best Buy or Fry's. I happened to have one just because my C64-TPC (a connection between my Commodore and my PC) needed one. Putting on-board USB would have been nice, but that typically requires a surface-mount FTDI chip which is very difficult for DIY soldering (or a breakout board from a place like SparkFun which adds bulk, cost, and complexity). The Netduino mini, unlike the Netduino, doesn't offer an external USB interface. So, while I'm not a fan of the serial approach, I do think it was the best choice here.

You can play the stock games by just loading them on the SD card. However, if you want to do any programming or debugging of your own, you'll really need the USB converter, as debugging is impossible without it.

Speaking of SD card, that's the other things that you'll need: A FAT32-formatted SD card. You'll need one of these to store the games you write and also to load the stock games.

Assembly

I love the blue board. I've always liked blue, black and red PCBs. The typical green solder mask just looks too much like some crap 486 motherboard. I'm glad they went with something attractive here.

First step is the most unusual bit of soldering. There's one surface mount component, but it's stunningly easy to solder. That's the SD card slot. Make sure you following the video and do not solder the two pins on the right (although if they're not connected to anything, as long as you don't short them, I would think they'd be fine)

Next up, flip the board over and install the IC socket for the LED controller, and then a resistor.

In this particular case, it seems the stencil for the resistor was sized for a 1/8" watt resistor. The space is also cramped, but this resistor sticking up like that just breaks my heart. At least, it's on the bottom side of the board so we can all hide our shame :)

Next, up, the LED array and then the Netduino mini socket.

A power switch and another resistor standing at attention

From there, it's the audio trim pot and the power LED. At this point, I have to mention that the power LED is REALLY bright and in your face when you're trying to play. I covered mine with a little bit of black paint, but even that isn't quite enough. I actually think it would be better to solder that LED upside down, so it is on the underside of the board. That might even be a cool effect with the acrylic down there. Fabien mentioned he might bump up the resistor value, but the more I think about putting it upside down, the more I like it. I might even desolder mine and put a new LED underneath :)

I did a few more steps before taking another photo. Resistors, the power connector (underside), and a transistor are all in place.

In case you haven't gathered, I'm not a big fan of having resistors stand up in general. In fact, I hate them in all but the most cramped design with huge multi-watt resistors. They're easy to knock over, bend, etc, and they're more difficult to solder in that configuration. There's tons of spare room on this board, so I'm not entirely sure why Fabien and folks did that. Just be careful when soldering the other components so you don't break these off.

Ceramic capacitor, electrolytic capacitor, and the 3.3v power regulator in place. If I were designing this board, I think I would have found a way to position the regulator so it lay flat on the board with its leads bent at 90 degree angles. That's a pretty common approach in other builds, like the Sammich SID I built.

Finally, the joysticks, pin headers, and the ICs themselves. Before I installed the ICs, I went and cleaned the bottom of the board with flux remover spray and a cleaning brush. It helps clean things up quite a bit. You'll see later, it also helped me see a bad solder joint. Organic Rosin flux isn't super harmful to leave on, but it's ugly to see on the board.

Don't forget the one IC that goes on the bottom.

Smoke Test

Time for a power-on test! After I cleaned it up, dried if off, and installed the ICs, I powered it up without an SD card. This is what I saw:

Sweet! I got the skull and crossbones, which means it's working. As an aside, you can also see what I was talking about with the super bright LED. It easily overpowers the playing field. Looks cool in a photo, though, a bit like a Star Trek II photon torpedo.

Next, I copied the three game folders (from the zip file referenced on the PIX-6T4 site) on to a 512MB SD card and started it up. I was greeted by the icons of the games I could choose. I picked a game and then…

And…I got nothing.

At first I thought it was this bad solder joint (which makes no sense, but hey, I figured the code was perfect!). It's really hard to see in this picture (and in fact, it looks ok in this picture), but when viewed through a lens you can see that I never heated the pin: the solder goes around the pin but never really joins with it.

I only found this after cleaning the board with flux remover. Flux can fill in holes like that and make it so you can't see them without doing a continuity test. I resoldered that pin (and the one next to it which didn't look much better), and then did a continuity test between the mini and each of the breakout pins, just to make sure there were no others.

Still no go.

After trying out a few SD cards and getting nothing, and following some other suggestions from Fabien, I still had nothing. Finally, Fabien recommended I dig out that usb->serial cable (I wasn't able to find it at first) and compile and re-deploy the current source from Codeplex. Guess what? It worked :)

It turns out I had one of the Netduino Minis that had the old firmware on it, and the games were built with new firmware. The deploy got them synchronized.

Excellent. I have a working PIX-6T4 :)

The Test Games

I tried the games that come with it. One plays the Pac Man song, one is a game of pong, and the other is an asteroid avoidance game. You have only 64 pixels to work with, and they're all the same color, so like the early days of video games, you need to use your imagination.

The stock games are well done. However, since I had the debugger/programmer connected, I wanted to go and build something myself.

My First Game

My first game is going to be a test game. I added a new Netduino application project named "PeteTestGame". I did this in the same solution that contains the PIX6T4 source code and the other three stock games. Next, I added a reference to pix6t4.netduino.helpers project.

In the project, I also removed the reference to SecretLabs.NETMF.Hardware.Netduino and add reference to SecretLabs.NETMF.Hardware.NetduinoMini

Next, add a GameOfTest class. I named it this following the naming conventions Fabien and Bertrand set up, but you can call it anything. GameOfThrones is an obvious choice ;)

The GameOfTest class

using System;

using Microsoft.SPOT;

using netduino.helpers.Fun;



namespace PeteTestGame

{

    class GameOfTest : Game

    {

        public GameOfTest(ConsoleHardwareConfig config)

            : base(config)

        {



        }



        protected override void OnGameEnd()

        {

            base.OnGameEnd();

        }



        protected override void OnGameStart()

        {

            base.OnGameStart();



            ScrollMessage(" Hello World!");

        }



        protected override void OnLeftButtonClick(uint port, uint state, DateTime time)

        {

            base.OnLeftButtonClick(port, state, time);

        }



        protected override void OnRightButtonClick(uint port, uint state, DateTime time)

        {

            base.OnRightButtonClick(port, state, time);

        }



        public override void Loop()

        {

       

        }

    }



}

Program

Next, I copied the Program.cs from one of the other projects. I made three changes to the source:

Uncomment the #define dev at the top
Changed the namespace to match the rest of the project
Changed the class in the Run method to be GameOfTest instead of the one copied from the other project

The program.cs enables you to deploy your test game as the only game on the device, without worrying about building up a manifest and icon and dealing with the SD card and whatnot. Obviously, this also makes debugging possible.

Set the game project as startup. Next, right-click and select project properties and navigate to the .NET Micro Framework tab. Make sure the deployment is set to Serial and you have the COM port that your Netduino mini is attached to.

Once done, you can run the project. In my case, I immediately saw the scrolling (and repeating) Hello World text. The ScrollMessage function is doing all the heavy lifting. It's great that Fabien put in the nifty retro font in there as well.

Next step was to add some beeping. Because, well, it's not a game without beeping.

using System;

using Microsoft.SPOT;

using netduino.helpers.Fun;



namespace PeteTestGame

{

    class GameOfTest : Game

    {

        public GameOfTest(ConsoleHardwareConfig config)

            : base(config)

        {



        }



        protected override void OnGameEnd()

        {

            base.Beep(440, 500);

            base.Beep(220, 500);

            base.Beep(440, 500);

        }





        protected override void OnGameStart()

        {

            base.OnGameStart();



            base.Beep(440, 500);

            base.Beep(220, 500);

            base.Beep(440, 500);



            ScrollMessage(" Hello World!");

        }



        protected override void OnLeftButtonClick(uint port, uint state, DateTime time)

        {

            base.OnLeftButtonClick(port, state, time);



            base.Beep(440, 500);



        }



        protected override void OnRightButtonClick(uint port, uint state, DateTime time)

        {

            base.OnRightButtonClick(port, state, time);



            base.Beep(220, 500);

   

        }



        public override void Loop()

        {

       

        }

    }



}

Now it plays a few beeps on startup and then beeps when you press down on either joystick. Note that that does stop the scrolling text, however.

I'll leave the more complex games to a later date :)

Update 1/22: To see my first real full game, check out my blog post on building Sixty4Racer.

Conclusion

I'm impressed with what Fabien has come up with here, and the stock games he and Bertrand have done are just perfect. I think the board and enclosure could use a little more design to make it more compact and also more hand-friendly, but overall, I think this is an excellent way to get into Netduino programming using something fun and exciting. Also, because of the display technology, you are constrained to creating games with very simple graphics (just LEDs) so, by necessity, you avoid that common barrier to entry. Sometimes constraint is a good thing.

Congratulations Fabien and Bertrand!

WPF 4.5 Cross-Thread Collection Synchronization Redux

Pete Brown — Fri, 20 Jan 2012 21:59:04 GMT

In my post about WPF 4.5 Observable Collection Cross-thread Change Notification, I showed the basics of how to synchronize collection updates in WPF, and how to avoid having to manually dispatch calls to the UI thread. In the comments, Jonathan Allen brought up some very good points that I simply didn't know the answers to (and a lock I was missing in the example). Thanks to Jonathan for keeping me honest :)

For background, go back and read that post, but then come here for some of the updates.

So, rather than guess at the answers, I went right to the guy responsible for most (all?) of the design of the binding structure in WPF: Sam Bent. I also went back to the spec document, and also dove deeper into what's actually happening.

Locking

Q: If I'm using collection synchronization, do I need to lock my own access to the collection?

A: Yes, you do. The collection won't do any locking by itself (I had thought that ObservableCollection was doing some, but both Jonathan and Sam corrected me here. Sam also pointed out this works with just about any collection). Having the collection handle any locking internally is "full of pitfalls" (Sam's words, which I agree with having seen the examples) and was abandoned early in .NET's development cycle.

What this does mean, is that my example from the previous post really needed to lock the collection add call. Here's the updated viewmodel source.

class MainViewModel

{

    public ObservableCollection<Stock> Stocks { get; private set; }



    private object _stocksLock = new object();



    public MainViewModel()

    {

        Stocks = new ObservableCollection<Stock>();



        BindingOperations.EnableCollectionSynchronization(Stocks, _stocksLock);

    }





    private Random _random = new Random();

    public void AddNewItems()

    {

        lock (_stocksLock)

        {

            for (int i = 0; i < 100; i++)

            {

                var item = new Stock();

                for (int j = 0; j < _random.Next(2, 4); j++)

                {

                    item.Symbol += char.ConvertFromUtf32(_random.Next(

                        char.ConvertToUtf32("A", 0),

                        char.ConvertToUtf32("Z", 0)));

                }



                item.Value = (decimal)(_random.Next(100, 6000) / 100.0);

                Stocks.Add(item);

                Debug.WriteLine(item.Symbol);

            }

        }

    }





    public void StartAddingItems()

    {

        Task.Factory.StartNew(() =>

        {

            while (true)

            {

                AddNewItems();

                Thread.Sleep(500);

            }

        });



    }

}

Notice how I lock the entire loop in AddNewItems. Depending on what's going on inside that loop, or how many iterations, that may simply be too large/long a lock. If you need a smaller/shorter lock, it would be safe to wrap the Add call instead, like this:

private Random _random = new Random();

public void AddNewItems()

{

    for (int i = 0; i < 100; i++)

    {

        var item = new Stock();

        for (int j = 0; j < _random.Next(2, 4); j++)

        {

            item.Symbol += char.ConvertFromUtf32(_random.Next(

                char.ConvertToUtf32("A", 0),

                char.ConvertToUtf32("Z", 0)));

        }



        item.Value = (decimal)(_random.Next(100, 6000) / 100.0);

        lock (_stocksLock)

        {

            Stocks.Add(item);

        }

        Debug.WriteLine(item.Symbol);

    }

}

I'll leave the choice of which one is appropriate up to the folks designing individual applications. It sounds like a punt, but it really is up to you guys. Each has merits (fewer lock acquisitions in first one, more atomic actions and less thread blocking in second one), but really are very application dependent. In my particular demo example here, with 100 iterations, I'm fine with handling the lock outside the loop.

About the EnableCollectionSynchronization Overload

Here's one question that Sam answered. I'll quote him directly.

Q: Why are there two overloads to EnableCollectionSynchronization?

A: You pick which overload of EnableCollectionSynchronization to use based on how your app synchronizes access to its own collection. If you're using fancy synchronization primitives - semaphores, ReadWriteLock, ManualResetEvent, etc. - you'd use the overload with a callback argument. Whenever WPF needs to touch the collection, it calls the callback, which uses the fancy primitive to gain the right permissions. On the other hand, if you're just using "lock(x) { … }", you'd use the overload with just a lock object, passing in x. Whenever WPF needs to touch the collection, it also does "lock(x) { … }". This saves one level of callback in the common case.

Also note that you can use BindingOperations.DisableCollectionSynchronization(collection) when you want to stop using synchronization.

Getting in Before the CollectionView is Created

The BindingOperations class provides an event CollectionRegistering, which lets you register the collection for cross-thread access before any CollectionView instances are generated for it. Inside this event handler, you can do the actual registering of the collection. Here's an example:

public ObservableCollection<Stock> Stocks { get; private set; }



private object _stocksLock = new object();



public MainViewModel()

{

    Stocks = new ObservableCollection<Stock>();

    BindingOperations.CollectionRegistering += BindingOperations_CollectionRegistering;



    //BindingOperations.EnableCollectionSynchronization(Stocks, _stocksLock);

}



void BindingOperations_CollectionRegistering(object sender, CollectionRegisteringEventArgs e)

{

    Debug.WriteLine("CollectionRegistering Event");

    if (e.Collection == Stocks)

    {

        BindingOperations.EnableCollectionSynchronization(Stocks, _stocksLock);

    }

}

This is actually a good place to handle the registration, as you know you'll get to register for cross-thread access at the right time, before any dependent objects are created. In fact, I'd say this is the best place to do the EnableCollectionSynchronization call. You can do it in the constructor for simple apps, but once you start adding views (and sorting, and datagrids and the like), you'll want to do it here.

What's Happening with Change Notifications

Inside the framework, pending change notifications from the background thread are queued up and then acted on by the UI thread when it has time. This helps increase responsiveness for higher-priority events like input (mouse, keyboard, touch).

This is new for .NET 4.5 as part of this cross-thread collection work.

Fin

I hope you've found that this post helps clarify some of the open questions from the previous post. The work the WPF team has done to enable cross-thread collections is a fair bit of work, even though it surfaces through a pretty small API. This is also one of those features which will simply make your own application code nicer, with less plumbing gunk in it.

Updated example code attached.

WPF 4.5: Observable Collection Cross-Thread Change Notification

Pete Brown — Mon, 16 Jan 2012 20:54:30 GMT

WPF 4.5 is available as part of the Visual Studio 11 Developer Preview released at the Build 2011 conference, and is part of the .NET Framework version 4.5. WPF 4.5 addresses several important customer requests including the ability to have cross-thread change notification for collections - the topic of this post.

Update 1/20/2012: I have posted a set of updates to this post with additional information about the details, as well as a few code changes. Be sure to read that post as well as this one.

The Problem

As I explained in my post on cross-thread change notification, Silverlight and WPF have the concept of the UI thread and background (or secondary) threads. Code on a background thread is not allowed to interact with UI elements (controls, etc.) on the foreground thread. You can find more information about the general problem in that post.

What happens when you need to add and remove items from a collection from that background thread? That's pretty common in applications which must keep a list updated (stock trading is an obvious example). When the collection raises the change notification events, the binding system and listeners, on the UI thread, have code executed. Remember, an event is just a delegate, or really, just a function pointer. So, essentially, the collection is calling a function on the UI thread. That's not allowed, and it throws an exception.

The approach pre-4.5 was to dispatch all calls to add items to the collection. The diagram from the Silverlight post applies here.

If code on the background thread needs to access elements on the UI thread, set a property for example, it needs to dispatch the call to the UI thread using the dispatcher or synchronization context. Get enough of this happening, such as when constantly updating a collection, and you can run into some real performance problems.

The 4.5 Solution

We actually have a good solution for this in WPF 4.5. The BindingOperations class includes the EnableCollectionSynchronization function. This function helps the binding system and the collection intelligently handle change notification.

Let's look at an example. The application, when run, will look like this:

The stocks in the ListBox are loaded by clicking the "Load" button. To test the change notification, click the Keep Loading button. For this example, the Keep Updating button doesn't do anything (more on that when I cover in-place sorting and updating in another post)

XAML

Just for grins, and to show its inclusion in 4.5, I've put the functionality into another new addition to WPF proper: the Ribbon. I didn't use commands although they are supported.

<RibbonWindow x:Class="WpfApplication2.MainWindow"

        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

        xmlns:local="clr-namespace:WpfApplication2"

        Title="MainWindow" Height="350" Width="525">

    <Grid>

        <Ribbon>

            <RibbonTab Header="First Tab">

                <RibbonGroup Header="Group 1">

                    <RibbonButton x:Name="Foo" Label="Foo!" />

                    <RibbonButton x:Name="Bar"

                                  Label="Bar!" />

                </RibbonGroup>

                <RibbonGroup Header="Group 2">

                    <RibbonButton x:Name="Load"

                                  Click="Load_Click"

                                  Label="Load" />

                    <RibbonButton x:Name="KeepLoading"

                                  Click="KeepLoading_Click"

                                  Label="Keep loading" />

                    <RibbonButton x:Name="KeepUpdating"

                                  Label="Keep Updating" />



                </RibbonGroup>

                <RibbonGroup Header="Count">

                    <TextBlock Text="{Binding Stocks.Count}" />

                </RibbonGroup>

            </RibbonTab>

            <RibbonTab Header="Second Tab">



            </RibbonTab>

            <RibbonTab Header="Stuff that doesn't go anywhere else">



            </RibbonTab>

        </Ribbon>

    

        <Grid Margin="0,156,0,0">

            <TextBlock VerticalAlignment="Top"

                       FontSize="20"

                       Text="WPF Rules" />

        

            <Grid>

                <Grid.ColumnDefinitions>

                    <ColumnDefinition Width="*" />

                    <ColumnDefinition Width="*" />

                </Grid.ColumnDefinitions>



                <ListBox ItemsSource="{Binding Stocks}"

                         VirtualizingPanel.IsVirtualizing="True"

                         VirtualizingPanel.CacheLengthUnit="Page"

                         VirtualizingPanel.CacheLength="2,2"

                         VirtualizingPanel.ScrollUnit="Item">

                    <ListBox.ItemTemplate>

                        <DataTemplate>

                            <Grid>

                                <Grid.ColumnDefinitions>

                                    <ColumnDefinition Width="100" />

                                    <ColumnDefinition Width="100" />

                                </Grid.ColumnDefinitions>



                                <TextBlock Text="{Binding Symbol}"

                                           Grid.Column="0" />

                                <TextBlock Text="{Binding Value}"

                                           Grid.Column="1" />

                            </Grid>

                        </DataTemplate>

                    </ListBox.ItemTemplate>

                </ListBox>



            </Grid>

        </Grid>

    </Grid>

</RibbonWindow>

For this example, the primary pieces to pay attention to are the ListBox which is bound to the stocks, and the ribbon buttons to Load and Update the stocks collection. Those use the Stock model item via the ViewModel.

The Model

The model consists of a single class, called Stock.

using System.ComponentModel;



namespace WpfApplication2.Model

{

    class Stock : INotifyPropertyChanged

    {

        public event PropertyChangedEventHandler PropertyChanged;



        private string _symbol;



        public string Symbol

        {

            get { return _symbol; }

            set { _symbol = value; NotifyPropertyChanged("Symbol"); }

        }

        private decimal _value;



        public decimal Value

        {

            get { return _value; }

            set { _value = value; NotifyPropertyChanged("Value"); }

        }



        protected void NotifyPropertyChanged(string propertyName)

        {

            if (PropertyChanged != null)

                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

        }

    }

}

The ViewModel

The ViewModel is where the action is. First the listing, and then the explanation.

using System.Threading;

using System.Threading.Tasks;

using System.Windows.Data;

using WpfApplication2.Model;



namespace WpfApplication2.ViewModel

{

    class MainViewModel

    {

        public ObservableCollection<Stock> Stocks { get; set; }



        private object _stocksLock = new object();



        public MainViewModel()

        {

            Stocks = new ObservableCollection<Stock>();



            BindingOperations.EnableCollectionSynchronization(Stocks, _stocksLock);

        }





        private Random _random = new Random();

        public void AddNewItems()

        {

            for (int i = 0; i < 100; i++)

            {

                var item = new Stock();

                for (int j = 0; j < _random.Next(2, 4); j++)

                {

                    item.Symbol += char.ConvertFromUtf32(_random.Next(

                        char.ConvertToUtf32("A", 0),

                        char.ConvertToUtf32("Z", 0)));

                }



                item.Value = (decimal)(_random.Next(100, 6000) / 100.0);

                Stocks.Add(item);

                Debug.WriteLine(item.Symbol);

            }

        }





        public void StartAddingItems()

        {

            Task.Factory.StartNew(() =>

            {

                while (true)

                {

                    AddNewItems();

                    Thread.Sleep(500);

                }

            });



        }

    }

}

When the MainViewModel is instantiated, the collection is created. Next, I call the EnableCollectionSynchronization method, providing it the collection and an object to use as a lock. The lock object is nothing special, just an instance of the CLR object type. This single method makes cross-thread collection change notification possible.

The StartAddingItems method spins up another thread, using the Task parallel library, which then loads items into the collection. The data is randomly generated, but includes a large number of updates. When you run the application, you'll see that the ListBox is able to be quickly updated and that there are no cross-thread exceptions reported.

If you want to cause the exceptions to happen as normal, comment out the BindingOperations.EnableCollectionSynchronization call.

Summary

WPF 4.5 includes a number of key targeted performance and capability features, one of which is cross-thread collection change notification. Enabling the change notification is as simple as the inclusion of a lock object and a single function call. Versus the manual dispatching approach, this can be a real performance win, not to mention save you some coding time.

GNU C++ BlinkenLED Part 1 on the AVR (ATmega1284P with MikroElektronika EasyAVR6) and Atmel AVR Studio 5.1

Pete Brown — Sun, 15 Jan 2012 23:49:40 GMT

In this Part 1 post, I'll show how to interface with ATmega ports and pins to light up LEDs on a board. The follow-up post will show how to use the timer to actually blink the LED.

Most of the Microcontroller code out in the public is C or Assembly. I have nothing personal against assembly or C (and may end up using a little assembly in the future), but I decided I wanted to write C++, as I like its encapsulation and structure when compared to straight C.

I've written some other posts about getting started with these boards and environments. Be sure to check them out:

Getting Started with AVR Studio 5

Setting up for Developing and Debugging the AVR (ATmega1284P) with AVRStudio 5.1

Disclaimer: I don't have a lot of experience with the AVR. I'm writing as I'm learning. If you find a mistake below, please point it out in the comments.

C++ Disclaimer: If code size and execution speed are your primary concerns, you can certain do a bit better in C or even more so in assembly. C++ does add some overhead, especially if you go nuts on the class hierarchies. I've tried to strike a balance between size, speed, and encapsulation in my own libraries here, and also to show the differences. If you intend to write for some of the ATtiny chips with their miniscule 2k or 4k (sometimes a bit more) program memory, write some macro-oriented C or better yet, break out that assembler. For the larger chips with a little more headroom, C++ is a fun way to go, and is my preference.

Platform Disclaimer: Most of my readers will be far more productive on the .NET Micro Framework and the Netduino, FEZ Devices, or Gadgeteer. If you're not doing heavy speed-critical signal processing, you'll probably have more fun with NETMF and get from zero to application much more quickly. For people not using C# but who wish to continue with C/C++ on the AVR specifically, Arduino has most of these types of things figured out in its rich library. It's not really C++, but it's a good approach to developing on a subset of the AVR MCUs. If you're interested more in just getting something done specifically on the AVR, I recommend looking at that. Finally, if you want to write C on the metal, Atmel also makes their own AVR library which helps abstract away the differences between MCUs. I personally found that confusing to use, with many different ways to accomplish the same tasks, and a large number of poorly documented APIs to learn. They were C as well, and without great naming conventions on their part, it was next to impossible to get a ful picture of everything available in a particular problem domain. In my case, I specifically want to learn MCU programming without all that baggage, so I'm simply coding on the metal but using C++.

Ports and pins

This family of MCUs have 8*4 (32) General Purpose Input/Output (GPIO) pins. They can all be used for GPIO, but some ports can also be assigned different functions. Here's are the pin configurations for the PDIP and the TQFP/QFN/MLF surface mount versions from the data sheet. (There are other pages covering the tiny VFBGA and DRQFN versions, in case you wanted super tiny surface mount versions)

I'm using the PDIP version on the left. On that, you can see, for example, that pins 14 through 21 (port D) have the transmit (TXD) and receive (RXD) functions for the USARTs. When you use those pins for the USART, you can't use them for GPIO, so you need to be smart about which pins you use for which functions. (I've been doing a lot with port D and MIDI - more on that in a future post.) You can also see that the entire family of chips ATmega164A, ATmega164PA, ATmega324A, ATmega644A, ATmega644PA, ATmega1284, and ATmega1284P all share the same pin configuration and device layout. (and yeah, I'll admit that listing them all here was for search engines <g>). Where they differ is in memory. Here's the table from the same data sheet.

In this post, I'll concentrate on using Port A. As I previously mentioned, the MCU I'm using is the ATmega1284P, so I have a whopping (in MCU terms) available program size of 128K. That's as much total memory as the Commodore 128 computer sitting behind me on my desk, and that doesn't even count the 16K available RAM and 4k available EEPROM. In a nutshell, here's how that memory is used:

Flash: This is the memory used to store your program code. When you "program" the MCU, this memory is directly consumed by the instructions for your application.
EEPROM: This is where you can store persistent settings, like configuration set by the user of your end product.
RAM: Allocated variables, arrays etc. You can blow through 16K very quickly if you try and do things like you would on the desktop (like a lookup table of 16 bit values to make SIN calculations faster), so you need to be smart about that.

Now, back to pins and ports. The ATmega and ATxmega MCUs by Atmel (and possibly the ATtiny and others - I haven't checked) group their IO pins into ports. The ATmega1284 has four ports A, B, C and D, each of which has 8 pins. By grouping this way, a single 8 bit register can contain the digital information for each in in the port.

So, if you know the base address of Port A's pins data register is 0x20 (or 0x00, for reasons explained in the data sheet), you can find out the value of pin 2 using code like this:

#define PINA_ADDRESS 0x20



isHigh = (*PINA_ADDRESS) & 0b00000100;

You can set pin 2 to high using this code, assuming that all the pins were low before (this actually *toggles* pin 2):

#define PINA_ADDRESS 0x20

(*PINA_ADDRESS) |= 0b00000100;

After you set it, that bit of PINA will be 1 if the pin is high, and 0 if it is low, regardless of what your code actually sets it to when toggling.

You can see how using preprocessor defines like that makes the code easier to read, but still results in a really tiny program. By default, the AVR libraries include even nicer preprocessor macros to get to individual pins, but we're not using them here. Of course, I did oversimplify a little, at least in the second example. There are other things you must consider before just setting pin values.

Direction and Data Registers

When you want to use pins on a port, you should configure its pins as input or output. For Port A, this involves the DDRA (Port A Data Direction Register). This is another 8 bit register which defines the direction for each pin: 1 is output, 0 is input.

Also, when reading and writing values, you don't always use the same register.

You have to read the data sheet about 100 times to make sense of these groups. When compared to the xmega, I found the uses a bit opaque. So, here's my summary:

To mark a pin as input, write a 0 to the appropriate bit in the DDRx register.
To mark a pin as output, write a 1 to the appropriate bit in the DDRx register
To read the value of a pin, check the appropriate bit in the PINx register
To TOGGLE the value of a pin, write to the appropriate bit in the PINx register
- This means you need to read the pin value before you toggle it.

Beyond that, there are some other registers that affect the entire port. This table is useful for figuring out what they do.

Basic Implementation

Let's first look at an implementation that looks like C code in a CPP file. We'll use that as the benchmark for the rest of the application.

Creating the project

First, I assume you have Atmel AVR Studio 5.1 installed on your machine. If not, please refer to the two previous posts linked at the top of this post. I'm also going to be using a JTAGICE-compatible programmer and debugger here, also covered in that previous post.

Create a new project in AVR Studio 5.1. If you're running only 5.0, you won't see the C++ options unless you have the C++ add-in. Also notice how these show up under "C/C++" and not under the board-specific folders. We won't be using the board templates here.

I named the project AvrBlinkenLed.

The next step is to pick the processor. Make sure you pick the one you're using. I'm using the ATmega1284P. The easiest way to find your processor is to enter its model number in the search box at the upper right.

Once you select the processor, Visual Studio will load up the project template and put you right in the main .cpp file. You'll want to adjust a couple things before you do any real coding, however.

Setting clock speed and Debugger

Next, we'll need to set the clock speed. You could leave it at the default 1Mhz, as we're not doing anything special here. However, why not bump it up to 8Mhz? To do that, we'll need to make changes in a few places. First, we'll need to actually set the value on the chip. In this case, we only need to clear the multiplier fuse which forces the ship at 1MHz by default.

Go into Tools | AVR Programming. After a moment, the AVR Programming tool will come up. It'll look for your JTAG programmer and, if found, will display it in the tool list at the left and the found MCU in the Device drop down to its right. If it was not found, your JTAG programmer/ debugger is not set up correctly, or your board isn't connected. Refer to the manufacturer instructions to fix that before going any further.

If you only have the one JTAG programmer/debugger installed, and aren't doing any chaining of devices (if you're reading this post, you almost certainly are not) simply click the "Apply" button to pull back the MCU information. Click on the "Fuses" tab.

WARNING: Setting some fuses or lock bits can brick your MCU and require special high-power parallel programming to reset it. Be sure you completely understand the purpose of a given fuse or lock before you do anything with it.

I had already cleared the CKDIV8 fuse in my MCU. If you just got yours, it will be set. What this does is divide the 8MHz clock down so you get a CPU clock of 1MHz. Clear that fuse, and only that fuse, and then click the "Program" button on the right. Make sure if works.

While there, make sure the JTAGEN fuse is set so you can use the JTAG debugger. If not set, set it and program that one fuse setting.

Next, go into the project properties (right-click the AvrBlinkenLed project and select "Properties") and click the "Tool" tab. This is where you set up the programmer/debugger to use.

Pick the JTAG programmer from the list. Once you do that, change the interface on the right to JTAG so you can debug. By default, it is ISP (In System Programmer) which only allows programming. Then change the JTAG clock so it's some value lower than 8Mhz / 4.

Finally, we'll define a compiler constant in the main file. The F_CPU constant is a standard approach you'll see often. In fact, if you use some of the AVR libraries, they require that specific constant to be set.

/*

 * AvrBlinkenLed.cpp

 *

 * Created: 1/15/2012 4:21:24 PM

 *  Author: Peter.Brown

 */

#define F_CPU 8000000

//#include <avr/io.h>



int main(void)

{

    while(1)

    {

        //TODO:: Please write your application code

    }

}

That's the default template with the addition of the F_CPU constant. Also note that I commented out the io.h include. We're going to do things from scratch here. The code doesn't do anything yet, though, although it does compile.

A few more helpful constants and macros

One reason straight C code tends to be so efficient, is that there are almost no constants, enums, or variables in use for chip-specific stuff. Instead, most everything is done in the preprocessor, which ends up resolving down to pointer manipulation.

We're not taking that approach here, but we'll still use some constants to help us out.

Add a new include file to the project, named ATmega1284P.h

The file will contain the processor-specific constants and types we want to use. In this case, the addresses for the registers.

/*

 * ATmega1284P.h

 *

 * Created: 1/15/2012 4:41:26 PM

 *  Author: Peter.Brown

 */





#ifndef ATMEGA1284P_H_

#define ATMEGA1284P_H_



typedef volatile unsigned char register8_t;



#define PINA    (*(register8_t*) 0x20)

#define DDRA    (*(register8_t*) 0x21)

#define PORTA   (*(register8_t*) 0x22)



#endif /* ATMEGA1284P_H_ */

Once you do that, we have enough to be able to turn the LEDs on or off. We're going to light the LEDs in a pattern as shown in this photo. You can see from the little diagram on the board (under the RoHS symbol) that the LEDs are configured in current source configuration, so setting them to 1 will light them up.

Here's the code for the main file. Doing this will set the above pattern for the LEDS.

/*

 * AvrBlinkenLed.cpp

 *

 * Created: 1/15/2012 4:21:24 PM

 *  Author: Peter.Brown

 */

#define F_CPU 8000000



#include "ATmega1284P.h"



int main(void)

{

    DDRA = 0b11111111;

    PINA = 0b10101010;

 

    while(1)

    {

        //TODO:: Please write your application code

     

    }

}

In this code, I set all 8 pins to output, and then set alternated pins to 1 to set them to high (it actually toggles the pin value, but because they were all low (0) to begin with, this works). In a current source configuration, where the LEDs get their voltage from the MCU and the MCU is the source of the current, setting the pin to high will cause the LED to light. If they were in a current sink configuration, where the MCU provides ground reference, setting them to low (0) would light the LEDs. The LED class we create will support either configuration.

Deploying and Running

To deploy the code, first compile. You'll see output which states how small the code is (178 bytes total, wow!)

------ Build started: Project: AvrBlinkenLed, Configuration: Debug AVR ------

Build started.

Project "AvrBlinkenLed.cppproj" (default targets):

Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').

Target "CoreBuild" in file "C:\Program Files (x86)\Atmel\AVR Studio 5.1\Vs\Compiler.targets" from project "D:\Documents\Docs\Projects\AvrBlinkenLed\AvrBlinkenLed\AvrBlinkenLed.cppproj" (target "Build" depends on it):

    Task "RunCompilerTask"

        C:\Program Files (x86)\Atmel\AVR Studio 5.1\make\make.exe all

AvrBlinkenLed.cpp

        Invoking: AVR8/GNU C++ Compiler

        "C:\Program Files (x86)\Atmel\AVR Studio 5.1\extensions\Atmel\AVRGCC\3.3.1\AVRToolchain\bin\avr-g++.exe" -funsigned-char -funsigned-bitfields -O1 -fpack-struct -fshort-enums -g2 -Wall -c  -mmcu=atmega1284p   -o"AvrBlinkenLed.o" ".././AvrBlinkenLed.cpp"

        Finished building: .././AvrBlinkenLed.cpp

        Building target: AvrBlinkenLed.elf

        Invoking: AVR8/GNU C++ Linker

        "C:\Program Files (x86)\Atmel\AVR Studio 5.1\extensions\Atmel\AVRGCC\3.3.1\AVRToolchain\bin\avr-g++.exe" -o AvrBlinkenLed.elf  AvrBlinkenLed.o   -Wl,-Map="AvrBlinkenLed.map" -Wl,-lm   -mmcu=atmega1284p

        Finished building target: AvrBlinkenLed.elf

        "C:\Program Files (x86)\Atmel\AVR Studio 5.1\extensions\Atmel\AVRGCC\3.3.1\AVRToolchain\bin\avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock -R .signature  "AvrBlinkenLed.elf" "AvrBlinkenLed.hex"

        "C:\Program Files (x86)\Atmel\AVR Studio 5.1\extensions\Atmel\AVRGCC\3.3.1\AVRToolchain\bin\avr-objcopy.exe" -j .eeprom --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0 --no-change-warnings -O ihex "AvrBlinkenLed.elf" "AvrBlinkenLed.eep" || exit -j .eeprom --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0 --no-change-warnings -O ihex "AvrBlinkenLed.elf" "AvrBlinkenLed.eep" || exit 0

        "C:\Program Files (x86)\Atmel\AVR Studio 5.1\extensions\Atmel\AVRGCC\3.3.1\AVRToolchain\bin\avr-objdump.exe" -h -S "AvrBlinkenLed.elf" > "AvrBlinkenLed.lss"

        "C:\Program Files (x86)\Atmel\AVR Studio 5.1\extensions\Atmel\AVRGCC\3.3.1\AVRToolchain\bin\avr-size.exe" -C --mcu=atmega1284p  "AvrBlinkenLed.elf"

        AVR Memory Usage

        ----------------

        Device: atmega1284p

        Program:     178 bytes (0.1% Full)

        (.text + .data + .bootloader)

        Data:          0 bytes (0.0% Full)

        (.data + .bss + .noinit)

    Done executing task "RunCompilerTask".

Done building target "CoreBuild" in project "AvrBlinkenLed.cppproj".

Target "PostBuildEvent" skipped, due to false condition; ('$(PostBuildEvent)' != '') was evaluated as ('' != '').

Target "Build" in file "C:\Program Files (x86)\Atmel\AVR Studio 5.1\Vs\Avr.common.targets" from project "D:\Documents\Docs\Projects\AvrBlinkenLed\AvrBlinkenLed\AvrBlinkenLed.cppproj" (entry point):

Done building target "Build" in project "AvrBlinkenLed.cppproj".

Done building project "AvrBlinkenLed.cppproj".



Build succeeded.

========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

The next step is to take the hex file that was created and load that to the board via the JTAG programmer. Go under Tools | AVR Programming again, and select the "Memories" tab after hitting "apply" to pull up the ATmega we're using.

Select the hex file from your project. You can see where it's located on my file system. The programmer will remember this from project to project, so always double-check to make sure you're programming the right code. Once sure, click the "Program" button. You'll see the following status:

You should immediately see the output on your test board. If not, close the AVR Programming tool and hit the Reset button on your board.

Now, all of that is wonderfully efficient, but not particularly friendly or reusable. So, let's look at how to do this another way.

First Implementation in real C++

The C code is simple and very tight. However, once you get into a complex application, the code can get confusing and jumbled. The nature of a language like C requires extreme discipline to keep the code compartmentalized and reduce dependencies between the different modules. Often times, the developer will trade away some of that for the sake of performance or code size. The AVR libraries that come with AVR Studio include a fair bit of that.

To be clear, you can write very good code in C as long as you have discipline. You can also write crap code in C++, but the compiler and language give you a few more things to help you do the right thing.

The IOPort class

In my first version of this code, I created an IOPin class rather than IOPort. I did this because I wanted to make my library smell a bit like the NETMF libraries where you code against DigitalInput and DigitalOutput classes. However, that meant creating an instance of the class for each pin you wanted to manipulate - an entire class for 3 bits (literally, bits) worth of data. It also didn't allow me to group operations at the port level. So, in the version I'm presenting here, I went at it at the port level with the IOPort class.

First, create a header file named IOPort.h

/*

 * IOPort.h

 *

 * Created: 1/15/2012 5:43:58 PM

 *  Author: Peter.Brown

 */





#ifndef IOPORT_H_

#define IOPORT_H_



#include "ATmega1284P.h"



enum PinDirection

{

    DirectionInput = 0,

    DirectionOutput = 1

};



class IOPort

{

protected:

    volatile register8_t* _port;

    volatile register8_t* _pins;

    volatile register8_t* _ddr;

public:

    IOPort(register8_t* portRegister, register8_t* pinsRegister, register8_t* ddrRegister) :

        _port(portRegister),

        _pins(pinsRegister),

        _ddr(ddrRegister) {}

         

    void SetPortDirection(register8_t directionBits); 

    void SetPortValues(register8_t valueBits);

    void GetPortValues(register8_t &valueBits);



    void SetPinDirection(int pin, PinDirection direction);

    void SetPinValue(int pin, bool value);

    void GetPinValue(int pin, bool &value);

};







#endif /* IOPORT_H_ */

You can see the class has separate methods for working with individual pins versus the entire port. In that way, we can do bulk port operations and individual pin operations from the same class. We can get away with that here, unlike in the .NET Micro Framework, because we know that all the AVR pinsNow for the implementation. Create a code file IOPort.cpp

/*

 * IOPort.cpp

 *

 * Created: 1/15/2012 6:03:06 PM

 *  Author: Peter.Brown

 */



#include "IOPort.h"



void IOPort::SetPortDirection(register8_t directionBits)

{

    *_ddr = directionBits;

}

void IOPort::SetPortValues(register8_t valueBits)

{

    *_pins = valueBits;

}

void IOPort::GetPortValues(register8_t &valueBits)

{

    valueBits = *_pins;

}



void IOPort::SetPinDirection(int pin, PinDirection direction)

{

    // assumes pin is correctly in the range of 0..7

    if (direction == DirectionOutput)

        *_ddr |= (1 << pin);

    else

        *_ddr ^= (1 << pin);

}





void IOPort::SetPinValue(int pin, bool value)

{

    // assumes pin is correctly in the range of 0..7

 

    // if the pin was already high and we want it high, do nothing.

    // if the pin was already low and we want it low, do nothing.

    // if the pin was high, and we're requesting low, toggle it

    // if the pin was low, and we're requesting high, toggle it



 

    if (*_pins & (1 << pin))

    {

        // pin is currently high

     

        if (!value)

            *_pins = (1 << pin);    // toggle pin because we want it low

    }

    else

    {

        // pin is currently low

     

        if (value)

            *_pins = (1 << pin);    // toggle pin because we want it high

    } 

     

}



void IOPort::GetPinValue(int pin, bool &value)

{

    value = (bool)(* _pins & (1 << pin));

}

Note how writing a 1 to the pin doesn't set it high, it toggles it. That means we need to read the current value of the pin, and then decide whether it needs to be toggled or not.

This IOPort class doesn't support everything. For example, I haven't included here the code to set the pull-up resistors. I also didn't add anything optional to the constructor to set initial direction or values from that call. However, it works for our purposes in this example.

Supporting multiple types of processors

In the code I'm using for my own projects, I don't include the processor-specific include file in every class. Instead, I include a common include file which has a preprocessor constant for the processor I'm using and then makes a decision as to which processor-specific include file to pull in. I blatantly stole this idea from the AVR libraries, as it's a good one.

Lighting up some LEDs

Now to light up some LEDs. I very slightly changed the pattern so you can be sure you're seeing the newly flash firmware, and not the original version. Here's the new code for the main function.

/*

 * AvrBlinkenLed.cpp

 *

 * Created: 1/15/2012 4:21:24 PM

 *  Author: Peter.Brown

 */

#define F_CPU 8000000



#include "ATmega1284P.h"

#include "IOPort.h"



int main(void)

{

    //DDRA = 0b11111111;

    //PINA = 0b10101010;

 

    IOPort portA(&PORTA, &PINA, &DDRA);

 

    portA.SetPortDirection(0xFF);

    portA.SetPortValues(0b10101111);

 

    while(1)

    {

        //TODO:: Please write your application code

     

    }

}

Program it on the MCU and look at the LEDs. You should now see pins 0-3 lit up, as well as pins 5 and 7. This works because the pins were, by default, all low. Calling SetPortValues toggles all the values for that port. If you called it again with the same pattern, they'd all turn off.

I prefer the ATxmega approach

The ATxmega (the follow-on to the ATmega) has a couple different registers to accomplish the task of setting the pin value. One is OUTSET where any set bits cause the pins to go high. The other is OUTCLR where any set bits cause the pins to go low. In that way, you don't have to do a read-compare-modify cycle. If that chip were available in PDIP so creating DIY kits for other people who don't want to surface mount solder, I'd be in heaven.

As to size: if I comment out the Pin-specific functionality, in order to get a fair comparison with our original program, the program compiles to 320 bytes. Compare that to the 178 bytes of the macro-version. It's a bit under twice the size for this tiny program. Whether that's a concern to you is, well, your concern :) If you leave in the pin-specific functionality, you get around 510 bytes. On a processor with 128K, that's not a big deal, but if you're looking at a processor with only 2K total memory, that can certainly be an important distinction. At the different levels of optimization, I get the following program sizes:

Optimization level	Program Size in Bytes
None (-O0)	856
Optimize (-O1) default	512
Optimize more (-O2)	496
Optimize most (-O3)	496
Optimize for size (-Os)	484

The different optimization levels certainly make an impact on size. Beware, though, as sometimes optimization can make the code larger, or slower. It can also make it more difficult to debug or trace. I tend to leave the optimization on the default -O1.

In addition, you can definitely trim this down a bit by removing some of the conversions, the enum, and doing a little more optimization. You can even do a little inline assembly, but I'm not a big fan of the AVR G++ approach to that, using strings. I used to write a fair bit of inline assembly in Borland C++ for DOS, and to do that, you simply had an asm block with statements in it like asm { mov AX, AY }.

Without actually trying it, I suspect that the code to construct the string would take up more space than the inline assembly would give us back, so I'm going to leave it out of this example.

Abstracting Away LED Behavior

LEDs can be connected a two main ways: in current source or current sink configuration. I would like to create an LED class which properly works regardless of how you hook up the LEDs.

Create a header file named Led.h

/*

 * Led.h

 *

 * Created: 1/15/2012 7:12:19 PM

 *  Author: Peter.Brown

 */



#ifndef LED_H_

#define LED_H_



#include "ATmega1284P.h"

#include "IOPort.h"



enum LedConfiguration

{

    LedCurrentSource,

    LedCurrentSink 

};



class Led

{

protected:

    IOPort*                _port;

    LedConfiguration    _configuration;

    uint8_t                _pin;

         

public:

    Led(IOPort* port, uint8_t pin, LedConfiguration configuration) :

        _port((IOPort *)port),

        _configuration(configuration),

        _pin(pin) {};

         

 

    void TurnOn();

    void TurnOff();

};



#endif /* LED_H_ */

Next, create the implementation file Led.cpp. The code in this file will set the pin values based on whether or not we're in Source (1 to light) or Sink (0 to light) mode.

/*

 * Led.cpp

 *

 * Created: 1/15/2012 7:18:36 PM

 *  Author: Peter.Brown

 */



#include "Led.h"





void Led::TurnOn()

{

    _port->SetPinValue(_pin, (_configuration == LedCurrentSource));

}



void Led::TurnOff()

{ 

    _port->SetPinValue(_pin, !(_configuration == LedCurrentSource));

}

To make that work, we're going to need another type, so let's add the following to the processor-specific header file ATmega1284P.h. At the same time, we'll change the definition of register8_t to use this type.

typedef unsigned char uint8_t;

typedef volatile uint8_t register8_t;

I need uint8_t because I'm keeping the pin number in the class, and don't want to allocate a whole 16 bit int to hold a number between 0 and 7. Memory on these devices is even more scarce than program memory so you want to use small types to keep the stack small and the data (if you allocate any) small.

Why no New Operator?

You'll notice that I'm not using the new operator anywhere, instead I'm allocating everything as local variables. At some point, I may change that, but at least for now, the price isn't worth it. Adding in the new operator, and all the malloc stuff it requires, adds a huge amount of code to your application. By default, AVR G++ doesn't include it in so you can save that 4-10k.

The new main function looks like this:

/*

 * AvrBlinkenLed.cpp

 *

 * Created: 1/15/2012 4:21:24 PM

 *  Author: Peter.Brown

 */

#define F_CPU 8000000



#include "ATmega1284P.h"

#include "IOPort.h"

#include "Led.h"



int main(void)

{

    IOPort portA(&PORTA, &PINA, &DDRA);

 

    portA.SetPortDirection(0xFF);

    //portA.SetPortValues(0b10101111);

 

    Led ledA0(&portA, (uint8_t)0, LedCurrentSource);

    Led ledA1(&portA, (uint8_t)1, LedCurrentSource);

    Led ledA2(&portA, (uint8_t)2, LedCurrentSource);

    Led ledA3(&portA, (uint8_t)3, LedCurrentSource);

    Led ledA4(&portA, (uint8_t)4, LedCurrentSource);

    Led ledA5(&portA, (uint8_t)5, LedCurrentSource);

    Led ledA6(&portA, (uint8_t)6, LedCurrentSource);

    Led ledA7(&portA, (uint8_t)7, LedCurrentSource);

 

    ledA0.TurnOn();

    ledA1.TurnOn();

    ledA2.TurnOn();

    ledA3.TurnOn();

    ledA4.TurnOn();

    ledA5.TurnOn();

    ledA6.TurnOn();

    ledA7.TurnOn();



    while(1)

    {

        //TODO:: Please write your application code

     

    }

}

Rather than inherit LED from the port, as I did in the pin-based version in some other code I've written, I decided to have the LED simply take in an instance of the port. The LED class assumes you've already configured the LED pin as output, as that is an operation that is often done an entire port at a time. Again, another small concession to efficiency without sacrificing the main benefits of C++.

If you want to test that the led is properly toggling the values, uncomment the SetPortValues call there to give the port some initial values. Or, you can just make the LEDs toggle like we will in the next post.

At this point, if you run the application, you should see all eight LEDs lit

In the next post, we'll learn what it's going to take to blink these LEDs with a specified time interval.

Setting up for Developing and Debugging the AVR (ATmega1284P) with AVRStudio 5.1

Pete Brown — Fri, 13 Jan 2012 23:31:25 GMT

In the wee hours of the night, I've been continuing to learn how to develop for the various AVR family chips from Atmel. I also do a lot with NETMF, Netduino, and the .NET Gadgeteer, but sometimes (despite the pain!) it feels good to code right on the metal.

Introductory/getting started information for the AVR family is not always the easiest to find, so this post covers a few other important details I think you'll find helpful.

Select the MCU

MCUs vary wildly in capabilities. Which MCU you choose for tinkering isn't hugely important, but if you have any sort of project in mind, you'll want to try and narrow it down to a family. The programming model is not identical across different families, and capabilities can vary in significant ways. Here are a few things to consider:

Do I need to limit myself to those offered in a PDIP package in order to make it easy for DIY use? Most people in the DIY community are not able to solder the zillion pins on the smaller surface mount packages. The more powerful the chip (and I define "powerful" very loosely here) the harder it will be to find a PDIP package. In those cases, you may need to rely on a vendor's own carrier boards.
How many USARTS (sync/async serial communication) do I need? Serial is important for microcontroller to device communication
How many I/O pins to I need?
How speed-intensive is my code?
How much program memory do I expect to require

For this project, I chose the ATmega1284P. I chose this because

It is offered in a 40 PDIP, so it is DIY friendly
It is inexpensive at under $6 per unit in very small quantities.
It has the most memory of any AVR PDIP package MCU
It has two USARTs for serial communication
It supports SPI so I'll be able to use the SPI DACs I'm playing with
It supports JTAG programming and debugging

Note that speed wasn't really a concern. You'll be amazed at how much you can accomplish in native code on an MCU running at just a couple MHz. Amazing!

Whatever microcontroller you choose, make sure you know what clock speed it's running at. It's not as simple as buying a 20Mhz MCU and saying it's running at 20Mhz. By default, some of the MCUs run at 1MHz to make sure you can program them with anything. Beyond that, you can change the speed using "fuses" (flags set on the chip outside of your program memory), external clock sources, and code in your application.

For example, the development board I use (more on that in a moment) has an 8MHz crystal oscillator on the board. I had incorrectly assumed that the chip was running at 8MHz. However, I stumbled across the following in the datasheet for the chip:

Aha! So many things rely on you knowing the correct clock speed, that if you get it wrong, you'll find half your code simply fails.

Get the Data Sheets

In the case of Atmel, finding the data sheets is pretty easy. What's confusing is that there will often be more than one version floating around, and they're not always updated correctly. In addition, newer chips like the XMega I played with previously, have a fair number of errors in the data sheet.

The way to find the sheet is to go to the Atmel site and browse for your chip. First pick the architecture

Then, and the bottom left, pick the family

In this case, I chose "megaAVR" as that's the family the MPU I chose belongs to. It's next to my awesome MSPaint arrow there on the left.

Next, scroll down and pick the model that's written on your chip.

You can, of course, simply type your chip's name into Bing/Google and see what comes up. Just ignore all those third-party datasheet sites. They're the usual link bait crap you find on the internet.

You'll eventually make your way to the MCU's product page on the Atmel site.

These product pages are really nice, especially when you're doing the initial research to figure out which MCU to choose.

Finally, clock on the "documents" tab at the top. The first two documents for any given MCU will typically be a short summary, useful when investigating capabilities, and then a a full data sheet.

Now, here comes the fun part with Atmel. Make note of the various MCUs listed in the data sheet. That means they all follow the same design, but differ in something relatively trivial like the amount of program or flash memory on board. Now, look up the data sheets for a couple of those and see if they're any later than this one. Atmel doesn't always do a good job of making sure the data sheets make it out to all the right places on their site. It'll only take a moment.

With the MCU chosen, the next step is to buy or build something to host it.

Optionally, Pick up a Development Board

When getting started, using a development board is almost always the easiest approach. Atmel makes a number of nice development boards for their MCUs. One great thing about them is that the development environment has templates and examples build around those.

You can also find relatively inexpensive development boards on ebay. My experience with those has been pretty spotty: if it works, awesome. If it doesn't work, support is pretty non-existent and the language barrier makes self-help on the sites almost impossible.

Despite the lack of direct support for them in AVR Studio, I'm really partial to the Mikroelektronika boards. They are extremely well made, and feature-rich without getting in your way. This EasyAVR6 is one that I put on my Christmas list and found under the tree on December 25 :) The board is not tiny, it's about the size of a mini ATX motherboard. Also note that it does not come with the two LCD screens, those must be purchased separately from Mikroelektronika. They're inexpensive enough, though.

Considerations when picking a board:

Does it support the MCU(s) I plan to use?
Is there native support for it in my dev environment? It's not necessary, but it removes some barriers to getting started
Does it break out all the pins in a way that is easy to use? In the AVR6, the pins are all broken out in the headers on the right
Does it break out key features in ways I plan to use them (RS-232 connector, display, buttons, LEDs)
Does it include debug LEDs so I can easily see the status of any pin? (not necessary, but VERY helpful)
Is it built well, well-supported, and easy to use?

You can go with less expensive boards, of course. MikroElektronika makes a much smaller Ready for AVR board which supports the 40 pin AVR chips like this one. It doesn't have any debug LEDs or buttons, but it has all the required oscillator circuitry and pin headers. It also supports USB deployment, but does not include a JTAG header for debugging. This is not a show-stopper, but I personally consider it critical for non-trivial work.

Here's an example of the debug LEDs in use on my board

Each LED on the left corresponds to one pin. They're labeled so I can easily see that Port A, Pin 0 and Pin 4, and Port D pins 2 and 3 are all high. This is incredibly helpful when writing your applications.

Whatever development board you choose, you'll ideally want to make sure it breaks out the interface for debugging the MCU, so you can attach a debugger to it.

Get a Debugger and Programmer

Most development boards include nice on-board USB programming. One thing none of them provide is any sort of USB debugging. For those of us used to single-stepping through code and adding breakpoints, inspecting values, etc., this can be a real step backwards in usability.

Without a debugger, all you can do is debug using tricks like blinky lights and (eventually) outputting messages to an LCD (but that comes MUCH later). It's time-consuming and can be frustrating.

For AVR programming in AVR Studio 5.1, one of the best consumer debuggers is the JTAGICE Mk3 from Atmel. The problem is, this thing costs $300!

There is one good chinese clone of this device. It's a reverse engineering of the protocol, not a blatant copy like some others. I recommend this one above all else. It's called the JTAGICE mkII-CN by Mcuzone. Make sure you get the red-case one branded by Mcuzone, and none of the other copies. It runs around $80. Get it shipped DHL, don't use China Post.

I did a quick ebay search on JTAGICE and crossed off the ones I do not recommend getting. Notice how one of those is the red box. It doesn't say "mcuZone" on it, so it may very well be a clone. You want one which says mcuZone and has the serial number tag on the bottom. That version comes build for use with AVR Studio 4, but includes a firmware update to work with AVR Studio 5.

Some of the other units are blatant copies of other people's IP, so I'd rather not support those.

Again, get it shipped DHL even though that costs a bit more. It's much faster and far more reliable.

You'll also need to make sure the test board you use has a debug port of some sort. For the larger AVR chips, that will almost always be JTAG, although there are other options.

Set up the IDE

AVR Studio 5.1 is build on Microsoft Visual Studio 2010 Isolated Shell. That means current Visual Studio developers will feel pretty comfortable with the IDE.

I previously covered using AVR Studio 5 in this blog post. In that one, I used the Ready for XMEGA board. That's a great board, but the XMEGA is a surface mount device. If surface mount isn't a concern, I highly recommend it as that chip has a lot of great capabilities and that board is nice and inexpensive…and includes a JTAG deployment/debugging report.

Atmel has released a beta of version 5.1. I found the link to that on the avrfreaks AVR Studio 5 forum. Be sure to visit there to get it, as the links change, and there may be a later version out by the time you read this.

Version 5.1 supports C++ right in the box, which was key to what I want to do. Note, however, that if you go C++, you're pretty much on your own. All the templates are for C and/or assembly. I was ok with that, though, as I actually found it easier to learn everything by discarding the AVR software framework that the templates use.

Looks familiar, doesn't it? That's a MIDI to CV project I've been working on. The AVR library I'm building is from scratch, primarily because I want to learn the chip without someone else's framework obscuring the details. Oh, and because I want to write C++ :) Still, the optimized byte size of this app so far is about 2k. In this screen shot, I had turned optimization off as I was trying to figure out why JTAG wasn't working. Speaking of that…

Important IDE Settings for JTAG Debugging

The external hardware debuggers are pretty much the only choice when it comes to actually debugging the chip. It's things like this that make you realize just how much the .NET Micro Framework is doing for you behind the scenes.

JTAG debugging has some important considerations with regard to the speed it runs at. This one tripped me up for quite a while. Remember earlier I said you need to know what clock speed you're running the MCU at? Here's one place where it makes a huge difference.

Notice the JTAG clock slider, and the note under it. If JTAG debugging isn't working, here's one place to check. By default, the slider was set at 1MHz. By default, the MCU was also running at 1MHz. So, once I slid the slider down to around 200Mhz (which was automatically corrected to the multiplied value you see above), JTAG debugging started working! Yay!

One you have that, you can set breakpoints and single-step through your code just like you thought you should. If you bump up the CPU speed on the processor, be sure to come back here and bump this up as well, so you get the most speed out it.

Windows Client Developer Roundup 086 for 1/11/2012

Pete Brown — Thu, 12 Jan 2012 01:02:35 GMT

Note that I've started breaking the Netduino, Electronics, Robotics, Synthesizer and similar content into a new roundup series called the Maker Geek Roundup.

Shout-Outs

Give us your feedback on Visual Studio 11 etc. and receive a gift! (Visual Studio Blog)

Windows 8 and WinRT/Metro General

Windows 8 - First Apps Contest (Dave Isbitski)
When Metro design falls off the tracks (Kelly Sommers)
SharpGIS | Make your Windows 8 Video App use the PlayTo feature (Morten Nielsen)

XAML Technologies (Silverlight, WPF, WinRT Metro XAML)

"Physamajig" for Windows 8 (Andy Beaulieu)
Building an Augmented Reality XAML control (Morten Nielsen)

WinJS / JavaScript and HTML Applications for Windows Metro

Setting up your first use of the Animation library in WinJS (Adam Kinney)
No Alert in WinJS! Use console or MessageDialog instead (Adam Kinney)

Direct X Technologies (DirectX, XNA, WinRT DirectX, General GPU and Game Programming)

Getting started with Metro style DirectX (Bob Taco Industries)
XNA 4.0 Shader Programming #1-Intro to HLSL, Ambient light (digitalerr0r)
XNA 4.0 Shader Programming #2-Diffuse light (digitalerr0r)
XNA 4.0 Shader Programming #3-Specular light (digitalerr0r)

C++ and Native Development

Compiler Security Enhancements in Visual Studio 11 (SDL Team)

Visual Studio and .NET General

Visual Studio 11 Platform Tooling Advances (Soma)
- Good DirectX content in this one as well
ManagedMsiExec sample app shows how to use the Windows Installer API from managed code (David Anson)

NUI (Kinect, Surface, More)

Microsoft Kinect coming to Windows on February 1st, up for pre-order now! (KinectHacks)
Kinect Apps - ensuring Kinect Runtime is installed (Rob Relyea)
Examples of depth API improvements coming in v1 (Rob Relyea)
Kinect + 3D = Fusion4D (Greg Duncan)
Connecting your Netduino to your Kinect (Greg Duncan)
Kinect Fundamentals #4: Implementing Skeletal Tracking | digitalerr0r (digitalerr0r)
Kinect & HTML5 using WebSockets and Canvas (Vangos Pterneas)

Off-Topic Fun

Poorly Drawn Lines - When It's Cold (for all the ADD types)
xkcd: Game AIs (xkcd)
Benoit Mandelbrot: Master of seduction (SMBC)
- and Saturday Morning Breakfast Cereal
- and Saturday Morning Breakfast Cereal
Grammar! (SMBC)
Lego Skeleton inside Mini Figure (for the purists) (MoistProduction)

Threading Considerations for Binding and Change Notification in Silverlight 5

Pete Brown — Tue, 10 Jan 2012 16:48:00 GMT

A reader of my Silverlight 5 book recently reached out to me about threading and why I create some objects on the UI thread in the examples. We discussed some of the reasons, but I felt this would be a good topic to share with everyone. In fact, this is one area where it would have been fun to go into great detail in my book, but there simply wasn't the space. Threading and cross-thread exceptions can be a bit of a mystery to new Silverlight and WPF developers.

Background

The user interface in Silverlight runs on a thread commonly known as the UI Thread. Any code you create in the code-behind, and any code it calls all the way down the chain, unless it explicitly creates another thread, runs on this same UI thread. It's not at all uncommon to see Silverlight and WPF applications which never explicitly create a second thread, but do make calls to other services which create background threads for processing.

There are many other examples, but networking is one place where the Silverlight .NET Framework explicitly creates (or uses) different threads. Not all calls return on the UI thread.

Threads other than the UI thread are not allowed to access or manipulate UI objects. If they attempt to do so, the runtime throws an Invalid Cross-Thread Access exception. It looks like this:

But wait! I wasn't accessing any UI objects from my code. What gives?

It's not always obvious that you're interacting with UI objects on the UI thread, though. Here's the stack trace from this particular exception:

{System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. --->

  System.UnauthorizedAccessException: Invalid cross-thread access.

   at MS.Internal.XcpImports.CheckThread()

   at MS.Internal.XcpImports.GetValue(IManagedPeerBase managedPeer, DependencyProperty property)

   at System.Windows.DependencyObject.GetOldValue(DependencyProperty property, EffectiveValueEntry& oldEntry)

   at System.Windows.DependencyObject.UpdateEffectiveValue(DependencyProperty property, EffectiveValueEntry oldEntry, EffectiveValueEntry& newEntry, ValueOperation operation)

   at System.Windows.DependencyObject.RefreshExpression(DependencyProperty dp)

   at System.Windows.Data.BindingExpression.SendDataToTarget()

   at System.Windows.Data.BindingExpression.SourcePropertyChanged(PropertyPathListener sender, PropertyPathChangedEventArgs args)

   at System.Windows.PropertyPathListener.ReconnectPath()

   at System.Windows.Data.Debugging.BindingBreakPoint.<>c__DisplayClass4.<BreakOnSharedType>b__3()

   --- End of inner exception stack trace ---

   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)

   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)

   at System.Delegate.DynamicInvokeImpl(Object[] args)

   at System.Delegate.DynamicInvoke(Object[] args)

   at MainPagexaml.BindingOperation(Object BindingState, Int32 , Action )}

This stack trace was generated by trying to raise a PropertyChangedNotification when I manipulated a model object from a background thread. So, it was obvious that I was working with an object on the background thread, but it wasn't obvious that I'd get a cross-thread exception (well it was in this case, as I contrived the example). If you consider a larger application where you have division of ownership for different pieces, a client-side developer may simply work with your viewmodel, but not realize you're farming some work out to another thread.

I wrote a blog post back in 2010 ( Essential Silverlight and WPF Skills: The UI Thread, Dispatchers, Background Workers and Async Network Programming) explaining some of the ways to work with threads and dispatching. I didn't have SynchronizationContext in there at the time, but it's something I tend to use a lot these days.

Let's take a look at a few of the common scenarios and how it works with threading.

Common Scenarios

All of these scenarios make use of a simple Customer class with a single property:

namespace SilverlightThreadingExample.Model

{

    public class Customer : Observable

    {

        private string _firstName;

        public string FirstName

        {

            get { return _firstName; }

            set { _firstName = value; NotifyPropertyChanged("FirstName"); }

        }

    }

}

The customer is observable that is, it notifies any listeners when properties change. While not necessary, I encapsulated the observable code in this base class. You could, instead, put the implementation in a partial class if you wanted to make sure your model object's signature from your ORM or whatever remains the same as it was on the server.

using System.ComponentModel;



namespace SilverlightThreadingExample

{

    public class Observable : INotifyPropertyChanged

    {

        public event PropertyChangedEventHandler PropertyChanged;



        protected void NotifyPropertyChanged(string propertyName)

        {

            if (PropertyChanged != null)

                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

        }

    }

}

This is actually a pretty typical approach to handling INotifyPropertyChanged. There are even more robust versions out there which use lambdas and reflection to help avoid passing in strings, but they ultimately come down to raising the PropertyChanged event. Many of them also fail to work properly in cross-thread situations.

I expose the Customer class and a collection of customers from a ViewModel class.

namespace SilverlightThreadingExample.ViewModel

{

    public class CustomerEntryViewModel : Observable

    {

        private Customer _currentCustomer;

        public Customer CurrentCustomer

        {

            get { return _currentCustomer; }

            set { _currentCustomer = value; NotifyPropertyChanged("CurrentCustomer"); }

        }



        private ObservableCollection<Customer> _customers = new ObservableCollection<Customer>();

        public ObservableCollection<Customer> Customers

        {

            get { return _customers; }

        }



        public void LoadCustomersOnSameThread()

        {

            LoadDummyData();

        }



        private void LoadDummyData()

        {

            _customers.Add(new Customer() { FirstName = "Pete" });

            _customers.Add(new Customer() { FirstName = "Jon" });

            _customers.Add(new Customer() { FirstName = "Tim" });

            _customers.Add(new Customer() { FirstName = "Scott" });

            _customers.Add(new Customer() { FirstName = "Andy" });

            _customers.Add(new Customer() { FirstName = "Blaine" });

            _customers.Add(new Customer() { FirstName = "Jesse" });

            _customers.Add(new Customer() { FirstName = "Rey" });



            _currentCustomer = _customers[0];

        }



    }

}

Finally, the UI is bound to those classes. The DataContext for the UI (which will be set in code-behind) is the ViewModel.

<UserControl x:Class="SilverlightThreadingExample.MainPage"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

    mc:Ignorable="d"

    d:DesignHeight="400" d:DesignWidth="600">



    <Grid x:Name="LayoutRoot" Background="White">

        <Grid Width="500">

            <Grid.ColumnDefinitions>

                <ColumnDefinition Width="*" />

                <ColumnDefinition Width="250" />

            </Grid.ColumnDefinitions>



            <ListBox x:Name="CustomerList"

                     Grid.Column="0" Margin="10"

                     ItemsSource="{Binding Customers}"

                     SelectedItem="{Binding CurrentCustomer, Mode=TwoWay}">

                <ListBox.ItemTemplate>

                    <DataTemplate>

                        <TextBlock Text="{Binding FirstName}" />

                    </DataTemplate>

                </ListBox.ItemTemplate>

            </ListBox>



            <StackPanel Grid.Column="1">

                <TextBox x:Name="FirstNameField" Margin="10"

                         DataContext="{Binding CurrentCustomer}"

                         Text="{Binding FirstName, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" />



                <Button x:Name="AddCustomer"

                        Content="Add Customer from UI Thread"

                        Height="30" Margin="5"

                        Click="AddCustomer_Click" />

                <Button x:Name="AddCustomerSecond"

                        Content="Add Customer from Second Thread"

                        Height="30" Margin="5"

                        Click="AddCustomerSecond_Click" />

                <Button x:Name="ChangeNameFromSecondThread"

                        Content="Change Name from Second Thread"

                        Height="30" Margin="5"

                        Click="ChangeNameFromSecondThread_Click" />

            </StackPanel>



        </Grid>

   

    </Grid>

</UserControl>

The code-behind looks like this

using System.Windows;

using System.Windows.Controls;

using SilverlightThreadingExample.ViewModel;

using System.Threading;

using SilverlightThreadingExample.Model;



namespace SilverlightThreadingExample

{

    public partial class MainPage : UserControl

    {

        CustomerEntryViewModel _vm;



        public MainPage()

        {

            InitializeComponent();



            CreateViewModelOnUIThread();

        }





        private void CreateViewModelOnUIThread()

        {

            _vm = new CustomerEntryViewModel();



            _vm.LoadCustomersOnSameThread();



            DataContext = _vm;

        }





        private void AddCustomer_Click(object sender, RoutedEventArgs e)

        {

        }





        private void AddCustomerSecond_Click(object sender, RoutedEventArgs e)

        {

        }





        private void ChangeNameFromSecondThread_Click(object sender, RoutedEventArgs e)

        {

        }





    }

}

The methods are named to keep the context clear in this example. I wouldn't expect you to name your VM instantiation/locator method "CreateViewModelOnUIThread", for example.

Now let's look at those scenarios.

Changing a property value from a background thread

Often in an application, you have a class which is used in UI binding (an entity/model object) but still need to modify a property from code. Sometimes, you need to do that from a background thread. For example, you make a network call to get an updated price for an item. You will get a cross-thread access error when the class raises change notification events from that property setter. If the class is truly POCO (Plan Old CLR Object) and doesn't do any change notification or other event raising, you'll be fine. If, however, change notification is involved, you'll get the cross-thread exception.

Assuming the same Customer and Observable classes defined above, and the same XAML UI, the following code in the code-behind will throw that exception.

private void ChangeNameFromSecondThread_Click(object sender, RoutedEventArgs e)

{

    Thread t = new Thread((o) =>

        {

            _vm.CurrentCustomer.FirstName = "UpdatedFromSecondThread";

        });



    t.Start();

}

The exception doesn't happen when you set the property value; that's perfectly acceptable. It happens here, at the highlighted line:

protected void NotifyPropertyChanged(string propertyName)

{

    if (PropertyChanged != null)

        PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

}

So, what are the options for working around this? Let's consider two common approaches.

Approach 1

The first approach is to do the whole property change from the UI thread. To do this, simply wrap the property set code with a call to the dispatcher. You can use either the Dispatcher object, or if you keep a copy of the SynchronizationContext around, use that.

Here's some example code which implements this. The code looks a bit silly because I'm forcing a background thread. However, pretend that the background thread is a given and you need to work from it (again, the callback from a network call or something.)

private void ChangeNameFromSecondThread_Click(object sender, RoutedEventArgs e)

{

    Thread t = new Thread((o) =>

    {

        Deployment.Current.Dispatcher.BeginInvoke(() =>

            {

                _vm.CurrentCustomer.FirstName = "UpdatedFromSecondThread";

            });

    });



    t.Start();

}

This approach works well, but requires the calling code to handle all the dispatching. If you have a number of properties to change in different bits of code, it gets a bit cumbersome. Let's look at another approach.

Approach 2

The real problem is the property change notification, so the the second approach is to dispatch just the change notification to the UI thread.

You can put this code into the Observable base class in order to avoid repeating it throughout all your classes.

// Code-behind

// ----------------------------------------------





// this version throws an exception if the Observable base class isn't doing thread checking

private void ChangeNameFromSecondThread_Click(object sender, RoutedEventArgs e)

{

    Thread t = new Thread((o) =>

        {

            _vm.CurrentCustomer.FirstName = "UpdatedFromSecondThread";

        });



    t.Start();

}





// Observable

// ----------------------------------------------





using System.ComponentModel;

using System.Windows;



namespace SilverlightThreadingExample

{

    public class Observable : INotifyPropertyChanged

    {

        public event PropertyChangedEventHandler PropertyChanged;



        protected void NotifyPropertyChanged(string propertyName)

        {

            if (PropertyChanged != null)

            {

                if (Deployment.Current.Dispatcher.CheckAccess())

                {

                    PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

                }

                else

                {

                    Deployment.Current.Dispatcher.BeginInvoke(() =>

                    {

                        PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

                    });

                }

            }

        }

    }

}

Note how I first check to see if we have access to the UI thread using the CheckAccess call. If we do, there's no reason to incur the overhead and delay of a dispatcher call. However, if we are running on the background thread, then the call is dispatched to the UI thread. In either case, we avoid the errors cause by cross-thread property change notification.

Next up: Collections

Populating an ObservableCollection from a networking return call

A more robust Observable base class like this won't help with collection change notification (WPF 4.5 has a great solution for that using BindingOperations.EnableCollectionSynchronization, but unfortunately Silverlight does not).

Most applications make networking calls to get information from some resource on an intranet or out on the web. In Silverlight (and WPF), it's common practice to populate an ObservableCollection with the results from those calls. The ObservableCollection class is nice because it implements INotifyCollectionChanged and raises an event whenever items are added to or deleted from the collection, or when the collection is cleared. It's this notification that enables the various items controls and grids in the UI to stay in sync with the items in the collection.

This version is very similar to what we saw with individual properties earlier. That's because, it's really the same problem: we're trying to notify the binding system across threads.

private void AddCustomerSecond_Click(object sender, RoutedEventArgs e)

{

    Thread t = new Thread((o) =>

    {

        var cust = new Customer() { FirstName = "AddedFromSecondThread" };

        _vm.Customers.Add(cust);

    });



    t.Start();

}

Note that the problem exists regardless of where you actually create the customer. For example, this code will also fail:

private void AddCustomerSecond_Click(object sender, RoutedEventArgs e)

{

    var cust = new Customer() { FirstName = "AddedFromSecondThread" };



    Thread t = new Thread((o) =>

    {

        _vm.Customers.Add(cust);

    });



    t.Start();

}

The reason is, again, it's not the object access that is causing the cross-thread exception, it's the collection changed notification that's full of hate here.

So, how do you get around this? Unless you want to create your own ObservableCollection type class for Silverlight, you'll need to dispatch all collection add calls. Luckily, you'll typically have fewer of these scattered throughout the application, so it's not quite so onerous.

The code to implement this is just another easy call to the dispatcher (or SynchronizationContext, if you prefer).

private void AddCustomerSecond_Click(object sender, RoutedEventArgs e)

{

    // you can create customer on any thread

    var cust = new Customer() { FirstName = "AddedFromSecondThread" };



    Thread t = new Thread((o) =>

        {



            // dispatch to UI thread to add it to the collection. You can't

            // access the observable collection x-thread

            Deployment.Current.Dispatcher.BeginInvoke(() =>

                {

                    _vm.Customers.Add(cust);

                });

        });



    t.Start();

}

If you're going to run from an unknown state, be sure to call CheckAccess to see if you really need to do the dispatching. In this case, I know I'm always going to be on a background thread, so I don't bother.

Summary

The intent here was to show a few of the common threading pitfalls in Silverlight (and WPF) applications, specifically in the context of change notification. In most code, it's easy to tell when you're accessing objects cross-thread, but change notification is a somewhat behind the scenes operation, so it's not always obvious.

For property change notification, the solutions were:

Dispatch the entire property change operation to the UI thread
Update the NotifyPropertyChanged code to check to see which thread it's running on, and then dispatch the event as appropriate

Either way works, but I prefer the update to the NotifyPropertyChanged method.

For collection change notifications in Silverlight, the solutions are:

Create (or find) an implementation of ObservableCollection which does the cross-thread checking. The reason this isn't built-in is change notification happens often, and dispatching each and every change notification can be a real performance drain. That's also why WPF has a separate and optimized solution. You'd need to enable batching to avoid the overhead of hundreds of dispatch calls.
Dispatch the entire collection update when you're running on a background thread.

In contrast to the property change notifications, for collection change, I prefer to dispatch the entire call. If you're adding 1 object or 100, you'll still get only one dispatch call, so performance is better.

The Task Parallel Library in WPF, and the subset of it in Silverlight also offer some alternative approaches to handling cross-thread work. Similarly, the async and await keywords in .NET 4.5 and Windows 8 XAML can also come into play. More on those in the future.

Silverlight Reporting Open Source Printing/Reports Example Updated for Silverlight 5

Pete Brown — Mon, 09 Jan 2012 20:44:30 GMT

I recently posted an updated version of Silverlight reporting on codeplex. Here's the overview.

This project, a unofficial project by Pete Brown of Microsoft, provides a a very basic framework for building simple, short, multi-page reports using Silverlight 5.

The intent is not to be an all-encompassing reporting solution, or a solution for large reports. Instead, this is a set of code you can build upon to create short (2-5 page) reports from your Silverlight applications.

Currently the sample consists of the full source code of a simple report writer. It includes:

automatic pagination
support for line items of varying height
total page count
templating
page headers and footers
report footer with support for calculated fields
events to allow hooking into printing at various stages

Latest Release

Version information changed to use semantic versioning. This vesion is numbered: 1.0.0-alpha.3

Now targets Silverlight 5
Added ability to specify postscript (vector) printing. The selected driver must support PostScript or this setting will have no effect.
Fixed issue with not being able to re-print the report. (and fixed leaky event handlers)
Added null check on templates

This is still alpha, and is a minor project. Expect bugs. Report them when you do. Offer fixes if you can :)

Get the latest release here.

MFOS Synth 7: Front Panel Update (Knobs and started wiring)

Pete Brown — Sun, 08 Jan 2012 06:19:46 GMT

Today, I started wiring the front panel.

Over the next several months I'll be building what is definitely my most complex electronics project to date: the MFOS (Music From Outer Space) Sound Lab Ultimate, Ultimate Expander and (if Santa brings one) Sound Lab Mini-Synth Mark II, likely all in the same home-made wooden case, side by side. The Ultimate and Expander are together a 3 oscillator monophonic true analog synthesizer with filters, envelopment generator, ring modulator, sample and hold and more. You patch between the different logical modules using banana cables, so it's a bit of a self-contained modular synthesizer. The Mark II is smaller, newer, and has a few fewer features, but a sound of its own. You also patch that with banana cables, and can integrate the two. This blog post is another in the series. Previous posts include:

MFOS Synth 1: Built the Power Supply

MFOS Synth 2: Some main synthesizer board work

MFOS Synth 3: Starting the Front Panel

MFOS Synth 4: Resistors all soldered

MFOS Synth 5: Trimmers and some capacitors in place

MFOS Synth 6: PCB Complete

I received a shipment from Small Bear Electronics. They had the 24mm Alpha 1M and 100K audio taper pots back in stock, so I ordered a few. I liked the smaller pots, but not how they wiggled in the holes no matter how much I tightened the nuts. I didn't feel like making spacers for them.

I also decided which control knobs I wanted to use. I was really torn as I liked the violet knobs both in size and style, but I really disliked how they showed the pot washer and nut. It just looked too DIY with those showing for each pot. Instead, I went with the other one I liked: the same style that's on my Moog slim phatty.

At Small Bear, these are Synth Pointer #4. I cleaned them out, and actually have a few on backorder.

With all the potentiometers in place, I decided to start some of the front panel wiring. Ray has a good diagram on his site showing the wiring. I printed that out, and as he recommended in the build notes, I took a marker and colored each wire as I completed it.

From the diagram, you can see, I've completed almost 1/2 the rear panel wiring. Here's the panel.

You can also see that I have a number of SPDT and DPDT where the plans call for SPST and DPST switches. I simply couldn't find a decent price on the latter, and just substituted the double throw switches. I'll wire them as though they were ST.

I decided to have all the intra-panel wiring gray. I'll use other color wires for connecting to the board, but the wires on the panel are easy to trace by eye (I know, famous last words).

Before I can do too much more with the front panel, I need to do the following:

Fabricate and install a few brackets to hold the grounded aluminum shield in place. Ray did this with the Mark II build, and I really like the idea.
Create a few LED holders (also like Ray did on the Mark II)

The Mark II is Ray's latest creation. Being able to incorporate some of the ideas from that into the Sound Lab Ultimate is fortunate. I'll do the same with the expander and the Mark II, both of which are waiting on my desk to be part of this one large synthesizer.

Oh, and tried out some new solder today: the recommended one from Kester. It smokes a lot more, but seems to let out less flux. Folks seem to swear by it, but I don't see a lot of difference right now. We'll see once I use it for component soldering.

Pete Brown's Blog (POKE 53280,0)

Maker Geek Roundup 007 for 2/8/2012

3d Printing and CAD/CAM/CNC

.NET Gadgeteer

.NET Micro Framework General (Netduino, GHI FEZ, etc.)

Arduino

Other Micro Controllers (PIC, AVR, ARM, BeagleBoard, and more)

General Electronics and Hardware Hacking

Robots and Robotics Studio

Clocks

Retro Computing and Commodore!

Windows Client Developer Roundup 087 for 2/9/2012

Windows 8 and WinRT/Metro General

XAML Technologies (Silverlight, WPF, WinRT Metro XAML)

DirectX Technologies (DirectX, XNA, WinRT DirectX, GPU and Game Programming)

C++ and Native Development

Visual Studio and .NET General

NUI (Kinect, Surface, More)

Off-Topic Fun

Creating Big Silverlight Windows and Getting Monitor Resolutions and Positions with PInvoke

Creating the Window

Positioning and Sizing the Window

Getting Display Informatin Using PInvoke

Positioning and Sizing the Window

Position Window on Primary Display

Position Window on Secondary Display

Make a window take up all Display Space

Position Main Window on a Named Display

Summary

The Commodore 64 Emulator: Emulating Pointers in a sandbox when the real thing is not allowed

How Pointers Work

How pointers are used in Frodo

The Simulated Pointer

Operator overloading and Offsets

Converting Strings

A Structure, not a Class

Summary

Event Handler Memory Leaks, Unwiring Events, and the WeakEventManager in WPF 4.5

The Problem

Basis for Comparison

Solution 1: Unwire Your Event Handlers

Solution 2: Weak Events

Summary

The .NET Gadgeteer Diaper Alarm Part 1 (Moisture Sensor)

First Iteration

Hardware

Yee Old Test Subject

Software

Le Code

Second Iteration - Configuration

Potentiometer approach

Summary

The n00b filter: Bad UX at its Finest in Eagle PCB

Maker Geek Roundup 006 for 1/25/2012

3d Printing and CAD/CAM/CNC

.NET Gadgeteer

.NET Micro Framework General (Netduino, GHI FEZ, etc.)

Arduino

Other Micro Controllers (PIC, AVR, ARM and more)

General Electronics and Hardware Hacking

Robotics and Robotics Studio

Clocks

Synthesizers, MIDI and Electronic Instruments

Photography

General Maker

Retro Computing and Commodore!

Misc Geek

Just Awesome

Now, more than ever, you need a designer

Knowing Your Limits

Modern Development

Is it Customer-Facing?

Just go Find Some Free Icons

Who is On Your Team?

Arduino The Documentary

My First Real PIX-6T4 Game: Sixty4Racer

Concept

GamePlay

Progression

Goals