WPF-Blogger.com [Language: en]

Marketplace now open in 5 new markets

Windows Phone Dev Blog — 2012-02-03T18:02:28

I’m happy to report that the Windows Phone Marketplace is now officially open for business in 5 new markets around the world—Argentina, Indonesia, Malaysia, Peru, and the Philippines. We can’t wait to see all the great new apps you’ll create and publish for customers there.

As I mentioned a few weeks ago, if you’d like your existing apps to reach Windows Phone owners in these new places, just log into App Hub and select them from the list—or choose “worldwide” if you want your app to appear in all 41 of the markets Marketplace is now available in. (You’ll need to do this even if you’ve previously opted to make your app available globally.) Here’s a quick walkthrough.

Just a reminder that apps submitted to the Marketplaces for Indonesia, Malaysia and China (which is accepting apps but not yet open to consumers) will be subject to additional requirements due to local laws, regulations, or norms. For more details, see the Application Certification Requirements. If your app fails certification because of these additional requirements, you’ll need to update and resubmit it, or uncheck the submission boxes for those markets.

That’s it for now.

Complimentary Copies

Charles Petzold — 2012-02-02T18:00:00

When an author gets a book published, the publisher generally gives the author 10 complimentary copies of the book. Usually the author signs these books and gives them to all his friends, but then he has 7 or 8 copies still left over, and these tend to gather dust on the bookshelves of the author's home.

... more ...

Windows 8 Touch Events Interactions

Charles Petzold — 2012-02-01T13:00:00

During the week in September that I was attending the Microsoft Build conference and learning all about Windows 8, only one topic made me gloomy: This was the Windows 8 implemention of the Manipulation events. These events provide a high-level application programming interface to touch input, so obviously they are very important.

... more ...

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

Pete Brown — 2012-02-01T05:27:14

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.

Memory Profiling for Application Performance

Windows Phone Dev Blog — 2012-01-31T19:50:33

Performance is a concern for all but the most trivial of applications, and in a constrained environment like the phone it is all the more so; performance issues directly manifest themselves in the user experience. Memory usage is one such source of performance issues that can degrade user experience, and the Windows Phone Marketplace enforces a technical certification requirement that an application must not exceed 90 MB of RAM usage, except on devices that have more than 256 MB of memory.

What could cause 90 MB of usage in a garbage-collected runtime? There could be several causes:

Allocating too much.
Long living objects that bloat working set.
Holding on to references unintentionally leading to memory leaks.

Applications allocating too much could end up with working sets breaching this threshold; applications with a large working set might eventually exit with an “Out of Memory” exception; and holding on to references unintentionally can lead to memory leaks causing working set to increase steadily and stealthily, eventually leading to the application exiting with an “Out of Memory” exception.

Up until the Windows Phone SDK 7.1 release, application developers had to guard against this by programmatically instrumenting their code with specific framework method calls and track memory usage. These methods included the following:

But beyond that there was little help from the tools.

The Windows Phone SDK 7.1 addresses this through the introduction to profiling tools to analyze the execution, visual, and memory characteristics of an application.

Install the SDK now, and let us walk through the Memory Profiler as we investigate a case of a memory leak caused by unintentionally holding on to references.

A Sample Application

Consider this application that has two pages, and where the second page renders several images within a grid, and where one may navigate between pages.

Page2 has 4 images controls within a grid control that is bitmapcached. During the initialization of Page2, it binds the 4 image controls to jpeg images and registers for an event handler.

The two pages look as follows:

As we try out the application going back and forth between the pages a few times, observe that memory usage keeps going up; there is a memory leak.

Visualizing the leak

To delve deeper into this leak further let us run this application through the Memory Profiler using the following steps:

Invoke the Profiler, choose “Memory (managed object allocation and texture usage)”, and launch the application. Note the memory used by the application at the top of the screen.
Click on Go To Page2. This will launch Page2, and display the 4 flower images.
Click on the back button.
Click on ‘Force GC’. Note the memory used by the application at the top of the screen. Observe that it does not go down.
Repeat steps 2, 3, 4 four more times.
Now click on ‘Stop Profiling’.

We should see a graph like the following:

As expected memory usage is steadily growing.

Analysis

Select a range, from before the start of the first plateau to just after the after the start of the last plateau, for analysis. Once analysis is complete, using Performance Warnings as the starting point, navigate to the Heap Summary view. We should see a table similar to the following:

Note that the memory held by Retained Silverlight Visuals at End is large as compared to that held by just managed objects. So, let’s drill down into these retained Silverlight visuals.

Select Retained Silverlight Visuals at End and navigate to the Types view. In the Types view, sort the Total Size (Bytes) column in descending order. We should now see a table similar to the following:

Note that Grid and Page2 are the heavy consumers. We also notice right away that 5 instances of Page2 are hanging around. In our scenario, we navigated 5 times to Page2, remember?

Let’s look at what those 10 instances of the Grid are: click on the Grid and navigate to the Instances view. We should now see a table similar to the following:

Note that 5 of the instances are being allocated from Page2. Click on the hyperlink and you can go the line of code in XAML where the Grid is allocated.

To see what is the memory being retained by the visual tree rooted at a Grid instance, click on, say, the grid with the ID 33 (this is a grid allocated from Page2), and navigate to the Visual Tree view. We should now a table similar to the following:

Note the visual tree rooted at that grid instance. We can see the 4 contained image controls, as well as the Texture memory associated with the grid.

To cross check the association between the grid instance and Page2, we can go back to the Types view, select Page2, and navigate to the Instances view. We should then see a table similar to the following:

Notice that there are 5 instances created and none of them has been destroyed (i.e. garbage collected).

Now let’s look at the Visual Tree rooted at a Page2 instance. Select the first instance, and navigate to the Visual Tree. We should see a table similar to the following:

Again, we see the grid, its associated texture memory, and its contained image controls. Earlier we saw that 5 instances of Page2 were hanging around. That leak was causing the associated grid, images, and texture memory to not get cleaned up.

Now let us see why the Page2 instances were hanging around.

Go back to the Instances view, select the first Page2 instance, and navigate to the GC Roots view. Collapse the tree structures. We should see a table similar to the following:

Ignore the weak references (these do not prevent the GC from acting on the references). But look at the TouchFrameEventHandler; expand it and we should see a table similar to the following:

There are 5 chained event handlers! The first one was allocated from our assembly. The rest were cloned within mscorlib, as each page appended its own TouchFrameEventHandler (the event handler is implemented as a .Net Delegate type). That event handler is holding a reference to the page that in turn is preventing the page from being garbage collected.

So the eventhandlers references the Page2 instances, preventing it from being GC’d; and thus assets contained in Page2 are not cleaned up (the grid, associated texture memory, images).

Solved!

All that remains to be done is to find where that handler is being registered in our assembly.

Go back to Heap Summary, select Retained Allocations at End, navigate to the Types view, sort by Type Name column, and scroll down to locate the TouchFrameEventHandler. We should see the following:

To find out where that 1 instance was allocated in our application code, select the first entry, and navigate to the Methods view. You should see the following:

Click on the Allocating Method hyperlink, and you will jump to the method that did the allocation. You should see the following:

There, right at the bottom is the place where we register to the eventhandler! The step of registering stashes away a strong reference to this instance of the page within the event handler delegate. Unless the user unregisters this handler, the Page2 instance will remain alive (and consequently so too will the grid and the images, and the texture memory will not get cleaned up).

If you comment out the line that enregisters the handler, and rerun this scenario, here is the graph you would see:

Voilà!

Conclusion

Having a garbage collected runtime removes one of the biggest sources of program errors, memory allocation errors; you no longer have to worry about freeing memory which you no longer use. But leaks spring when you unintentionally hold on to object references that you no longer use. By providing a variety of Views on the applications memory usage the Memory Profiler can be a valuable tool to detect and fix such leaks.

Yet Another Podcast #58–Julie Lerman and EF/CF

Jesse Liberty [MS] — 2012-01-31T17:34:48

Happy 75th Birthday, Philip Glass!

Charles Petzold — 2012-01-31T11:00:00

About 14 months ago I saw the New York premiere of Philip Glass's Concerto for Violin and Orchestra No.2 at Carnegie Hall performed by violinist Robert McDuffie and the Venice Baroque Orchestra. McDuffie had commissioned the Glass work (subtitled "The American Four Seasons") for a program that also included the four violin concertos collected by Antonio Vivaldi as The Four Seasons almost three centuries earlier, and McDuffie took the program on a tour of 30 American cities.

... more ...

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

Pete Brown — 2012-01-30T23:22:37

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 Last Catfish in the East Village?

Charles Petzold — 2012-01-30T19:40:41

People who live in New York City often inhabit tiny apartments, and the only reason we tolerate them is that we've exchanged private spaces for public spaces. We can frequently be found not in our apartments but walking around outside, or in a store, or a theater, or a concert hall, or a museum.

... more ...

BAOC Countdown and WPAppItUp Wrap-Up

Windows Phone Dev Blog — 2012-01-27T20:01:43

Big App on Campus: Two Weeks Left!

Back in November, we announced a developer promotion for US students called “Big App on Campus.” There are exactly 18 days left to enter. Though we think it’s a no brainer, some of you have asked “Why should I enter?” Let’s recap:

1. For the experience of a lifetime -> 10 finalists, along with one of their friends, will win a trip to SxSW in March. If selected as a finalist, you and your friend will get to come hang out with The Gracious Few (featuring members of the bands LIVE and Candlebox) and attend a rocking concert.

2. $30k in prize money -> the top paid app and the top free app will each win $15,000!

3. Serious bragging rights -> finalist apps will be featured on our Facebook page and the developers behind these creations will have some crazy stories to tell about their time in Austin at SxSW.

<aside reason=”toAppeaseTheLawyers”>No Purchase Necessary. Open only to US university students 18+ who are legal residents of the U.S. and D.C. Submissions due 02/14/2012 and game ends 03/13/2012. For Official Rules, click here</aside>

All Windows Phone applications published since August 1, 2011 are eligible for entry. However all apps must be published to the Marketplace by February 14^th. Make your Valentine proud and enter your app today – I’m sure she/he won’t mind helping you spend the $15k in winnings up for grabs. Check out our Facebook page for all details and information on how to get started on building your first, or next, Windows Phone app.

#WPAppItUp Wrap-Up

Starting back in October, we challenged students to create Sketchflow prototypes of their app ideas for Windows Phone. I’m happy to announce the full list of winners:

Congratulations to all the winners!

Ben

@benlower | phoneninja@microsoft.com | +1 (206) 659-NINJA (6465)

Playing A Sound, Simplified

Jesse Liberty [MS] — 2012-01-27T17:49:25

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

Pete Brown — 2012-01-27T03:55:54

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 — 2012-01-25T20:08:25

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.

Now, more than ever, you need a designer

Pete Brown — 2012-01-25T07:52:53

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 — 2012-01-24T05:48:51

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.

Yet Another Podcast #57–Kendo UI

Jesse Liberty [MS] — 2012-01-23T19:49:57

My First Real PIX-6T4 Game: Sixty4Racer

Pete Brown — 2012-01-22T14:34:30

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 — 2012-01-21T08:12:51

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 — 2012-01-20T22:59:04

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.

Full Stack Resumes–MVVM Design

Jesse Liberty [MS] — 2012-01-19T15:15:29

New Videos Uploaded

Jesse Liberty [MS] — 2012-01-18T18:50:10

Calling Navigate From The View Model

Jesse Liberty [MS] — 2012-01-17T17:04:01

WPF 4.5: Observable Collection Cross-Thread Change Notification

Pete Brown — 2012-01-16T21:54:30

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 — 2012-01-16T00:49:40

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 — 2012-01-14T00:31:25

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 — 2012-01-12T02:02:35

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.

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)

Windows Phone 2011 Retrospective

Windows Phone Dev Blog — 2012-01-11T19:30:12

We created this infographic to provide a retrospective look back on Windows Phone in 2011, with a specific view to information developers would want to see.

Your Welcome

Charles Petzold — 2012-01-11T15:01:52

Dear Spammer,

... more ...

Expression Blend 4, MRU location

Walt Ritscher — 2012-01-11T07:20:34

I’m working on my book for O’Reilly this month (HLSL and Pixel Shaders for XAML Developers). If you’ve written books or articles yourself you know there is a lot of prep involved in getting your machine into a clean state for screenshots. You don’t want to show a list of client project names to the [...]

Threading Considerations for Binding and Change Notification in Silverlight 5

Pete Brown — 2012-01-10T17:48:00

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.

Tracking Expression Blend 4 version numbers

Walt Ritscher — 2012-01-10T01:13:22

It’s a bit hard to know the version numbers for Expression Blend releases as the information is scattered about the Internet. Version Name Number Release Date Expression Blend 4, original release 4.0 June 7, 2010 Expression Blend 4 Service Pack 1 (SP1) 4.0.20901.0 Sept 7, 2010 Windows Phone SDK 7.1 version 4.0.30816.0 Sept 28,2011 Microsoft [...]

Silverlight Reporting Open Source Printing/Reports Example Updated for Silverlight 5

Pete Brown — 2012-01-09T21:44:30

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 — 2012-01-08T07:19:46

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.

Maker Geek Roundup 005 for 1/7/2012

Pete Brown — 2012-01-08T00:27:11

Shout Outs

MakerBot launches a text adventure to give a hint of what we're going to announce at CES! (Makerbot Industries)

3d Printing and CAD/CAM/CNC

Wiring Diagram for DC Motor + Domo*pes or Arduino + Circuit + Code (CNC Snap)
Mendel90 (HydraRaptor)
- also Mendel90 extruder and Mendel90 axes
3d Printed Snowman Army (Grass Roots Engineering)
Lego compatible Android minifigure (Johan von Konow)
3D Printing Bridges across Gaps (3d Printing is the Future)

.NET Gadgeteer

GHI (non-beta) .NET Gadgeteer SDK released! - Devhammer's Den (G. Andrew Duthie)
Why not while(true)? - .NET Gadgeteer (Kerry Hammil)
Looking for API reference docs for the core Gadgeteer libraries? (Kerry Hammil)
How to Build a Flipbook Maker: Part 1 (Kerry Hammil)
- Part 2, and Part 3
Thursday Featured Module: Buttons - .NET Gadgeteer (Kerry Hammil)
Great Sites and Blogs for Learning about .NET Gadgeteer - Devhammer's Den (G. Andrew Duthie)
Seeed Temperature Humidity Sensor with OLED Display (Integral Design)
Using a Servo in a .NET Gadgeteer Camera Device « Integral Design (Integral Design)
- also Controlling the Servo using a Windows Phone application
Software & Sawdust: Making a Gadgeteer DaisyLink Extender Module (Software & Sawdust)

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

Very fast SPI-to-parallel interface for Netduino (Highfield Tales)
ASP.NET and .NET Microframework HTTP web server together (part 1/2) (Laurent Ellerbach)
- Part 2
Creating dynamically a web page using .NET Micro framework (Laurent Ellerbach)
Netduino - Long awaited update (My projects)

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

News - New EasyMx PRO v7 board coming January 2012 (MikroElektronika)
AVR Analog Comparator (Jumptuck)

General Electronics

Remove Function Lock Key with a 4016 and a 555 (Hack a Day)
TV Transmitter Circuit (Circuit-Zone)
Capacitance Meter (Circuit-Zone)
Function Generator XR2206 (Circuit-Zone)
High resolution capacitor meter (Dangerous Prototypes)
Using 555 timers to add "free play" functionality to classic arcade machines (Hack a Day)

Robotics and Robotics Studio

What is a Household Robot? (Greg Shirakyan)
Announcing Robotics Developer Studio 4 Beta 2 (Trevor Taylor)
Behind the Scenes: Motion Tracking Robot Controller at Maker Faire 2011 (Gershon Parent)
Treaded robot modified for stair climbing (Hack a Day)

Clocks

Soviet Nixie Clock IN-18 (HD) (Electronics-Lab.com)
Binary Burst clock concept (Jumptuck)

Synthesizers, MIDI and Electronic Instruments

Meet the MeeBlip micro: Small, Hackable Project Synth, Shipping Now, $39.95 (Meeblip)
How We Changed the MeeBlip To Make it More Playable: New Firmware-Overlay Tour (Meeblip)
Casio DG-20, fretboard (My DIY Blog)

General Maker

Half Life 2: Gravity Gun (Volpin Props)
737 cockpit will satisfy even the most discriminating simulator afficiandos (Hack a Day)
MAME cabinet, system upgrade part 2 (My DIY Blog)

Retro Computing and Commodore!

PREVIEW: CPLD-based XT-IDE adapter V2 (Dangerous Prototypes)
30 Years of Commodore 64 (MOS6502)
Being precise on the C64 (MOS6502)

Misc Geek

Take a break: Show your skills (Valentin Ivanov)
Trillion-frame-per-second video (Electronics-Lab.com)

Just Awesome

Jetpack Man Races With Fighter Jets (Maker Masters)

Rick Santorum and Group Marriage

Charles Petzold — 2012-01-07T16:31:20

One of the most common arguments against same-sex marriage is that it would open the floodgates to all sorts of other types of marriage. For example, James Dobson in his book Gay Marriage: Why We Must Win This Battle (Multnomah, 2004) writes:

... more ...

New Markets for Windows Phone Developers

Windows Phone Dev Blog — 2012-01-05T23:57:33

We’re pleased to start off the New Year with an update to App Hub that will enable you to distribute apps and games to even more customers in more markets. App Hub now allows you to submit apps for distribution in 6 new markets; Argentina, China, Indonesia, Malaysia, Peru and the Philippines. Although you will be able to now select these markets for distribution in App Hub, the Windows Phone Marketplace is not yet available to customers in these markets. We will provide more information about availability of the Marketplace for customers in these markets in a future post.

You should be aware that applications submitted to three of these six new markets – China, Indonesia and Malaysia – will be subject to additional requirements due to local laws, regulations or norms. You can find information on these additional requirements in the Application Certification Requirements.

Given the Marketplace is not yet available for customers in these markets and the addition of new requirements, we’re opening the submission process early to give those of you interested in distribution to these markets a head start on certification. We’re viewing this as an early access period and you can expect the certification process to take a little longer during this time period.

As usual, when submitting either an update or a new application in App Hub, you can choose to publish the app “worldwide” to the full set of 41 markets to you can select specific markets. When you select worldwide, the additional requirements of the new markets apply. As a result, if your application fails certification, you will need to either update and resubmit your app to meet all worldwide requirements, or de-select the markets where your application will not meet requirements.

Also included in this release are a number of minor enhancements and bug fixes, including improvements that will streamline the payout process and enhance reporting to provide data like crash counts and exceptions to assist in improving your apps. These are a result of your feedback and we’ll continue to provide other improvements in each release.

We’re pleased to start the New Year off by expanding markets to which you can submit apps for distribution, and will provide more information on the consumer experiences for those markets when we are ready to go live.

My new recording mic: Shure SM7B

Pete Brown — 2012-01-05T06:01:08

Over the Christmas break, I decided to replace my great Samson C01U mic with something a little more high end. Today was the first day I really got to try it out at work.

Criteria

I knew I wanted a new mic, but there were some specific things I was looking for. For the new one, I had the following criteria:

Not a USB mic. Straight XLR
Must sound good for close-talking voice overs
Must be well under $500
Visually needs to let me see more of my screen (more on that in a second)
Similar to the last one, it needs to mount on my boom arm, and not require desk space when not in use

Why not USB?

My C01U USB mic worked well, but it was very picky about the juice in the USB line. Depending on what else was running (even with a powered hub) it would sometimes produce really low volume output. In addition, it took up a lot of USB bandwidth while in use. Recognizing that, I made sure to hook up my MOTU using Firewire instead of USB. Still, I have a TON of USB devices hanging off my machine, and I just needed to eliminate this one. The MOTU has balanced mic inputs and plenty of DSP to spare.

The use and price should be easy to understand. I use my mic for Skype and Lync calls almost every weekday, sometimes on podcasts with other folks, and when recording narration for the videos I create (which I plan to do even more in 2012). My office is not silent. There's a fridge behind me, and my PC itself produces more noise than I'd want in video (I'm picky). Also, some mics (especially headset mics) pick up keyboard taps as loud thumps. I can't have any of that.

Seeing my Screen!

When recording a video showing how to use an app or write some code, it helps if I could actually see my screen at the same time. The Samson had a largish shock mount and then a big pop screen. If I ran it without the pop screen (as I did later), the plosives would come through on the recordings as very loud spikes. I spent a bit of time editing them out for the latest Silverlight videos, but I didn't get them all. Small pop screens weren't worth the effort as they were hard to position and also just didn't work well. You should have seen the neck contortion to see my screen with a mic in my face.

The C01U

My C01U is still a good microphone. If you don't have an external audio interface with balanced mic inputs and good preamps, I wouldn't hesitate to to recommend it to someone looking for a USB microphone. In fact, I've recommended it to many others, with the caveat about USB power. Several of the Blue mics are also good to check out.

The SM7B

The mic I finally decided on is the Shure SM7B. This is a broadcast quality mic, but still within the price range of most mortals. The cardiod pickup pattern helps reduce the amount of keyboard and background noise that makes it into the recording.

I decided on this mic after a lot of research. Initially I looked at condensor mics, but came to the conclusion that at my price range, they're all a bit meh. Granted, I didn't get a chance to actually use any in-person, so I was only able to go by recordings, reviews, and feedback on the web.

Why did I pick this mic?

Industry standard sound, often used in talk radio and video voice overs. Optimized for those scenarios, but useful in many others.
Does not need a separate shock mount
Does not need an external pop filter even when used in close-mic applications.
Has good shielding for use around computers and other equipment (have you seen my desk?)
Price was within budget

I use this mic with the large close-mic foam windscreen over the end. I even like the way that looks a bit better. It's also still smaller than most pop filters.

Here's a good review of the SM7B at TweakHeadz.

Preamp

The SM7B needs a powerful preamp. That was a bit of a surprise when I picked it up, as I thought my MOTU would be sufficient. The 52db of gain available on the MOTU 828mkIII may be appropriate for a condensor mic, but I got almost nothing out of the SM7B with the gain cranked all the way up. After a bunch of research I made two decisions:

I really want to build my own preamp based on plans/kits on the web. They're just cool electronics projects with significant opportunity for high-voltage electrocution. I can't resist!
I need something fairly inexpensive but decent to work with until I get around to building my own.

So, I went to the local Guitar Center and picked up a PreSonus TUBEPre. This is a tube-based 1/3 width 1U high microphone pre-amp. It sounds decent enough, although you can replace the inexpensive Chinese 12AX7 tube for further customization of the sound. There's a VU meter on the front, but it isn't particularly useful and is more just for eye candy unless you're screaming into the mic.

Surprisingly, the TubePre gain only goes up to about 40db. However, it sounds louder and cleaner than the MOTU at the full 52db gain setting. I haven't investigated why.

I found a number of cool plans and kits for building your own preamp. They all tended to run several hundred dollars in parts, but that's still a lot cheaper than most "good" preamps. More on those when I decide to build one.

In the end…

The mic sounds great, although I am still tweaking it (and the preamp and eq) to see what things I like and don't. In the end, typical video compression renders a lot of the nuance from the preamp and mic pretty much undetectable. That's ok, though, as I'll create the best possible source recordings, and enjoy myself while doing it. It just feels better to work with good equipment.

Yet Another Podcast #56–Jeff Blankenburg: Evangelist

Jesse Liberty [MS] — 2012-01-04T16:45:04

MFOS Synth 6: PCB Complete

Pete Brown — 2012-01-04T08:08:42

Over Christmas vacation, I completed all the component mounting on my MFOS Ultimate board.

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

The board now has installed all the capacitors, resistors, diodes, ICs, trimpots, and transistors specified in the parts list.

Here's the overall shot of the board. For the most part, I tried to use the best components I could reasonably get. One place where I decided to spring for a little bit better was with capacitors 49 and 50 in the filter. I don't have a DMM sensitive enough to measure pF capacitance, so I couldn't measure and match those. There are circuits you can build which will let you measure capacitance, but I'm not particularly interested in building one. Instead, I sprung for 1% tolerance capacitors figuring that will get them pretty darn close.

A thing of beauty!

Here's a shot of one of the three oscillators. You can see the 2k ohm tempco (temperature compensating) resistor mounted over the SSM2210. I don't have any appropriate thermal or potting epoxy around, so it's just touching it right now. I'll bed it once I test everything and I pick up the epoxy.

After I took these photos, I cleaned the bottom of the board using Flux Off Rosin Flux remover by Chemtronics. What a mess! It took the whole 10oz can to clean the board (at $17 a can!), and then it still (due to the "X" holes) redistributed some of the sticky flux to the component side. Once I finished up the can, I managed to get almost all of the flux off the top, and all of it off the bottom. Still, what a mess. You have to spray enough of the remover on to liquefy the flux and run it off the board. Any dissolved flux which stays on the board simply spreads out. That stickiness, if not removed, will attract dust and dirt, making more of a mess of the board.

I'll give it this: the bottom *did* get clean. The burnt flux from removing a couple mistakes (one transistor soldered backwards, for example) was all washed off, as were the sticky hard globs of resin.

Of course, this is before I solder on all the front panel wires, so there will be flux from that too.

Flux can be corrosive over time, not to mention ugly, so it's a good idea to clean it off. Other approaches to consider include using 99% alcohol if you can get it. I just ordered order some of this, because it is likely the same type of stuff for less than half the price of the Flux Off.

Rosin flux is more benign than most, and actually cures hard to entrap the contaminants. Don't get water washable flux unless you intend to do a really thorough job cleaning the board. Typical water washable flux is highly corrosive if only partially cleaned.

I've also heard that the particular solder I used for this project (60/40 from Radio Shack) tends to have quite a mess of flux. Folks have recommended Kester 44 Rosin Core 63/37 as a better replacement with both more stable soldering (less time in the intermediate state) and cleaner flux. I have some on order for the next few boards :)

Here are a few more glam shots of the board

For the next step, I'll either work on testing and calibrating the oscillators here (which will require building the 1V/Octave test board), or I'll start wiring some of the panel. Whatever I end up doing, I'll be sure to write about it here :)

Vibrating the phone

Jesse Liberty [MS] — 2012-01-03T18:31:15

Binding Formatting

Jesse Liberty [MS] — 2011-12-29T18:48:15

Perspective : easy 3D programming with Silverlight 5 RTM

Olivier Dewit — 2011-12-28T22:09:00

While Silverlight 5 has hit its final (? wait and see :-) version, I've updated my work about 3D programming with the Perspective library.

Enjoy !

Parsing CSS for EPUB

Charles Petzold — 2011-12-26T19:33:30

I've been trying to build an EPUB viewer for Windows 8, mostly because I want to read books on the Windows 8 tablet I got at the Build conference, and it's more fun writing one's own application rather than using someone else's. This will obviously not be a commercial product or I would have thought of a snappier and less wonky name for the program than The New Epublic! [I've decided I don't want to distribute the code at this time. — Jan. 5, 2012]

... more ...

DecryptR Part 2

Jesse Liberty [MS] — 2011-12-21T16:37:03

Living room window bench and bookcase update: cabinet doors!

Pete Brown — 2011-12-19T04:25:50

In every project, there comes a part you just dread doing. It's always the part you put off until the very end. When programming, maybe it's that exception logging, or security interface. With most house projects, it's painting.

With carpentry/cabinetry, well, I hate building cabinet doors.

There. I said it. I love woodworking, but BOY do I hate doors. I know the appropriate tricks for squaring them up and for adjusting the squareness once they are assembled, but it seems they always bite me in the end. Bah!

Well, I couldn't have yet another set of cabinets without doors (ask my wife about the kitchen), so I decided to build the four doors for the living room window bench seat cabinets. These doors go on the lower cabinets underneath the bookcases on either side of the bench seat.

Want to see more of this project including the full view of the bench seat and cabinets? Here's the recap I wrote in October.

I may hate making doors, but I hate looking at ugly doors even more. So, I went and made these flush inset doors, but compromised on the hinge. It's a nice hinge, but unlike the maple cabinets in the kitchen, these painted poplar cabinets use simple 1/16" spacing no-mortise surface mounted hinges. No mortising means these doors won't be quite so fiddly to hang.

I took some basic measurements, dug up all the wood, and headed out to the shed with my scribbled notes in hand.

The stiles are 1x3 (3/4" x 2 1/2") poplar while the top rail is 1x4 (3/4" x 3 1/2") and the bottom rail is cut to 1x5" (3/4" x 5" exactly) from larger stock.

The core of each door is 1/4" thick plywood, glued into 1/4" routed grooves 1/2" deep in the rails and stiles, offset 3/8" from the front of the door. As is always the case, the plywood was warped, so I had to fight that during assembly.

The rail and stile joints are reinforced with 8x50 dowels using my Festool Domino. I've had that tool since it first came out in 2007ish, and have used it over and over again. It's really a huge help when it comes to this type of assembly. FWIW, I cut the mortises in the rails to the exact width, and used the wider setting when cutting the mortises in the stiles. This gives me a little wiggle room during assembly.

It's humid year-round here in the mid-atlantic, so I had to microwave the domino tenons to get them to fit reasonably well. Microwaving helps remove some of the moisture that swells the wood. I had them stored in a plastic bag inside a Festool systainer, but it was outside in my work shed.

The detail in the center of the door is 1/4" x 2 1/2" poplar simply glued in place on the plywood.

The joints came out horribly. But honestly I didn't fuss over them that much as the doors will simply be painted. I'm just happy to have the doors done :) Between the glued-in plywood (it's plywood, so you can glue it in. Don't do that with solid wood) and the eight big 8x50 dominos used on each door, they should hold up to quite a bit of use…maybe even to what my kids dish out. I'm not so sure about the overlays in the middle, though. Only time will tell there, but as they rely on the stability and quality of the plywood (ha!), I can see them popping off with the top skin of the plywood going with them. I hope not, but it seems plausible.

The next step was into the house to have wood filler put on the defects and bad joinery. After that, because they're ever so slightly oversize (something I did on purpose), I'll trim them on the table saw and do a final squaring up at the same time. Here are all four doors in front of one of the cabinets. As you can see, the cabinet is already being put to good use.

From there, it will be final sanding and then painting. They look horrible right now, but once sanded and painted, no one will ever know of my sins. Well, except all of you :)

What do you know? I might actually have doors on these cabinets in time so Santa doesn't have to see all our messy craft and homeschool supplies.

MFOS Synth 5: Trimmers and some capacitors in place

Pete Brown — 2011-12-19T03:04:55

The next step was to solder yet more components to the board. I soldered the trimmer potentiometers as well as a number of the capacitors.

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

Trim pots

The MFOS synthesizer uses multi-turn cermet trim pots to make tuning the various parameters possible. I picked them up from Tayda Electronics. These are used throughout the synthesizer to enable calibration.

These are +/- 10% Cermet pots with a top-mounted multi-turn (25 I think) adjustment screw. Not for this board, but for the others, I recall running into a case where I could only find the side-mounted adjustment screw versions for at least one of the values. Those will work too, but the adjustment screw may be more difficult to access.

Capacitors

Pay attention to the build notes at the MFOS site. Ray has a few substitutions you may wish to make, specifically swapping out some of the Tantalum capacitors for aluminum electrolytic ones of the same value.

One thing I didn't like about the board layout was that several of the spots for the aluminum electrolytics were sized for a much larger capacitor with 5mm leads. The smaller sized ones (of the correct voltage and capacitance) work fine, but they stick up from the board a bit rather than sitting flat. For grins, I tried finding 5mm lead versions on Mouser, but those are almost impossible to find. My guess is that Ray had much larger values originally spec'd or something.

I ordered some additional capacitors from Mouser. It turns out I was missing a few values. Those should hopefully arrive either just before or just after Christmas. Once those are in, I'll be able to calibrate the three oscillators. That's where the real fun begins :)

Other work

Based on feedback from the last post, I also replaced the doubled-up 1/8W 3M resistors with single ones. Doubling up the resistors in parallel actually decreased the resistance, and it turns out the board won't need the full 1/4" watt ones anyway (although those might be more heat stable). I'll keep an eye on them in case heat becomes an issue.

Also, after pricing out the headers I'd need to make this board easily disconnected from the panel, I decided to just pass and instead wire the front panel directly to the board like everyone else. I will, however, end up using coax for the mixer section as Ray recommended in his MFOS Sound Lab Mini Synth Mark II build.

Yet Another Podcast #55–David Plat on Why Software Sucks

Jesse Liberty [MS] — 2011-12-16T18:44:57

MFOS Synth 4: Resistors all soldered

Pete Brown — 2011-12-16T05:14:26

Phew! The resistors are all soldered. The board has a few hundred of them, so there was quite a bit of soldering.

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

Here's an image of the board with all the resistors in place. In the oscillator section to the left, one resistor in each of the three is not used. I marked it with a silver sharpie. In addition, a second resistor is left empty in each oscillator if you use the temperature compensating resistors. Since I'm going that route, that slot is empty and marked with a brown sharpie.

Overall the resistor soldering was enjoyable but monotonous. The only problem I ran into was a mistake I made when ordering. When I ordered the 3M resistors, I accidentally ordered 1/8W instead of 1/4W. Looking at inventory at Mouser, I realize why: they have no small quantities available for 1/4w 3M resistors. It's possible the board only needs 1/8W (I haven't calculated it), but rather than take any chances, I put two 1/8W 3M resistors in parallel in the two spots that required 1/4W 3M resistors.

NOTE: Don't do this. I was only thinking about wattage, but didn't realize that resistance drops when you do this. The two 3M resistors end up producing only 1.5M actual resistance. Thanks to Michael in the comments for saving me some annoying debugging later :)

Other than that, I forgot to swap out two replacement values for R184 and R189 as recommended in the MFOS page. I did that after I took the photo.

I could have just ordered some replacements, but I really didn't feel like waiting, or wasting the money. Here's another shot of the board with resistors in place.

Once everything is assembled, I'll set up some better lighting and take a few wallpaper-quality shots of the board. Here are some opinions on soldering all these resistors:

I actually found it relaxing to solder all those (well, once I got a decent fume removing fan). Resistors are pretty immune to all types of crappy techniques: other than making sure you have the right values, you don't have to worry a whole lot about them. Soldering transistors, on the other hand…

Next up will likely be capacitors or the trimmer pots.

Slides and Code from my VSLive Silverlight 5, REST, WCF Web API, MVC talk

Pete Brown — 2011-12-15T22:13:05

This talk was an adaptation of two chapters from Silverlight 5 in Action. I started with a brief explanation of REST, and then explained the solution we were going to build during the session. The idea was to show how you can use REST in place of the heavier Soap approach in many cases, and make your services accessible to far more clients.

I also showed how to share model objects between various implementations of .NET, using linked files and conditional compilation.

Without watching the session or reading the chapters, the source and slides are only somewhat useful as you miss the interim steps. So, if you happen to be at an event where I deliver this again (I've submitted it to several upcoming 2012 events), great. If not…buy my Silverlight 5 book ;)

In addition to what's covered in my book, I also showed how to create a basic Razor Helper to load Silverlight in the page. You can learn more at the linked blog post.
The WCF Web API may be found at the WCF CodePlex Site.
You can learn (a lot) more about ASP.NET MVC at our ASP.NET Community Site.
Of course, you can get all the Silverlight 5 bits at our Silverlight Community Site.

Everything else is attached to this blog post. The zip file is around 7mb.

Feel free to present this at your own internal or public events. I only ask that you not submit this as a session at VSLive, TechEd, DevConnections or other large events where I may be planning to present. When in doubt, ask.

DecryptR–A Glass House Application

Jesse Liberty [MS] — 2011-12-12T21:40:16

WPF-Blogger.com [Language: en]

Marketplace now open in 5 new markets

Complimentary Copies

Windows 8 Touch Events Interactions

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

Memory Profiling for Application Performance

A Sample Application

Visualizing the leak

Analysis

Conclusion

Yet Another Podcast #58–Julie Lerman and EF/CF

Happy 75th Birthday, Philip Glass!

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 Last Catfish in the East Village?

BAOC Countdown and WPAppItUp Wrap-Up

Playing A Sound, Simplified

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

Yet Another Podcast #57–Kendo UI

My First Real PIX-6T4 Game: Sixty4Racer

Concept

GamePlay

Progression

Goals

Screen Design

First Iteration: Creating the scrolling playfield

The Screens Class

The RacerGame class

Second Iteration: Adding in the player

Third Iteration: Polishing

Sound Effects

The Explosion Sprite

Final Steps

What You Can Do

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

Unboxing

What the Kit Includes

What it doesn't Include

Assembly

Smoke Test

And…I got nothing.

The Test Games

My First Game

The GameOfTest class

Program

Conclusion