[1] https://github.com/bytecodealliance/componentize-py [2] https://peps.python.org/pep-0816/

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

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.

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.

There is also Construct which has a different syntax but is similar in many ways: http://construct.readthedocs.io/en/latest/index.html

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).

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.

https://github.com/nix-rust/nix

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, ...).

Disclosure: I'm the primary author/maintainer of suitcase (https://github.com/digidotcom/python-suitcase). In your example, you can shave off a line by doing the following:

    example = FIDOAttestation.from_data(a)

This predates some of my more recent work with the grouplens database, but here is a parser I put together for the data awhile back: https://github.com/posborne/mlcollection/blob/master/mlcolle...

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.

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:

1. Execute `cargo build --target=foo`.

2. There is no step 2.

* I don't think a few tens of bytes is realistic for a real application that needs to set up the stack, timers, and then blink some LEDs (https://github.com/mcoffin/zinc/blob/new-build/examples/app_... / https://github.com/mcoffin/zinc/blob/new-build/examples/app_...)

* 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/

The Due has 512KB of room for code which is quite a lot (for microcontrollers).

My experience with code automatically converted has not been good.

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 string this together with another script to rename content and it drops right into my Plex library.