And is has more than 1 serial port. Embedded devices still use that old serial port and the RPi is seriously lacking in this department.
I love the Windows IoT on the RPi and development is easy with VS but I need at a minimum of 2 serial ports for a project I have.
The Octavo is starting to look more appealing even down to using the chip itself as it handles all of the power and memory handling internal. I am waiting to see what the development system is going to be before I commit any more to it.
I love using Win IoT on my rp3, but I like the flexibility of the BBB more. With the BBBW (not to be confused with BBW) that lack of win Iot is the only thing left holding me back from getting one.
The only painful thing with the Pi3 and Windows is the boot time. Painfully slow. My Pi3 for home automation runs Debian and I am up and running with all the services start in under 30 seconds with that.
I’d also like to see this on the BBB(W) with the extra serial ports this would allow me to use this for industrial type applications. 1 UART on the PI is not ideal and I know I can add USB ones but that bulks it up too much.
This year has been tough as a lot of my work for oil industry based. Looking at other options now but margins are much lower so one off custom solutions really hard to get out there.
I really like Win Iot programming experience, display approach is nice, you don’t have real desktop just run application with UI, it is more problematic with Linux, you need to interact directly with Framebuffer when in console or configure kiosk mode in x-window a bit of overhead when you need simple application with basic UI
I see some problems preventing windows iot in production systems:
boot time as @ Dave mentioned
power loss vulnerability - it seems you can’t configure win iot in read only fs as you can do it with linux i.e. corrupted sd card/emmc
automatic updates which can damage the system, there is iot core pro where you can manage and defer updates but still think it is an issue in embedded systems
I work for that Windows company, and Windows is my OS of choice for pretty much everything I do on the desktop and in the cloud, with the only exception being VMs that I use for stuff that has to run in Linux (e.g., building yocto images for BB).
HOWEVER, for embedded stuff, I still stick with NETMF, Linux and an occasional foray into mbed.
The main reason is that there is still no analog for Docker-style (or even MFDeploy-style) in-field updates. In fact, there are a number of built-in measures against side-loading that work against you developing your own IFU mechanisms. On top of that, unless you pony up to get IoT Pro, it’s simply not acceptable for your clients in the field to get updates pushed to them at the same time you are seeing those updates for the first time. You can’t guarantee stability unless you can accommodate breaking changes in those updates concurrent with the update. There are a number of built-in impediment to starting small-but-viable with Win IoT and scaling up (you can start small, but with unacceptable restrictions) - no such impediments or buy-ins exists in the Linux world.
If we could get Docker-like containers on Win IoT and update throttling without having a big buy-in, then I’d definitely give it a second look because the tooling is otherwise superior.
I think they’ll (WIn IoT) get there - they just aren’t there yet.
