posborne

From my experience (from a few years back but still appears to be the case) is that Wind River is just wrapping Yocto these days. There could be value for some orgs where they don't have engineering teams if they do a contracting arrangement but I think, generally, orgs are better building directly on Yocto (or BuildRoot) without a vendor in the middle (other than your SoC vendor and their support layers). I'd save your money and pay for a seasoned embedded linux expert or three if you are maintained a connected product.

For smaller deployments, I think it makes more sense to look into solutions like mender.io, etc. for updates/fleet mgmt/etc.

The agnosticism may be refreshing for some use cases but for things like interoperable home automation the lack of an application layer associated with thread makes it useless to design into a product at this point as there is no real open ecosystem around the technology.

The fact that ZigBee (application layer) requires data to go through a gateway via a standard before hitting some server on the internet is probably a very good thing for pushing interoperability. What you see with IP bulbs is that each bulb hits its own servers on the internet -- when that business disappears in a few years, the customer is probably SOL.

ZigBee app layer on Thread (DotDot) will probably be pushed more. Just a question of whether the advantages of Thread over Zigbee (3) will have enough benefits to push ecosystems like home automation to switch over to this stack.

Awesome, I would love to see hear more about the approach you guys used for building base images with Yocto. I'm willing to give up a little elegance for control and reproducibility.

I have used Yocto for building a new of embedded Linux systems in production. I understand that Yocto is used for the resin hostOS images and Docker is used for the images run as containers.

Is it possible or has any thought been put into making it possible to use Yocto for building the containerized images that are deployed to resin (probably in the form of docker images)? Although this is less convenient than using off-the-shelf docker images and customizing with your own docker files, I believe many of the benefits of Yocto in terms of building a custom embedded linux system might also be recognized within the context of resin.

Very often. Vendors such as NXP/Freescale, TI, Intel (and Chinese manufacturers on top of MIPS) all tend to target Linux-first. For some drivers (e.g. wireless), you sometimes need to work directly with that vendor (Qualcomm/Broadcom/...). In my experience, it is almost the default except in cases where you need 1) Hard real-time, 2) Very low power (most battery applications), 3) Very low cost. Those still go to MCUs where life is more difficult for anything complex (e.g. requiring graphics, a network stack).

For most embedded use cases, Android is still not suitable as you have to jump through many hoops to get sufficient control over exactly how the device operates (you can make it work but the further away your device is from a phone/tablet, the harder it gets).

Source: Worked in embedded design services until recently.

Is there a good way to look up no_std crates? For crates written with no_std, is there a keyword we should be tagging things with?

I have several crates providing access to GPIO/SPI/I2C under Linux and would like to put together a roadmap for having the interface to these types of devices that is portable to various platforms and devices (e.g. Linux as well as Zinc, ...).

I work for a wireless design services company. There is a large divide between using a Cellular module (e.g. Telit LE910) versus doing a chip-down Cellular design (e.g. Qualcomm/Infineon). This design has a module at its core.

Modules are based around the chipsets but they do the most expensive certification (both FCC and Carrier) work for you. As a purchaser of the module, you pay for this on each module.

Certifying a cellular end device is usually <$50K (depending on number of bands, # of carriers, fallback, etc.). Certifying a new chip-down cellular design can easily exceed $1-2M in just certification and testing costs. Development costs and complexity will also be increased.