Being an MVP

I’ve been a Microsoft “Most Valued Professional,” or MVP, for a long time now.  So long that I had to actually go look up when I was first got the award (2002).  Over those years, the program has changed, the technology for which I am an MVP has changed, and I’m certain that I’ve changed.

When I first got my MVP status, it was not long after I co-authored a book on embedded Visual Basic with a friend, Tim Bassett and at the time I was being pretty prolific in that extremely niche segment of the development community, publishing articles on DevBuzz and answering question in the now-defunct Usenet groups from embedded development (as a side note Microsoft has tried many incarnations to replace those groups, and have never found one that was as easy to use or navigate).

I remember that I felt a bit out of place at my first MVP Summit – the annual meeting of all MVPs in Redmond – because I was seeing and meeting all sorts of people that I had been using for information since I had started developing.

It wasn’t long, and my focus changed from eVB to the .NET Compact Framework – largely because Microsoft killed eVB as a product.  I embraced the CF and continued writing articles for MSDN and answering loads of questions and even doing the speaking circuit at what was then called Embedded DevCon.  I helped “start” OpenNETCF, which at the time was really just a collection of Compact Framework MVPs trying to answer questions, cover the stuff Microsoft was missing, and not duplicate effort.

In those early days of the CF, being an MVP was fantastic – it really was.  A few times a year the MVPs and the product teams would actually get together in the same room.  They would tell us what they were planning.  They would ask for feedback.  They’d listen to our ideas and our criticisms.  You could count on seeing direct results from those meetings in future releases of products coming out of Redmond, and so the MVPs continued to pour effort into keeping the community vibrant and well-informed.

Back in those days I knew both PMs and developers from most of the teams involved in the products I used.  I knew people on the CF team.  The test team.  The CE kernel and drivers teams.  The CE tools team.  The Visual Studio for Devices team.  And when I say I “knew” them, I don’t mean that at a conference, I could point them out, I mean that at the conference we went to the bars together.  I had their phone numbers and email addresses, and they would respond if I needed to get a hold of them.

Those I now know were the golden days of the program, at least from the embedded perspective. It could well be that C# MVPs or some other group still sees that kind of interaction, but the embedded side doesn’t see much of that any longer.  In fact, I know very few people on any of the teams, and I guess that most of those people probably wouldn’t answer my emails.

What’s changed, then?  Well, Microsoft is a business, of course.  A large one at that.  As such, they have constant internal churn.  Most of the people I one knew are still at Microsoft – they’ve just moved on to other things, other groups and other positions and the people that came in to replace them didn’t necessarily have the mechanism (or maybe the desire) to get to know the community of experts in the field.  The teams also shifted a lot – Embedded got moved from one group to another and to another inside of Microsoft, and the business unit got less and less priority for quite some time – especially when it and the group shipping quantity (Windows Mobile) were separated.  The Embedded DevCon became the Mobile and Embedded DevCon, then it went away.  Budgets shrank.  Community interaction receded.

I can’t say I fault Microsoft for this.  After all, they are a business, and they make decisions based on what provides shareholder value.  I may disagree with some, or even many of their decisions on the embedded side, but I don’t work at Microsoft, and I’m definitely not in their management team, so my opinions simply do not matter.

So why do I bother mentioning all of this, if not to complain?  Because I want you, as a reader, to understand where I come from in some of the articles I’ll be posting over the coming weeks.  I no longer have any inside information about the future of Windows CE or the Compact Framework.  I don’t know what Microsoft intends to do or not do.  I find out things about the technologies at the same time as the rest of the world.

This means that if you see me write something about the future of Windows CE, now called Windows Embedded Compact (and yes, expect to see something on that soon), it’s all based on my personal opinion and thoughts based on history *not* on any insider information.  If what I predict happens, it’s only because my guesses were educated and/or lucky.  If it doesn’t, it’s not because I was trying to be misleading, it’s because I simply got it wrong.  Basically, as with anything you read, I expect you to use your own critical thinking skills, and I fully encourage discussion and debate.

Raw Flash Access from a CF app?

A new customer came to me late last week with an interesting problem.  They have hundreds of Motorola/Symbol MC70 barcode scanners in the field and occasionally the flash memory on the devices gets corrupted.

The current “solution” these guys are using involves removing the flash chips from the board, reprogramming it in a separate device, re-balling the BGA pins, and re-soldering it to the board. That explains why they desperately want an application that can do it.

They know the range where the corruption occurs and wanted an application that would allow a user to read, update and rewrite the corrupted bytes in flash.  They had talked with five separate developers before they found me, and all 5 had agreed that it was impossible, so naturally I took that as a challenge.

First, there are lots of things to know about how flash access works.  Most importantly, it’s not like RAM.  You can’t just map to it, then go about your merry way doing 32-bit reads and writes.  You can read it that way, sure, but writing is a whole new game.  Flash is broken up into “blocks” (which aren’t even always the same size – in the case of the MC70, the first 4 blocks are 64k long, and the rest are 256k long.) and writes must be done following this general procedure:

  1. Read the *entire* block that contains the byte you want to change into RAM
  2. Change to flash to Lock mode (a flash register write)
  3. Unlock the block of flash (another register write)
  4. Change the flash to erase mode (register write)
  5. Erase the *entire* block of flash (which writes all FF’s to it)
  6. Change the flash to write mode (register write)
  7. Update the RAM buffer with your changes
  8. Write in the *entire* block block to flash
  9. Tell the flash to commit (register write)
  10. Wait for the flash to finish (register read)
  11. Put the flash back into read mode (register write)

Oh, and if you get any of this wrong, you’ve made yourself an expensive brick.  The only solution at that point is the de-soldering and reprogramming route, and I don’t have that kind of hardware in my office.

So I started writing the app Monday morning, using C# since I had to create a UI for the editor, and on Wednesday morning this is what I delivered:

FlashEdit

So, in just 2 days I did what was “impossible”. I not only wrote all of the flash access code, I also wrote a hex editor control and an app UI to make use of the flash library.