Ha! Win 10 preview for Raspberry Pi 2 pops out of the Microsoft oven Microsoft has released a preview of Windows 10 Internet of Things Core for the diminutive ARM-Cortex-powered Raspberry Pi 2 and the MinnowBoard Max, a computer driven by an Intel Bay Trail Atom. The operating system image for the Raspberry Pi 2 requires an 8GB micro SD card, though the OS itself is only about 1GB, with the …
This post has been deleted by its author
> Five years ago, I would never have imagined Microsoft doing this...
Microsoft jumping on another bandwagon is a surprise to you?
Just about everything Microsoft has ever done has been where others have led the way and started to succeed, either to take control or to kill off using their billions and their contracts.
They perceive Pi as a threat in Education which they have nearly monopolized outside worldwide.
Note - unlike the Linux Pi you also need a fully blown remote Windows PC to work on it. Two windows licenses for the price of one and all in the name of Education. Hurray. Now watch it being driven top down to all schools. In the olden days there would have been salesman visits by Billigatus himself to the Bliar and the other top politicos. It is interesting what level will go Nadella to push it.
"Two windows licenses for the price of one and all in the name of Education. Hurray."
Yeah...but I'm pretty sure IoT Core will be free. Most schools already use Windows PCs and will do for the foreseeable future.
Is it a blatant grab by Microsoft to gain future share in a the fledgeling IoT industry? Yes.
Is it a blatant grab for the hearts and minds of young folk to become used to programming for Microsoft products using Microsoft's tools (i.e. Visual Studio)? Yes.
Is it a blatant grab to make various impoverished education systems around the world shell out for 2 Windows licenses to use a single device, as you seem to be implying? Uhhhh...no.
> Yeah...but I'm pretty sure IoT Core will be free.
MS have said that IoT will be free to 'makers'. Whether it is free to makers' clients on production devices is yet to be seen.
Also IoT is designed to connect to the Internet via Azure. MS will probably require a subscription or access charges for that.
Yes IoT Core is a grab by MS for a piece of the action, but the grab is in the wrong direction. 'Home Automation' and similar does not need to go via servers in another state or country, it should be localised and go via a gateway if necessary.
Microsoft released the .NET Micro Framework- free-as-in-beer and open-source under Apache 2.0- almost 6 years ago, allowing .NET code (okay, MOST .NET code) to run on anything from tiny ARM microcontrollers (anything with >256kbyte Flash and 64k RAM) up through mobile devices, through PCs and on to massive hyperscale Azure deployments.
They've also not set the lawyers on groups like the open-source Mono ".NET on non-Windows platforms" project, either (indeed they're now actively helping them), so that code can be run on Android, iOS, OSX, loads of flavours of Linux, UNIX.
As for their Windows range of OSes, CE/Compact have been about for years on a variety of platforms. It also provided the basis for their older Windows Mobile platform and the (terrible) new Windows Phone platform.
So no, Microsoft doing things with ARM based devices isn't exactly anything new, and neither is their fondness for developers.
I'll just leave this here for a laugh too... https://www.youtube.com/watch?v=8To-6VIJZRE
I really think we're at the tipping point where MS has truly seen that x86 PCs are not a given for the future and, frankly, the future of their company depends on them being interesting in the post-PC world. I know the term "post-PC" has been used for years and years, but this really does feel like it might be true.
Intel chips have been RISC for years now. The x86 instruction set is decoded into RISC "micro ops" which are executed out-of-order by the RISC core; a retirement unit then sequences completion to maintain coherency. Interesting discussion about if here: http://stackoverflow.com/questions/5806589/why-does-intel-hide-internal-risc-core-in-their-processors
"At the very least, the end of the dominance of the x86 instruction set"
What dominance? In mobile (phones and tablets), x86 is probably less than 5%, with the rest being ARM.
What we seem to have is two different architectures, that have different strengths and weaknesses, being used for different applications. ARM for low power and x86 for applications where more CPU is required. It's engineering, not religion.
This isn't to say that some applications where x86 currently rules the roost aren't also appropriate for ARM, and micros-servers are a good example, so Microsoft are making sure they have an option on ARM.
As far as I can see, this looks like a sensible re-use of the investment they made in Windows-on-ARM for the original Surface; that didn't pay off, but this might, so they may as well invest a small amount (in Microsoft terms) in this.
> What we seem to have is two different architectures, that have different strengths and weaknesses, being used for different applications...
So where does that put the POWER8? Besides in the dustbin of amazing technologies made by dimwit companies who can't get their heads out of their butts.
(not that anyone will have to worry about the POWER9 ever coming out. Every time IBM lays off more people their new products get pushed further and further out. Power9 will be released shortly before the heat-death of the universe.)
Raspberry Pi turns out to be a bit of a success.
Thousands of kids are getting to use Linux and possibly liking it.
Original Pi is too weedy to run Windows.
Problem.
Let's have a chat with the Pi Foundation and become buddies...
New Pi released with 6x the CPU and 4x the RAM. (For the same price?!)
Get a sawn-off version of windows running on it ("runs apps written in HTML", wtf?)
"Developers will need PowerShell running on a connected PC". There's the payback / lock-in.
Have chat with our buddies that run the National Curriculum and get some Windows-based Pi modules made mandatory.
All Pi's in schools must run Windows. Putting Linux on them is forbidden as a security risk / hackers training tool.
Profit.
Damn, that takes more than three steps. Ah well....
> Except that Powershell has been widley ported to just about every other OS including Linux...
You show that you fail to understand the word 'ported'.
Powershell has not been ported anywhere, the source code for it is not available for that to happen. There is a _partial_ separate implementation that appears to be able to run on some other OSes.
Nothing to see here.
Simply a homeless and un-loved OS trying to find somewhere, anywhere to stay.
Linux = Open, choose what works for you, learn about how it works freely. Net result, its installed in lots of places
Windows = locked down (UEFI), bundled (tax'ed) onto new hardware, a constantly changing UI, licenced to hell and back (ExFAT), good bits being thrown away for "new stuff" and as a result ending up in less places as everyone got fed up with all the BS.
Genuinely not sure which OS you're calling unloved and homeless there, as the Windows you refer to (UEFI, Tax'ed [sic]) isn't the same version that you install on the Pi, unless you've soldered a UEFI BIOS to your Pi and have been duped into paying for Windows on one of those dodgy malware ridden sites.
For people that are all for "Open" and "Choice", you penguin people don't seem to like it when other people exercise their right to choose ;)
The implication of Universal Apps is that they will run anywhere. IoT apps tend to be _very_ hardware specific. In fact W10 IoT is said to support the Arduino Wing API which would seem to be the whole point of it. These IoT apps won't run on any other version of W10 and it would seem pointless to run non-IoT apps on this hardware.
No, they're not "very hardware specific", unless your only exposure to software has been in database-driven applications.
If you're doing it properly, you separate the hardware specific parts of your application into their own module (or assembly or library, take your pick - the term isn't as important as the principle) with a defined API, and you make the rest, the 95% that has no need to know anything about the specific hardware, from components that will run on any kind of hardware. If your board changes, you've just got to change that 5% of code that dealt directly with the old board's hardware.
Same principle as any other piece of software development, really.
> No, they're not "very hardware specific",
The "hardware specific" refers to the type of devices the IoT app is intended to control or monitor - the "Things" in IoT. An app intended to monitor and control the air conditioning may have modules to work with different brands but it is unlikely to be useful for dealing with your garage door.
Neither of these examples would run on your phone or tablet because they wouldn't have the Arduino API nor the hardware: the analogue and/or digital ports needed.
Okay, I'd describe that as "task specific", not "hardware specific", but the point still stands. The bulk of any automation task is not the automation itself, but rather the interfacing with whatever is in charge of the automation. In the simplest case, you the user are in charge, and the device needs to present a user interface to you, and respond to those commands. Most of the software is in co-ordinating the requests and responses and making sure everything is working correctly. The direct control is a very small part.
If you use a common framework, you can develop an test this I/O and management layer on a more developer-friendly platform like a desktop PC, with a high degree of confidence that the deployed result will be functionally identical to the what you see. Once the functional correctness has been established, you can move the focus of testing onto the target hardware to address performance issues (That's not to say you don't look at the target all along, just that the focus of testing moves towards the target as you approach completion).
The other big advantage is in component re-use - it may not be sensible to run your garage controller on your phone or tablet, but it does make sense to run a control and observation application on such a device. That application will need the same protocol support as those controllers, and because the software that implements those controllers runs on Windows10, the monitoring app can use it too. (Actually, if you've been careful, you'll have written those modules against the Portable Class Library core of .NET, which is available on just about any platform, including OSX and Linux)
Note that none of this is specific to the OS being "Windows" (.NET actually): the same principles would be true of iOS or Android or even Linux (if you put the effort into ensuring your distributions on each device are comparable) — but only if those platforms were to offer the same deployment target on single-board-computers, phones, tablets and desktops.
> That application will need the same protocol support as those controllers, and because the software that implements those controllers runs on Windows10, the monitoring app can use it too.
No they won't. The IoT app will be using the GPIO to drive the motors and sense the positions and probably other safety sensors. The phone app will just have an Up and a Down button and will send a signal to the IoT device. The IoT app may have an up and down button too - probably real buttons - and LEDs to signal faults or safety issues, also on the GPIO, but that will simply set the local signal to operate.
You seem to have a strange idea of what embedded systems and IoT are about. The whole point of running on Raspberry Pi, or other boards, is that it has these interfaces to control and sense the hardware directly.
No strange ideas, just experience of writing real systems. What you're describing is the interfacing layer. If there is any intelligence at all on the "Thing" device, then that code will not be the totality of the application, and it will easily be contained in one small module. (If it isn't contained, then the software design is broken, because when your hardware revs, you'll end up needing to re-write and re-qualify high-level logic that should not have been affected by a hardware change)
The only case where interfacing is the majority of the code is when you're making a dumb sensor/actuator. But if you're doing that, you're not talking about "Internet of Things"; you're talking about centralised command-and-control. IoT is not that. It is about distributing the intelligence to manage remote functions at the edge of the networks.
The intelligence that runs in the system does not need to know that a falling edge on GPIO pin 4 causes a lamp to light; it just needs to know that there's a visual indicator available for a given condition - the code will still work regardless of whether that "indicator" is an LED (wall-mounted control panel), or a toast notification (phone), or a broadcast event message.
> What you're describing is the interfacing layer. If there is any intelligence at all on the "Thing" device, then that code will not be the totality of the application
Of course I am describing 'the interfacing layer', that is what the intelligence of the 'thing' is.
A dumb 'garage door opener' has a control board that drives the motor and responds to sensors. It may also respond to a remote control with an IR sensor or similar. An IoT garage door opener will have the dumb control board replaced by a RaspberryPi 'compute' module or an Arduino or similar that has Wifi or ethernet connection to the home network, and through this to the internet. The code on this will not only drive the opening and closing of the door and use sensors to stop, but may also detect any forcing of the door or other unusual conditions in order to send messages. It will respond to commands arriving on the network to show status, activate a sequence or other.
Your phone app will do _none_ of that. The phone app may connect and ask status, view history, (including notifications sent), and request open or close. The app running in your car may also, given that it gets to a certain GPS location, request an open or close. None of this is in the door opener.
> It is about distributing the intelligence to manage remote functions at the edge of the networks.
Exactly. The door opener (or light bulb, or fridge) _is_ the edge of the network, the intelligence is the Arduino or RaspberryPi compute module or similar.
You seem to want to distribute the 'intelligence' of _how_ the door should be opened and the sensors interpreted to your phone whereas the phone app should only need to send a 'please open' command and get back a status regardless of how that should be achieved.
The door and its RPi is the 'Thing'. It acts a server. The phone app (or car app, or other) is a client. There is almost no commonality of code - except the base OS and network stack. It is the same relationship as a web server and a web client - would you claim they are the same thing ?
For more complex systems "Clients and servers" is not the correct terminology: what you call a "server" in one instance can also be a "client" for another type of request. There's no client or server connection either, just messages. This isn't a "new for IoT" thing, it's a fundamental concept in distributed control systems. All of the equipment controls in your car work the same way: you push the "A/C on" button; a message is emitted indicating that this control has been depressed; the A/C controller sees the message, activates the compressor; an A/C compressor status-change message is emitted; the cabin controls panel sees this message and lights or extinguishes the indicator lamp appropriately. Everything is asynchronous and distributed, and concerns are separated - you can use that A/C control switch with any type of A/C compressor, so long as both use the pre-agreed messages: the microcontroller in the switch panel has no idea how the A/C compressor is turned on or off, and this is good: it doesn't need to know. Knowing creates a pointless dependency which means both components must change if either does.
At a basic level, the messages exchanged between devices will have to conform to an agreed format and protocol. The code to implement that protocol will be common to both. Even if the protocol is open and published, it's better to use the same implementation of it at as many endpoints as you can. (Here's the place where everyone who's used any kind of CSV-based message interchange nods and winces...)
It's possible to use different code to do the same thing on client or server, but it's not a decision people are willing to repeat in my experience.
Your garage door example is too simplistic to illustrate the point. Instead, consider a house with motion detectors, and lighting controllers. Normally, local intelligence ensures that lighting comes on (and stays on) while you're in a room. A phone app can receive that motion and light-state data as well as issue commands to control the lights. A timed lighting sequence (for security lighting or just a wakeup lamp) could be managed either from the phone, or via another device within the home, but the intelligence to operate a timed sequence of lighting will be common code that uses and generates messages. The light switches might not even be of the same type, but as long as the messages are agreed, the common controller code can be used on any of them, with only a very small amount needing to know how the device is switched.
If you still don't see what I'm talking about, have a look at how existing IoT protocols like DDS and MQTT work. These are what the "intelligence" part of your application are talking to, not GPIO lines and network sockets.
> For more complex systems "Clients and servers" is not the correct terminology: what you call a "server" in one instance can also be a "client" for another type of request.
The 'garage door' IoT program _is_ a server - is serves the purpose of driving the door open or closed. The mobile phone app _is_ a client to that. Whether there are other apps in the controller of the garage door that make other requests is irrelevant.
> The code to implement that protocol will be common to both.
Which is part of the 'base OS and network stack' and not a 'module of the app'. In any case your mobile phone app that has open and close buttons will not be using IoT protocols. It will send an encoded SMS message, or a coded phone call or an http message to your home network gateway which will extract orinterpret that to IoT protocol messages.
> It's possible to use different code to do the same thing on client or server, ..
In most cases they use different code because they are doing _different_ things. They may have the same 'base OS and network stack' but the _apps_ (in my example) are not 'doing the same thing' at all. One is displaying a GUI, sending requests and displaying status, the other is actioning the requests (driving the motors) while monitoring and sending status. The device may also have other programs that do other things such as sending video or acting as a alarm system.
> Your garage door example is too simplistic to illustrate the point.
It illustrates _my_ points fine. The base OS (Win10, Linux, Android, ..) may well have the same or similar code in each device and this will include networking using various protocols and libraries for various utility functions.
Microsoft on the RPI, I say Microsoft because they couldn't even manage to fit a GUI into their image so "windows" is something of a misnomer. Compare with pretty much any of the other OSs where you get a GUI and full functionality without having to have an additional computer plugged in just so you can communicate with it.
So what we have here is a load of non-standard APIs and bloat that adds zero additional functionality to a RPI running linux. Why on earth would anyone want to sully their PI with this when there are compliant open standards already in place? the RPI is supposed to be a learning platform adding unnecessary abstraction simply to be compatable with a dying OS has got to be the single most stupid idea I ever heard of
If you want to continue developing for the microsoft environment then don't bother with the RPI, you are never going to be able to compete with real coders in this niche and very soon the kids who grow up with RPI and linux are going to put you out of job completely.
It is always amusing to read the hopeful commentary from Linux trolls in the comments.
Win10 is probably going to address a lot of your concerns such as increasing use of standards, being free to use (admittedly with the hope of you using their cloud backend)
It also has a massive user base that ain't going anywhere because they don't need to.. Mostly I think you guys are afraid because for once Microsoft are not being tools about it.
Anyways. Continue on with your hate... Don't mind me.
Everyone else... I am sorry for feeding the trolls.
> (admittedly with the hope of you using their cloud backend)
I think we refer to that as bait & switch or is it closer to giving away the handle so people buy your razor blades?
> Mostly I think you guys are afraid because for once Microsoft are not being tools about it.
Lets run a little comparison here:
* Win10 on Rasberry Pi: I can run a basic custom written application with a basic UI.
* Linux on Rasberry Pi: I can run the full OS with full UI and with a fast collection of applications. There are a variety of distributions including those for specialised uses (e.g. OpenElec & OSMC media centres, Kano for Education, etc.) and general purpose (Debian, Ubuntu, Fedora, ArchOS, etc.)
With Linux you can build your own custom distributions. With Win10, you enter a world of licensing pain.
"""Win10 is probably going to address a lot of your concerns such as increasing use of standards, being free to use (admittedly with the hope of you using their cloud backend)"""
I do not know even how to begin to address this. Either you are very naive or you do not know who MS is.
Why wasn't windows using standards before? Why Windows being free (that remains to be seen) stops what is bad about Windows?
And as for windows on the PI, I said it before this is just an expensive PR exercise.
It seems that the Robot in the picture has a USB cable to the HP Laptop and an HDMI cable to the monitor to display instructions. These indicate that it is manoeuvred using keystrokes (QWEASDZXC), presumably the laptop's keyboard.
It seems less than useful for a Robot to have several cables tying it down.
I find this interesting. But I can't work out exactly what it is.
It presumably isn;t full windows on arm, but what exactly will it run? Is it like windows rt which may as well have been a different os entirely as it didn;t run win32 apps or is it in some form "proper" windows?
Looking at the "APIs we don't support" list, it seems to be most of Windows Phone, except for those features to do with running a phone, so no calendar, no contacts manager, no notifications centre or air interface/carrier/SIM management.
Of the APIs that aren't phone-specific, only BackgroundMediaPlayer would be missed, but this may be a work in progress.
The UI framework does appear to be mostly present, albeit with some missing controls (no "flyout" windows for some reason...)
Where everyone had hope that you'd finally get small and affordable mobile computing, but then Microsoft jumped on it, ruining the market with arbitrary limitations. Making Netbooks with Windows essentially useless... even by the standards of the most die hard Windows fanboys.
Writing an application on a host PC, deploying it to the target, and then controlling and debugging that target from the host PC is quite common for embedded development. And there is no other option if the target does not have a display output. There is little reason an embedded target would have an OS-style desktop. If one wants a GUI interface the embedded app can create that but it usually will be a GUI more than a desktop come app launcher.
Hyping it as "Windows 10 coming to the Pi" has rather distorted expectations and has misled many. A lot of people are expecting a typical PC desktop OS when it is very different to that. For most people saying it's not for them; it was never going to be for them, it will never fulfil desires it was never intended to fulfil.
Windows IoT is not a replacement for desktop Linux on a Pi. It may perhaps be best thought of as an alternative to a minimal command line only Linux install, accessed only via SSH/Telnet, which has access to a frame buffer. If that's not good enough for what someone wants to do with a Pi then Windows IoT likely isn't either.
I'm interested to see what I can put on it, see if it has good drivers for the pi's various chippery so I can get a transcoding DLNA server running on it.
I won't be deleting my rasbian images, but I'll certainly see what I can do on it. I fear this will mean installing visual studio though. Such sacrifices we must make.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
