Math lib inclusion in BSP not required if CAN drivers are considered
sudarshan.rajagopalan at vecna.com
Thu Oct 1 15:15:42 UTC 2015
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
> 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:
> 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.
> 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
>>>> >> least, what sort of operations and why not move them upwards.
>>>> > We are doing floating point operations in one of the device
>>>> as part of the BSP - to perform buadrate calculation, to be
>>>> 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
>> registers. See Linux SocketCAN implementation
>> 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
>> You can find simpler version in LinCAN driver code
>> where LinCAN is released under license crated specially to be
>> with RTEMS as well.
>> Generally, Volkswagen SocketCAN is intended to be available under BSD
>> 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
>> I am horribly out of time this and next week but I can clean a dust
>> my memory and prepared files after this time and send the utility
>> 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
>> less applications and then selected by Linux kernel community can be
>> in RTEMS. It would really simplify new drivers and CAN HW introduction
>> because you can use already elaborated values instead to reading
>> 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,
>> devel mailing list
>> devel at rtems.org
> devel mailing list
> devel at rtems.org
More information about the devel