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.rajagopa...@vecna.com> escribió: > > > On 2015-09-25 11:06, Daniel Gutson wrote: > > >> On Thu, Sep 24, 2015 at 4:49 PM, sudarshan.rajagopalan > > >> > > >> <sudarshan.rajagopa...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
