Re: CAN driver implementation for Xilinx Zynq
Hi @carlo.broker...@dlr.de , Once the commands are defined the corresponding command and buffer should be passed as arguments. As the commands are not defined Null and zero are passed as buffer and command respectively. Regards Prashanth S On Thu, 2 Mar, 2023, 2:22 pm , wrote: > Hello @Prashanth S > > > > > I saw in discord there was a discussion for the rework of CAN framework, > so you could start a discussion in this mailing list or in discord. > > Good to know. I’ll have a look there. > > > > > The ioctl commands are not defined for the CAN framework, so NULL and 0 > are passed to dev_ioctl. > > Ok but i don't quite understand how commands are otherwise sent to the bsp > driver. > > Should that only work once defined commands have been discussed and > implemented? > > > > > > Best regards > > Carlo Brokering > > > > > > *Von:* Prashanth S > *Gesendet:* Donnerstag, 2. März 2023 07:25 > *An:* Brokering, Carlo > *Cc:* devel@rtems.org > *Betreff:* Re: CAN driver implementation for Xilinx Zynq > > > > Hi @carlo.broker...@dlr.de , > > > > > 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 saw in discord there was a discussion for the rework of CAN framework, > so you could start a discussion in this mailing list or in discord. > > > > > > 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); > > The ioctl commands are not defined for the CAN framework, so NULL and 0 > are passed to dev_ioctl. > > > > Regards > > Prashanth S > > > > On Wed, 1 Mar 2023 at 21:08, wrote: > > 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 > *Gesendet:* Mittwoch, 1. März 2023 11:53 > *An:* Brokering, Carlo > *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) 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 > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: CAN driver implementation for Xilinx Zynq
Hi @carlo.broker...@dlr.de , > 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 saw in discord there was a discussion for the rework of CAN framework, so you could start a discussion in this mailing list or in discord. > > 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); The ioctl commands are not defined for the CAN framework, so NULL and 0 are passed to dev_ioctl. Regards Prashanth S On Wed, 1 Mar 2023 at 21:08, wrote: > 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 > *Gesendet:* Mittwoch, 1. März 2023 11:53 > *An:* Brokering, Carlo > *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) 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 > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
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) 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: CAN Framework Docs for RTEMS-DOCS
Hi All, This is a reminder for the CAN framework docs written with .uml diagrams. Regards Prashanth S On Fri, 25 Nov 2022 at 20:07, Prashanth S wrote: > Hi All, > > This is a review request for CAN Framework docs. > > I pasted the link to gitlab, as the patch size exceeds the mailing list > limit. > https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/869438a9da4a31a69f8d2718d5789d76fe209929 > > Regards > Prashanth S > > On Mon, 14 Nov 2022 at 20:03, Prashanth S > wrote: > >> Hi All, >> >> I have pasted the link to CAN framework docs for rtems-docs. As the patch >> size exceeds the mailing list, so pasted the link to GitLab. >> >> >> https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/01bd99dd8228128fdb5189e65ffa198312012d34 >> >> Regards >> Prashanth S >> > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/4] cpukit/include/dev/can: Added debug print configuration under RTEMS_CAN_DEBUG macro.
Hi All, This is a reminder for review requests for the patches to CAN Framework changes based on review comments. Regards Prashanth S On Fri, 16 Dec 2022 at 18:58, Prashanth S wrote: > --- > cpukit/include/dev/can/can.h | 27 +-- > 1 file changed, 21 insertions(+), 6 deletions(-) > > diff --git a/cpukit/include/dev/can/can.h b/cpukit/include/dev/can/can.h > index 9e55395039..4ee51ebc9d 100644 > --- a/cpukit/include/dev/can/can.h > +++ b/cpukit/include/dev/can/can.h > @@ -53,13 +53,28 @@ >printf(str, ##__VA_ARGS__); > \ > } while (false); > > +#ifdef RTEMS_CAN_DEBUG > + > #define CAN_DEBUG(str, ...) DEBUG(str, ##__VA_ARGS__) > -#define CAN_DEBUG_BUF(str, ...) CAN_DEBUG(str, ##__VA_ARGS__) > -#define CAN_DEBUG_ISR(str, ...) CAN_DEBUG(str, ##__VA_ARGS__) > -#define CAN_DEBUG_LOCK(str, ...) CAN_DEBUG(str, ##__VA_ARGS__) > -#define CAN_DEBUG_RX(str, ...) CAN_DEBUG(str, ##__VA_ARGS__) > -#define CAN_DEBUG_TX(str, ...) CAN_DEBUG(str, ##__VA_ARGS__) > -#define CAN_DEBUG_REG(str, ...) //CAN_DEBUG(str, ##__VA_ARGS__) > +#define CAN_DEBUG_BUF(str, ...) DEBUG(str, ##__VA_ARGS__) > +#define CAN_DEBUG_ISR(str, ...) DEBUG(str, ##__VA_ARGS__) > +#define CAN_DEBUG_LOCK(str, ...) DEBUG(str, ##__VA_ARGS__) > +#define CAN_DEBUG_RX(str, ...) DEBUG(str, ##__VA_ARGS__) > +#define CAN_DEBUG_TX(str, ...) DEBUG(str, ##__VA_ARGS__) > +#define CAN_DEBUG_REG(str, ...) /* CAN_DEBUG(str, ##__VA_ARGS__) */ > + > +#else /* RTEMS_CAN_DEBUG */ > + > +#define CAN_DEBUG(str, ...) > +#define CAN_DEBUG_BUF(str, ...) > +#define CAN_DEBUG_ISR(str, ...) > +#define CAN_DEBUG_LOCK(str, ...) > +#define CAN_DEBUG_RX(str, ...) > +#define CAN_DEBUG_TX(str, ...) > +#define CAN_DEBUG_REG(str, ...) > + > +#endif /* RTEMS_CAN_DEBUG */ > + > #define CAN_ERR(str, ...) DEBUG(str, ##__VA_ARGS__) > > #define CAN_MSG_LEN(msg) ((char *)(&((struct can_msg > *)msg)->data[(uint16_t)((struct can_msg *)msg)->len]) - (char *)(msg)) > -- > 2.25.1 > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/4] cpukit/include/dev/can: Added debug print configuration under RTEMS_CAN_DEBUG macro.
--- cpukit/include/dev/can/can.h | 27 +-- 1 file changed, 21 insertions(+), 6 deletions(-) diff --git a/cpukit/include/dev/can/can.h b/cpukit/include/dev/can/can.h index 9e55395039..4ee51ebc9d 100644 --- a/cpukit/include/dev/can/can.h +++ b/cpukit/include/dev/can/can.h @@ -53,13 +53,28 @@ printf(str, ##__VA_ARGS__); \ } while (false); +#ifdef RTEMS_CAN_DEBUG + #define CAN_DEBUG(str, ...) DEBUG(str, ##__VA_ARGS__) -#define CAN_DEBUG_BUF(str, ...) CAN_DEBUG(str, ##__VA_ARGS__) -#define CAN_DEBUG_ISR(str, ...) CAN_DEBUG(str, ##__VA_ARGS__) -#define CAN_DEBUG_LOCK(str, ...) CAN_DEBUG(str, ##__VA_ARGS__) -#define CAN_DEBUG_RX(str, ...) CAN_DEBUG(str, ##__VA_ARGS__) -#define CAN_DEBUG_TX(str, ...) CAN_DEBUG(str, ##__VA_ARGS__) -#define CAN_DEBUG_REG(str, ...) //CAN_DEBUG(str, ##__VA_ARGS__) +#define CAN_DEBUG_BUF(str, ...) DEBUG(str, ##__VA_ARGS__) +#define CAN_DEBUG_ISR(str, ...) DEBUG(str, ##__VA_ARGS__) +#define CAN_DEBUG_LOCK(str, ...) DEBUG(str, ##__VA_ARGS__) +#define CAN_DEBUG_RX(str, ...) DEBUG(str, ##__VA_ARGS__) +#define CAN_DEBUG_TX(str, ...) DEBUG(str, ##__VA_ARGS__) +#define CAN_DEBUG_REG(str, ...) /* CAN_DEBUG(str, ##__VA_ARGS__) */ + +#else /* RTEMS_CAN_DEBUG */ + +#define CAN_DEBUG(str, ...) +#define CAN_DEBUG_BUF(str, ...) +#define CAN_DEBUG_ISR(str, ...) +#define CAN_DEBUG_LOCK(str, ...) +#define CAN_DEBUG_RX(str, ...) +#define CAN_DEBUG_TX(str, ...) +#define CAN_DEBUG_REG(str, ...) + +#endif /* RTEMS_CAN_DEBUG */ + #define CAN_ERR(str, ...) DEBUG(str, ##__VA_ARGS__) #define CAN_MSG_LEN(msg) ((char *)(&((struct can_msg *)msg)->data[(uint16_t)((struct can_msg *)msg)->len]) - (char *)(msg)) -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 4/4] cpukit/dev/can: Fix 64 bit build compilation warnings
---
cpukit/dev/can/can.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c
index 7098ce16c2..ca855951d5 100644
--- a/cpukit/dev/can/can.c
+++ b/cpukit/dev/can/can.c
@@ -203,7 +203,7 @@ static ssize_t can_bus_read(rtems_libio_t *iop, void
*buffer, size_t count)
len = CAN_MSG_LEN(>can_rx_msg);
if (count < len) {
-CAN_DEBUG("can_bus_read: buffer size is small min sizeof(struct can_msg) =
%u\n",
+CAN_DEBUG("can_bus_read: buffer size is small min sizeof(struct can_msg) =
%zu\n",
sizeof(struct can_msg));
return -RTEMS_INVALID_SIZE;
}
--
2.25.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/4] cpukit/dev/can: Removed extra debug prints in CAN Framework
---
cpukit/dev/can/can.c | 20
1 file changed, 20 deletions(-)
diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c
index 2e6d5df65b..7098ce16c2 100644
--- a/cpukit/dev/can/can.c
+++ b/cpukit/dev/can/can.c
@@ -73,19 +73,14 @@ static int try_sem(struct can_bus *);
static int take_sem(struct can_bus *);
static int give_sem(struct can_bus *);
-
static void can_bus_obtain(can_bus *bus)
{
- CAN_DEBUG("can_bus_obtain Entry\n");
rtems_mutex_lock(>mutex);
- CAN_DEBUG("can_bus_obtain Exit\n");
}
static void can_bus_release(can_bus *bus)
{
- CAN_DEBUG("can_bus_release Entry\n");
rtems_mutex_unlock(>mutex);
- CAN_DEBUG("can_bus_release Exit\n");
}
static void can_bus_destroy_mutex(struct can_bus *bus)
@@ -182,8 +177,6 @@ static int try_sem(struct can_bus *bus)
static ssize_t
can_bus_open(rtems_libio_t *iop, const char *path, int oflag, mode_t mode)
{
- CAN_DEBUG("can_bus_open\n");
-
return 0;
}
@@ -231,21 +224,16 @@ static int can_xmit(struct can_bus *bus)
struct can_msg *msg = NULL;
- CAN_DEBUG(" can_xmit Entry\n");
-
while (1) {
-CAN_DEBUG("can_dev_ops->dev_tx_ready\n");
if (bus->can_dev_ops->dev_tx_ready(bus->priv) != true) {
break;
}
-CAN_DEBUG("can_tx_get_data_buf\n");
msg = can_bus_tx_get_data_buf(bus);
if (msg == NULL) {
break;
}
-CAN_DEBUG("can_dev_ops->dev_tx\n");
ret = bus->can_dev_ops->dev_tx(bus->priv, msg);
if (ret != RTEMS_SUCCESSFUL) {
CAN_ERR("can_xmit: dev_send failed\n");
@@ -259,8 +247,6 @@ static int can_xmit(struct can_bus *bus)
}
}
- CAN_DEBUG(" can_xmit Exit\n");
-
return ret;
}
@@ -284,13 +270,11 @@ void can_print_msg(struct can_msg const *msg)
/* can_tx_done should be called only with CAN interrupts disabled */
int can_tx_done(struct can_bus *bus)
{
- CAN_DEBUG(" can_tx_done Entry\n");
int ret = RTEMS_SUCCESSFUL;
if (bus->can_dev_ops->dev_tx_ready(bus->priv) == true) {
ret = can_xmit(bus);
}
- CAN_DEBUG(" can_tx_done Exit\n");
return ret;
}
@@ -312,7 +296,6 @@ can_bus_write(rtems_libio_t *iop, const void *buffer,
size_t count)
uint32_t msg_size = CAN_MSG_LEN(msg);
- CAN_DEBUG_TX("can_bus_write: can_msg_size = %u\n", msg_size);
if (msg_size > sizeof(struct can_msg)) {
CAN_ERR("can_bus_write:"
"can message len error msg_size = %u struct can_msg = %u\n",
@@ -343,9 +326,7 @@ can_bus_write(rtems_libio_t *iop, const void *buffer,
size_t count)
goto release_lock_and_return;
}
- CAN_DEBUG_TX("can_bus_write: empty_count = %u\n", bus->tx_fifo.empty_count);
- CAN_DEBUG_TX("can_bus_write: copying msg from application to driver
buffer\n");
memcpy(fifo_buf, msg, msg_size);
if (bus->can_dev_ops->dev_tx_ready(bus->priv) == true) {
@@ -426,7 +407,6 @@ rtems_status_code can_bus_register(can_bus *bus, const char
*bus_path)
}
bus->index = index++;
- CAN_DEBUG("Registering CAN bus index = %u\n", bus->index);
ret = IMFS_make_generic_node(bus_path, S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO,
_bus_node_control, bus);
--
2.25.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 3/4] testsuites/libtests/can01: Serialize CAN write and read messages among the tasks
The CAN framework has minimal Rx implementation, so to test loopback
driver the test application is modified to write and read atomically
---
testsuites/libtests/can01/init.c | 69 ++--
1 file changed, 30 insertions(+), 39 deletions(-)
diff --git a/testsuites/libtests/can01/init.c b/testsuites/libtests/can01/init.c
index 0675fe606f..235651d06d 100644
--- a/testsuites/libtests/can01/init.c
+++ b/testsuites/libtests/can01/init.c
@@ -63,6 +63,10 @@
else \
c4++ \
+struct test_thread {
+ rtems_mutex mutex;
+};
+
static void test_task(rtems_task_argument);
int can_loopback_init(const char *);
int create_task(int);
@@ -70,60 +74,54 @@ int create_task(int);
static rtems_id task_id[TASKS];
static rtems_id task_test_status[TASKS] = {[0 ... (TASKS - 1)] = false};
+static struct test_thread thread;
+
const char rtems_test_name[] = "CAN test TX, RX with CAN loopback driver";
-/*FIXME: Should Implement one more test application for the
- * RTR support
- *
- * For testing, the number of successful read and write
- * count is verified.
- */
static void test_task(rtems_task_argument data)
{
- //sleep so that other tasks will be created.
sleep(1);
int fd, task_num = (uint32_t)data;
uint32_t count = 0, msg_size;
- struct can_msg msg;
+ struct can_msg send_msg, recv_msg;
printf("CAN tx and rx for %s\n", CAN_DEV_FILE);
fd = open(CAN_DEV_FILE, O_RDWR);
if (fd < 0) {
-printf("open error: task = %u %s: %s\n", task_num, CAN_DEV_FILE,
strerror(errno));
+printf("error: open task = %u %s: %s\n", task_num, CAN_DEV_FILE,
strerror(errno));
}
rtems_test_assert(fd >= 0);
for (int i = 0; i < NUM_TEST_MSGS; i++) {
-printf("test_task %u\n", task_num);
-
-msg.id = task_num;
-//FIXME: Implement Test cases for other flags also.
-msg.flags = 0;
-msg.len = (i + 1) % 9;
+send_msg.id = task_num;
+send_msg.flags = 0;
+send_msg.len = (i + 1) % 9;
-for (int j = 0; j < msg.len; j++) {
- msg.data[j] = 'a' + j;
+for (int j = 0; j < send_msg.len; j++) {
+ send_msg.data[j] = 'a' + j;
}
-msg_size = ((char *)[msg.len] - (char *));
+msg_size = ((char *)_msg.data[send_msg.len] - (char *)_msg);
-printf("calling write task = %u\n", task_num);
+rtems_mutex_lock();
-count = write(fd, , sizeof(msg));
+count = write(fd, _msg, sizeof(send_msg));
rtems_test_assert(count == msg_size);
-printf("task = %u write count = %u\n", task_num, count);
-printf("calling read task = %u\n", task_num);
-count = read(fd, , sizeof(msg));
-rtems_test_assert(count > 0);
-printf("task = %u read count = %u\n", task_num, count);
+count = read(fd, _msg, sizeof(recv_msg));
+rtems_test_assert(send_msg.len == recv_msg.len);
+
+for (int i = 0; i < recv_msg.len; i++) {
+ rtems_test_assert(send_msg.data[i] == recv_msg.data[i]);
+}
-printf("received message\n");
-can_print_msg();
+rtems_mutex_unlock();
+
+can_print_msg(_msg);
sleep(1);
}
@@ -131,14 +129,11 @@ static void test_task(rtems_task_argument data)
task_test_status[task_num] = true;
- printf("task exited = %u\n", task_num);
rtems_task_exit();
}
int create_task(int i)
{
- printf("Creating task %d\n", i);
-
rtems_status_code result;
rtems_name name;
@@ -156,21 +151,18 @@ int create_task(int i)
RTEMS_FIFO | RTEMS_FLOATING_POINT,
_id[i]);
if (result != RTEMS_SUCCESSFUL) {
-printf("rtems_task_create error: %s\n", rtems_status_text(result));
+printf("error rtems_task_create: %s\n", rtems_status_text(result));
rtems_test_assert(result == RTEMS_SUCCESSFUL);
}
- printf("number = %3" PRIi32 ", id = %08" PRIxrtems_id ", starting, ", i,
task_id[i]);
-
fflush(stdout);
- printf("starting task\n");
result = rtems_task_start(task_id[i],
test_task,
(rtems_task_argument)i);
if (result != RTEMS_SUCCESSFUL) {
-printf("rtems_task_start failed %s\n", rtems_status_text(result));
+printf("error rtems_task_start: %s\n", rtems_status_text(result));
rtems_test_assert(result == RTEMS_SUCCESSFUL);
}
@@ -183,8 +175,6 @@ static rtems_task Init(
rtems_task_argument ignored
)
{
- printf("Init\n");
-
int ret;
rtems_print_printer_fprintf_putc(_test_printer);
@@ -199,10 +189,12 @@ static rtems_task Init(
ret = can_loopback_init(CAN_DEV_FILE);
if (ret != RTEMS_SUCCESSFUL) {
-printf("%s failed\n", rtems_test_name);
+printf("error: %s failed\n", rtems_test_name);
rtems_test_assert(ret == RTEMS_SUCCESSFUL);
}
+ rtems_mutex_init(, "CAN test");
+
for (int i = 0; i < TASKS; i++) {
Re: [PATCH 1/2] testsuites/libtests/can01: Serialize CAN write and read messages among the tasks
>> >> +++ b/testsuites/libtests/can01/init.c
>> >> @@ -48,7 +48,7 @@
>> >> if (c3 == '9') { \
>> >> if (c2 == 'z') { \
>> >> if (c1 == 'z') { \
>> >> - printf("not enough task letters for names
>> !!!\n"); \
>> >> + CAN_ERR("not enough task letters for names
>> !!!\n"); \
>> >
>> >I don't think the print statements need to be macro'd in your test, so
>> >long as they only get printed when the test fails. When it's passing,
>> >then we would prefer it be quiet.
>>
>> The CAN_ERR expands to printing the file name, line number, thread
>> id and error message.
>>
>> Can we have this information printed by expanded macro or change to
>> printf?
>
>The RTEMS Test Framework does all this. Why do we have to implement
>things specifically for this test?
Ok, updating CAN_ERR to printf.
Regards
Prashanth S
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/4] cpukit/include/dev/can: Added debug print configuration under RTEMS_CAN_DEBUG macro.
>How does this debugging get turned on/off? -DRTEMS_CAN_DEBUG as a Compiler Flag will enable the debug prints. > >maybe use CAN_ERROR? unless there's a reason not to. The debug #defines helps us to have control over the debug prints based on the entity (isr, locks, rx, tx). This helps the BSP CAN driver development to have debug prints based on the entity (isr, locks, rx, tx). Can we have this feature? > >> #define CAN_MSG_LEN(msg) ((char *)(&((struct can_msg *)msg)->data[(uint16_t)((struct can_msg *)msg)->len]) - (char *)(msg)) On Thu, 15 Dec 2022 at 02:55, Gedare Bloom wrote: > How does this debugging get turned on/off? > > > On Sat, Dec 3, 2022 at 2:00 AM Prashanth S > wrote: > > > > --- > > cpukit/include/dev/can/can.h | 27 +-- > > 1 file changed, 21 insertions(+), 6 deletions(-) > > > > diff --git a/cpukit/include/dev/can/can.h b/cpukit/include/dev/can/can.h > > index 9e55395039..4ee51ebc9d 100644 > > --- a/cpukit/include/dev/can/can.h > > +++ b/cpukit/include/dev/can/can.h > > @@ -53,13 +53,28 @@ > >printf(str, ##__VA_ARGS__); >\ > > } while (false); > > > > +#ifdef RTEMS_CAN_DEBUG > > + > > #define CAN_DEBUG(str, ...) DEBUG(str, ##__VA_ARGS__) > > -#define CAN_DEBUG_BUF(str, ...) CAN_DEBUG(str, ##__VA_ARGS__) > > -#define CAN_DEBUG_ISR(str, ...) CAN_DEBUG(str, ##__VA_ARGS__) > > -#define CAN_DEBUG_LOCK(str, ...) CAN_DEBUG(str, ##__VA_ARGS__) > > -#define CAN_DEBUG_RX(str, ...) CAN_DEBUG(str, ##__VA_ARGS__) > > -#define CAN_DEBUG_TX(str, ...) CAN_DEBUG(str, ##__VA_ARGS__) > > -#define CAN_DEBUG_REG(str, ...) //CAN_DEBUG(str, ##__VA_ARGS__) > > +#define CAN_DEBUG_BUF(str, ...) DEBUG(str, ##__VA_ARGS__) > > +#define CAN_DEBUG_ISR(str, ...) DEBUG(str, ##__VA_ARGS__) > > +#define CAN_DEBUG_LOCK(str, ...) DEBUG(str, ##__VA_ARGS__) > > +#define CAN_DEBUG_RX(str, ...) DEBUG(str, ##__VA_ARGS__) > > +#define CAN_DEBUG_TX(str, ...) DEBUG(str, ##__VA_ARGS__) > > +#define CAN_DEBUG_REG(str, ...) /* CAN_DEBUG(str, ##__VA_ARGS__) */ > > + > > +#else /* RTEMS_CAN_DEBUG */ > > + > > +#define CAN_DEBUG(str, ...) > > +#define CAN_DEBUG_BUF(str, ...) > > +#define CAN_DEBUG_ISR(str, ...) > > +#define CAN_DEBUG_LOCK(str, ...) > > +#define CAN_DEBUG_RX(str, ...) > > +#define CAN_DEBUG_TX(str, ...) > > +#define CAN_DEBUG_REG(str, ...) > > + > > +#endif /* RTEMS_CAN_DEBUG */ > > + > > #define CAN_ERR(str, ...) DEBUG(str, ##__VA_ARGS__) > > > maybe use CAN_ERROR? unless there's a reason not to. > > > #define CAN_MSG_LEN(msg) ((char *)(&((struct can_msg > *)msg)->data[(uint16_t)((struct can_msg *)msg)->len]) - (char *)(msg)) > > -- > > 2.25.1 > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/2] testsuites/libtests/can01: Serialize CAN write and read messages among the tasks
>>
>> The CAN framework has minimal Rx implementation, so to test loopback
>> driver the test application is modified to write and read atomically
>> ---
>> testsuites/libtests/can01/init.c | 71 ++--
>> 1 file changed, 31 insertions(+), 40 deletions(-)
>>
>> diff --git a/testsuites/libtests/can01/init.c
b/testsuites/libtests/can01/init.c
>> index 0675fe606f..f70e68fb51 100644
>> --- a/testsuites/libtests/can01/init.c
>> +++ b/testsuites/libtests/can01/init.c
>> @@ -48,7 +48,7 @@
>> if (c3 == '9') { \
>> if (c2 == 'z') { \
>> if (c1 == 'z') { \
>> - printf("not enough task letters for names
!!!\n"); \
>> + CAN_ERR("not enough task letters for names
!!!\n"); \
>
>I don't think the print statements need to be macro'd in your test, so
>long as they only get printed when the test fails. When it's passing,
>then we would prefer it be quiet.
The CAN_ERR expands to printing the file name, line number, thread id and
error message.
Can we have this information printed by expanded macro or change to printf?
On Thu, 15 Dec 2022 at 02:57, Gedare Bloom wrote:
> On Sat, Dec 3, 2022 at 2:02 AM Prashanth S
> wrote:
> >
> > The CAN framework has minimal Rx implementation, so to test loopback
> > driver the test application is modified to write and read atomically
> > ---
> > testsuites/libtests/can01/init.c | 71 ++--
> > 1 file changed, 31 insertions(+), 40 deletions(-)
> >
> > diff --git a/testsuites/libtests/can01/init.c
> b/testsuites/libtests/can01/init.c
> > index 0675fe606f..f70e68fb51 100644
> > --- a/testsuites/libtests/can01/init.c
> > +++ b/testsuites/libtests/can01/init.c
> > @@ -48,7 +48,7 @@
> > if (c3 == '9') { \
> > if (c2 == 'z') { \
> > if (c1 == 'z') { \
> > - printf("not enough task letters for names
> !!!\n"); \
> > + CAN_ERR("not enough task letters for names
> !!!\n"); \
>
> I don't think the print statements need to be macro'd in your test, so
> long as they only get printed when the test fails. When it's passing,
> then we would prefer it be quiet.
>
> > exit( 1 ); \
> > } else \
> > c1++; \
> > @@ -63,6 +63,10 @@
> > else \
> > c4++ \
> >
> > +struct test_thread {
> > + rtems_mutex mutex;
> > +};
> > +
> > static void test_task(rtems_task_argument);
> > int can_loopback_init(const char *);
> > int create_task(int);
> > @@ -70,60 +74,54 @@ int create_task(int);
> > static rtems_id task_id[TASKS];
> > static rtems_id task_test_status[TASKS] = {[0 ... (TASKS - 1)] = false};
> >
> > +static struct test_thread thread;
> > +
> > const char rtems_test_name[] = "CAN test TX, RX with CAN loopback
> driver";
> >
> > -/*FIXME: Should Implement one more test application for the
> > - * RTR support
> > - *
> > - * For testing, the number of successful read and write
> > - * count is verified.
> > - */
> > static void test_task(rtems_task_argument data)
> > {
> > - //sleep so that other tasks will be created.
> >sleep(1);
> >
> >int fd, task_num = (uint32_t)data;
> >uint32_t count = 0, msg_size;
> >
> > - struct can_msg msg;
> > + struct can_msg send_msg, recv_msg;
> >
> >printf("CAN tx and rx for %s\n", CAN_DEV_FILE);
> >
> >fd = open(CAN_DEV_FILE, O_RDWR);
> >if (fd < 0) {
> > -printf("open error: task = %u %s: %s\n", task_num, CAN_DEV_FILE,
> strerror(errno));
> > +CAN_ERR("open error: task = %u %s: %s\n", task_num, CAN_DEV_FILE,
> strerror(errno));
> >}
> >
> >rtems_test_assert(fd >= 0);
> >
> >for (int i = 0; i < NUM_TEST_MSGS; i++) {
> > -printf("test_task %u\n", task_num);
> > -
> > -msg.id = task_num;
> > -//FIXME: Implement Test cases for other flags also.
> > -msg.flags = 0;
> > -msg.len = (i + 1) % 9;
> > +send_msg.id = task_num;
> > +send_msg.flags = 0;
> > +send_msg.len = (i + 1) % 9;
> >
> > -for (int j = 0; j < msg.len; j++) {
&
[PATCH 2/2] cpukit/dev/can: Fix 64 bit build compilation warnings
---
cpukit/dev/can/can.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c
index 7098ce16c2..2462df7e25 100644
--- a/cpukit/dev/can/can.c
+++ b/cpukit/dev/can/can.c
@@ -204,7 +204,7 @@ static ssize_t can_bus_read(rtems_libio_t *iop, void
*buffer, size_t count)
if (count < len) {
CAN_DEBUG("can_bus_read: buffer size is small min sizeof(struct can_msg) =
%u\n",
-sizeof(struct can_msg));
+(uint32_t)sizeof(struct can_msg));
return -RTEMS_INVALID_SIZE;
}
--
2.25.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/2] testsuites/libtests/can01: Serialize CAN write and read messages among the tasks
The CAN framework has minimal Rx implementation, so to test loopback
driver the test application is modified to write and read atomically
---
testsuites/libtests/can01/init.c | 71 ++--
1 file changed, 31 insertions(+), 40 deletions(-)
diff --git a/testsuites/libtests/can01/init.c b/testsuites/libtests/can01/init.c
index 0675fe606f..f70e68fb51 100644
--- a/testsuites/libtests/can01/init.c
+++ b/testsuites/libtests/can01/init.c
@@ -48,7 +48,7 @@
if (c3 == '9') { \
if (c2 == 'z') { \
if (c1 == 'z') { \
- printf("not enough task letters for names !!!\n"); \
+ CAN_ERR("not enough task letters for names !!!\n"); \
exit( 1 ); \
} else \
c1++; \
@@ -63,6 +63,10 @@
else \
c4++ \
+struct test_thread {
+ rtems_mutex mutex;
+};
+
static void test_task(rtems_task_argument);
int can_loopback_init(const char *);
int create_task(int);
@@ -70,60 +74,54 @@ int create_task(int);
static rtems_id task_id[TASKS];
static rtems_id task_test_status[TASKS] = {[0 ... (TASKS - 1)] = false};
+static struct test_thread thread;
+
const char rtems_test_name[] = "CAN test TX, RX with CAN loopback driver";
-/*FIXME: Should Implement one more test application for the
- * RTR support
- *
- * For testing, the number of successful read and write
- * count is verified.
- */
static void test_task(rtems_task_argument data)
{
- //sleep so that other tasks will be created.
sleep(1);
int fd, task_num = (uint32_t)data;
uint32_t count = 0, msg_size;
- struct can_msg msg;
+ struct can_msg send_msg, recv_msg;
printf("CAN tx and rx for %s\n", CAN_DEV_FILE);
fd = open(CAN_DEV_FILE, O_RDWR);
if (fd < 0) {
-printf("open error: task = %u %s: %s\n", task_num, CAN_DEV_FILE,
strerror(errno));
+CAN_ERR("open error: task = %u %s: %s\n", task_num, CAN_DEV_FILE,
strerror(errno));
}
rtems_test_assert(fd >= 0);
for (int i = 0; i < NUM_TEST_MSGS; i++) {
-printf("test_task %u\n", task_num);
-
-msg.id = task_num;
-//FIXME: Implement Test cases for other flags also.
-msg.flags = 0;
-msg.len = (i + 1) % 9;
+send_msg.id = task_num;
+send_msg.flags = 0;
+send_msg.len = (i + 1) % 9;
-for (int j = 0; j < msg.len; j++) {
- msg.data[j] = 'a' + j;
+for (int j = 0; j < send_msg.len; j++) {
+ send_msg.data[j] = 'a' + j;
}
-msg_size = ((char *)[msg.len] - (char *));
+msg_size = ((char *)_msg.data[send_msg.len] - (char *)_msg);
-printf("calling write task = %u\n", task_num);
+rtems_mutex_lock();
-count = write(fd, , sizeof(msg));
+count = write(fd, _msg, sizeof(send_msg));
rtems_test_assert(count == msg_size);
-printf("task = %u write count = %u\n", task_num, count);
-printf("calling read task = %u\n", task_num);
-count = read(fd, , sizeof(msg));
-rtems_test_assert(count > 0);
-printf("task = %u read count = %u\n", task_num, count);
+count = read(fd, _msg, sizeof(recv_msg));
+rtems_test_assert(send_msg.len == recv_msg.len);
+
+for (int i = 0; i < recv_msg.len; i++) {
+ rtems_test_assert(send_msg.data[i] == recv_msg.data[i]);
+}
-printf("received message\n");
-can_print_msg();
+rtems_mutex_unlock();
+
+can_print_msg(_msg);
sleep(1);
}
@@ -131,14 +129,11 @@ static void test_task(rtems_task_argument data)
task_test_status[task_num] = true;
- printf("task exited = %u\n", task_num);
rtems_task_exit();
}
int create_task(int i)
{
- printf("Creating task %d\n", i);
-
rtems_status_code result;
rtems_name name;
@@ -156,21 +151,18 @@ int create_task(int i)
RTEMS_FIFO | RTEMS_FLOATING_POINT,
_id[i]);
if (result != RTEMS_SUCCESSFUL) {
-printf("rtems_task_create error: %s\n", rtems_status_text(result));
+CAN_ERR("rtems_task_create error: %s\n", rtems_status_text(result));
rtems_test_assert(result == RTEMS_SUCCESSFUL);
}
- printf("number = %3" PRIi32 ", id = %08" PRIxrtems_id ", starting, ", i,
task_id[i]);
-
fflush(stdout);
- printf("starting task\n");
result = rtems_task_start(task_id[i],
test_task,
(rtems_task_argument)i);
if (result != RTEMS_SUCCESSFUL) {
-printf("rtems_task_start failed %s\n", rtems_status_text(result));
+CAN_ERR("rtems_task_start failed %s\n", rtems_status_text(result));
rtems_test_assert(result == RTEMS_SUCCESSFUL);
}
@@ -183,8 +175,6 @@ static rtems_task Init(
rtems_task_argument ignored
)
{
-
[PATCH 2/4] cpukit/dev/can: Removed extra debug prints in CAN Framework
---
cpukit/dev/can/can.c | 20
1 file changed, 20 deletions(-)
diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c
index 2e6d5df65b..7098ce16c2 100644
--- a/cpukit/dev/can/can.c
+++ b/cpukit/dev/can/can.c
@@ -73,19 +73,14 @@ static int try_sem(struct can_bus *);
static int take_sem(struct can_bus *);
static int give_sem(struct can_bus *);
-
static void can_bus_obtain(can_bus *bus)
{
- CAN_DEBUG("can_bus_obtain Entry\n");
rtems_mutex_lock(>mutex);
- CAN_DEBUG("can_bus_obtain Exit\n");
}
static void can_bus_release(can_bus *bus)
{
- CAN_DEBUG("can_bus_release Entry\n");
rtems_mutex_unlock(>mutex);
- CAN_DEBUG("can_bus_release Exit\n");
}
static void can_bus_destroy_mutex(struct can_bus *bus)
@@ -182,8 +177,6 @@ static int try_sem(struct can_bus *bus)
static ssize_t
can_bus_open(rtems_libio_t *iop, const char *path, int oflag, mode_t mode)
{
- CAN_DEBUG("can_bus_open\n");
-
return 0;
}
@@ -231,21 +224,16 @@ static int can_xmit(struct can_bus *bus)
struct can_msg *msg = NULL;
- CAN_DEBUG(" can_xmit Entry\n");
-
while (1) {
-CAN_DEBUG("can_dev_ops->dev_tx_ready\n");
if (bus->can_dev_ops->dev_tx_ready(bus->priv) != true) {
break;
}
-CAN_DEBUG("can_tx_get_data_buf\n");
msg = can_bus_tx_get_data_buf(bus);
if (msg == NULL) {
break;
}
-CAN_DEBUG("can_dev_ops->dev_tx\n");
ret = bus->can_dev_ops->dev_tx(bus->priv, msg);
if (ret != RTEMS_SUCCESSFUL) {
CAN_ERR("can_xmit: dev_send failed\n");
@@ -259,8 +247,6 @@ static int can_xmit(struct can_bus *bus)
}
}
- CAN_DEBUG(" can_xmit Exit\n");
-
return ret;
}
@@ -284,13 +270,11 @@ void can_print_msg(struct can_msg const *msg)
/* can_tx_done should be called only with CAN interrupts disabled */
int can_tx_done(struct can_bus *bus)
{
- CAN_DEBUG(" can_tx_done Entry\n");
int ret = RTEMS_SUCCESSFUL;
if (bus->can_dev_ops->dev_tx_ready(bus->priv) == true) {
ret = can_xmit(bus);
}
- CAN_DEBUG(" can_tx_done Exit\n");
return ret;
}
@@ -312,7 +296,6 @@ can_bus_write(rtems_libio_t *iop, const void *buffer,
size_t count)
uint32_t msg_size = CAN_MSG_LEN(msg);
- CAN_DEBUG_TX("can_bus_write: can_msg_size = %u\n", msg_size);
if (msg_size > sizeof(struct can_msg)) {
CAN_ERR("can_bus_write:"
"can message len error msg_size = %u struct can_msg = %u\n",
@@ -343,9 +326,7 @@ can_bus_write(rtems_libio_t *iop, const void *buffer,
size_t count)
goto release_lock_and_return;
}
- CAN_DEBUG_TX("can_bus_write: empty_count = %u\n", bus->tx_fifo.empty_count);
- CAN_DEBUG_TX("can_bus_write: copying msg from application to driver
buffer\n");
memcpy(fifo_buf, msg, msg_size);
if (bus->can_dev_ops->dev_tx_ready(bus->priv) == true) {
@@ -426,7 +407,6 @@ rtems_status_code can_bus_register(can_bus *bus, const char
*bus_path)
}
bus->index = index++;
- CAN_DEBUG("Registering CAN bus index = %u\n", bus->index);
ret = IMFS_make_generic_node(bus_path, S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO,
_bus_node_control, bus);
--
2.25.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/4] cpukit/include/dev/can: Added debug print configuration under RTEMS_CAN_DEBUG macro.
--- cpukit/include/dev/can/can.h | 27 +-- 1 file changed, 21 insertions(+), 6 deletions(-) diff --git a/cpukit/include/dev/can/can.h b/cpukit/include/dev/can/can.h index 9e55395039..4ee51ebc9d 100644 --- a/cpukit/include/dev/can/can.h +++ b/cpukit/include/dev/can/can.h @@ -53,13 +53,28 @@ printf(str, ##__VA_ARGS__); \ } while (false); +#ifdef RTEMS_CAN_DEBUG + #define CAN_DEBUG(str, ...) DEBUG(str, ##__VA_ARGS__) -#define CAN_DEBUG_BUF(str, ...) CAN_DEBUG(str, ##__VA_ARGS__) -#define CAN_DEBUG_ISR(str, ...) CAN_DEBUG(str, ##__VA_ARGS__) -#define CAN_DEBUG_LOCK(str, ...) CAN_DEBUG(str, ##__VA_ARGS__) -#define CAN_DEBUG_RX(str, ...) CAN_DEBUG(str, ##__VA_ARGS__) -#define CAN_DEBUG_TX(str, ...) CAN_DEBUG(str, ##__VA_ARGS__) -#define CAN_DEBUG_REG(str, ...) //CAN_DEBUG(str, ##__VA_ARGS__) +#define CAN_DEBUG_BUF(str, ...) DEBUG(str, ##__VA_ARGS__) +#define CAN_DEBUG_ISR(str, ...) DEBUG(str, ##__VA_ARGS__) +#define CAN_DEBUG_LOCK(str, ...) DEBUG(str, ##__VA_ARGS__) +#define CAN_DEBUG_RX(str, ...) DEBUG(str, ##__VA_ARGS__) +#define CAN_DEBUG_TX(str, ...) DEBUG(str, ##__VA_ARGS__) +#define CAN_DEBUG_REG(str, ...) /* CAN_DEBUG(str, ##__VA_ARGS__) */ + +#else /* RTEMS_CAN_DEBUG */ + +#define CAN_DEBUG(str, ...) +#define CAN_DEBUG_BUF(str, ...) +#define CAN_DEBUG_ISR(str, ...) +#define CAN_DEBUG_LOCK(str, ...) +#define CAN_DEBUG_RX(str, ...) +#define CAN_DEBUG_TX(str, ...) +#define CAN_DEBUG_REG(str, ...) + +#endif /* RTEMS_CAN_DEBUG */ + #define CAN_ERR(str, ...) DEBUG(str, ##__VA_ARGS__) #define CAN_MSG_LEN(msg) ((char *)(&((struct can_msg *)msg)->data[(uint16_t)((struct can_msg *)msg)->len]) - (char *)(msg)) -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit/include/dev/can: Disabled debug prints in CAN Framework
>The CAN bus changes have warnings ...
>
>In file included from ../../../cpukit/include/dev/can/canqueueimpl.h:48,
>from ../../../cpukit/dev/can/can.c:45:
>../../../cpukit/dev/can/can.c: In function 'can_bus_read':
>../../../cpukit/dev/can/can.c:213:15: warning: format '%u' expects
argument of
>type 'unsigned int', but argument 2 has type 'long unsigned int'
[-Wformat=]
> 213 | CAN_DEBUG("can_bus_read: buffer size is small min sizeof(struct
>can_msg) = %u\n",
> |
>^~
> 214 | sizeof(struct can_msg));
> | ~~
> | |
> | long unsigned int
>../../../cpukit/include/dev/can/can.h:53:14: note: in definition of macro
>
>etc etc etc
>
>Can these please be fixed? Use #4662.
Yes, I will typecast the value returned by sizeof().
Regards
Prashanth S
On Fri, 2 Dec 2022 at 09:09, Chris Johns wrote:
> The CAN bus changes have warnings ...
>
> In file included from ../../../cpukit/include/dev/can/canqueueimpl.h:48,
> from ../../../cpukit/dev/can/can.c:45:
> ../../../cpukit/dev/can/can.c: In function 'can_bus_read':
> ../../../cpukit/dev/can/can.c:213:15: warning: format '%u' expects
> argument of
> type 'unsigned int', but argument 2 has type 'long unsigned int'
> [-Wformat=]
> 213 | CAN_DEBUG("can_bus_read: buffer size is small min sizeof(struct
> can_msg) = %u\n",
> |
> ^~
> 214 | sizeof(struct can_msg));
> | ~~
> | |
> | long unsigned int
> ../../../cpukit/include/dev/can/can.h:53:14: note: in definition of macro
>
> etc etc etc
>
> Can these please be fixed? Use #4662.
>
> Thanks
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit/include/dev/can: Disabled debug prints in CAN Framework
>On Tue, Nov 29, 2022 at 6:58 AM Prashanth S
wrote:
>>
>> > On 29/11/2022 05:57, Gedare Bloom wrote:
>> > >> @@ -111,18 +113,18 @@ static void test_task(rtems_task_argument
data)
>> > >>
>> > >> msg_size = ((char *)[msg.len] - (char *));
>> > >>
>> > >> -printf("calling write task = %u\n", task_num);
>> > >> +CAN_DEBUG("calling write task = %u\n", task_num);
>> > > The general philosophy in our test suite is to only print something
if
>> > > there's a failure. So just remove these debug statements that are
>> > > leftover from your development approach.
>> >
>> > Another approach could be to use the RTEMS Test Framework in which the
>> > test verbosity is controlled by a configuration option.
>>
>> I will look into the RTEMS Test Framework.
>>
>> >
>> > >
>> > >> count = write(fd, , sizeof(msg));
>> > >> rtems_test_assert(count == msg_size);
>> > >> -printf("task = %u write count = %u\n", task_num, count);
>> > >> +CAN_DEBUG("task = %u write count = %u\n", task_num, count);
>> > >>
>> > >> -printf("calling read task = %u\n", task_num);
>> > >> +CAN_DEBUG("calling read task = %u\n", task_num);
>> > >> count = read(fd, , sizeof(msg));
>> > >> rtems_test_assert(count > 0);
>> > > Since you send the messages, you know their sizes. You should be able
>> > > to assert the exact amount received?
>> > >
>> >
>> > Yes, and you probably know also the expected content of the message.
>> > This should be also checked. If there are ordering guarantees, then
each
>> > message should have a unique content and the ordering should be checked
>> > as well.
>>
>> The CAN framework has only minimal Rx support (CAN Framework sends the
latest received CAN message).
>> So only the read success is checked.
>>
>You should be able to structure your test to serialize the writes and
>reads in a predictable way, and then verify they are received as you
>expect.
Ok, I will serialize the write, read and verify the content.
It can be done in the test application, but from the CAN Framework I need
to find a way to uniquely identify an
open call (I tried looking for that, but the documentation for GSoC was
pending from my side), so that we can
create an Rx queue for each open call which will be the essential Rx
implementation. I will try to propose a design
within 1 or 2 weeks.
Regards
Prashanth S
On Wed, 30 Nov 2022 at 06:47, Gedare Bloom wrote:
> On Tue, Nov 29, 2022 at 6:58 AM Prashanth S
> wrote:
> >
> > > On 29/11/2022 05:57, Gedare Bloom wrote:
> > > >> @@ -111,18 +113,18 @@ static void test_task(rtems_task_argument
> data)
> > > >>
> > > >> msg_size = ((char *)[msg.len] - (char *));
> > > >>
> > > >> -printf("calling write task = %u\n", task_num);
> > > >> +CAN_DEBUG("calling write task = %u\n", task_num);
> > > > The general philosophy in our test suite is to only print something
> if
> > > > there's a failure. So just remove these debug statements that are
> > > > leftover from your development approach.
> > >
> > > Another approach could be to use the RTEMS Test Framework in which the
> > > test verbosity is controlled by a configuration option.
> >
> > I will look into the RTEMS Test Framework.
> >
> > >
> > > >
> > > >> count = write(fd, , sizeof(msg));
> > > >> rtems_test_assert(count == msg_size);
> > > >> -printf("task = %u write count = %u\n", task_num, count);
> > > >> +CAN_DEBUG("task = %u write count = %u\n", task_num, count);
> > > >>
> > > >> -printf("calling read task = %u\n", task_num);
> > > >> +CAN_DEBUG("calling read task = %u\n", task_num);
> > > >> count = read(fd, , sizeof(msg));
> > > >> rtems_test_assert(count > 0);
> > > > Since you send the messages, you know their sizes. You should be able
> > > > to assert the exact amount received?
> > > >
> > >
> > > Yes, and you probably know also the expected content of the message.
> > > This should be also checked. If there are ordering guarantees, then
> ea
Re: [PATCH] cpukit/include/dev/can: Disabled debug prints in CAN Framework
> On 29/11/2022 05:57, Gedare Bloom wrote:
> >> @@ -111,18 +113,18 @@ static void test_task(rtems_task_argument data)
> >>
> >> msg_size = ((char *)[msg.len] - (char *));
> >>
> >> -printf("calling write task = %u\n", task_num);
> >> +CAN_DEBUG("calling write task = %u\n", task_num);
> > The general philosophy in our test suite is to only print something if
> > there's a failure. So just remove these debug statements that are
> > leftover from your development approach.
>
> Another approach could be to use the RTEMS Test Framework in which the
> test verbosity is controlled by a configuration option.
I will look into the RTEMS Test Framework.
>
> >
> >> count = write(fd, , sizeof(msg));
> >> rtems_test_assert(count == msg_size);
> >> -printf("task = %u write count = %u\n", task_num, count);
> >> +CAN_DEBUG("task = %u write count = %u\n", task_num, count);
> >>
> >> -printf("calling read task = %u\n", task_num);
> >> +CAN_DEBUG("calling read task = %u\n", task_num);
> >> count = read(fd, , sizeof(msg));
> >> rtems_test_assert(count > 0);
> > Since you send the messages, you know their sizes. You should be able
> > to assert the exact amount received?
> >
>
> Yes, and you probably know also the expected content of the message.
> This should be also checked. If there are ordering guarantees, then each
> message should have a unique content and the ordering should be checked
> as well.
The CAN framework has only minimal Rx support (CAN Framework sends the
latest received CAN message).
So only the read success is checked.
Regards
Prashanth S
On Tue, 29 Nov 2022 at 12:24, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
>
>
> On 29/11/2022 05:57, Gedare Bloom wrote:
> >> @@ -111,18 +113,18 @@ static void test_task(rtems_task_argument data)
> >>
> >> msg_size = ((char *)[msg.len] - (char *));
> >>
> >> -printf("calling write task = %u\n", task_num);
> >> +CAN_DEBUG("calling write task = %u\n", task_num);
> > The general philosophy in our test suite is to only print something if
> > there's a failure. So just remove these debug statements that are
> > leftover from your development approach.
>
> Another approach could be to use the RTEMS Test Framework in which the
> test verbosity is controlled by a configuration option.
>
> >
> >> count = write(fd, , sizeof(msg));
> >> rtems_test_assert(count == msg_size);
> >> -printf("task = %u write count = %u\n", task_num, count);
> >> +CAN_DEBUG("task = %u write count = %u\n", task_num, count);
> >>
> >> -printf("calling read task = %u\n", task_num);
> >> +CAN_DEBUG("calling read task = %u\n", task_num);
> >> count = read(fd, , sizeof(msg));
> >> rtems_test_assert(count > 0);
> > Since you send the messages, you know their sizes. You should be able
> > to assert the exact amount received?
> >
>
> Yes, and you probably know also the expected content of the message.
> This should be also checked. If there are ordering guarantees, then each
> message should have a unique content and the ordering should be checked
> as well.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit/include/dev/can: Disabled debug prints in CAN Framework
>On Mon, Nov 28, 2022 at 8:46 PM Prashanth S
wrote:
>>
>> ---
>> cpukit/include/dev/can/can.h | 2 +-
>> testsuites/libtests/can01/init.c | 14 --
>> 2 files changed, 9 insertions(+), 7 deletions(-)
>>
>> diff --git a/cpukit/include/dev/can/can.h b/cpukit/include/dev/can/can.h
>> index 9e55395039..27afd00088 100644
>> --- a/cpukit/include/dev/can/can.h
>> +++ b/cpukit/include/dev/can/can.h
>> @@ -53,7 +53,7 @@
>>printf(str, ##__VA_ARGS__);
\
>> } while (false);
>>
>> -#define CAN_DEBUG(str, ...) DEBUG(str, ##__VA_ARGS__)
>> +#define CAN_DEBUG(str, ...) //DEBUG(str, ##__VA_ARGS__)
>
>This is not the right way to disable this, for several reasons.
>
>I should have caught this DEBUG printing stuff earlier. My guess is
>that you should just remove it all from the production code, or it
>should be controlled at a higher level with -DDEBUG kind of flag.
>However, I agree that the current implementation is overly verbose in
>debug mode. I'd just strip it all out.
I will update the debug prints implementation. I will add -DCAN_DEBUG
option to be used
if debug prints are required.
>
>> #define CAN_DEBUG_BUF(str, ...) CAN_DEBUG(str, ##__VA_ARGS__)
>> #define CAN_DEBUG_ISR(str, ...) CAN_DEBUG(str, ##__VA_ARGS__)
>> #define CAN_DEBUG_LOCK(str, ...) CAN_DEBUG(str, ##__VA_ARGS__)
>> diff --git a/testsuites/libtests/can01/init.c
b/testsuites/libtests/can01/init.c
>> index 0675fe606f..c19d45602e 100644
>> --- a/testsuites/libtests/can01/init.c
>> +++ b/testsuites/libtests/can01/init.c
>> @@ -97,8 +97,10 @@ static void test_task(rtems_task_argument data)
>>
>>rtems_test_assert(fd >= 0);
>>
>> + printf("test_task %u\n", task_num);
>> +
>>for (int i = 0; i < NUM_TEST_MSGS; i++) {
>> -printf("test_task %u\n", task_num);
>> +CAN_DEBUG("test_task %u\n", task_num);
>>
>> msg.id = task_num;
>> //FIXME: Implement Test cases for other flags also.
>
>There shouldn't be // comments anywhere.
I will remove that.
>
>> @@ -111,18 +113,18 @@ static void test_task(rtems_task_argument data)
>>
>> msg_size = ((char *)[msg.len] - (char *));
>>
>> -printf("calling write task = %u\n", task_num);
>> +CAN_DEBUG("calling write task = %u\n", task_num);
>
>The general philosophy in our test suite is to only print something if
>there's a failure. So just remove these debug statements that are
>leftover from your development approach.
I will remove extra debug prints.
>
>>
>> count = write(fd, , sizeof(msg));
>> rtems_test_assert(count == msg_size);
>> -printf("task = %u write count = %u\n", task_num, count);
>> +CAN_DEBUG("task = %u write count = %u\n", task_num, count);
>>
>> -printf("calling read task = %u\n", task_num);
>> +CAN_DEBUG("calling read task = %u\n", task_num);
>> count = read(fd, , sizeof(msg));
>> rtems_test_assert(count > 0);
>Since you send the messages, you know their sizes. You should be able
>to assert the exact amount received?
The CAN framework has only minimal Rx support (CAN Framework sends the
latest received CAN message).
So only the read success is checked in the test files.
>
>> -printf("task = %u read count = %u\n", task_num, count);
>> +CAN_DEBUG("task = %u read count = %u\n", task_num, count);
>>
>> -printf("received message\n");
>> +CAN_DEBUG("received message\n");
>> can_print_msg();
>>
>> sleep(1);
Regards
Prashanth S
On Tue, 29 Nov 2022 at 10:27, Gedare Bloom wrote:
> Hi Prashanth,
>
> On Mon, Nov 28, 2022 at 8:46 PM Prashanth S
> wrote:
> >
> > ---
> > cpukit/include/dev/can/can.h | 2 +-
> > testsuites/libtests/can01/init.c | 14 --
> > 2 files changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/cpukit/include/dev/can/can.h b/cpukit/include/dev/can/can.h
> > index 9e55395039..27afd00088 100644
> > --- a/cpukit/include/dev/can/can.h
> > +++ b/cpukit/include/dev/can/can.h
> > @@ -53,7 +53,7 @@
> >printf(str, ##__VA_ARGS__);
>\
> > } while (false);
> >
> > -#define CAN_DEBUG(str, ...) DEBUG(str, ##__VA_ARGS__)
> > +#define CAN_DEBUG(str, ...) //DEBUG(str, ##__VA_ARGS__)
>
> This is not the right way to disable this, for several reasons.
>
> I should have caught this DEBUG p
[PATCH] cpukit/include/dev/can: Disabled debug prints in CAN Framework
---
cpukit/include/dev/can/can.h | 2 +-
testsuites/libtests/can01/init.c | 14 --
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/cpukit/include/dev/can/can.h b/cpukit/include/dev/can/can.h
index 9e55395039..27afd00088 100644
--- a/cpukit/include/dev/can/can.h
+++ b/cpukit/include/dev/can/can.h
@@ -53,7 +53,7 @@
printf(str, ##__VA_ARGS__); \
} while (false);
-#define CAN_DEBUG(str, ...) DEBUG(str, ##__VA_ARGS__)
+#define CAN_DEBUG(str, ...) //DEBUG(str, ##__VA_ARGS__)
#define CAN_DEBUG_BUF(str, ...) CAN_DEBUG(str, ##__VA_ARGS__)
#define CAN_DEBUG_ISR(str, ...) CAN_DEBUG(str, ##__VA_ARGS__)
#define CAN_DEBUG_LOCK(str, ...) CAN_DEBUG(str, ##__VA_ARGS__)
diff --git a/testsuites/libtests/can01/init.c b/testsuites/libtests/can01/init.c
index 0675fe606f..c19d45602e 100644
--- a/testsuites/libtests/can01/init.c
+++ b/testsuites/libtests/can01/init.c
@@ -97,8 +97,10 @@ static void test_task(rtems_task_argument data)
rtems_test_assert(fd >= 0);
+ printf("test_task %u\n", task_num);
+
for (int i = 0; i < NUM_TEST_MSGS; i++) {
-printf("test_task %u\n", task_num);
+CAN_DEBUG("test_task %u\n", task_num);
msg.id = task_num;
//FIXME: Implement Test cases for other flags also.
@@ -111,18 +113,18 @@ static void test_task(rtems_task_argument data)
msg_size = ((char *)[msg.len] - (char *));
-printf("calling write task = %u\n", task_num);
+CAN_DEBUG("calling write task = %u\n", task_num);
count = write(fd, , sizeof(msg));
rtems_test_assert(count == msg_size);
-printf("task = %u write count = %u\n", task_num, count);
+CAN_DEBUG("task = %u write count = %u\n", task_num, count);
-printf("calling read task = %u\n", task_num);
+CAN_DEBUG("calling read task = %u\n", task_num);
count = read(fd, , sizeof(msg));
rtems_test_assert(count > 0);
-printf("task = %u read count = %u\n", task_num, count);
+CAN_DEBUG("task = %u read count = %u\n", task_num, count);
-printf("received message\n");
+CAN_DEBUG("received message\n");
can_print_msg();
sleep(1);
--
2.25.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: CAN Framework Docs for RTEMS-DOCS
Hi All, This is a review request for CAN Framework docs. I pasted the link to gitlab, as the patch size exceeds the mailing list limit. https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/869438a9da4a31a69f8d2718d5789d76fe209929 Regards Prashanth S On Mon, 14 Nov 2022 at 20:03, Prashanth S wrote: > Hi All, > > I have pasted the link to CAN framework docs for rtems-docs. As the patch > size exceeds the mailing list, so pasted the link to GitLab. > > > https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/01bd99dd8228128fdb5189e65ffa198312012d34 > > Regards > Prashanth S > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] c-user: CAN framework docs
Hi Gedare, > What are the images? There three images: images/c_user/CAN-framework.jpg->* Overview of CAN-Framework* images/c_user/CAN-rx-data-path.jpg -> *Rx Data Path flow* images/c_user/CAN-tx-data-path.jpg -> *Tx Data Path flow* > This is not exactly correct. It is actually recessive where | CANH - > CANL | < t1 for some threshold t1, > and dominant where | CANH - CANL | > t2. And there is a gap where the > bus is not defined at t1 < | CANH - CANL| < t2 > This detail is not so important here, but if we're going to describe > it then we need it to be correct. > > > +A 0 data bit encodes a dominant state, while a 1 data bit encodes a recessive > > +state, supporting a wired-AND convention, which gives nodes with lower ID > > +numbers priority on the bus. > > I see this text has been copied from Wikipedia. This is not acceptable > without proper attribution/reference. Please rewrite, remove, or > reference cited material properly. Please identify if any of the below > text is also copied from anywhere else. I will rewrite this text. > > > + > > +This document covers, the CAN framework and its usage by BSP CAN drivers and > Remove the comma after covers > typo: Initialize > typo: Further I will update these typo errors. Regards Prashanth S On Tue, 15 Nov 2022 at 20:34, Gedare Bloom wrote: > Hi Prashant, > > What are the images? > > On Tue, Nov 15, 2022 at 7:49 AM Prashanth S > wrote: > > > > --- > > bsp-howto/can.rst | 201 + > > bsp-howto/index.rst| 1 + > > images/c_user/CAN-framework.jpg| Bin 0 -> 146625 bytes > > images/c_user/CAN-rx-data-path.jpg | Bin 0 -> 187438 bytes > > images/c_user/CAN-tx-data-path.jpg | Bin 0 -> 128765 bytes > > 5 files changed, 202 insertions(+) > > create mode 100644 bsp-howto/can.rst > > create mode 100644 images/c_user/CAN-framework.jpg > > create mode 100644 images/c_user/CAN-rx-data-path.jpg > > create mode 100644 images/c_user/CAN-tx-data-path.jpg > > > > diff --git a/bsp-howto/can.rst b/bsp-howto/can.rst > > new file mode 100644 > > index 000..36d6a04 > > --- /dev/null > > +++ b/bsp-howto/can.rst > > @@ -0,0 +1,201 @@ > > +.. SPDX-License-Identifier: CC-BY-SA-4.0 > > + > > +.. Copyright (C) 2022 Prashanth S > > + > > +CAN Library > > +*** > > + > > +Introduction > > + > > + > > +The Controller Area Network is a robust multi-master serial > communication > > +protocol extensively used in automobiles for reliable data transfer. > Two or more > > +nodes are required on the CAN network to communicate. All nodes are > connected to > > +each other through a physically conventional two-wire bus. The wires > are a > > +twisted pair with a 120 Ω (nominal) characteristic impedance. > > + > > +This bus uses differential wired-AND signals. Two signals, CAN high > (CANH) and > > +CAN low (CANL) are either driven to a "dominant" state with CANH > CANL > or not > > +driven and pulled by passive resistors to a "recessive" state with CANH > ≤ CANL. > This is not exactly correct. It is actually recessive where | CANH - > CANL | < t1 for some threshold t1, > and dominant where | CANH - CANL | > t2. And there is a gap where the > bus is not defined at t1 < | CANH - CANL| < t2 > This detail is not so important here, but if we're going to describe > it then we need it to be correct. > > > +A 0 data bit encodes a dominant state, while a 1 data bit encodes a > recessive > > +state, supporting a wired-AND convention, which gives nodes with lower > ID > > +numbers priority on the bus. > > I see this text has been copied from Wikipedia. This is not acceptable > without proper attribution/reference. Please rewrite, remove, or > reference cited material properly. Please identify if any of the below > text is also copied from anywhere else. > > > + > > +This document covers, the CAN framework and its usage by BSP CAN > drivers and > Remove the comma after covers > > > +applications. > > + > > +The CAN framework allows the applications to be written in a portable > manner, > > +which implies that an application can access the CAN bus without > knowing the > > +details of the CAN hardware, the platform specific translations are > taken care > > +by the CAN framework (So the application can focus more on the CAN > protocol > > +specific implementation). > > + > > +The CAN framework aims to be compatible with classical CAN and CAN FD.
CAN Framework Docs for RTEMS-DOCS
Hi All, I have pasted the link to CAN framework docs for rtems-docs. As the patch size exceeds the mailing list, so pasted the link to GitLab. https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/01bd99dd8228128fdb5189e65ffa198312012d34 Regards Prashanth S ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Review Request for DCAN patches
Hi Christian, I squashed the commits and pushed to the same branch. https://gitlab.com/slpp95prashanth/gsoc-2022/-/tree/can-dev-squashed1 Regards Prashanth S On Wed, 26 Oct, 2022, 10:56 pm , wrote: > Hello Prashanth, > > from my point of view the patches look good and I think you processed > Gedares feedback too. So if no one objects I'll pus the patches on the > weekend. > > Last version is this one: > > > https://gitlab.com/slpp95prashanth/gsoc-2022/-/commits/30199c2af1c65f05f820a/ > > Like discussed in Discord, it would be good to squash the canqueueimpl.h > into the CAN support. Either you can do that or I'll do it right before > pushing. > > Best regards > > Christian > > Am 16.10.22 um 19:12 schrieb Prashanth S: > > Hi All, > > > > This is a review request for the DCAN patch, I have updated the files > > based on review comments. > > Attaching the patch as a zip file. > > > > Regards > > Prashanth S > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Review Request for DCAN patches
Hi All, This is a review request for the DCAN patch, I have updated the files based on review comments. Attaching the patch as a zip file. Regards Prashanth S DCAN.tar.lzma Description: application/lzma ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Review request for DCAN support
Hi All, This is a review request for DCAN and CAN support (merge patch). Attaching compressed file for DCAN patch, as file size exceeds 256KB. Regards Prashanth S DCAN.tar.lzma Description: application/lzma ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v5 1/2] cpukit/dev/can: Added CAN support
---
cpukit/dev/can/can-queue.h | 230 +++
cpukit/dev/can/can.c | 505 +++
cpukit/include/dev/can/can-msg.h | 105 +
cpukit/include/dev/can/can.h | 284 +
spec/build/cpukit/librtemscpu.yml| 5 +
spec/build/testsuites/libtests/can01.yml | 20 +
spec/build/testsuites/libtests/grp.yml | 2 +
testsuites/libtests/can01/can-loopback.c | 110 +
testsuites/libtests/can01/init.c | 251 +++
9 files changed, 1512 insertions(+)
create mode 100644 cpukit/dev/can/can-queue.h
create mode 100644 cpukit/dev/can/can.c
create mode 100644 cpukit/include/dev/can/can-msg.h
create mode 100644 cpukit/include/dev/can/can.h
create mode 100644 spec/build/testsuites/libtests/can01.yml
create mode 100644 testsuites/libtests/can01/can-loopback.c
create mode 100644 testsuites/libtests/can01/init.c
diff --git a/cpukit/dev/can/can-queue.h b/cpukit/dev/can/can-queue.h
new file mode 100644
index 00..9a3610c908
--- /dev/null
+++ b/cpukit/dev/can/can-queue.h
@@ -0,0 +1,230 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup CANBus
+ *
+ * @brief Controller Area Network (CAN) Bus Implementation
+ *
+ */
+
+/*
+ * Copyright (C) 2022 Prashanth S
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _DEV_CAN_CAN_QUEUE_H
+#define _DEV_CAN_CAN_QUEUE_H
+
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+
+/**
+ * @defgroup Controller Area Network (CAN) Driver
+ *
+ * @ingroup RTEMSDeviceDrivers
+ *
+ * @brief Controller Area Network (CAN) bus and device driver support.
+ *
+ * @{
+ */
+
+/**
+ * @defgroup CANBus CAN Bus Driver
+ *
+ * @ingroup CAN
+ *
+ * @{
+ */
+
+/**
+ * @brief Create CAN tx buffers.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ * @retval 0 Successful operation.
+ * @retval >0 error number in case of an error.
+ */
+static rtems_status_code can_create_tx_buffers(struct can_bus *bus);
+
+/**
+ * @brief Free CAN tx buffers.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ */
+static void can_free_tx_buffers(struct can_bus *bus);
+
+/**
+ * @brief Check for atleast one empty CAN tx buffer.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ * @retval true If atleast one CAN buffer is empty.
+ * @retval false If no CAN buffer is empty.
+ */
+static bool can_tx_buf_isempty(struct can_bus *bus);
+
+/**
+ * @brief Get a produced tx buffer to transmit from the tx fifo.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ * @retval can_msg Pointer to can_msg structure buffer.
+ * @retval NULL If no can_msg buffer.
+ */
+static struct can_msg *can_tx_get_data_buf(struct can_bus *bus);
+
+/**
+ * @brief Get a empty tx buffer.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ * @retval can_msg Pointer to can_msg structure buffer.
+ * @retval NULL If no empty can_msg buffer.
+ */
+static struct can_msg *can_tx_get_empty_buf(struct can_bus *bus);
+
+/**
+ * @brief Creates tx buffers for the CAN bus driver.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ * @retval rtems_status_code
+ */
+static rtems_status_code can_create_tx_buffers(struct can_bus *bus)
+{
+ bus->tx_fifo.pbuf = (struct can_msg *)malloc(CAN_TX_BUF_COUNT *
+ sizeof(struct can_msg));
+ if (bus->tx_fifo.pbuf == NULL) {
+CAN_ERR("can_create_tx_buffers: malloc failed\n");
+return RTEMS_NO_MEMORY;
+ }
+
+ bus->tx_fifo.empty_count = CAN_TX_BUF_COUNT;
+
+ return RTEMS_SUCCESSFUL;
+}
+
+/**
+ * @brief Free tx buffers for the CAN bus driver.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ */
+static void can_free_tx_buffers(str
[PATCH v4] cpukit/dev/can: Added CAN support
---
cpukit/dev/can/can-queue.h | 230 +++
cpukit/dev/can/can.c | 503 +++
cpukit/include/dev/can/can-msg.h | 105 +
cpukit/include/dev/can/can.h | 282 +
spec/build/cpukit/librtemscpu.yml| 5 +
spec/build/testsuites/libtests/can01.yml | 20 +
spec/build/testsuites/libtests/grp.yml | 2 +
testsuites/libtests/can01/can-loopback.c | 110 +
testsuites/libtests/can01/init.c | 251 +++
9 files changed, 1508 insertions(+)
create mode 100644 cpukit/dev/can/can-queue.h
create mode 100644 cpukit/dev/can/can.c
create mode 100644 cpukit/include/dev/can/can-msg.h
create mode 100644 cpukit/include/dev/can/can.h
create mode 100644 spec/build/testsuites/libtests/can01.yml
create mode 100644 testsuites/libtests/can01/can-loopback.c
create mode 100644 testsuites/libtests/can01/init.c
diff --git a/cpukit/dev/can/can-queue.h b/cpukit/dev/can/can-queue.h
new file mode 100644
index 00..9a3610c908
--- /dev/null
+++ b/cpukit/dev/can/can-queue.h
@@ -0,0 +1,230 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup CANBus
+ *
+ * @brief Controller Area Network (CAN) Bus Implementation
+ *
+ */
+
+/*
+ * Copyright (C) 2022 Prashanth S
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _DEV_CAN_CAN_QUEUE_H
+#define _DEV_CAN_CAN_QUEUE_H
+
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+
+/**
+ * @defgroup Controller Area Network (CAN) Driver
+ *
+ * @ingroup RTEMSDeviceDrivers
+ *
+ * @brief Controller Area Network (CAN) bus and device driver support.
+ *
+ * @{
+ */
+
+/**
+ * @defgroup CANBus CAN Bus Driver
+ *
+ * @ingroup CAN
+ *
+ * @{
+ */
+
+/**
+ * @brief Create CAN tx buffers.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ * @retval 0 Successful operation.
+ * @retval >0 error number in case of an error.
+ */
+static rtems_status_code can_create_tx_buffers(struct can_bus *bus);
+
+/**
+ * @brief Free CAN tx buffers.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ */
+static void can_free_tx_buffers(struct can_bus *bus);
+
+/**
+ * @brief Check for atleast one empty CAN tx buffer.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ * @retval true If atleast one CAN buffer is empty.
+ * @retval false If no CAN buffer is empty.
+ */
+static bool can_tx_buf_isempty(struct can_bus *bus);
+
+/**
+ * @brief Get a produced tx buffer to transmit from the tx fifo.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ * @retval can_msg Pointer to can_msg structure buffer.
+ * @retval NULL If no can_msg buffer.
+ */
+static struct can_msg *can_tx_get_data_buf(struct can_bus *bus);
+
+/**
+ * @brief Get a empty tx buffer.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ * @retval can_msg Pointer to can_msg structure buffer.
+ * @retval NULL If no empty can_msg buffer.
+ */
+static struct can_msg *can_tx_get_empty_buf(struct can_bus *bus);
+
+/**
+ * @brief Creates tx buffers for the CAN bus driver.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ * @retval rtems_status_code
+ */
+static rtems_status_code can_create_tx_buffers(struct can_bus *bus)
+{
+ bus->tx_fifo.pbuf = (struct can_msg *)malloc(CAN_TX_BUF_COUNT *
+ sizeof(struct can_msg));
+ if (bus->tx_fifo.pbuf == NULL) {
+CAN_ERR("can_create_tx_buffers: malloc failed\n");
+return RTEMS_NO_MEMORY;
+ }
+
+ bus->tx_fifo.empty_count = CAN_TX_BUF_COUNT;
+
+ return RTEMS_SUCCESSFUL;
+}
+
+/**
+ * @brief Free tx buffers for the CAN bus driver.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ */
+static void can_free_tx_buffers(str
Re: devel Digest, Vol 129, Issue 37
Hi Christian, > I added a number of comments for the first (API) commit using the gitlab > comment function: > > https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/2283ab18bd2fbfa363233c6dabcfa5123225f27c > > PS: Please don't answer to Devel Digests. That adds totally unrelated > content to your mails. Beneath that it has a compleatly meaningless > toppic. That's why the original devel digest mail had this note: > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of devel digest..." > > Normally I strongly suggest to disable digest and let the list send > individual messages instead. Use a mail filter (ideally server side) to > move them into one folder so that they don't spam your inbox. Ok. I will address the review comments and upload the changes. Regards Prashanth S On Sun, 21 Aug 2022 at 15:40, wrote: > Hello Prashanth, > > I added a number of comments for the first (API) commit using the gitlab > comment function: > > > https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/2283ab18bd2fbfa363233c6dabcfa5123225f27c > > PS: Please don't answer to Devel Digests. That adds totally unrelated > content to your mails. Beneath that it has a compleatly meaningless > toppic. That's why the original devel digest mail had this note: > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of devel digest..." > > Normally I strongly suggest to disable digest and let the list send > individual messages instead. Use a mail filter (ideally server side) to > move them into one folder so that they don't spam your inbox. > > Best regards > > Christian > > Am 21.08.22 um 08:02 schrieb Prashanth S: > > Hi All, > > > > This is a review request for DCAN and CAN support. The review comments > > would be very helpful for stabilizing the source files. > > > > > https://gitlab.com/slpp95prashanth/gsoc-2022/-/tree/can-review-latest-squash-02-squash/ > > > > Regards > > Prashanth S > > > > On Mon, 15 Aug 2022 at 11:57, Prashanth S > wrote: > >> > >> Hi All, > >> > >> This is a review request for DCAN (Work in Progress) support. > >> > >> As the patch size exceeds the mail limit, I am attaching the patch in > >> compressed format. > >> > >> Regards > >> Prashanth S > >> > >> Prashanth S > >> > >> On Sun, 14 Aug 2022 at 13:56, wrote: > >>> > >>> Send devel mailing list submissions to > >>> devel@rtems.org > >>> > >>> To subscribe or unsubscribe via the World Wide Web, visit > >>> http://lists.rtems.org/mailman/listinfo/devel > >>> or, via email, send a message with subject or body 'help' to > >>> devel-requ...@rtems.org > >>> > >>> You can reach the person managing the list at > >>> devel-ow...@rtems.org > >>> > >>> When replying, please edit your Subject line so it is more specific > >>> than "Re: Contents of devel digest..." > >>> > >>> > [...] > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: devel Digest, Vol 129, Issue 37
Hi All, This is a review request for DCAN and CAN support. The review comments would be very helpful for stabilizing the source files. https://gitlab.com/slpp95prashanth/gsoc-2022/-/tree/can-review-latest-squash-02-squash/ Regards Prashanth S On Mon, 15 Aug 2022 at 11:57, Prashanth S wrote: > > Hi All, > > This is a review request for DCAN (Work in Progress) support. > > As the patch size exceeds the mail limit, I am attaching the patch in > compressed format. > > Regards > Prashanth S > > Prashanth S > > On Sun, 14 Aug 2022 at 13:56, wrote: > > > > Send devel mailing list submissions to > > devel@rtems.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://lists.rtems.org/mailman/listinfo/devel > > or, via email, send a message with subject or body 'help' to > > devel-requ...@rtems.org > > > > You can reach the person managing the list at > > devel-ow...@rtems.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of devel digest..." > > > > > > Today's Topics: > > > >1. [PATCH v4] cpukit/dev/can: Added CAN support (Prashanth S) > > > > > > ------ > > > > Message: 1 > > Date: Sun, 14 Aug 2022 13:56:16 +0530 > > From: Prashanth S > > To: devel@rtems.org > > Cc: Prashanth S > > Subject: [PATCH v4] cpukit/dev/can: Added CAN support > > Message-ID: <20220814082616.7345-1-fishesprasha...@gmail.com> > > > > --- > > cpukit/dev/can/can.c | 521 +++ > > cpukit/include/dev/can/can-msg.h | 105 + > > cpukit/include/dev/can/can-queue.h | 219 ++ > > cpukit/include/dev/can/can.h | 258 +++ > > spec/build/cpukit/librtemscpu.yml| 6 + > > spec/build/testsuites/libtests/can01.yml | 19 + > > spec/build/testsuites/libtests/grp.yml | 2 + > > testsuites/libtests/can01/init.c | 257 +++ > > 8 files changed, 1387 insertions(+) > > create mode 100644 cpukit/dev/can/can.c > > create mode 100644 cpukit/include/dev/can/can-msg.h > > create mode 100644 cpukit/include/dev/can/can-queue.h > > create mode 100644 cpukit/include/dev/can/can.h > > create mode 100644 spec/build/testsuites/libtests/can01.yml > > create mode 100644 testsuites/libtests/can01/init.c > > > > diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c > > new file mode 100644 > > index 00..02377a9098 > > --- /dev/null > > +++ b/cpukit/dev/can/can.c > > @@ -0,0 +1,521 @@ > > +/* SPDX-License-Identifier: BSD-2-Clause */ > > + > > +/** > > + * @file > > + * > > + * @ingroup CANBus > > + * > > + * @brief Controller Area Network (CAN) Bus Implementation > > + * > > + */ > > + > > +/* > > + * Copyright (C) 2022 Prashanth S (fishesprasha...@gmail.com) > > + * > > + * Redistribution and use in source and binary forms, with or without > > + * modification, are permitted provided that the following conditions > > + * are met: > > + * 1. Redistributions of source code must retain the above copyright > > + * notice, this list of conditions and the following disclaimer. > > + * 2. Redistributions in binary form must reproduce the above copyright > > + * notice, this list of conditions and the following disclaimer in the > > + * documentation and/or other materials provided with the distribution. > > + * > > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS > > IS" > > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, > > THE > > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > > PURPOSE > > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE > > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF > > THE > > + * POSSIBILITY OF SUCH DAMAGE. > > + */ > > + > > +#include > > +#incl
Re: devel Digest, Vol 129, Issue 37
Hi All,
This is a review request for DCAN (Work in Progress) support.
As the patch size exceeds the mail limit, I am attaching the patch in
compressed format.
Regards
Prashanth S
Prashanth S
On Sun, 14 Aug 2022 at 13:56, wrote:
>
> Send devel mailing list submissions to
> devel@rtems.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.rtems.org/mailman/listinfo/devel
> or, via email, send a message with subject or body 'help' to
> devel-requ...@rtems.org
>
> You can reach the person managing the list at
> devel-ow...@rtems.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of devel digest..."
>
>
> Today's Topics:
>
>1. [PATCH v4] cpukit/dev/can: Added CAN support (Prashanth S)
>
>
> ------
>
> Message: 1
> Date: Sun, 14 Aug 2022 13:56:16 +0530
> From: Prashanth S
> To: devel@rtems.org
> Cc: Prashanth S
> Subject: [PATCH v4] cpukit/dev/can: Added CAN support
> Message-ID: <20220814082616.7345-1-fishesprasha...@gmail.com>
>
> ---
> cpukit/dev/can/can.c | 521 +++
> cpukit/include/dev/can/can-msg.h | 105 +
> cpukit/include/dev/can/can-queue.h | 219 ++
> cpukit/include/dev/can/can.h | 258 +++
> spec/build/cpukit/librtemscpu.yml| 6 +
> spec/build/testsuites/libtests/can01.yml | 19 +
> spec/build/testsuites/libtests/grp.yml | 2 +
> testsuites/libtests/can01/init.c | 257 +++
> 8 files changed, 1387 insertions(+)
> create mode 100644 cpukit/dev/can/can.c
> create mode 100644 cpukit/include/dev/can/can-msg.h
> create mode 100644 cpukit/include/dev/can/can-queue.h
> create mode 100644 cpukit/include/dev/can/can.h
> create mode 100644 spec/build/testsuites/libtests/can01.yml
> create mode 100644 testsuites/libtests/can01/init.c
>
> diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c
> new file mode 100644
> index 00..02377a9098
> --- /dev/null
> +++ b/cpukit/dev/can/can.c
> @@ -0,0 +1,521 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup CANBus
> + *
> + * @brief Controller Area Network (CAN) Bus Implementation
> + *
> + */
> +
> +/*
> + * Copyright (C) 2022 Prashanth S (fishesprasha...@gmail.com)
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in the
> + * documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +
> +#define can_interrupt_lock_acquire(bus) \
> + do { \
> + CAN_DEBUG_LOCK("acquiring lock %s:%d\n",
> __FILE__, __LINE__); \
> + real_can_interrupt_lock_acquire(bus);
> \
> + } while (0);
> +
> +#define can_interrupt_lock_release(bus) \
> + do { \
> + CAN_DEBUG_LOCK("releasing lock %s:%d\n",
> __FILE__, __LINE__); \
> + real_can_interrupt_lock_release(bus);
> \
> + } while (0);
> +
> +static ssize_t
> +can_bus_open(rtems_libio_t
[PATCH v4] cpukit/dev/can: Added CAN support
---
cpukit/dev/can/can.c | 521 +++
cpukit/include/dev/can/can-msg.h | 105 +
cpukit/include/dev/can/can-queue.h | 219 ++
cpukit/include/dev/can/can.h | 258 +++
spec/build/cpukit/librtemscpu.yml| 6 +
spec/build/testsuites/libtests/can01.yml | 19 +
spec/build/testsuites/libtests/grp.yml | 2 +
testsuites/libtests/can01/init.c | 257 +++
8 files changed, 1387 insertions(+)
create mode 100644 cpukit/dev/can/can.c
create mode 100644 cpukit/include/dev/can/can-msg.h
create mode 100644 cpukit/include/dev/can/can-queue.h
create mode 100644 cpukit/include/dev/can/can.h
create mode 100644 spec/build/testsuites/libtests/can01.yml
create mode 100644 testsuites/libtests/can01/init.c
diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c
new file mode 100644
index 00..02377a9098
--- /dev/null
+++ b/cpukit/dev/can/can.c
@@ -0,0 +1,521 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup CANBus
+ *
+ * @brief Controller Area Network (CAN) Bus Implementation
+ *
+ */
+
+/*
+ * Copyright (C) 2022 Prashanth S (fishesprasha...@gmail.com)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+
+#include
+
+#define can_interrupt_lock_acquire(bus) \
+ do { \
+ CAN_DEBUG_LOCK("acquiring lock %s:%d\n", __FILE__,
__LINE__); \
+ real_can_interrupt_lock_acquire(bus);
\
+ } while (0);
+
+#define can_interrupt_lock_release(bus) \
+ do { \
+ CAN_DEBUG_LOCK("releasing lock %s:%d\n", __FILE__,
__LINE__); \
+ real_can_interrupt_lock_release(bus);
\
+ } while (0);
+
+static ssize_t
+can_bus_open(rtems_libio_t *iop, const char *path, int oflag, mode_t mode);
+static ssize_t
+can_bus_read(rtems_libio_t *iop, void *buffer, size_t count);
+static ssize_t
+can_bus_write(rtems_libio_t *iop, const void *buffer, size_t count);
+static ssize_t
+can_bus_ioctl(rtems_libio_t *iop, ioctl_command_t request, void *buffer);
+
+static int can_xmit(struct can_bus *bus);
+
+static int can_create_sem(struct can_bus *);
+static int try_sem(struct can_bus *);
+static int take_sem(struct can_bus *);
+static int give_sem(struct can_bus *);
+
+/* sem_count this is for debug purpose, for debugging
+the take_sem and give_sem
+*/
+static int sem_count = 0;
+
+static void can_bus_obtain(can_bus *bus)
+{
+ printf("can_bus_obtain Entry\n");
+ rtems_mutex_lock(>mutex);
+ printf("can_bus_obtain Exit\n");
+}
+
+static void can_bus_release(can_bus *bus)
+{
+ printf("can_bus_release Entry\n");
+ rtems_mutex_unlock(>mutex);
+ printf("can_bus_release Exit\n");
+}
+
+static void can_bus_destroy_mutex(struct can_bus *bus)
+{
+ rtems_mutex_destroy(>mutex);
+}
+
+static int can_create_sem(struct can_bus *bus)
+{
+ int ret = 0;
+
+ ret = rtems_semaphore_create(rtems_build_name('c', 'a', 'n', bus->index),
+ CAN_TX_BUF_COUNT, RTEMS_FIFO | RTEMS_COUNTING_SEMAPHORE | RTEMS_LOCAL,
+ 0, >tx_fifo_sem_id);
+
+ if (ret != 0) {
+printf("can_create_sem: rtems_semaphore_create failed %d\n", ret);
+ }
+
+ return ret;
+}
+
+static void can_free_tx_semaphore(struct can_bus *bus)
+{
+ rtems_semaphore_delete(bus->tx_fifo_sem_id);
+}
+
+static void real_can_interrupt_lock_acquire(struct can_bus
Re: [PATCH] cpukit/dev/can: Added CAN support
Hi Christian, Oops, I apologize. I think I used gmail style quotes that might have added html. I will not use it. Regards Prashanth S On Mon, 8 Aug 2022 at 05:31, Chris Johns wrote: > Hi > > Could you please configure your email client to not send HTML emails to > the list? > > I am reluctant to enable filtering in mailman and have managed to avoid it > so far. > > Thanks > Chris > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit/dev/can: Added CAN support
); \
> real_can_interrupt_lock_acquire(__VA_ARGS__);
> } while(0)
>
Then you can just write it as normal can_interrupt_lock_acquire but get
> a debug print with file and line on every call.
>
now moved the logs and call to the lock acquire/release to #defines.
> +can_interrupt_lock_acquire(bus);
> > +bus->can_tx_buf_waiters++;
> > +CAN_DEBUG_LOCK("can_bus_write: release lock
> can_tx_buf_waiters++\n");
> > +can_interrupt_lock_release(bus);
> > +
> > +ret = take_sem(bus);
> > +
> > +CAN_DEBUG_LOCK("can_bus_write: acquiring lock
> can_tx_buf_waiters--\n");
> > +can_interrupt_lock_acquire(bus);
> > +bus->can_tx_buf_waiters--;
> > +CAN_DEBUG_LOCK("can_bus_write: release lock
> can_tx_buf_waiters--\n");
> > +can_interrupt_lock_release(bus);
> > +
>
> +if (ret != RTEMS_SUCCESSFUL) {
> > + printf("can_bus_write: cannot take semaphore\n");
> > + ret = -RTEMS_INTERNAL_ERROR;
> > + goto return_from_func;
>
Why not just use a return here instead of the goto? The label isn't used
> anywhere else.
>
changed to return.
> > +}
> > + }
> > +
> > + /* sleep is for debug purpose to test concurrency issues */
> > + printf("can_bus_write: calling sleep\n");
> > + sleep(1);
> > + printf("can_bus_write: coming out sleep\n");
>
> Obviously this shouldn't be there in the later merge-ready patch.
Yes, these sleeps will be removed.
> Do these really have to be in a header that you (most likely) will later
> install? With that they are public visible API.
On Tue, 2 Aug 2022 at 23:19, wrote:
> Hello Duc,
>
> general note: You add an API to cpukit. Most APIs there should have a
> test case in the testsuite. In this case the test case would have to
> create some dummy CAN driver and check whether everything works like
> expected. As an example take a look at the SPI test:
>
>https://git.rtems.org/rtems/tree/testsuites/libtests/spi01/init.c
>
> It creates a dummy device and checks whether the SPI layer does
> everything as expected. Would be great if you could add something like
> this. Target of such a test should be more or less that every branch in
> your code is triggered at least once (code coverage). It doesn't has to
> be every combination but it shows that the code is at least reachable
> and works as expected.
>
> Am 31.07.22 um 13:53 schrieb Prashanth S:
> > ---
> > cpukit/dev/can/can.c | 514 +
> > cpukit/include/dev/can/can-msg.h | 55 +++
> > cpukit/include/dev/can/can-queue.h | 127 +++
> > cpukit/include/dev/can/can.h | 102 ++
> > spec/build/cpukit/librtemscpu.yml | 6 +
> > 5 files changed, 804 insertions(+)
> > create mode 100644 cpukit/dev/can/can.c
> > create mode 100644 cpukit/include/dev/can/can-msg.h
> > create mode 100644 cpukit/include/dev/can/can-queue.h
> > create mode 100644 cpukit/include/dev/can/can.h
> >
> > diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c
> > new file mode 100644
> > index 00..8feec8800b
> > --- /dev/null
> > +++ b/cpukit/dev/can/can.c
> > @@ -0,0 +1,514 @@
> > +/* SPDX-License-Identifier: BSD-2-Clause */
> > +
> > +/**
> > + * @file
> > + *
> > + * @ingroup CANBus
> > + *
> > + * @brief Controller Area Network (CAN) Bus Implementation
> > + *
> > + */
> > +
> > +/*
> > + * Copyright (C) 2022 Prashanth S (fishesprasha...@gmail.com)
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions
> > + * are met:
> > + * 1. Redistributions of source code must retain the above copyright
> > + * notice, this list of conditions and the following disclaimer.
> > + * 2. Redistributions in binary form must reproduce the above copyright
> > + * notice, this list of conditions and the following disclaimer in the
> > + * documentation and/or other materials provided with the distribution.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS"
> > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
> TO, THE
> > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> CONTRIBUTORS BE
> > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> > + * CONSEQUENTIAL DAMA
[PATCH] cpukit/dev/can: Added CAN support (Prashanth S)
Hi All, This is a review request for CAN support. I have addressed the review comments. The files are work in progress, I need to add few more comments in the include (*.h) files. Regards Prashanth S On Sun, 31 Jul 2022 at 17:24, wrote: > Send devel mailing list submissions to > devel@rtems.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.rtems.org/mailman/listinfo/devel > or, via email, send a message with subject or body 'help' to > devel-requ...@rtems.org > > You can reach the person managing the list at > devel-ow...@rtems.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of devel digest..." > > > Today's Topics: > >1. Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL (Karel Gardas) >2. Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL > (o...@c-mauderer.de) >3. [PATCH] cpukit/dev/can: Added CAN support (Prashanth S) > > > -- > > Message: 1 > Date: Sat, 30 Jul 2022 21:41:19 +0200 > From: Karel Gardas > To: o...@c-mauderer.de, Duc Doan , devel@rtems.org > Subject: Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL > Message-ID: <2af4f901-b157-c0b0-cc75-45921bf788eb@functional.vision> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 7/30/22 16:32, o...@c-mauderer.de wrote: > >> ? bsps/arm/include/cmsis_compiler.h |?? 266 + > >> ? bsps/arm/include/cmsis_gcc.h? |? 3460 +-- > >> ? bsps/arm/include/cmsis_version.h? |??? 39 + > >> ? bsps/arm/include/core_cm4.h?? |?? 524 +- > >> ? bsps/arm/include/core_cm7.h?? |? 5186 ++-- > >> ? bsps/arm/include/mpu_armv7.h? |?? 270 + > > > > Are the cmsis files from the same source or directly from ARM? > > > > The cmsis_gcc.h has a lot of changes compared to the earlier version > > that has been present in RTEMS. A lot of the changes seem to be > > whitespace changes. Can these be avoided somehow (for example by using > > dos2unix before overwriting the file)? > > > > In the discord chat there was one suggestion from Ho Kaido to move the > > files one level down and make them BSP specific. I'm not sure whether > > I'm for or against that idea. Advantage is that it makes BSPs > > independant from each other. Disadvantage is that it duplicates code. > > > > I think I would try to avoid moving them down due to the code > > duplication but it raises the question: Which BSPs use the files too and > > did you try whether they still compile after the upgrade? > > We have had this dicussion with Duc on discord IIRC when he started. He > needed new CMSIS (v5) version due to new HAL which Duc claims depends on > them. I have not verified that claim personally. > > New CMSIS v5 brings obviously: > > - by ARM maintained code (v4 is unmaintained IIRC) > > but also: > > - license change from BSD to Apache-2 > > At that time I've told Duc to continue with the code and not to worry > about license changes -- as this would be longer discussion anyway. Not > sure, but IIRC he also wrote to Sebastian asking for clarification -- > well, not sure about that. Certainly IIRC I suggested that. > > Anyway, I took Duc code and try H7 BSPs and to my surprise they compiles > more or less all without any compilation related issue. Well, I've not > tried M4 variants. So far I've not run full tester on this. I'll, but > first I'd like to test his API if it's possible to also use with H7. > > BTW: if RTEMS prefer old unmaintained BSD-3 ARM CSMIS code, then it's > perhaps possible to go in F4 HAL history back and grab just the three > with the v4 dependency. On the other hand, for ARM Apache-2 seems to be > the way forward and for some ST.com depended code too -- so I guess > RTEMS project will need to live with that fact somehow. > > Thanks, > Karel > > > -- > > Message: 2 > Date: Sat, 30 Jul 2022 22:19:54 +0200 > From: o...@c-mauderer.de > To: Karel Gardas , Duc Doan > , devel@rtems.org > Subject: Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL > Message-ID: <3628b5b2-0848-304f-9738-f6d64e9bb...@c-mauderer.de> > Content-Type: text/plain; charset=UTF-8; format=flowed > > > > > Am 30.07.22 um 21:41 schrieb Karel Gardas: > > On 7/30/22 16:32, o...@c-mauderer.de wrote: > >>> ? bsps/arm/include/cmsis_compiler.h |?? 266 + > >>> ? bsps/arm/include/cmsis_gcc.h? |? 3460 +-- > >>> ? bsps/a
[PATCH] cpukit/dev/can: Added CAN support
---
cpukit/dev/can/can.c | 514 +
cpukit/include/dev/can/can-msg.h | 55 +++
cpukit/include/dev/can/can-queue.h | 127 +++
cpukit/include/dev/can/can.h | 102 ++
spec/build/cpukit/librtemscpu.yml | 6 +
5 files changed, 804 insertions(+)
create mode 100644 cpukit/dev/can/can.c
create mode 100644 cpukit/include/dev/can/can-msg.h
create mode 100644 cpukit/include/dev/can/can-queue.h
create mode 100644 cpukit/include/dev/can/can.h
diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c
new file mode 100644
index 00..8feec8800b
--- /dev/null
+++ b/cpukit/dev/can/can.c
@@ -0,0 +1,514 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup CANBus
+ *
+ * @brief Controller Area Network (CAN) Bus Implementation
+ *
+ */
+
+/*
+ * Copyright (C) 2022 Prashanth S (fishesprasha...@gmail.com)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+
+#include
+
+static ssize_t
+can_bus_open(rtems_libio_t *iop, const char *path, int oflag, mode_t mode);
+static ssize_t
+can_bus_read(rtems_libio_t *iop, void *buffer, size_t count);
+static ssize_t
+can_bus_write(rtems_libio_t *iop, const void *buffer, size_t count);
+static ssize_t
+can_bus_ioctl(rtems_libio_t *iop, ioctl_command_t request, void *buffer);
+
+static int can_xmit(struct can_bus *bus);
+
+static int can_create_sem(struct can_bus *);
+static int try_sem(struct can_bus *);
+static int take_sem(struct can_bus *);
+static int give_sem(struct can_bus *);
+
+/* sem_count this is for debug purpose, for debugging
+the take_sem and give_sem
+*/
+static int sem_count = 0;
+
+static void can_bus_obtain(can_bus *bus)
+{
+ rtems_recursive_mutex_lock(>mutex);
+}
+
+static void can_bus_release(can_bus *bus)
+{
+ rtems_recursive_mutex_unlock(>mutex);
+}
+
+int can_create_sem(struct can_bus *bus)
+{
+ int ret = 0;
+
+ ret = rtems_semaphore_create(rtems_build_name('c', 'a', 'n', bus->index),
+ CAN_TX_BUF_COUNT, RTEMS_FIFO | RTEMS_COUNTING_SEMAPHORE | RTEMS_LOCAL,
+ 0, >tx_fifo_sem_id);
+
+ if (ret != 0) {
+printf("can_create_sem: rtems_semaphore_create failed %d\n", ret);
+ }
+
+ return ret;
+}
+
+static void can_interrupt_lock_acquire(struct can_bus *bus)
+{
+ can_bus_obtain(bus);
+ bus->can_dev_ops->dev_int(bus->priv, false);
+}
+
+static void can_interrupt_lock_release(struct can_bus *bus)
+{
+ bus->can_dev_ops->dev_int(bus->priv, true);
+ can_bus_release(bus);
+}
+
+static int take_sem(struct can_bus *bus)
+{
+ int ret = rtems_semaphore_obtain(bus->tx_fifo_sem_id, RTEMS_WAIT,
+RTEMS_NO_TIMEOUT);
+ if (ret == RTEMS_SUCCESSFUL) {
+CAN_DEBUG_LOCK("take_sem: Counting semaphore count = %d\n", ++sem_count);
+if (sem_count > CAN_TX_BUF_COUNT) {
+ printf("take_sem error: sem_count is misleading\n");
+ while (1);
+}
+ }
+
+ return ret;
+}
+
+static int give_sem(struct can_bus *bus)
+{
+ int ret = rtems_semaphore_release(bus->tx_fifo_sem_id);
+ if (ret == RTEMS_SUCCESSFUL) {
+CAN_DEBUG_LOCK("give_sem: Counting semaphore count = %d\n", --sem_count);
+if (sem_count < 0) {
+ printf("give_sem error: sem_count is misleading\n");
+ while (1);
+}
+ }
+
+ return ret;
+}
+
+static int try_sem(struct can_bus *bus)
+{
+ int ret = rtems_semaphore_obtain(bus->tx_fifo_sem_id, RTEMS_NO_WAIT,
+RTEMS_NO_TIMEOUT);
+ if (ret == RTEMS_SUCCESSFUL) {
+CAN_DEBUG_LOCK("take_sem: Counting semaphore count = %d\n", ++sem_count)
Re: [PATCH] cpukit/dev/can: Added CAN support
ile or a driver facing one. > >> +#define CAN_MSG_MAX_SIZE (8u) >> + >> +#define CAN_TX_BUF_COUNT (10u) >> +#define CAN_RX_BUF_COUNT (10u) > > Is that really a value that does match the needs of all drivers / > applications? Based on the suggestions, need to decide a suitable count. > What's the advantage of implementing two types of semaphores depending > on the _POSIX_SEM_ macro instead of just using only one RTEMS-native type? That I used for debug purposes, as at first rtems_semaphore_release was not working. So to test whether POSIX works I used that. Removing POSIX API. > I haven't had a detailed look at the useage of the semaphores yet. > Personally I prefer the self-contained objects because they have the > advantage that the application-developers don't have to think about them > when configuring their application: > > > https://docs.rtems.org/branches/master/c-user/self_contained_objects.html# <https://docs.rtems.org/branches/master/c-user/self_contained_objects.html#> > > Not sure whether that would be an option here. Ok, I will look into the link. > Some of the functions seem to be internal functions that are only used > in the framework (especially the ones with *_sem() but also the whole > create*buffers() stuff). You shouldn't expose them to the user. Make > them static or put them into some internal header. Moving them to can-queue.h or can.h header file. Regards Prashanth S On Tue, 19 Jul 2022 at 14:47, wrote: > Hello Prashanth, > > first question: You also worked on a driver for beagle DCAN. Did you > already adapt that driver to this API? If yes, it would be usefull to > post that as a patch too so that the direction and the method how it > will be used is more clear. > > Note that some of my comments might are a bit critical because you add a > general API. I would have a lot less problems if it would be only a > driver specific API. If you add a general API, it has to fit the needs > of not only your current driver but most future drivers too. Changing an > API later is allways tricky. > > Am 15.07.22 um 20:11 schrieb Prashanth S: > > --- > > cpukit/dev/can/can-queue.c| 112 +++ > > cpukit/dev/can/can.c | 480 ++ > > cpukit/include/dev/can/can.h | 115 +++ > > spec/build/cpukit/librtemscpu.yml | 5 + > > 4 files changed, 712 insertions(+) > > create mode 100644 cpukit/dev/can/can-queue.c > > create mode 100644 cpukit/dev/can/can.c > > create mode 100644 cpukit/include/dev/can/can.h > > > > diff --git a/cpukit/dev/can/can-queue.c b/cpukit/dev/can/can-queue.c > > new file mode 100644 > > index 00..1cebed2ca4 > > --- /dev/null > > +++ b/cpukit/dev/can/can-queue.c > > @@ -0,0 +1,112 @@ > > +/* SPDX-License-Identifier: BSD-2-Clause */ > > + > > +/** > > + * @file > > + * > > + * @ingroup CANBus > > + * > > + * @brief Controller Area Network (CAN) Bus Implementation > > + * > > + */ > > + > > +/* > > + * Copyright (C) 2022 > > + * > > + * Redistribution and use in source and binary forms, with or without > > + * modification, are permitted provided that the following conditions > > + * are met: > > + * 1. Redistributions of source code must retain the above copyright > > + * notice, this list of conditions and the following disclaimer. > > + * 2. Redistributions in binary form must reproduce the above copyright > > + * notice, this list of conditions and the following disclaimer in the > > + * documentation and/or other materials provided with the distribution. > > + * > > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS > "AS IS" > > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED > TO, THE > > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE > > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR > CONTRIBUTORS BE > > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR > BUSINESS > > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER > IN > > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR > OTHERWISE) > > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED > OF THE > > + * POSSIBILITY OF SUCH DAMAGE. > > + */ > > + > > +#include > > +#include > > + > > +#include > > + > >
[PATCH] cpukit/dev/can: Added CAN support
---
cpukit/dev/can/can-queue.c| 112 +++
cpukit/dev/can/can.c | 480 ++
cpukit/include/dev/can/can.h | 115 +++
spec/build/cpukit/librtemscpu.yml | 5 +
4 files changed, 712 insertions(+)
create mode 100644 cpukit/dev/can/can-queue.c
create mode 100644 cpukit/dev/can/can.c
create mode 100644 cpukit/include/dev/can/can.h
diff --git a/cpukit/dev/can/can-queue.c b/cpukit/dev/can/can-queue.c
new file mode 100644
index 00..1cebed2ca4
--- /dev/null
+++ b/cpukit/dev/can/can-queue.c
@@ -0,0 +1,112 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup CANBus
+ *
+ * @brief Controller Area Network (CAN) Bus Implementation
+ *
+ */
+
+/*
+ * Copyright (C) 2022
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+
+rtems_status_code can_create_rx_buffers(struct can_bus *bus)
+{
+ static int init = 0;
+
+ return rtems_message_queue_create(rtems_build_name('c', 'a', 'n', '0' +
init++), CAN_RX_BUF_COUNT, sizeof(struct can_msg),
+RTEMS_FIFO | RTEMS_LOCAL,
>rx_queue_id);
+}
+
+rtems_status_code can_create_tx_buffers(struct can_bus *bus)
+{
+ if ((bus->tx_fifo.pbuf = (struct can_msg *)malloc(CAN_TX_BUF_COUNT *
sizeof(struct can_msg))) == NULL) {
+printf("malloc failed\n");
+return RTEMS_NO_MEMORY;
+ }
+
+ bus->tx_fifo.head = bus->tx_fifo.tail = 0;
+ bus->tx_fifo.empty_count = CAN_TX_BUF_COUNT;
+
+ return 0;
+}
+
+bool can_tx_buf_isempty(struct can_bus *bus)
+{
+ if (bus->tx_fifo.empty_count <= 0) {
+/* tx_fifo.empty_count does not go below zero, incase if it goes update to
zero */
+bus->tx_fifo.empty_count = 0;
+
+return false;
+ }
+
+ return true;
+}
+
+struct can_msg *can_tx_get_data_buf(struct can_bus *bus)
+{
+ struct can_msg *msg = NULL;
+
+ if (bus->tx_fifo.empty_count == CAN_TX_BUF_COUNT) {
+printf("can_tx_get_next_data_buf All buffers are empty\n");
+return NULL;
+ }
+
+ msg = >tx_fifo.pbuf[bus->tx_fifo.tail];
+ bus->tx_fifo.empty_count++;
+ bus->tx_fifo.tail = (bus->tx_fifo.tail + 1) % CAN_TX_BUF_COUNT;
+
+ return msg;
+}
+
+struct can_msg *can_tx_get_empty_buf(struct can_bus *bus)
+{
+ struct can_msg *msg = NULL;
+
+ /* Check whether there is a empty CAN msg buffer */
+ if (can_tx_buf_isempty(bus) == false) {
+printf("can_tx_get_empty_buf No empty buffer\n");
+return NULL;
+ }
+
+ bus->tx_fifo.empty_count--;
+
+ /* tx_fifo.head always points to a empty buffer if there is atleast one */
+ msg = >tx_fifo.pbuf[bus->tx_fifo.head];
+ bus->tx_fifo.head = (bus->tx_fifo.head + 1) % CAN_TX_BUF_COUNT;
+
+ return msg;
+}
diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c
new file mode 100644
index 00..e8aa9d20ca
--- /dev/null
+++ b/cpukit/dev/can/can.c
@@ -0,0 +1,480 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup CANBus
+ *
+ * @brief Controller Area Network (CAN) Bus Implementation
+ *
+ */
+
+/*
+ * Copyright (C) 2022
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES,
Review Request for CAN patch for tx path and minimal rx support
This is a review request for the CAN patch with tx and minimal rx support. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2022:
Hi Christian, I created a patch (attached in the mail) for review, which has CAN support. Shall I send the patch for review to @rtems-de...@rtems.org ? Regards Prashanth S On Mon, 11 Jul 2022 at 10:03, Prashanth S wrote: > Hi Christian, > > This is to update the status. > > Yesterday, pushed a fix for a bug in tx path and added minimal rx path. > > Regards > Prashanth S > > On Thu, 7 Jul, 2022, 10:58 am Prashanth S, > wrote: > >> Hi Gedare, >> >> This is to ask for the License on the TI files. >> >> As we already confirmed on the license for TI files as BSD, this is to >> double check. >> >> I found two different licenses, I have added both of them. >> >> >> *dcan.c and all header files (except dcan_frame.h)* >> /** >> * \file dcan.c >> * >> * \brief DCAN APIs. >> * >> * This file contains the device abstraction layer APIs for >> * Dual Controller Area Network(DCAN). >> */ >> >> /* >> * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/ >> */ >> /* >> * Redistribution and use in source and binary forms, with or without >> * modification, are permitted provided that the following conditions >> * are met: >> * >> *Redistributions of source code must retain the above copyright >> *notice, this list of conditions and the following disclaimer. >> * >> *Redistributions in binary form must reproduce the above copyright >> *notice, this list of conditions and the following disclaimer in the >> *documentation and/or other materials provided with the >> *distribution. >> * >> *Neither the name of Texas Instruments Incorporated nor the names of >> *its contributors may be used to endorse or promote products derived >> *from this software without specific prior written permission. >> * >> * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS >> * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT >> * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR >> * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT >> * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, >> * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT >> * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, >> * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY >> * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT >> * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE >> * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. >> * >> */ >> >> >> *dcan_frame.c and dcan_frame.h* >> * \file dcan_frame.c >> * >> * \brief This file consists of wrapper functions which internally call >> * DCAN APIs. >> */ >> >> /* >> * Copyright (C) 2005 Marc Kleine-Budde, Pengutronix >> * Copyright (C) 2006 Andrey Volkov, Varma Electronics >> * Copyright (C) 2008-2009 Wolfgang Grandegger >> * >> * This program is free software; you can redistribute it and/or modify >> * it under the terms of the version 2 of the GNU General Public License >> * as published by the Free Software Foundation >> * >> * This program is distributed in the hope that it will be useful, >> * but WITHOUT ANY WARRANTY; without even the implied warranty of >> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> * GNU General Public License for more details. >> * >> * You should have received a copy of the GNU General Public License >> * along with this program; if not, write to the Free Software >> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 >> USA >> */ >> >> Regards >> Prashanth S >> >> On Wed, 1 Jun 2022 at 07:15, Gedare Bloom wrote: >> >>> On Sun, May 29, 2022 at 6:09 AM Prashanth S >>> wrote: >>> > >>> > Hi Christian, >>> > >>> > Please make sure to take notes for blog posts or the weekly >>> > status meeting. >>> > Ok. >>> > >>> > The License mentined in drivers/dcan.c >>> > >>> > /* >>> > * Copyright (C) 2010 Texas Instruments Incorporated - >>> http://www.ti.com/ >>> > */ >>> > /* >>> > * Redistribution and use in source and binary forms, with or without >>> > * modification,
Updated CAN message structure.
Hi All,
This is to present the updated CAN message structure.
*Updating the CAN message structure:*
struct can_message {
uint32_t id; // 32 bits to support extended id (29 bits)
uint32_t timestamp;
uint16_t flags;// RTR | BRS | EXT ...
uint16_t len;
uint8_t data[64]; // For supporting data transfer up to 64 bytes.
};
Regards
Prashanth S
On Tue, 21 Jun 2022 at 14:43, Oliver Hartkopp
wrote:
> Hi Christian,
>
> I'm not subscribed to the RTEMS ML so my mail has not been forwarded.
>
> I'm with you about the 16 bit length info.
>
> See below ...
>
> On 6/21/22 08:55, Oliver Hartkopp wrote:
> > Hello all,
> >
> > I'm definitely with Pavel's suggestions here!
> >
> > I added some small remarks regarding the current CAN XL discussion
> in-line:
> >
> > On 20.06.22 22:57, Pavel Pisa wrote:
> >> Hello Prashanth S and others,
> >>
> >> excuse me for lower activity last weeks. We have exams period
> >> and I have lot of other duties and was even ill. I am at Embedded
> >> World in Nuremberg now, so may it be there is some chance to meet
> >> somebody other from RTEMS community.
> >>
> >> As for the e-mail it is better to add one of my personal e-mails
> >> (p...@cmp.felk.cvut.cz or pp...@pikron.com)
> >> to notice me for something important, I do not check every
> >> message comming through my list subscription. I go through
> >> RTEMS, NuttX, CAN, etc. forums only when I have spare time.
> >>
> >> On Monday 20 of June 2022 18:37:38 Prashanth S wrote:
> >>> This is a request for suggestions and feedback for the CAN message
> >>> structure.
> >>>
> >>> *CAN message structure that represents the can messages from
> >>> application to
> >>> driver:*
> >>>
> >>> struct can_message {
> >>> uint32_t timestamp;
> >>> uint32_t id; // 32 bits to support extended id (29
> bits)
> >>> uint16_t flags;// RTR | BRS | EXT ...
> >>> uint8_t dlc; // (0 - 8) | 12 | 16 | 20 | 24 | 32 | 48
> >>> | 64
> >>> uint8_t res; // reserved for alignment.
> >>> uint8_t data[64]; // For supporting data transfer up to 64
> >>> bytes.
> >>> };
> >>>
> >>> This is the CAN messages structure created based on the suggestions
> >>> in the
> >>> mail chain and looking through other CAN solutions (Nuttx, GRCAN,
> >>> LinCAN).
> >>
> >> Yes I like solution with explicit and aligned fields.
> >> I confirm that I think that length representing real data length is
> >> better
> >> and it has been chosen for CAN FD by SocketCAN.
> >
> > Yes. Handling the DLC/Length conversion in every user program is a mess.
> > That's why we actually changed the dlc to len even for Classical CAN
> > frames in the struct can_frame:
> >
> > struct can_frame {
> > canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
> > union {
> > /* CAN frame payload length in byte (0 .. CAN_MAX_DLEN)
> > * was previously named can_dlc so we need to carry that
> > * name for legacy support
> > */
> > __u8 len;
> > __u8 can_dlc; /* deprecated */
> > } __attribute__((packed)); /* disable padding added in some
> > ABIs */
> > __u8 __pad; /* padding */
> > __u8 __res0; /* reserved / padding */
> > __u8 len8_dlc; /* optional DLC for 8 byte payload length (9 ..
> > 15) */
> > __u8 data[CAN_MAX_DLEN] __attribute__((aligned(8)));
> > };
> >
> > You might also think about a union to carry the Classical CAN length and
> > the CAN FD length in one 8 bit value and add the extra Classical CAN raw
> > DLC in another 8 bit value - and make a union with a 16 bit length value
> > which is needed for CAN XL.
> >
> >
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/uapi/linux/can.h?id=ea7800565a128c1adafa1791ce80afd6016fe21c
> >
> >
> > But in fact the raw DLC value has been introduced only because of some
> > people doing security testing. The Classical CAN raw DLC value has no
> > value for normal CAN applications and therefore using a simple 16 bit
> > length value would be the best choice IMHO (see below).
> >
> >> I confirm that flags implemented with expli
Request for feedback for CAN message structure
Hi All,
This is a request for suggestions and feedback for the CAN message
structure.
*CAN message structure that represents the can messages from application to
driver:*
struct can_message {
uint32_t timestamp;
uint32_t id; // 32 bits to support extended id (29 bits)
uint16_t flags;// RTR | BRS | EXT ...
uint8_t dlc; // (0 - 8) | 12 | 16 | 20 | 24 | 32 | 48 | 64
uint8_t res; // reserved for alignment.
uint8_t data[64]; // For supporting data transfer up to 64 bytes.
};
This is the CAN messages structure created based on the suggestions in the
mail chain and looking through other CAN solutions (Nuttx, GRCAN, LinCAN).
Regards
Prashanth S
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: CAN Options and Licensing, Testing, etc
Hi All, This is to summarize the things suggested from the discussions and clarify on CAN generic APIs. Things on the plate: - CAN driver for BBB. - CAN driver for any one of the QEMU supported SoC (SJA1000 on PCI/e on x86, Zynq UltraScale+ MPSo on QEMU). - Generic CAN APIs. - ADC driver (not using libbsd) for BBB. Please correct me if I missed out anything. Query on CAN generic APIs: With my understanding on the discussions, Should I use the mentioned stacks (LinCAN, CANOpen) as reference and define the data structures (CAN message header and CAN message structures) or port one of the stacks (In case port one of the stacks is the right option: >From the suggestions given in the discussions, I could not conclude which stack to choose, Considering the future Scalability (both software stack and CAN protocol features) and portability) to RTEMS. Please correct me if I am wrong with my understanding. Regards Prashanth S On Thu, 14 Apr 2022 at 18:33, Joel Sherrill wrote: > > > On Wed, Apr 13, 2022, 10:46 PM Prashanth S > wrote: > >> Hi Pavel, >> >> But if you would fit with writing/porting driver >>> for some other CAN interface which is available >>> under QEMU it would be great. I.e. SJA1000 on PCI/e >>> on x86 and may be some other target or Zynq UltraScale+ >>> MPSo on QEMU it would be nice to have ability to test >>> driver by everybody and writing at least one other to BBB >>> would help to define API which would fit more targets better >>> even in future. >>> >> >> Yes, Adding a CAN driver in QEMU would be more accessible for everyone to >> test the APIs. I will try to do that. >> > > Depends on your goal. If porting a CAN stack, it doesn't matter which > architecture or bsp you are using. You just need an easy way to test it. > Qemu is that easy way. > > If CAN on BBB, then you need to be on hardware and plan for that. > > >> Other option is to add writing BBB CAn controller support >>> for QEMU, but I think that it would be too much load. >>> >> >> I think QEMU does not have Am335x support ( >> https://wiki.qemu.org/Documentation/Platforms/ARM). >> >> Regards >> Prashanth S >> >> On Thu, 14 Apr 2022 at 00:29, Pavel Pisa wrote: >> >>> Dear Prashanth, >>> >>> On Wednesday 13 of April 2022 04:32:45 Prashanth S wrote: >>> > Have you determined how you will test CAN on BBB? >>> > >>> > I planned to test the CAN driver with another BBB running linux. And >>> if CAN >>> > analyzer is economical then I would use that. >>> >>> I think that testing against Linux kernel is good >>> option. AM3358 has to CAN controllers so if you can >>> find pin mux combination to connect CAN transceivers >>> to both then you can test and load/flood them directly >>> by the board. So I agree with this as a good environment >>> for development. >>> >>> The BBB is probably relatively accessible for others too. >>> >>> But if you would fit with writing/porting driver >>> for some other CAN interface which is available >>> under QEMU it would be great. I.e. SJA1000 on PCI/e >>> on x86 and may be some other target or Zynq UltraScale+ >>> MPSo on QEMU it would be nice to have ability to test >>> driver by everybody and writing at least one other to BBB >>> would help to define API which would fit more targets better >>> even in future. >>> >>> Other option is to add writing BBB CAn controller support >>> for QEMU, but I think that it would be too much load. >>> >>> I suggest to focus mainly on CAN anyway and left ADC as >>> optional task if the time remains... >>> >>> When RTEMS has reasonable CAN API it would be big GSoC >>> achievement. >>> >>> Best wishes, >>> >>> Pavel >>> >>> ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: CAN Options and Licensing, Testing, etc
> > And should be able to demonstrate CAN Linux <-> on the same hardware to > verify your test setup. > Ok, that will be helpful to verify the hardware test setup. Regards, Prashanth S On Thu, 14 Apr 2022 at 00:52, Joel Sherrill wrote: > > > On Tue, Apr 12, 2022 at 9:32 PM Prashanth S > wrote: > >> Hi Joel, >> >> Have you determined how you will test CAN on BBB? >> >> I planned to test the CAN driver with another BBB running linux. And if >> CAN analyzer is economical then I would use that. >> > > OK. I assume you have accounted for all the cables, transceivers, etc. > > And should be able to demonstrate CAN Linux <-> on the same hardware to > verify your test setup. > > I'm deferring to others for the hardware needed. I just know there has to > be a shopping list. > > --joel > >> >> Regards >> Prashanth S >> >> On Wed, 13 Apr 2022 at 00:38, Joel Sherrill wrote: >> >>> >>> >>> On Tue, Apr 12, 2022 at 12:39 PM Oliver Hartkopp >>> wrote: >>> >>>> Hi Joel, >>>> >>>> at least for the SocketCAN network layer part the license is a dual >>>> license BSD3/GPLv2 >>>> >>>> // SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) >>>> >>>> https://elixir.bootlin.com/linux/v5.17.2/source/net/can/af_can.c#L1 >>>> >>>> The reason was that we (at Volkswagen) intended the idea, the API, >>>> (CAN) >>>> data structures and code could be easily ported to BSD/MacOS/Windows. >>>> >>>> In fact we created a working Windows PoC but CAN hardware vendors had >>>> no >>>> interest to unify a open CAN driver API - to maintain their Lock-In :-/ >>>> >>>> Today only a few CAN network drivers in linux/drivers/net/can follow >>>> this dual license approach. As they are 'Linux-specific' they are >>>> mostly >>>> GPLv2. >>>> >>> >>> Thanks for clarifying that. >>> >>> The PowerPC qoriq network drivers in libbsd are dual licensed and there >>> is some framework included to support Linux drivers in libbsd. That's the >>> extent of my knowledge but it at least means this could be possible to >>> integrate without knowingly diving into a deep pit. >>> >>> It has the disadvantage that CAN support would be tied to using libbsd. >>> That's likely too heavy for some environments. But might be a good >>> solution if portability of applications is a goal. >>> >>> >>>> Best regards, >>>> Oliver >>>> >>>> >>>> On 12.04.22 19:13, Prashanth S wrote: >>>> > Hi All, >>>> > >>>> > This is to ask for suggestions on implementing the CAN driver for BBB. >>>> > >>>> > Can I proceed with defining driver specific structures for the CAN >>>> > driver or go with adding a generic API layer for ADC and GPIO. >>>> >>> >>> Have you determined how you will test CAN on BBB? >>> >>> I imagine you can use libdebugger to debug CAN. >>> >>> A big part of the community part of GSoC is making sure you are >>> in a good position to succeed. That means knowing how you will >>> test. >>> >>> --joel >>> >>> --joel >>> >>> >>>> > >>>> > Regards >>>> > Prashanth S >>>> > >>>> > >>>> > On Tue, 12 Apr 2022 at 19:14, Joel Sherrill >>> > <mailto:j...@rtems.org>> wrote: >>>> > >>>> > Hi >>>> > >>>> > I didn't want to post this in the other thread and turn it from a >>>> > technical into licensing discussion but that must be the first >>>> > filter for a CAN solution for RTEMS if it uses third-party code. >>>> If >>>> > I have extracted the options correctly, we have: >>>> > >>>> > + LinCAN - GPL >>>> > + SocketCAN - GPL >>>> > + NuttX CAN - Apache >>>> > + CANOpen - Apache >>>> > >>>> > The licensing alone eliminates two of the solutions. >>>> > >>>> > My other concern was how you were going to test the drivers you >>>> > wrote. Pavel mentions CAN in qemu. Perhaps the project should drop >>>> > the ADC and focus on a CAN solution using the BSP supported by >>>> Qemu >>>> > along with whatever analysis tools Pavel recommends. I am sure >>>> Pavel >>>> > has some driver code for the Qemu path (not sure if it is in RTEMS >>>> > or not) This would move the project from a single driver to trying >>>> > to provide a CAN solution. This is much more valuable to the >>>> project >>>> > long term. >>>> > >>>> > And since CANOpen is an independent and long running project, I'd >>>> > lean to it as the selection. >>>> > >>>> > Just my thoughts >>>> > >>>> > --joel >>>> > >>>> > >>>> >>> ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: CAN Options and Licensing, Testing, etc
Hi Pavel, But if you would fit with writing/porting driver > for some other CAN interface which is available > under QEMU it would be great. I.e. SJA1000 on PCI/e > on x86 and may be some other target or Zynq UltraScale+ > MPSo on QEMU it would be nice to have ability to test > driver by everybody and writing at least one other to BBB > would help to define API which would fit more targets better > even in future. > Yes, Adding a CAN driver in QEMU would be more accessible for everyone to test the APIs. I will try to do that. Other option is to add writing BBB CAn controller support > for QEMU, but I think that it would be too much load. > I think QEMU does not have Am335x support ( https://wiki.qemu.org/Documentation/Platforms/ARM). Regards Prashanth S On Thu, 14 Apr 2022 at 00:29, Pavel Pisa wrote: > Dear Prashanth, > > On Wednesday 13 of April 2022 04:32:45 Prashanth S wrote: > > Have you determined how you will test CAN on BBB? > > > > I planned to test the CAN driver with another BBB running linux. And if > CAN > > analyzer is economical then I would use that. > > I think that testing against Linux kernel is good > option. AM3358 has to CAN controllers so if you can > find pin mux combination to connect CAN transceivers > to both then you can test and load/flood them directly > by the board. So I agree with this as a good environment > for development. > > The BBB is probably relatively accessible for others too. > > But if you would fit with writing/porting driver > for some other CAN interface which is available > under QEMU it would be great. I.e. SJA1000 on PCI/e > on x86 and may be some other target or Zynq UltraScale+ > MPSo on QEMU it would be nice to have ability to test > driver by everybody and writing at least one other to BBB > would help to define API which would fit more targets better > even in future. > > Other option is to add writing BBB CAn controller support > for QEMU, but I think that it would be too much load. > > I suggest to focus mainly on CAN anyway and left ADC as > optional task if the time remains... > > When RTEMS has reasonable CAN API it would be big GSoC > achievement. > > Best wishes, > > Pavel > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: CAN Options and Licensing, Testing, etc
Hi Joel, Have you determined how you will test CAN on BBB? I planned to test the CAN driver with another BBB running linux. And if CAN analyzer is economical then I would use that. Regards Prashanth S On Wed, 13 Apr 2022 at 00:38, Joel Sherrill wrote: > > > On Tue, Apr 12, 2022 at 12:39 PM Oliver Hartkopp > wrote: > >> Hi Joel, >> >> at least for the SocketCAN network layer part the license is a dual >> license BSD3/GPLv2 >> >> // SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) >> >> https://elixir.bootlin.com/linux/v5.17.2/source/net/can/af_can.c#L1 >> >> The reason was that we (at Volkswagen) intended the idea, the API, (CAN) >> data structures and code could be easily ported to BSD/MacOS/Windows. >> >> In fact we created a working Windows PoC but CAN hardware vendors had no >> interest to unify a open CAN driver API - to maintain their Lock-In :-/ >> >> Today only a few CAN network drivers in linux/drivers/net/can follow >> this dual license approach. As they are 'Linux-specific' they are mostly >> GPLv2. >> > > Thanks for clarifying that. > > The PowerPC qoriq network drivers in libbsd are dual licensed and there > is some framework included to support Linux drivers in libbsd. That's the > extent of my knowledge but it at least means this could be possible to > integrate without knowingly diving into a deep pit. > > It has the disadvantage that CAN support would be tied to using libbsd. > That's likely too heavy for some environments. But might be a good > solution if portability of applications is a goal. > > >> Best regards, >> Oliver >> >> >> On 12.04.22 19:13, Prashanth S wrote: >> > Hi All, >> > >> > This is to ask for suggestions on implementing the CAN driver for BBB. >> > >> > Can I proceed with defining driver specific structures for the CAN >> > driver or go with adding a generic API layer for ADC and GPIO. >> > > Have you determined how you will test CAN on BBB? > > I imagine you can use libdebugger to debug CAN. > > A big part of the community part of GSoC is making sure you are > in a good position to succeed. That means knowing how you will > test. > > --joel > > --joel > > >> > >> > Regards >> > Prashanth S >> > >> > >> > On Tue, 12 Apr 2022 at 19:14, Joel Sherrill > > <mailto:j...@rtems.org>> wrote: >> > >> > Hi >> > >> > I didn't want to post this in the other thread and turn it from a >> > technical into licensing discussion but that must be the first >> > filter for a CAN solution for RTEMS if it uses third-party code. If >> > I have extracted the options correctly, we have: >> > >> > + LinCAN - GPL >> > + SocketCAN - GPL >> > + NuttX CAN - Apache >> > + CANOpen - Apache >> > >> > The licensing alone eliminates two of the solutions. >> > >> > My other concern was how you were going to test the drivers you >> > wrote. Pavel mentions CAN in qemu. Perhaps the project should drop >> > the ADC and focus on a CAN solution using the BSP supported by Qemu >> > along with whatever analysis tools Pavel recommends. I am sure Pavel >> > has some driver code for the Qemu path (not sure if it is in RTEMS >> > or not) This would move the project from a single driver to trying >> > to provide a CAN solution. This is much more valuable to the project >> > long term. >> > >> > And since CANOpen is an independent and long running project, I'd >> > lean to it as the selection. >> > >> > Just my thoughts >> > >> > --joel >> > >> > >> > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: CAN Options and Licensing, Testing, etc
Hi All, This is to ask for suggestions on implementing the CAN driver for BBB. Can I proceed with defining driver specific structures for the CAN driver or go with adding a generic API layer for ADC and GPIO. Regards Prashanth S On Tue, 12 Apr 2022 at 19:14, Joel Sherrill wrote: > Hi > > I didn't want to post this in the other thread and turn it from a > technical into licensing discussion but that must be the first filter for a > CAN solution for RTEMS if it uses third-party code. If I have extracted the > options correctly, we have: > > + LinCAN - GPL > + SocketCAN - GPL > + NuttX CAN - Apache > + CANOpen - Apache > > The licensing alone eliminates two of the solutions. > > My other concern was how you were going to test the drivers you wrote. > Pavel mentions CAN in qemu. Perhaps the project should drop the ADC and > focus on a CAN solution using the BSP supported by Qemu along with whatever > analysis tools Pavel recommends. I am sure Pavel has some driver code for > the Qemu path (not sure if it is in RTEMS or not) This would move the > project from a single driver to trying to provide a CAN solution. This is > much more valuable to the project long term. > > And since CANOpen is an independent and long running project, I'd lean to > it as the selection. > > Just my thoughts > > --joel > > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
CAN driver message structure
Hi All,
This is to query on CAN message format for CAN drivers.
I want to implement a CAN driver for BeagleBone Black in RTEMS(GSoC).
As I looked through the RTEMS Source Tree, found
https://devel.rtems.org/browser/rtems/bsps/arm/lpc176x/can
<https://www.google.com/url?q=https://devel.rtems.org/browser/rtems/bsps/arm/lpc176x/can=D=docs=1649726382869937=AOvVaw3vJP6V_BiCCjzC3q-F4AH1>
, https://devel.rtems.org/browser/rtems/bsps/powerpc/gen5200/mscan
<https://www.google.com/url?q=https://devel.rtems.org/browser/rtems/bsps/powerpc/gen5200/mscan=D=docs=1649726382870043=AOvVaw3i4_IK73l4WoZ7u64ab0yB>
CAN drivers, which have driver specific CAN message structure.
https://devel.rtems.org/browser/rtems/bsps/powerpc/gen5200/include/bsp/mscan.h
struct can_message {
/* uint16_t mess_len; */
uint16_t mess_id;
uint16_t mess_time_stamp;
uint8_t mess_data[MSCAN_MAX_DATA_BYTES];
uint8_t mess_len;
uint8_t mess_rtr;
uint32_t toucan_tx_idx;
};
https://devel.rtems.org/browser/rtems/bsps/arm/lpc176x/include/bsp/can.h
typedef union {
low_level_can_message low_level;
registers_can_message registers;
} can_message;
I would like to know if I should define a driver dependent CAN message
structure or use one of the existing ones.
Ideally, I think a generic (driver independent) CAN message structure will
help applications to be portable.
Regards
Prashanth S
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
GSoC-2022 Hello-World Project for BeagleBone Black
Hi All, This is to send the Hello-World Project for BeagleBone Black BSP. I am Prashanth S a working professional with experience of 3 years and 6 months. I wanted to be part of open source community especially contributing RTOS, by taking GSoC-2022 as an opportunity I like to contribute to BeagleBone Black BSP. I have previously worked on beaglebone black, developing a learning tool kit (Bare metal firmware with few supported peripherals CPSW, gpio, interrupt). GitHub - slpp95prashanth/Beaglebone-mBootloader at cpsw <https://github.com/slpp95prashanth/Beaglebone-mBootloader/tree/cpsw> Please find the attachment for the patch and screenshot for the hello world project. Regards Prashanth S Phone Number: 9942432100 Gmail: fishesprasha...@gmail.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
