Hello,
Although this thread mainly concerns Stéphane, it can maybe interest /
concern other people, thus I also post on this list.
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...
Regards,
Florian
_______________________________________________
Aseba-dev mailing list
Aseba-dev@gna.org
https://mail.gna.org/listinfo/aseba-dev
