posborne

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

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

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

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

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.

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

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

Very cool. Any conclusions from the experiment?

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)

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/

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

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:

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

2. There is no step 2.

A few points:

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

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.

Freescale provides an RTOS for free called MQX (http://www.freescale.com/webapp/sps/site/homepage.jsp?code=M...) that I have seen used on some projects. Otherwise, bare metal or one of the other standard RTOS options.

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.

Yes, it has been done before... But I don't think it has been done in an environment where you need to scale up quickly.

They had a problem, they solved it in a very cool fashion using the best tool for the job (Erlang), they thought of a very good way of testing the application, and they were gracious enough to share their experiences with us, other developers...

Seems like a win all around, so I'm not going to complain.

The way I picked up AJAX was by looking of some of the simpler articles on the basics (don't worry about cross-browser to start with) around the web. The basic concept is quite simple and it is easy to get up-and-running if you have experience with client-side and server-side scripting.

For me, the firebug tool for firefox was indispensable as it allows you to see the requests that are being sent out and received from the server, information you have no easy way to get at without such a tool.

Once you are up and running with the basics, the magic of AJAX will no longer be so mysterious and you can move on to one of the frameworks for adding cross-browser compatibility (I like jquery personally).

I think that the argument given could definitely be considered ad hominem, but as I read it definitely stuck out that a better examples of ad hominem could have been given (that has much less to do with the subject matter at hand).

For instance: "Why should we give creedence to his position on the origin of the universe? He has been divorced twice and is cheating on his current wife... Surely we can't trust what he has to say."

Here the argument is attack by attacking the person. The attack on the person has no direct translation to the dispute at hand.