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.
>orgs are better building directly on Yocto (or BuildRoot) without a vendor in the middle
Going on a tangent here, but does anyone else also agree that BuildRoot is much, much nicer to work with as a dev than Yocto? I've had to work with both and BuildRoot was easy, just like building a Linux kernel with 'make menuconfig', whereas Yocto was downright painful.
I worked with Yocto for about 8 years and about as much with buildroot.
They both get the job done but I find that yocto recipes are more tractable. You see clearly what comes from the main git tree and what patches a vendor adds on top.
I've seen some really ugly chimeras built with buildroot as a base..
Not a real expert with those systems, but I have used both. I believe buildroot is much smaller (as in much less binaries can be built) than Yocto. Yocto has its learning curve, but there is a lot readily available and you can do a lot more. It's extensible by desgn. You can build basically everything, but not without understanding the principles by just searching a few odd SO answers.
I have used buildroot for an initramfs. If you have configured a kernel before, you get going in an afternoon.
The main problem of buildroot is the fact you need to rebuild from scratch all the time. Yocto has properly working incremental builds.
Yocto is definitely more flexible, which can be a curse as it gives architecture astronauts more chances to split up all the stuff it several repos and dozens of files.
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.
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.
Yes! We've actually created extremely small base images with Yocto for our own agent at resin.io, and it's a really cool approach, though it is very complex to set up and handle, and has approximately none of the elegance of a Dockerfile. Also, resinOS images are available as containers for some very specific use cases, so that's another instance where we've done something like that. Perhaps we should write up more about the approach.
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 am the author of one such library for the problem of writing parsers (particularly for binary protocols). The declaration of the protocol structures are separate from anything involving I/O. Not trying to push it too hard but it is one approach: https://github.com/digidotcom/python-suitcase
Both suitcase/construct are definitely better suited for parsing binary protocols -- In my line of work, that limitation hasn't been a deal breaker. With suitcase, at least, I haven't done much work to optimize performance (mostly because if I cared, I wouldn't be using Python).
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.
For safe, well-reviewed wrappers around libc (a different problem, but one which is more realistic to solve), I would encourage you to check out the nix crate (I am a maintainer -- the original author was Carl Lerche). It doesn't look like we have a wrapper for getaddrinfo currently, but it is something I think we would welcome.
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'm trying various not-regex syntaxes. My motivation is: we all agree regex is bad, but we keep using it because it's available everywhere and hence the least common denominator (a schelling point). What would it take to get beyond regex as the goto pattern matching/parsing? At least for casual use.
Here's the dataset they use. I have used this as part of developing and testing the fitness of recommender systems in the past: http://grouplens.org/datasets/movielens/
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.
> Certifying a cellular end device is usually <$50K
Suppose the author wants to (completely legally) use the phone he just built.
Does he have to go through this "end device" certification? Or does "end device" mean something else here?
what if he wanted to sell the phone?
I was wondering what the regulatory landscape looks like during the last portion of the talk -- it'd be a real shame if he put all this time into designing a beautiful phone and couldn't (legally) use it!
In this guys case there is an FCC allowance that you can build up to five devices for personal use that this cellphone project might fall under. Building a bunch to sell is a different matter though, especially since this is an intentional radiator vs. a unintentional one.
I get the sense that it's a bit of a taboo topic to talk about publicly in the opensource / hobbyist world. Adafruit and Sparkfun, the two major outlets for hobby electronics in the USA, for example generally won't discuss publicly what the companies stance on their FCC rules compliance obligation is.
My feeling based on reading a bit about it is that until you reach a certain scale the cost of FCC testing is prohibitive. So when companies like Sparkfun and Adafruit were starting out they simply followed best design practices and fudged a little on the FCC side of things by saying that their products fell under one of the exceptions or that they use a pre-certified module. Now that they are bigger it seems a small number of their products actually do get certified. It's a mess for sure.
For smaller deployments, I think it makes more sense to look into solutions like mender.io, etc. for updates/fleet mgmt/etc.