[PATCH] RTEMS CAN Rough Draft Implementation

[Gedare Bloom]

On Thu, Aug 27, 2015 at 2:45 PM, Isaac Gutekunst
<isaac.gutekunst at vecna.com> wrote:
> Hi All,
>
> Here is the RTEMS CAN driver framework I've been talking about. Please give
> me feedback, and don't worry about being harsh. I want to commit something
> of value.
>
I found some time this morning, and took a look at the version on
vecna's github and made comments there, mostly related to minor
(style) issues.

Instead of going straight into cpukit, I might prefer to see something
grow organically within libbsp, where the API is malleable. Then, the
below concerns can be dealt with incrementally, until we all are happy
with the interface and it's default implementation.

>
> Concerns
> ========
>
> * Usage of return codes.
> * General higher level error handling.
Yes, the asserts need to change to something more graceful.

> * Changing can bit rate.
Yes, even just adding a stub for functionality to add down-the-road
will be good. Same goes for the data length.

> * In general, changing CAN parameters at runtime.
> * Task model: Should there really be an RX and TX task required by the RTEMS
> driver? Is the method of starting and stopping tasks acceptable?
>
I didn't see the TX task being used.

RX task looks normal enough to me. You may want to look at what is
done with the termios/uart drivers.

> The motivation for this is that the CAN controller we are using, (STM32
> BxCAN) requires you to re-initialize the device to change parameters. This
> is a bit awkward with first calling open, and then IOCTL to configure the
> bus. Any thoughts?
>
This kind of quirk needs to be accommodated for in the driver/BSP
level and not creep into cpukit API design/implementation.

Gedare

> Thanks,
>
> Isaac
>
>
> P.S. I'm having trouble with git send-email. Something is not quite right
> with our mail server here. I've attached the patch instead.
>
> --
> Isaac Gutekunst
> Embedded Systems Software Engineer
> isaac.gutekunst at vecna.com
> www.vecna.com
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel