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

[Isaac Gutekunst]

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
>