The ATUSB driver
werner at almesberger.net
Sun Mar 27 19:38:09 EDT 2011
Richard Sharpe wrote:
> An important question will be to what extent can a usbnet-based driver
> be developed? Will it be easier to use the usbnet infrastructure and
> do what it needs or write our own stuff.
There's already a nice standard for transmitting IP over WPAN, 6LoWPAN.
It only has a few minor drawbacks:
- not entirely trivial. But the linux-zigbee project has implemented
the key pieces of the stack.
- IPv6. Well, we're on the IPv4 titanic in a sea of IPv6 addresses.
Now is a good time to learn to swim :-)
- alas, not transparent for the host (i.e., needs an extension to the
networking stack, etc.)
- some parts of the standard are still a moving target (mainly
6LoWPAN is an on-going standardization effort at IETF:
The key document is RFC4944, http://datatracker.ietf.org/doc/rfc4944/
The compression is likely to be superseded by
What I plan to do is to first make sure we have proper support for
6LoWPAN in the Linux kernel, based on the work of linux-zigbee.
For atben, this would already be the end of the development. For
atusb, it may be attractive to reduce the number of things that
need to be changed on the host.
E.g., if atusb could appear as an Ethernet-like device (i.e.,
usbnet) and translate between the IPv6 encapsulation for Ethernet
and that for the WPAN link layer, the host would need to know less
about WPAN, and just a general IPv6-capable kernel plus some
user-space configuration tool may be sufficient.
An even more radical approach would be to provide transparent IPv4
to IPv6 translation/tunneling.
The feasibility of such deployment-friendly simplifications would
have to be studied. The ATmega32U2 has 28 kB of Flash for the
firmware (the boot loader will consume 4 kB), so there's room for
experiments. (If we should find out that a "dumb" firmware is all
we need, the ATmega32U2 could be replaced with an ATmega16U2 or
even ATmega8U2 in future revisions, to slightly reduce cost.)
We could also invent some non-standard IPv4 over IEEE 802.15.4
transport as a short-term hack, but deploying what amounts to a
proprietary solution may mean trouble later on.
More information about the discussion