@Doctor Who: as far as I understand, the Motion combined sensor works best when the phone has an accelerometer, compass and gyroscope available. It still works, although not with the same quality, when the gyroscope is absent.
In WPF you could probably get something like that with a Popup. If I remember correctly that's how they implemented several flyouts in the WPF Ribbon. The bending part would still require the Pixel Shader _aL mentioned, but that's actually fun.
Considering the knee-jerk reaction they got with partial demos and statements, it doesn't surprise me much. They are seriously risking a marketing issue of Vista proportions here, so it makes sense to try and get the whole story out, all in one piece.
@Dr Herbie: btiyf (Bing Translator is your friend).
If I read correctly, it says that they didn't ban Marmite: it's just that food enhanced with vitamines must be specifically approved before it can be sold and no submission for Marmite or Vegemite was received yet.
Hmm.. in the translation the two products become "Marmite and Vegemite lubrication". I see how they might object if one tried to dress his salad with WD-40.
@W3bbo: A Silverlight client would make a lot of sense, not just for the Linux implication, but because of WP7 and the upcoming ARM tablets (if and when).
This might have a nice side effect: Microsoft will have either to provide its own SL implementation for Linux, or to help Miguel on Moonlight, to make sure it's on par with SL. Either way, that would be a good thing.
I happen to despise the stuff, but banning food on the grounds that it's not healthy (or not as healty as it claims to be) is beyond silly. If fixing the adverts and a warning label is enough for tobacco and alcohol, banning should be reserved for substances that have significantly worse effects than those two.
If anything should be banned are laws intended to prevent you from doing something "for your own good".
@BitFlipper: Yep, that's what I plan to use to drive the Peltier cells and the fans. Aside of the usual "heartbeat" (2Hz or so), the only use I have for a tight loop is to maintain a good running average and I hope that timers are stable enough for that. As far as I understand, interrupts are handled via delegates, which might create some overhead... we'll see.
As for the Visual Micro add-in, if debugging is not supported all bets are off. Debugging firmware without a decent IDE is a painful journey in psychic debugging land and that's no place to send a postcard from. I'll try it out and see how it goes...
@Bass: the main reason I am considering this excercise is that I want to use Visual Studio for a change. Yes, I may have been spoiled rotten, but if you ever tried using - say - Keil uVision, you know what I'm talking about. In all fairness I haven't upgraded my embedded dev tools in a while, but considering the price tag of the upgrade and their lousy track record, it's not something I'm looking forward to. I'd rather try and get a 32bit ARM7 to do the job of a lowly 8x51, if this means I get to use VS.
Unfortunately, the Arduino doesn't seem to provide any integration option with VS, so that would kind of defeat the whole purpose. At that point I could just use the right microcontroller for the job.
@BitFlipper: I'm starting with a simple peltier-based fuzzy logic temperature controller, with a display and a few buttons to control it (maybe I'll go for broke and try a rotary encoder).
Considering the application, reaction times are not really that important, but your benchmark is somewhat scary, as a tight loop on an 8051 can easily get to several MHz (depending on the clock and chip manufacturer). Even discounting the fact that the emitted IL is probably more complex than what you would normally write in C (above all, I wouldn't use a call to set an output pin), I must admit that I expected something less dramatic than this. I'll have to try it for myself and see how it scales... I have high hopes that having 32bit registers might compensate some of the losses in the more computation intensive parts.
Anyway, thanks for your help: now I know that I really want the 72MHz unit.
I finally decided to go with a .NET MF solution for the next project, but now I'm a little perplexed, for a number of reasons, so I thought I would ask for your opinion and experiences before I try to "sell" this decision to my customer. There are a few problems I got stuck with:
- The hardware. There seems to be several alternatives, but all from manufacturers I don't have any experience with. If anybody tried out some solution, it would be interesting to know if you would recommend it and why (horror stories are also welcome).
- Performance. My undestanding is that the Micro Framework does not JIT the IL to native code, but interprets it instead. I can live with that, but I cannot seem to find a reasonable number about the kind of performance I can expect as compared to native code on the same platform. Even a ballpark figure would do...
- Licensing. The whole matter seems foggy, even because I'm not a lawyer and I didn't marry one. From what I read, MF should be released under an Apache 2 license, but on the download site there is still a 2007 document that states otherwise. Is there a definitive word on the subject that I missed, somewhere?