Ok, so let’s say I make a project with a RPI2, official wifi module, a FEZ Cream, and official 7" screen (when it works) and W10 IoT: how much of a pain is it going to be to commercialize this?
I get the idea behind a Gadgeteer project, you redesign around the underlying SoC and hardwire everything in, but will there be similar options when you’re building on an RPi2?
I think the main challenge is that there is no RPI2 Compute Module (the SOM version of RPi). The CM1 exists, but there is no CM2 yet. And the RPi foundation has not committed to a timeline (as a matter of policy, they don’t pre-announce products or even plans for products). Also, their focus is education, so creation of compute modules seems down on the list of priorities.
There are also some critical software areas that aren’t clear - like how to pull off in-field updates. This is especially interesting for compute modules, because the CM design does not include an sd card for booting - the CM1 boots from onboard flash.
So, if you want to build a product around RPi, you have to accept that you’re a second-class citizen in the RPi world; that you have to use the Model B board (not an SOM); and that Win10 IoT app distribution and management is not fully worked out with respect to IoT scenarios.
This is a hot topic for me because I wanted RPi based hubs and control points, but decided that GHI SoMs were the only reliable and predictable source right now. The RPI2 IoT HW & SW story just hasn’t gelled enough yet (IMHO).
@ mcalsyn - I’m with you, I guess a more related question would be, is there a future SoM where W10 IoT will be supported?
@ andre.m - I get that, but assuming that W10 IoT gets some legs, there has to be a vendor that starts providing a SoM or something similar, right? I mean Microsoft knows it can’t be just for hobbyists. You don’t create a whole branch of your OS just for people to tinker with, they will want this to be the successor for .NETMF, and to that end they will have to have a path to commercial use.
So yes, maybe RPI2 is forever the path for tinkering, but someone has to make a SoM (with support) to allow for commercialization of W10 IoT. Otherwise it would be like developing Windows Phone OS, but expecting it to just deploy to a bunch of dev boards.
I would look more toward the Intel and Beaglebone folks for WIn10-capable embeddable hardware. You’re always going to be a second-class citizen with RPi because industry is not central to their mission.
@ mcalsyn - Ok fair enough, but that still tells me that if I put together a full prototype with the gear listed, I will eventually be able to turn it into something that can be manufactured (and I’ll be modifying the code to some degree I’m sure).
I am far too amateur at this point for this to be an immediate concern, but I do like to somewhat think ahead.
For me, it’s more of a question of scale. If you have identified something that exists in WIn10 IoT that you cannot conveniently or cost effectively do in netmf, then go with Win10 IoT by all means (though with your eyes open regarding some of the rough edges). But I think there’s still a fairly narrow set of things that fit in that category. Certainly, AllJoyn router capability is one of those things (AllJoyn tiny core functionality exists in 4.4, but not router capability). A richer multi-route IP stack is another one. UWP portability is another. If you were building a new home automation gateway device, then Win10 might be a good choice, but not on RPi hardware other than for proof-of-concept work.
Win10 IoT exists in a space between NETMF and full PCs. It has it’s place, but if you are really thinking commercially, I think you really want to exhaust the possibilities in NETMF before committing to the Win10 IoT platform. Not to avoid it, but to make sure it is the right tool for the problem you are solving.
I do believe Win10 IoT will be a solid and formidable IoT platform - far easier to apply than previous Windows embedded platforms. But “right tool for the right job” still applies.
And just to vamp on that theme using your plant project as an exemplar - go back and ask yourself if you couldn’t have done that same project with an ack.me AMW106 wifi-enabled mcu, or maybe a G30-based system. Your bom with both is probably sub-$30 and you get the same network-attached functionality in something that would probably end up being 30mm x 80mm or so and with year-long battery life. You might even be able to use a standalone ESP8266-12 with LUA for a $15’ish bom. Your customer is buying the end product and probably only cares about form factor and value-for-money in the end product. So, have you chosen the hardware platform that gives you the best fitness to task for the lowest cost (cost being both material and dev labor)?
@ mcalsyn - Oh fair enough, and I very much did that project just to get a first project done on Cream, and I literally pulled the parts of a Cerberus where I had previously implemented it.
That said, I’m looking more at a gateway device with a number of XBee sensors, and a touchscreen interface. I do personally expect this particular project to eventually benefit greatly from being able to easily handle a touchscreen UI built from XAML.
Unless you through AllJoyn into that mix, or you mean a device that also replaces a home’s network router device, you could still do all of that with GHI netmf devices. What you are describing is also what we are building as a Verdant gateway device (with touch screen, XBee and Synapse radio options, etc). I only jumped on Win10 for Verdant where I wanted AllJoyn router or Device Bridge Service functionality. For industrial applications of Verdant, where AllJoyn’s broadcast behavior isn’t so desirable, netmf is the platform of choice.
Not trying to beat up on your choices by the way - totally get how you started out on the project. I’m just saying that when you go from project to product, you need to squint much harder at the choices and tradeoffs and not get seduced into bigger platforms than you really need.
@ mcalsyn - Ok, one of my views was the idea of getting most of this into a web UI, with the device mostly showing the web UI, is that ok with Glide?
Not that I am aware of. There’s no browser renderer that I know of for netmf. Even so, you still have to consider whether the savings realized by having a single web-based interface isn’t offset by other costs.
I also have my own philosophical doubts as to whether devices like gateways should have any embedded UI on them. I have come to believe that UI should come to me - I should not have to walk somewhere to interact with a single-purpose display head. All good infrastructure is invisible, so I don’t want to see gateways. They should be inside utility enclosures somewhere out of sight. Just my own design bias. Add to that the fact that the screen could end up being close to half of your total BOM cost.
My own choice was to only build headless devices and then companion apps for all the popular platforms.