Description
I have a use case where I have a need to control many independent CAN nodes with separate controls. In order to do that one could either do regular CAN callbacks and state machines, or do them concurrently with an async framework in Python. After investigating a bit, the python-can package does support async operations and I think that canopen should get async support. The biggest upside to concurrent async programming is that the async user code is linearized as if using regular blocking functions, and it makes coding and maintenance much simpler.
I have started on the concept work in my own private fork using asyncio, linked here https://github.com/sveinse/canopen-asyncio/tree/feature-asyncio. For a peek I have a simple example code at https://github.com/sveinse/canopen-asyncio/blob/feature-asyncio/examples/canopen_async.py. This specific example won't work out of box, but a modified variant of the same script with real PDOs and SDOs is tested against physical CANopen HW devices.
I believe it should be rather feasible to add asyncio support alongside the existing API, which is what I've started on in my branch. I'd argue strongly for releasing it as one package/repo due to the constant risk of getting any asyncio fork out of sync with the official upstream canopen package.
This work is currently WIP. I hope this work could be considered for the official upstream canopen. I had hoped we could use this issue as a place to discuss async support. A warning is in order: My motivation in this is a specific use case for a very specific CAN system diagnostics tool and I plan to take it as far as that task requires. The system doesn't implement all of canopen and thus there are many functions in the canopen package I will never encounter. Hopefully this work may become a start point that can inspire others to continue developing it.