Hello Prashanth S,

 

the design for the rx data path including the RxFIFO looks promising. If nobody 
is working on it yet, I would try to implement it. You said it still needs to 
be approved - who do I have to contact for this?

 

I think you misunderstood me about the ioctl api. My main question was why 
command and buffer are not passed to the dev_ioctl here:

 

bus->can_dev_ops->dev_ioctl(bus->priv, NULL, 0);

 

Regards

Carlo Brokering

 

Von: Prashanth S <fishesprasha...@gmail.com> 
Gesendet: Mittwoch, 1. März 2023 11:53
An: Brokering, Carlo <carlo.broker...@dlr.de>
Cc: devel@rtems.org
Betreff: Re: CAN driver implementation for Xilinx Zynq

 

Hello @Carlo Brokering,

 

> As part of an internship at the German Aerospace Center, I am currently 
> working on the implementation of a CAN driver for a Xilinx

> Zynq SoC. For this I used the existing CAN framework /dev/can/can.h. A merge 
> request will follow soon.

All the best for your Internship.

> 

>
> Here's what I'd like to add to the framework if it hasn't already been done:
>
> * RxFIFO. Currently can_bus_read only stores the latest CAN message in 
> can_bus->can_rx_msg.

> There is a FIXME note on this in can.c, line 188, but I couldn't find an 
> implementation of it.

Currently, the CAN framework has minimal rx support. The design of the rx data 
path in the CAN Framework is ready (You could use that design if approved or 
you can have your own design).

 

Note: The tx data path has been implemented, it supports multiple open among 
different tasks, configurable buffers.

>
> * ioctl functionality. can_bus_ioctl does not forward the commands and 
> arguments to can_dev_ops->dev_ioctl.

> Is there a reason for that? I propose a command enum that would provide 
> consistency.

The bsp CAN driver should register the ioctl api with the CAN Framework for 
device specific commands (To add commands for hardware independent 
functionality the commands can be added before "if (bus == NULL || 
bus->can_dev_ops->dev_ioctl == NULL)" statement.

 

struct can_dev_ops dev_ops (.dev_ioctl member should be registered).

> 

>
> @Prashanth S (fishesprasha...@gmail.com <mailto:fishesprasha...@gmail.com> ) 
> have you already worked on these points?

 

For the overview of the CAN framework, tx, rx, data paths you can refer the 
docs files in the gitlab link (.puml version of the docs are also available if 
you needed 
(https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/f42e192afefdd94a66456181f9d169f0728d5b4f)).

 

You can use the gitlab 
https://gitlab.com/slpp95prashanth/gsoc-2022/-/tree/can-bsp-docs/can-docs link 
for the design documents.

 

Regards

Prashanth S

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to