The WASI support in CPython has moved along very well and it is an early target via componentize-py[1]. Notes on WASI support in Python can be found in PEP 816[2]; CPython will be jumping from 0.1 to 0.3 (0.2 is adapted in componentize-py) which should unlock a fair bit of support, especially once cooperative threads lands (providing a pthreads impl in wasi-libc).
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.
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, ...).
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.
This indeed would be very cool! Right now things work relatively well with the biggest pain being the acquisition of std for your target.
If std and core could be made into first-class crates, then you could get rid of the need to find a pre-built version of libstd for your target. It would just be built when needed by a project.
This is what we currently do in zinc for core via the hack here: https://github.com/hackndev/zinc/blob/master/Cargo.toml#L27. Zinc doesn't use std (for obvious reasons). Right now, targeting a raspberry pi is much harder than it should be as a result of having to having to find an appropriate cross-compiled std.
That is, I want the steps for cross-compilation to be:
* Assuming the code size overhead does not continue to bloat after some initial overhead, I think rust can still be very competitive. Although modern embedded systems are still very constrained, the days of 8-bit micros are basically over. You can buy a 32-bit ARM micro for nearly the same cost with sufficient RAM/Flash to run rust well.
* Looking back, I think the size of blink should actually be closer to 600 bytes. Will need to investigate: http://zinc.rs/stats/
Yes, I believe so. The binaries I have built so far have been very small (<2KB for a blink example). mcoffin has a branch with SAM3x support, which appears to be the processor on the Due: https://github.com/mcoffin/zinc/tree/sam3x
The Due has 512KB of room for code which is quite a lot (for microcontrollers).
I think the better approach here is to phase out existing applications in chunks. You can link call rust code from C (when externed and rustc is told not to mangle) and C code from rust (via ffi).
My experience with code automatically converted has not been good.
That is the hope, since master is currently out of date.
I have been working with Matt Coffin some on getting this working. Feel free to increase its chances of merging by helping us test any of the supported boards (Freescale K20, NXP LPC17xx, SAM3x (on a branch), STM32F4, STM32l1, TI Tiva C).
I plan on putting together an RFC for how we can modify zinc (or provide documentation) to make it easier for individuals to create both libraries and projects that work well with zinc, but do not require modifying zinc itself.
I wrote this (https://github.com/posborne/putio-sync) a few weekends ago for automatically grabbing content from put.io using their API (https://put.io/v2/docs/index.html). Pretty handy and performs downloads quickly by doing multi-segment downloads. Pure python and MIT licensed -- should be pip installable from pypi.
I string this together with another script to rename content and it drops right into my Plex library.
Undergraduate student and associate software engineer at an embedded systems startup (that just got bought recently). I also do some side work with some peers at my school.
[1] https://github.com/bytecodealliance/componentize-py [2] https://peps.python.org/pep-0816/