Hello,
The first prototype of the future motherboard for the MarXbot, with an
omap3 (ARMv7) processor, is under testing on my desk. Philippe + me
successfully integrated a real CAN controller on it, mapped in memory.
This brings a new shiny 'can0' network interface, getting rid of the
current UART translator and the related problems.
But this improvement brings a concern for the current software. In order
to connect to this interface, we must implement a socket to a CAN_RAW
unix-style socket. Obviously, this can be done in dashel by adding a CAN
target. But the work done by the previous translator, aka CAN packets
assembling to build valid Aseba packets and dis-mangling when several
targets speak at the same time, this work musts be done by the software
stack.
Thus, where should we put this packet management stuff? We have a patch
for Dashel, but it makes Dashel to be dependant of Aseba. If we put this
in Aseba, it breaks the Dashel abstraction principle...
Any proposition? For now, it works well with the patch in Dashel...
As there are other Dashel users than Aseba (sensefly, as far as I know),
I propose not to put this code into Dashel. I propose to put the
protocol-agnostic part into Dashel (so that we can use CAN0 along with a
Dashel Hub), but to put the rest inside its own library, that would be
linked and used by asebaswitch. By the way, are you re-using
transport/can/can-net.*? Because these files already implement the Aseba
CAN protocol. Therefore, it is essentially a matter of glue to add
support for CAN to asebaswitch using them, isn't it?
On my side I plan to use Ubuntu and ROS on the omap3 board, therefore I
will also add CAN support to asebaros, which would reduce delays and
context switches between the CAN bus and ROS.
What do you think?
All the best,
Stéphane
--
Dr Stéphane Magnenat
http://stephane.magnenat.net
_______________________________________________
Aseba-dev mailing list
Aseba-dev@gna.org
https://mail.gna.org/listinfo/aseba-dev
