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

[sudarshan.rajagopalan]

  +1.

  - Sudarshan

On 2015-10-01 11:06, Isaac Gutekunst wrote:
> Hi Pavel,
> 
> Thanks for the detailed reply. I guess you aren't as "horribly out of
> time" as you said, or perhaps are no even more out of time :)
> 
> We will definitely take a good look at the LinCAN source for baud rate
> calculations.
> 
> The more I think about it, the more I think it's worth to port LinCAN
> to RTEMS, even though it wouldn't be the most trivial. Then we
> wouldn't have yet another CAN implementation that is subtly different
> than LinCAN.
> 
> Here is the file in question:
> 
> https://github.com/vecnatechnologies/rtems/blob/stm32-bsp-rebase-fixes/c/src/lib/libbsp/arm/shared/stm32fxxxx/can/hal-can.c
> 
> Since I wrote it, I think it makes a lot of sense. However, I'll take
> a look at the LinCAN code some more and see if I can understand it.
> 
> 
> Again, thanks for the email.
> 
> Isaac
> 
> 
> 
> On 09/30/2015 06:08 PM, Pavel Pisa wrote:
>> 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
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>> 
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel