Math lib inclusion in BSP not required if CAN drivers are considered

[Pavel Pisa]

Hello Sudarshan,

On Friday 25 of September 2015 19:13:53 sudarshan.rajagopalan wrote:
> On 2015-09-25 12:21, Daniel Gutson wrote:
> > El 25/9/2015 13:17, "sudarshan.rajagopalan"
> >
> > <sudarshan.rajagopalan at vecna.com> escribió:
> >  > On 2015-09-25 11:06, Daniel Gutson wrote:
> >  >> On Thu, Sep 24, 2015 at 4:49 PM, sudarshan.rajagopalan
> >  >>
> >  >> <sudarshan.rajagopalan at vecna.com> wrote:
> >  >>> Hey all,
> >  >>>
> >  >>> We are developing a new BSP that uses math.h in few of the BSP
> >
> > files. I do
> >
> >  >> May I ask why do you need floating point operations in a kernel?
> >
> > At
> >
> >  >> least, what sort of operations and why not move them upwards.
> >  >
> >  > We are doing floating point operations in one of the device drivers
> >
> > as part of the BSP - to perform buadrate calculation, to be specific,
> > which involes inverse operations and using roundf().

If this is part of CAN driver baudrate calculation then floating point
is usually not required and can be sometimes harmfull because you need
to find best matching ratio of integer numbers which are send to controller
registers. See Linux SocketCAN implementation

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/dev.c?id=refs/tags/v4.3-rc3#n74

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/can/netlink.h?id=refs/tags/v4.3-rc3#n46

I have proposed it with structures defining CAN controller
parameters many years ago and it seems that it has been enough
for all controllers supported by Linux drivers.

I suggest to not reinvent the wheel and use solution compatible
with this one because you can use values already tested in the
Linux kernel.

As for the License, actual Linux code has been updated and enhanced
by more people and is strict GPLv2 only. The main change is movement
of sample point computation to the separate function can_update_spt()
and change of sample point specification from 1/100 (%) to 1/1000
fractions.

You can find simpler version in LinCAN driver code

http://sourceforge.net/p/ortcan/lincan/ci/can-usb1/tree/embedded/app/usbcan/lpc17xx_can.c#l90

http://sourceforge.net/p/ortcan/lincan/ci/can-usb1/tree/embedded/app/usbcan/can/can_bittiming.h

where LinCAN is released under license crated specially to be compatible
with RTEMS as well.

Generally, Volkswagen SocketCAN is intended to be available under BSD license
in these parts where it does not directly interact with Linux kernel
structures so I expect that there is no problem when some of Linux
specific enhancements for bitrate calculation are reintroduced in
our code. I check that directly with Linux CAN maintainers
(Oliver Hartkopp, etc.).

I have even userspace test code for these computations and some examples.
I am horribly out of time this and next week but I can clean a dust from
my memory and prepared files after this time and send the utility sources.

But please, if you intend to have generic RTEMS CAN infrastructure,
do not introduce floating point computation to CAN drivers and try
to check if computations introduced by us initially for embedded system
less applications and then selected by Linux kernel community can be used
in RTEMS. It would really simplify new drivers and CAN HW introduction
because you can use already elaborated values instead to reading complex
chip manuals.

Unfortuantelly, I cannot allocate time to RTEMS CAN as I would like.
We have no project at university or company which would backup
the work and there are still even higher priority "hobby" projects
investments on my list - i.e. move forward (with my student) TMS570
BSP networking, QEMU CAN support and some motion control experimental
stuff on RPi, Linux and our conceptually new solution for motor
control current sensing, FPGA D-Q vector control and its combination
with predictive control algorithms.

Best wishes,

               Pavel