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
<devel@rtems.org>?
Regards
Prashanth S
On Mon, 11 Jul 2022 at 10:03, Prashanth S <fishesprasha...@gmail.com> 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, <fishesprasha...@gmail.com>
> 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 <w...@grandegger.com>
>> *
>> * 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 <ged...@rtems.org> wrote:
>>
>>> On Sun, May 29, 2022 at 6:09 AM Prashanth S <fishesprasha...@gmail.com>
>>> 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, 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.
>>> > *
>>> > */
>>> >
>>> That license looks ok. It is a 3-BSD (2-BSD with advertising
>>> restriction).
>>>
>>> Is there an AM335x API for CAN in addition to the drivers? I have used
>>> TI's Tivaware before which has it's own CAN API, for example. That
>>> could be another possibility to consider for an initial simple target,
>>> if the code already exists for it.
>>>
>>> I think the choice of CAN API is a bit complicated. The grlib/grcan is
>>> actually a good choice for RTEMS.
>>>
>>> > Regards
>>> > Prashanth S
>>> >
>>> > On Sun, 29 May 2022 at 13:33, Christian Mauderer <o...@c-mauderer.de>
>>> wrote:
>>> >>
>>> >> Hello Prashanth,
>>> >>
>>> >> sounds good. Please make sure to take notes for blog posts or the
>>> weekly
>>> >> status meeting.
>>> >>
>>> >> You mention "Am335x starterware". Which license does that have? If it
>>> is
>>> >> compatible to the BSD license, it might would be possible to just port
>>> >> the driver.
>>> >>
>>> >> Best regards
>>> >>
>>> >> Christian
>>> >>
>>> >> Am 28.05.22 um 16:15 schrieb Prashanth S:
>>> >> > Hi All,
>>> >> >
>>> >> > This is a status update on today's work.
>>> >> >
>>> >> > Gone through the HW initialization requirements for CAN loopback to
>>> work
>>> >> > in interrupt mode from Am335x starterware.
>>> >> > With this and the Am335x reference manual, I would try to
>>> understand the
>>> >> > HW initialization sequence and then start implementing the driver
>>> in RTEMS.
>>> >> >
>>> >> > Regards
>>> >> > Prashanth S
>>> >> >
>>> >> > On Fri, 27 May 2022 at 00:00, Christian Mauderer <o...@c-mauderer.de
>>> >> > <mailto:o...@c-mauderer.de>> wrote:
>>> >> >
>>> >> > Am 26.05.22 um 19:16 schrieb Prashanth S:
>>> >> > > Hi Christian,
>>> >> > >
>>> >> > > You have a medium sized project. That means it's no full
>>> time. Do
>>> >> > > you plan to work full time on the start or the end or part
>>> time
>>> >> > during
>>> >> > > the whole GSoC time?
>>> >> > > I plan to work part time on the weekdays and full time on the
>>> >> > weekends.
>>> >> > >
>>> >> > > The plan of project is more or less your proposal, isn't it?
>>> >> > > Yes the plan is the same as the proposal.
>>> >> > >
>>> >> > > Beneath that: I think you need a decision soon which CAN
>>> stack
>>> >> > you want
>>> >> > > to use. It will define some of the interfaces for the CAN
>>> driver.
>>> >> > Pavel
>>> >> > > suggested a few on the mailing list. I'm not sure whether
>>> there
>>> >> > was some
>>> >> > > final one selected?
>>> >> > > The final one is not selected yet. Meanwhile, I thought of
>>> >> > implementing
>>> >> > > the CAN driver
>>> >> > > and get the tx and rx working, and get the driver into the
>>> framework.
>>> >> >
>>> >> > You can start working on some parts but note that different
>>> driver
>>> >> > stacks can have quite different APIs. Therefore most of the
>>> time it's
>>> >> > simpler if you know the stack that should be used.
>>> >> >
>>> >> > >
>>> >> > > @p...@cmp.felk.cvut.cz <mailto:p...@cmp.felk.cvut.cz>
>>> >> > <mailto:p...@cmp.felk.cvut.cz <mailto:p...@cmp.felk.cvut.cz>> ,
>>> >> > @Christian
>>> >> > > Mauderer <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>
>>> ,
>>> >> > @Gedare Bloom
>>> >> > > <mailto:ged...@rtems.org <mailto:ged...@rtems.org>> .
>>> >> > >
>>> >> > > May I ask for suggestions on the CAN framework for RTEMS.
>>> >> > > Shall I take the suggested stacks as reference and develop
>>> APIs
>>> >> > and data
>>> >> > > structures.
>>> >> > > Or select a particular stack and port the required features?
>>> >> >
>>> >> > I think Pavel knows CAN stacks and frameworks a lot better than
>>> me.
>>> >> > So I
>>> >> > hope that he can suggest a good approach here.
>>> >> >
>>> >> > I think the discussion on the list about the stacks stopped
>>> about a
>>> >> > month ago without a result, did it? The last mail seems to be
>>> from
>>> >> > Pavel
>>> >> > from 16.04.. He suggested some directions. Maybe you can create
>>> a plan
>>> >> > based on that and post it to the list for further discussions.
>>> >> >
>>> >> > It would be good to do that soon so that the discussion can
>>> take place
>>> >> > while you are still doing other things like setting up your
>>> hardware
>>> >> > and
>>> >> > the Linux test setup.
>>> >> >
>>> >> > >
>>> >> > > Is a JTAG setup for BBB needed or prints would be sufficient
>>> for
>>> >> > debugging?
>>> >> >
>>> >> > Having a good debug solution is always useful in my experience.
>>> So if
>>> >> > you have the possibility to set up a JTAG debugger, you should
>>> invest
>>> >> > the time. Using prints could work in this project but it is
>>> >> > definitively
>>> >> > a inferior solution. Another possibility in this case could be
>>> >> > libdebugger. But I have to say that I never used that myself
>>> because I
>>> >> > always had a hardware debugger.
>>> >> >
>>> >> > Best regards
>>> >> >
>>> >> > Christian
>>> >> >
>>> >> > >
>>> >> > >
>>> >> > > Regards
>>> >> > > Prashanth S
>>> >> > >
>>> >> > >
>>> >> > > On Thu, 26 May 2022 at 21:33, Christian Mauderer
>>> >> > <o...@c-mauderer.de <mailto:o...@c-mauderer.de>
>>> >> > > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>>
>>> wrote:
>>> >> > >
>>> >> > > Hello Prashanth,
>>> >> > >
>>> >> > > Am 26.05.22 um 17:40 schrieb Prashanth S:
>>> >> > > > Hi Christian Mauderer,
>>> >> > > >
>>> >> > > > Thank You.
>>> >> > > >
>>> >> > > > Most of the time the RTEMS mailing list is quite
>>> informal and
>>> >> > > most of us
>>> >> > > > just use first names to address someone ("Christian"
>>> in my
>>> >> > case). Is
>>> >> > > > that OK for you too? How do you prefer to be
>>> addressed?
>>> >> > > > Yes, no problem in calling me by first name
>>> (Prashanth).
>>> >> > > >
>>> >> > > > Last years it always was a good idea to sort out time
>>> >> > zones. You
>>> >> > > > mentioned that you are from India so you are most
>>> likely at
>>> >> > > UTC+5:30? Is
>>> >> > > > that correct? I'm in Germany and therefore my time is
>>> UTC+2
>>> >> > > during the
>>> >> > > > summer. That means that I sometimes forget at my
>>> evening
>>> >> > that's
>>> >> > > already
>>> >> > > > late in the night for you. Please don't hesitate to
>>> just
>>> >> > tell me
>>> >> > > that we
>>> >> > > > should continue a discussion on the next day if it
>>> starts
>>> >> > to get too
>>> >> > > > late for you ;-)
>>> >> > > > Yes, my time zone is UTC +5:30.
>>> >> > > >
>>> >> > > > Do you already have everything set up or do you
>>> >> > > > need some help with that? Maybe you can tell me
>>> roughly
>>> >> > what hardware
>>> >> > > > you use? I would like to try to reproduce the setup
>>> here
>>> >> > so that
>>> >> > > I can
>>> >> > > > test your software or help with debugging where
>>> necessary.
>>> >> > > > I have a BBB and Sn65Hvd230 Can Bus Transceiver. I am
>>> >> > planning to
>>> >> > > buy
>>> >> > > > one more
>>> >> > > > BBB for testing CAN driver.
>>> >> > > >
>>> >> > > > @o...@c-mauderer.de <mailto:o...@c-mauderer.de>
>>> >> > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>
>>> >> > > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>
>>> >> > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>> ,
>>> @Pavel Pisa
>>> >> > > > <mailto:ppisa4li...@pikron.com
>>> >> > <mailto:ppisa4li...@pikron.com> <mailto:ppisa4li...@pikron.com
>>> >> > <mailto:ppisa4li...@pikron.com>>> ,
>>> >> > > @Gedare Bloom <mailto:ged...@rtems.org
>>> >> > <mailto:ged...@rtems.org> <mailto:ged...@rtems.org
>>> >> > <mailto:ged...@rtems.org>>> .
>>> >> > > >
>>> >> > > > How do you prefer to be addressed?
>>> >> > >
>>> >> > > Like I said: First name is OK. So just Christian.
>>> >> > >
>>> >> > > >
>>> >> > > > I would like to start the programming part early.
>>> >> > >
>>> >> > > OK. You have a medium sized project. That means it's no
>>> full
>>> >> > time. Do
>>> >> > > you plan to work full time on the start or the end or
>>> part
>>> >> > time during
>>> >> > > the whole GSoC time?
>>> >> > >
>>> >> > > >
>>> >> > > > May I ask, what are the things I need to do before
>>> starting?
>>> >> > > > (Like, plan of the project, module design, creating a
>>> github
>>> >> > > repo, blog
>>> >> > > > posts)
>>> >> > >
>>> >> > > The plan of project is more or less your proposal, isn't
>>> it?
>>> >> > >
>>> >> > > I would suggest to start with a blog early. It's nice if
>>> you
>>> >> > create it
>>> >> > > more or less as a "diary" what you did. It maybe isn't a
>>> bad
>>> >> > idea to
>>> >> > > plan for example about weekly posts as a preparation for
>>> the
>>> >> > > meetings on
>>> >> > > Discord. But you can also do posts every time you have a
>>> nice
>>> >> > > self-contained part of work or similar.
>>> >> > >
>>> >> > > I think you planned to test your hardware setup with
>>> Linux.
>>> >> > So maybe a
>>> >> > > nice first post could be about your hardware setup and
>>> how it
>>> >> > runs the
>>> >> > > Linux sample.
>>> >> > >
>>> >> > > Beneath that: I think you need a decision soon which CAN
>>> >> > stack you want
>>> >> > > to use. It will define some of the interfaces for the CAN
>>> >> > driver. Pavel
>>> >> > > suggested a few on the mailing list. I'm not sure whether
>>> >> > there was
>>> >> > > some
>>> >> > > final one selected?
>>> >> > >
>>> >> > >
>>> >> > > Setting up a GitHub Repo is also a good idea but you need
>>> >> > something
>>> >> > > that
>>> >> > > you want to put there. Only cloning the RTEMS repo isn't
>>> >> > really useful
>>> >> > > if you don't add patches.
>>> >> > >
>>> >> > > I tend to keep my working environment in a repository.
>>> If you
>>> >> > want to
>>> >> > > use something like that, this might be a good starting
>>> point
>>> >> > for a
>>> >> > > repository. Basically just some commands in scripts and
>>> makefiles
>>> >> > > together with demo applications and repositories pulled
>>> in as
>>> >> > > submodules. That makes it simple to reproduce a certain
>>> >> > version. I
>>> >> > > would
>>> >> > > strongly suggest to create it yourself because then you
>>> know
>>> >> > your way
>>> >> > > around it. But if you want, you can also take a look at
>>> what
>>> >> > I use
>>> >> > > since
>>> >> > > some years for testing code from BBB-GSoC projects:
>>> >> > >
>>> >> > > https://gitlab.com/c-mauderer/rtems-bbb
>>> >> > <https://gitlab.com/c-mauderer/rtems-bbb>
>>> >> > > <https://gitlab.com/c-mauderer/rtems-bbb
>>> >> > <https://gitlab.com/c-mauderer/rtems-bbb>>
>>> >> > >
>>> >> > > But like I said: Please think about starting something
>>> like
>>> >> > that from
>>> >> > > scratch because you then know every line of it and where
>>> you
>>> >> > have to
>>> >> > > change something.
>>> >> > >
>>> >> > > Best regards
>>> >> > >
>>> >> > > Christian
>>> >> > >
>>> >> > > >
>>> >> > > > Regards
>>> >> > > > Prashanth S
>>> >> > > >
>>> >> > > > On Thu, 26 May 2022 at 20:24, Christian Mauderer
>>> >> > > <o...@c-mauderer.de <mailto:o...@c-mauderer.de>
>>> >> > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>
>>> >> > > > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>
>>> >> > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>>> wrote:
>>> >> > > >
>>> >> > > >
>>> >> > > > Hello Prashanth S,
>>> >> > > >
>>> >> > > > welcome to this years GSoC.
>>> >> > > >
>>> >> > > > I'm sure you have already seen that Pavel and I
>>> have been
>>> >> > > assigned as
>>> >> > > > mentor to your project. Gedare is backup in case
>>> one
>>> >> > or both
>>> >> > > of us are
>>> >> > > > unavailable for some reason (which normally
>>> shouldn't
>>> >> > be the
>>> >> > > case).
>>> >> > > >
>>> >> > > > Gedare already mentioned it in yesterdays
>>> meeting: We
>>> >> > should
>>> >> > > try to
>>> >> > > > communicate often. Don't hesitate to ask many
>>> questions if
>>> >> > > you get
>>> >> > > > stuck. Don't worry whether a question might be to
>>> >> > "easy". Asking
>>> >> > > > them is
>>> >> > > > the best way to learn the answer. Beneath that it
>>> >> > helps me to
>>> >> > > keep
>>> >> > > > up to
>>> >> > > > date what are you doing and that makes it simpler
>>> to
>>> >> > help you.
>>> >> > > >
>>> >> > > >
>>> >> > > > Most of the time the RTEMS mailing list is quite
>>> >> > informal and
>>> >> > > most
>>> >> > > > of us
>>> >> > > > just use first names to address someone
>>> ("Christian" in my
>>> >> > > case). Is
>>> >> > > > that OK for you too? How do you prefer to be
>>> addressed?
>>> >> > > >
>>> >> > > >
>>> >> > > > We should try to find some common communication
>>> >> > methods. In
>>> >> > > the best
>>> >> > > > case you use public channels like the mailing
>>> list or
>>> >> > the public
>>> >> > > > Discord
>>> >> > > > chat. But I know that it's sometimes a bit
>>> difficult
>>> >> > to use
>>> >> > > these if
>>> >> > > > you
>>> >> > > > are new to open source projects. I still know how
>>> >> > nervous I
>>> >> > > have been
>>> >> > > > when I wrote my first mails to the list. So if you
>>> >> > have some
>>> >> > > topics
>>> >> > > > that
>>> >> > > > you prefere to discuss private, you can always
>>> reach us by
>>> >> > > mail or
>>> >> > > > private chat.
>>> >> > > >
>>> >> > > > I think Pavel isn't on Discord (Pavel: please
>>> correct
>>> >> > me if
>>> >> > > I'm wrong).
>>> >> > > > Discord isn't really known for their privacy
>>> friendly
>>> >> > > attitude so I can
>>> >> > > > completely understand that. So at the moment the
>>> best
>>> >> > method
>>> >> > > to reach
>>> >> > > > all of us is most likely mail.
>>> >> > > >
>>> >> > > > My private mail address that I use for open source
>>> >> > work is the
>>> >> > > > <o...@c-mauderer.de <mailto:o...@c-mauderer.de>
>>> >> > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>
>>> >> > > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>
>>> >> > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>>>. I
>>> check
>>> >> > > these mails
>>> >> > > > at least once a day (most of
>>> >> > > > the time more often). If you have something that
>>> has to be
>>> >> > > answered
>>> >> > > > really fast, you might want to add my company
>>> mail address
>>> >> > > > <christian.maude...@embedded-brains.de
>>> >> > <mailto:christian.maude...@embedded-brains.de>
>>> >> > > <mailto:christian.maude...@embedded-brains.de
>>> >> > <mailto:christian.maude...@embedded-brains.de>>
>>> >> > > > <mailto:christian.maude...@embedded-brains.de
>>> >> > <mailto:christian.maude...@embedded-brains.de>
>>> >> > > <mailto:christian.maude...@embedded-brains.de
>>> >> > <mailto:christian.maude...@embedded-brains.de>>>> to CC. You
>>> will find
>>> >> > > > these two
>>> >> > > > addresses on the mailing list too.
>>> >> > > >
>>> >> > > > Note that I have a mail filter that sorts mails
>>> from
>>> >> > the list
>>> >> > > into
>>> >> > > > folders. If you want to make sure that I read a
>>> mail
>>> >> > on the
>>> >> > > list: Add
>>> >> > > > one of my addresses to CC so that my filter keeps
>>> it
>>> >> > in the
>>> >> > > inbox.
>>> >> > > > That's a good idea for most people on the list:
>>> If you
>>> >> > want
>>> >> > > someone
>>> >> > > > special to answer something: Add him or her to
>>> CC. But
>>> >> > please
>>> >> > > make sure
>>> >> > > > that you only add addresses to CC that are
>>> already used in
>>> >> > > public.
>>> >> > > >
>>> >> > > >
>>> >> > > > Last years it always was a good idea to sort out
>>> time
>>> >> > zones. You
>>> >> > > > mentioned that you are from India so you are most
>>> >> > likely at
>>> >> > > > UTC+5:30? Is
>>> >> > > > that correct? I'm in Germany and therefore my
>>> time is
>>> >> > UTC+2
>>> >> > > during the
>>> >> > > > summer. That means that I sometimes forget at my
>>> evening
>>> >> > > that's already
>>> >> > > > late in the night for you. Please don't hesitate
>>> to
>>> >> > just tell me
>>> >> > > > that we
>>> >> > > > should continue a discussion on the next day if it
>>> >> > starts to
>>> >> > > get too
>>> >> > > > late for you ;-)
>>> >> > > >
>>> >> > > > I'm not entirely sure which time zones Pavel and
>>> >> > Gedare have
>>> >> > > but I'm
>>> >> > > > sure you will find out soon enough when you can
>>> reach
>>> >> > every
>>> >> > > one of them.
>>> >> > > >
>>> >> > > >
>>> >> > > > I think that's enough general information for the
>>> moment.
>>> >> > > Let's start a
>>> >> > > > (short) technical part:
>>> >> > > >
>>> >> > > > I have to be honest: I haven't followed every
>>> mail on
>>> >> > the list
>>> >> > > > regarding
>>> >> > > > your project during the last weeks. So maybe let
>>> me
>>> >> > ask a bit
>>> >> > > about
>>> >> > > > your
>>> >> > > > current hardware setup: Do you already have
>>> everything
>>> >> > set up
>>> >> > > or do you
>>> >> > > > need some help with that? Maybe you can tell me
>>> >> > roughly what
>>> >> > > hardware
>>> >> > > > you use? I would like to try to reproduce the
>>> setup
>>> >> > here so
>>> >> > > that I can
>>> >> > > > test your software or help with debugging where
>>> necessary.
>>> >> > > >
>>> >> > > > Best regards
>>> >> > > >
>>> >> > > > Christian
>>> >> > > >
>>> >> > >
>>> >> >
>>>
>>
From 61e6aac842bd7a11492f2dbbf5d72b7f9b0545d6 Mon Sep 17 00:00:00 2001
From: Prashanth S <fishesprasha...@gmail.com>
Date: Fri, 15 Jul 2022 19:58:44 +0530
Subject: [REVIEW-PATCH CAN support] cpukit/dev/can: Added CAN support
---
cpukit/dev/can/can-queue.c | 76 +++++
cpukit/dev/can/can.c | 446 ++++++++++++++++++++++++++++++
cpukit/include/dev/can/can.h | 79 ++++++
spec/build/cpukit/librtemscpu.yml | 5 +
4 files changed, 606 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 0000000000..debd55bef4
--- /dev/null
+++ b/cpukit/dev/can/can-queue.c
@@ -0,0 +1,76 @@
+#include <rtems/imfs.h>
+#include <rtems/thread.h>
+
+#include <dev/can/can.h>
+
+#include <string.h>
+#include <stdlib.h>
+#include <stdio.h>
+
+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, &bus->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 = &bus->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 = &bus->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 0000000000..1fd1080a48
--- /dev/null
+++ b/cpukit/dev/can/can.c
@@ -0,0 +1,446 @@
+#include <rtems/imfs.h>
+#include <rtems/thread.h>
+
+#include <dev/can/can.h>
+
+#include <string.h>
+#include <stdlib.h>
+
+#include <fcntl.h>
+
+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 void can_bus_obtain(can_bus *bus)
+{
+ rtems_recursive_mutex_lock(&bus->mutex);
+}
+
+static void can_bus_release(can_bus *bus)
+{
+ rtems_recursive_mutex_unlock(&bus->mutex);
+}
+
+static ssize_t can_bus_open(rtems_libio_t *iop, const char *path, int oflag, mode_t mode)
+{
+ return 0;
+/*
+ static int init = 0;
+
+ if (init == 1) {
+ return 0;
+ }
+
+ init = 1;
+
+ can_bus *bus = IMFS_generic_get_context_by_iop(iop);
+
+ if (bus == NULL) {
+ return -RTEMS_NOT_DEFINED;
+ }
+
+ can_create_sem(bus);
+
+ return 0;
+*/
+}
+
+int can_receive(struct can_bus *bus, struct can_msg *msg)
+{
+ int32_t ret = 0;
+
+ uint32_t count = 0;
+
+ if ((ret = rtems_message_queue_broadcast(bus->rx_queue_id, msg, sizeof(struct can_msg) - (CAN_MSG_MAX_SIZE - msg->len), &count)) != RTEMS_SUCCESSFUL) {
+ printf("rtems_message_queue_send failed\n");
+ }
+
+ printf("rtems_message_queue_broadcast = %u\n", count);
+
+ return ret;
+}
+
+/* count argument is not used here as struct can_msg has the dlc member */
+static ssize_t can_bus_read(rtems_libio_t *iop, void *buffer, size_t count)
+{
+ int32_t ret = 0;
+ uint32_t flags = 0;
+
+ can_bus *bus = IMFS_generic_get_context_by_iop(iop);
+
+ if (bus == NULL || bus->can_dev_ops->dev_rx == NULL) {
+ return -RTEMS_NOT_DEFINED;
+ }
+
+ struct can_msg *msg = (struct can_msg *)buffer;
+
+ if ((iop->flags & O_NONBLOCK) != 0) {
+ flags = RTEMS_NO_WAIT;
+ }
+
+ if ((ret = rtems_message_queue_receive(bus->rx_queue_id, (void *)msg, &count, flags, 0)) != RTEMS_SUCCESSFUL) {
+ return ret;
+ }
+
+ return count;
+}
+
+int can_create_sem(struct can_bus *bus)
+{
+ int ret = 0;
+
+#ifndef _POSIX_SEM_
+ //TODO: for test purpose
+ static int init = 0;
+
+ ret = rtems_semaphore_create(rtems_build_name('c', 'a', 'n', '0' + init++), 1,
+ RTEMS_FIFO | RTEMS_SIMPLE_BINARY_SEMAPHORE | RTEMS_LOCAL, 0, &bus->tx_fifo_sem_id);
+
+ if (ret != 0) {
+ printf("rtems_semaphore_create failed %d\n", ret);
+ return ret;
+ }
+
+ ret = rtems_semaphore_obtain(bus->tx_fifo_sem_id, RTEMS_WAIT, RTEMS_NO_TIMEOUT);
+
+ if (ret != 0) {
+ printf("rtems_semaphore_obtain failed %d\n", ret);
+ return ret;
+ }
+#else
+ ret = sem_init(&bus->tx_sem_id, 0, 1);
+
+ if (ret != 0) {
+ printf("sem_init failed %d\n", ret);
+ return ret;
+ }
+#endif /* _POSIX_SEM_ */
+ return ret;
+}
+
+int take_sem(struct can_bus *bus)
+{
+ int ret = 0;
+
+#ifndef _POSIX_SEM_
+ ret = rtems_semaphore_obtain(bus->tx_fifo_sem_id, RTEMS_WAIT, RTEMS_NO_TIMEOUT);
+#else
+ ret = sem_wait(&bus->tx_sem_id);
+#endif /* _POSIX_SEM_ */
+
+ return ret;
+}
+
+int give_sem(struct can_bus *bus)
+{
+ int ret = 0;
+
+#ifndef _POSIX_SEM_
+ ret = rtems_semaphore_release(bus->tx_fifo_sem_id);
+#else
+ ret = sem_post(&bus->tx_sem_id);
+#endif /* _POSIX_SEM_ */
+
+ return ret;
+}
+
+static int can_xmit(struct can_bus *bus)
+{
+ int ret = 0;
+
+ struct can_msg *msg = NULL;
+
+ rtems_interrupt_lock_context lock_context;
+
+ while (1) {
+ rtems_interrupt_lock_acquire(&bus->can_bus_lock, &lock_context);
+
+ ret = bus->can_dev_ops->dev_tx_ready(bus->priv);
+
+ if (ret != true) {
+ goto return_with_lock_release;
+ }
+
+ msg = can_tx_get_data_buf(bus);
+
+ if (msg == NULL) {
+ goto return_with_lock_release;
+ }
+
+ ret = bus->can_dev_ops->dev_tx(bus->priv, msg);
+
+ if (ret != RTEMS_SUCCESSFUL) {
+ printf("dev_send failed\n");
+ }
+
+ rtems_interrupt_lock_release(&bus->can_bus_lock, &lock_context);
+
+ //can_tx_done(bus);
+ }
+
+ return RTEMS_SUCCESSFUL;
+
+return_with_lock_release:
+
+ rtems_interrupt_lock_release(&bus->can_bus_lock, &lock_context);
+ return RTEMS_SUCCESSFUL;
+}
+
+void can_print_canmsg(struct can_msg const *msg)
+{
+ printf("\n----------------------------------------------------------------------------------------------------------------------\n");
+ printf("id = %d len = %d flags = 0x%08X\n", msg->id, msg->len, msg->flags);
+
+ for (int i = 0; i < msg->len; i++) {
+ printf("%02x ", msg->data[i]);
+ }
+
+ printf("\n----------------------------------------------------------------------------------------------------------------------\n");
+}
+
+int can_tx_done(struct can_bus *bus)
+{
+ int ret = 0;
+
+ if (bus->can_dev_ops->dev_tx_ready(bus) == true) {
+ can_xmit(bus);
+ }
+
+ if (bus->can_tx_buf_waiters > 0 && (can_tx_buf_isempty(bus) != 0)) {
+ ret = give_sem(bus);
+ if (ret != 0) {
+ printf(">>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> rtems_semaphore_release failed = %d\n", ret);
+ } else {
+ }
+ }
+
+ return ret;
+}
+
+static ssize_t can_bus_write(rtems_libio_t *iop, const void *buffer, size_t count)
+{
+ can_bus *bus = IMFS_generic_get_context_by_iop(iop);
+
+ if (bus == NULL || bus->can_dev_ops->dev_tx == NULL) {
+ return -RTEMS_NOT_DEFINED;
+ }
+
+ int32_t ret = 0;
+
+ struct can_msg const *msg = buffer;
+ struct can_msg *fifo_buf = NULL;
+
+ rtems_interrupt_lock_context lock_context;
+
+ while (1) {
+ /* sleep is for debug purpose to test concurrency issues */
+ sleep(1);
+
+ rtems_interrupt_lock_acquire(&bus->can_bus_lock, &lock_context);
+
+ fifo_buf = can_tx_get_empty_buf(bus);
+
+ if (fifo_buf != NULL) {
+ uint32_t msg_size = (char *)&msg->data[msg->len] - (char *)msg;
+
+ if (msg_size > sizeof(struct can_msg)) {
+ printf("can message len error msg_size = %u struct can_msg = %u\n", msg_size, sizeof(struct can_msg));
+ return -RTEMS_INVALID_SIZE;
+ }
+
+ memcpy(fifo_buf, msg, msg_size); //sizeof(struct can_msg) - (CAN_MSG_MAX_SIZE - msg->len));
+ ret = msg_size;
+ //can_print_canmsg(msg);
+ }
+
+ rtems_interrupt_lock_release(&bus->can_bus_lock, &lock_context);
+
+ /* sleep is for debug purpose to test concurrency issues */
+ sleep(1);
+
+ if (fifo_buf != NULL) {
+ break;
+ }
+
+ /* Enters if clause, if there are no empty tx fifo buffers. Based on the flags, sleep until buffer
+ * is empty or return error status
+ */
+
+ if (fifo_buf == NULL) {
+ if ((iop->flags & O_NONBLOCK) != 0) {
+ return -RTEMS_RESOURCE_IN_USE;
+ }
+
+ if (bus->can_dev_ops->dev_tx_ready(bus) == true) {
+ can_xmit(bus);
+ }
+
+ rtems_interrupt_lock_acquire(&bus->can_bus_lock, &lock_context);
+ ret = can_tx_buf_isempty(bus);
+ rtems_interrupt_lock_release(&bus->can_bus_lock, &lock_context);
+
+ if (ret == true) {
+ continue;
+ }
+
+ rtems_interrupt_lock_acquire(&bus->can_bus_lock, &lock_context);
+ bus->can_tx_buf_waiters++;
+ rtems_interrupt_lock_release(&bus->can_bus_lock, &lock_context);
+
+ printf("empty_count = %u\n", bus->tx_fifo.empty_count);
+
+ ret = take_sem(bus);
+
+ rtems_interrupt_lock_acquire(&bus->can_bus_lock, &lock_context);
+ bus->can_tx_buf_waiters--;
+ rtems_interrupt_lock_release(&bus->can_bus_lock, &lock_context);
+
+ if (ret != RTEMS_SUCCESSFUL) {
+ printf("cannot take semaphore\n");
+ ret = -RTEMS_INTERNAL_ERROR;
+ goto return_release_lock;
+ }
+ }
+ }
+
+ if (bus->can_dev_ops->dev_tx_ready(bus) == true) {
+ can_xmit(bus);
+ }
+
+return_release_lock:
+
+ return ret;
+}
+
+static ssize_t can_bus_ioctl(rtems_libio_t *iop, ioctl_command_t request, void *buffer)
+{
+ can_bus *bus = IMFS_generic_get_context_by_iop(iop);
+
+ if (bus == NULL || bus->can_dev_ops->dev_ioctl == NULL) {
+ return -RTEMS_NOT_DEFINED;
+ }
+
+ can_bus_obtain(bus);
+
+ bus->can_dev_ops->dev_ioctl(bus->priv, NULL, 0);
+
+ can_bus_release(bus);
+
+ return RTEMS_SUCCESSFUL;
+}
+
+static const rtems_filesystem_file_handlers_r can_bus_handler = {
+ .open_h = can_bus_open,
+ .close_h = rtems_filesystem_default_close,
+ .read_h = can_bus_read,
+ .write_h = can_bus_write,
+ .ioctl_h = can_bus_ioctl,
+ .lseek_h = rtems_filesystem_default_lseek,
+ .fstat_h = IMFS_stat,
+ .ftruncate_h = rtems_filesystem_default_ftruncate,
+ .fsync_h = rtems_filesystem_default_fsync_or_fdatasync,
+ .fdatasync_h = rtems_filesystem_default_fsync_or_fdatasync,
+ .fcntl_h = rtems_filesystem_default_fcntl,
+ .kqfilter_h = rtems_filesystem_default_kqfilter,
+ .mmap_h = rtems_filesystem_default_mmap,
+ .poll_h = rtems_filesystem_default_poll,
+ .readv_h = rtems_filesystem_default_readv,
+ .writev_h = rtems_filesystem_default_writev
+};
+
+static void can_bus_node_destroy(IMFS_jnode_t *node)
+{
+ can_bus *bus;
+
+ bus = IMFS_generic_get_context_by_node(node);
+ (*bus->destroy)(bus);
+
+ IMFS_node_destroy_default(node);
+}
+
+static const IMFS_node_control can_bus_node_control = IMFS_GENERIC_INITIALIZER(&can_bus_handler,
+ IMFS_node_initialize_generic, can_bus_node_destroy);
+
+rtems_status_code can_bus_register(can_bus *bus, const char *bus_path)
+{
+ int ret = RTEMS_SUCCESSFUL;
+
+ ret = IMFS_make_generic_node(bus_path, S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, &can_bus_node_control, bus);
+
+ if (ret != RTEMS_SUCCESSFUL) {
+ printf("Creating node failed: %d\n", ret);
+ goto fail;
+ }
+
+ RTEMS_INTERRUPT_LOCK_INITIALIZER(bus->can_bus_lock);
+
+ if ((ret = can_create_sem(bus)) != RTEMS_SUCCESSFUL) {
+ printf("can_create_sem failed = %d\n", ret);
+ goto fail;
+ }
+
+ if ((ret = can_create_tx_buffers(bus)) != RTEMS_SUCCESSFUL) {
+ printf("can_create_tx_buffers failed = %d\n", ret);
+ goto fail;
+ }
+
+ if ((ret = can_create_rx_buffers(bus)) != RTEMS_SUCCESSFUL) {
+ printf("can_create_rx_buffers failed = %d\n", ret);
+ goto fail;
+ }
+
+ return ret;
+
+fail:
+ (*bus->destroy)(bus);
+ return ret;
+
+}
+
+static void can_bus_destroy(can_bus *bus)
+{
+ rtems_recursive_mutex_destroy(&bus->mutex);
+}
+
+static int can_bus_do_init(can_bus *bus, void (*destroy)(can_bus *bus))
+{
+ rtems_recursive_mutex_init(&bus->mutex, "CAN Bus");
+ bus->destroy = can_bus_destroy;
+
+ return RTEMS_SUCCESSFUL;
+}
+
+static void can_bus_destroy_and_free(can_bus *bus)
+{
+ can_bus_destroy(bus);
+ free(bus);
+}
+
+int can_bus_init(can_bus *bus)
+{
+ memset(bus, 0, sizeof(*bus));
+
+ return can_bus_do_init(bus, can_bus_destroy);
+}
+
+can_bus *can_bus_alloc_and_init(size_t size)
+{
+ can_bus *bus = NULL;
+
+ if (size >= sizeof(*bus)) {
+ bus = calloc(1, size);
+ if (bus != NULL) {
+ int rv;
+
+ rv = can_bus_do_init(bus, can_bus_destroy_and_free);
+ if (rv != 0) {
+ return NULL;
+ }
+ }
+ }
+
+ return bus;
+}
diff --git a/cpukit/include/dev/can/can.h b/cpukit/include/dev/can/can.h
new file mode 100644
index 0000000000..46faabc5aa
--- /dev/null
+++ b/cpukit/include/dev/can/can.h
@@ -0,0 +1,79 @@
+#ifndef _DEV_CAN_CAN_H
+#define _DEV_CAN_CAN_H
+
+#include <rtems/imfs.h>
+#include <rtems/thread.h>
+#include <semaphore.h>
+
+#include <string.h>
+#include <stdlib.h>
+#include <stdio.h>
+
+#define CAN_MSG_MAX_SIZE (8u)
+
+#define CAN_TX_BUF_COUNT (10u)
+#define CAN_RX_BUF_COUNT (10u)
+
+typedef struct can_dev_ops {
+ int32_t (*dev_rx)(void *priv, void *buffer);
+ int32_t (*dev_tx)(void *priv, void *buffer);
+ bool (*dev_tx_ready)(void *priv);
+ void (*dev_tx_int)(void *priv, bool);
+ int32_t (*dev_ioctl)(void *priv, void *buffer, size_t cmd);
+} can_dev_ops;
+
+struct ring_buf {
+ struct can_msg *pbuf;
+ uint32_t head;
+ uint32_t tail;
+ uint32_t empty_count;
+};
+
+typedef struct can_bus {
+ void *priv; // CAN controller specific struct.
+ struct can_dev_ops *can_dev_ops; // CAN controller operations.
+ struct ring_buf tx_fifo; // TX fifo
+#ifndef _POSIX_SEM_
+ rtems_id tx_fifo_sem_id; // TX fifo counting semaphore id
+#else
+ sem_t tx_sem_id;
+ uint32_t tx_fifo_sem_name; // TX fifo sem name
+#endif /* _POSIX_SEM_ */
+ uint32_t can_tx_buf_waiters;
+ rtems_id rx_queue_id;
+ uint32_t rx_queue_name;
+ rtems_recursive_mutex mutex; // For handling driver concurrency.
+ RTEMS_INTERRUPT_LOCK_MEMBER(can_bus_lock);
+ void (*destroy)(struct can_bus *bus); // Clean the CAN controller specific resources.
+} can_bus;
+
+struct can_msg {
+ 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[CAN_MSG_MAX_SIZE]; // For supporting data transfer up to 64 bytes.
+};
+
+extern can_bus *can_bus_alloc_and_init(size_t size);
+extern int can_bus_init(can_bus *bus);
+extern rtems_status_code can_bus_register(can_bus *bus, const char *bus_path);
+extern int can_tx_done(struct can_bus *);
+extern int can_receive(struct can_bus *, struct can_msg *);
+
+extern uint16_t can_len_to_dlc(uint16_t len);
+extern uint16_t can_dlc_to_len(uint16_t dlc);
+
+extern rtems_status_code can_create_tx_buffers(struct can_bus *bus);
+extern rtems_status_code can_create_rx_buffers(struct can_bus *bus);
+extern bool can_tx_buf_isempty(struct can_bus *bus);
+extern struct can_msg *can_tx_get_data_buf(struct can_bus *bus);
+extern struct can_msg *can_tx_get_empty_buf(struct can_bus *bus);
+
+extern int take_sem(struct can_bus *);
+extern int give_sem(struct can_bus *);
+extern int can_create_sem(struct can_bus *bus);
+
+extern void can_print_canmsg(struct can_msg const *);
+
+#endif /* _DEV_CAN_CAN_H */
diff --git a/spec/build/cpukit/librtemscpu.yml b/spec/build/cpukit/librtemscpu.yml
index 31a68cf85a..b700935f82 100644
--- a/spec/build/cpukit/librtemscpu.yml
+++ b/spec/build/cpukit/librtemscpu.yml
@@ -50,6 +50,9 @@ install:
- destination: ${BSP_INCLUDEDIR}/dev/spi
source:
- cpukit/include/dev/spi/spi.h
+- destination: ${BSP_INCLUDEDIR}/dev/can
+ source:
+ - cpukit/include/dev/can/can.h
- destination: ${BSP_INCLUDEDIR}/linux
source:
- cpukit/include/linux/i2c-dev.h
@@ -530,6 +533,8 @@ source:
- cpukit/dev/serial/sc16is752-spi.c
- cpukit/dev/serial/sc16is752.c
- cpukit/dev/spi/spi-bus.c
+- cpukit/dev/can/can.c
+- cpukit/dev/can/can-queue.c
- cpukit/dtc/libfdt/fdt.c
- cpukit/dtc/libfdt/fdt_addresses.c
- cpukit/dtc/libfdt/fdt_empty_tree.c
--
2.25.1
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
