Repository navigation
micropython can api #93
Description
Activity
This seems possible. But first, we should try to setup Travis CI to test for it (and probably also allow failures for the beginning), and then start developing.
I'm having a look at this. See branch
micropython-port. At least installingmicropythonworks now but the dependencies are problematic ...Hello,
As somebody that uses both Python-CAN and Micropython I feel it would be hard to get a unified API. Microcontrollers are just very architecture specific, so you see differences just in between ports due to this. Send and receive because is easier to abstract, but lower level controls and other management might be too limited or too complex depending on device.
My suggestion would be to make a uPython-CAN library that does not impact the much more optimized main library. Microcontrollers are just so resourced constrained that I would not want to or try to get a desktop application to act like or mimic that world. Micropython already is forced to make compromises calls for efficiency and resources.
It might also be good to clarify the goal of this, because it is bridging two worlds and could easily be a lot of work, Micropython being for bare metal, and Python being for full desktops.
I am sorry, I realized I am providing mostly just my opinion. Hopefully it is helpful.
Reacted by Felix DivoHm, you might be right with that. The thing is: I initially (=this morning) thought it would be just a matter of setting up a new environment and tweaking our library in one or two corners. But MicroPython turned out to be more specific and different from CPython than I thought. I personally have no interest in using
python-cantogether with MicroPython, and thus won't devote a huge amount of time to it. But maybe there are others interested in this? We'd probably have to change a lot in this code base if we wanted to support it here, which would make it hard to maintain, if it is even possible anyways. A separate and detached repository for "uPython-CAN" seems more appropriate.The best scenario I can come up with is when you are running a headless embedded OS (could even be Rasberry pi or Beaglebone. And you really want/need a lean python implementation but it needs to run on top of a unix OS. Because Micropython is very fast in a lot of respects, but partly because it is so lean.
I think this also only makes sense if you are using a very low level and cheap. It does not make a lot of sense to use a $200 PCAN adapter, on a $50 embedded computer, and still need Micropython. So supporting only the built in CAN controllers (like the mentioned embedded computers) make the most sense and would then focus on Socket based communication. Then you do not need to worry about other drivers and potential issues.
But then your argument for MicroPython would be increased performance. But when we arrived at that point, we could also "simply" use C as a programming language, right? Because either way we would have to move away from plain CPython and all the great libraries that come along with it, and I guess even MicroPython is not as fast as C code.
In other words; I do not see the great benefit that would justify the probably quite significant work that would have to be done in order to make the MicroPython spin-off as efficient as a plain C implementation.
For me Micropython is the balance of speed and ease of use on Microcontrollers. But even as a big fan, I have yet to use it on any system with an OS, because I had more than enough power to run full Python3 implementations.
I have read and heard of use-cases where Micropython can be used in ways like PyPy, to optimize code for certain applications, but even that is hard to justify because in many cases PyPy can just be used.
Even though I want to use Micropython grow, I doubt this is needed for python-can. Probably better to just make (or make sure) the unix port of Micropython support the Socket-can sockets.
Reacted by Felix DivoYes, that sounds reasonable!
While at PyConAU 2016 I attended the Monday sprints and spent a fair bit of time discussing the python-can api with Damien George from micropython and Jim Mussared from Grok Learning. We were trying to see if the python-can api could be used within micropython so that Python programs written to use a CAN bus could work on PC and micropython without changes.
I think it would be worth revisiting after version 2.0 is released.