Add asyncio support [WIP]

[sveinse]

This PR adds support of asyncio to canopen. The overall goals is to make canopen able to be used in either with asyncio or regular synchronous mode (but not at the same time) from the same code base.

Note that this work is still work in progress. This PR was created to discuss the specific solutions for async and non-async as mentioned in #272. This PR closes #272.

Current status until feature complete:

• Implement ABlockUploadStream, ABlockDownloadStream and ATextIOWrapper for async in SdoClient. Not needed
• Implement EcmyConsumer.wait() for async
• Async implementation of LssMaster
• Async implementation of BaseNode402
• Implement async variant of Network.add_node()
• Update unittests for async
• Update documentation and examples

[sveinse]

What is the best way to deal with Variable attributes? The feedback from #355 indicates that it is desirable to keep the attr based get/set mechanisms. However, this scheme cannot be used for async as there is no await mechanism built into @data.setter.

    var = param.data   # Non-async use
    var = await param.aget_data()   # Async use

My goal has been to keep the async and non-async uses of canopen as equal as possible, but this is an area where users will see a difference.

[acolomb]

There is an implementation for .read() and .write() on the underlying canopen.variable.Variable type. Could that be used in an async wrapper, or something similar added for async?

[sveinse]

@acolomb I'm not precisely sure what you mean, so let me guess: You need separate async methods for read and right and they should only call their respective async setters/getters.

[acolomb]

Sorry, I was trying to answer your question in the previous comment about synchronous getters / setters used in the properties. What I meant was that instead we already do have methods to access a variable remotely. Those might be a better fit to mirror to the async world:

value = sdo_var.raw  # This is the usual, terse style recommended in the docs
value = sdo_var.read(fmt='raw')  # This also works already
value = await sdo_var.aread(fmt='raw')  # Feels like a natural enhancement for async

Note that the fmt='raw' argument can of course be left out, it's only needed for phys or desc variants. This would give us an easy way to support async without changing the existing synchronous property-based access.

[sveinse]

Sorry, I was trying to answer your question in the previous comment about synchronous getters / setters used in the properties. What I meant was that instead we already do have methods to access a variable remotely. Those might be a better fit to mirror to the async world:

value = sdo_var.raw  # This is the usual, terse style recommended in the docs
value = sdo_var.read(fmt='raw')  # This also works already
value = await sdo_var.aread(fmt='raw')  # Feels like a natural enhancement for async

Note that the fmt='raw' argument can of course be left out, it's only needed for phys or desc variants. This would give us an easy way to support async without changing the existing synchronous property-based access.

Sorry for late reply here. All of these methods are supported in the async port. In addition to await sdo_var.aget_raw() as mentioned. What if all the getter and setters-like functions and only rely on aread() and awrite() for async? Interesting. I need to contemplate that.

The areas of challenge for async currently are:

• Variable: .data, .raw, .phys, .desc, .bits
• BaseNode402: .op_mode, .statusword, .controlword, .state
• PdoMap.read() and .save() - Because it contains logic among blocking IO. I'm not sure if my dual sync-async solution is elegant or if its smelly.
• SdoClient - is an ongoing challenge. The *Stream() classes contains considerable logic and relies on RawIOBase mixin, all synchronous code. I'd rather not need to replicate all those methods and functions for async.