<offlist> GSoC 2022:
Prashanth S
fishesprashanth at gmail.com
Fri Jul 15 14:54:16 UTC 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-devel at rtems.org
<devel at rtems.org>?
Regards
Prashanth S
On Mon, 11 Jul 2022 at 10:03, Prashanth S <fishesprashanth at 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, <fishesprashanth at 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 <wg at 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 <gedare at rtems.org> wrote:
>>
>>> On Sun, May 29, 2022 at 6:09 AM Prashanth S <fishesprashanth at 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 <oss at 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 <oss at c-mauderer.de
>>> >> > <mailto:oss at 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.
>>> >> >
>>> >> > >
>>> >> > > @pisa at cmp.felk.cvut.cz <mailto:pisa at cmp.felk.cvut.cz>
>>> >> > <mailto:pisa at cmp.felk.cvut.cz <mailto:pisa at cmp.felk.cvut.cz>> ,
>>> >> > @Christian
>>> >> > > Mauderer <mailto:oss at c-mauderer.de <mailto:oss at c-mauderer.de>>
>>> ,
>>> >> > @Gedare Bloom
>>> >> > > <mailto:gedare at rtems.org <mailto:gedare at 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
>>> >> > <oss at c-mauderer.de <mailto:oss at c-mauderer.de>
>>> >> > > <mailto:oss at c-mauderer.de <mailto:oss at 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.
>>> >> > > >
>>> >> > > > @oss at c-mauderer.de <mailto:oss at c-mauderer.de>
>>> >> > <mailto:oss at c-mauderer.de <mailto:oss at c-mauderer.de>>
>>> >> > > <mailto:oss at c-mauderer.de <mailto:oss at c-mauderer.de>
>>> >> > <mailto:oss at c-mauderer.de <mailto:oss at c-mauderer.de>>> ,
>>> @Pavel Pisa
>>> >> > > > <mailto:ppisa4lists at pikron.com
>>> >> > <mailto:ppisa4lists at pikron.com> <mailto:ppisa4lists at pikron.com
>>> >> > <mailto:ppisa4lists at pikron.com>>> ,
>>> >> > > @Gedare Bloom <mailto:gedare at rtems.org
>>> >> > <mailto:gedare at rtems.org> <mailto:gedare at rtems.org
>>> >> > <mailto:gedare at 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
>>> >> > > <oss at c-mauderer.de <mailto:oss at c-mauderer.de>
>>> >> > <mailto:oss at c-mauderer.de <mailto:oss at c-mauderer.de>>
>>> >> > > > <mailto:oss at c-mauderer.de <mailto:oss at c-mauderer.de>
>>> >> > <mailto:oss at c-mauderer.de <mailto:oss at 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
>>> >> > > > <oss at c-mauderer.de <mailto:oss at c-mauderer.de>
>>> >> > <mailto:oss at c-mauderer.de <mailto:oss at c-mauderer.de>>
>>> >> > > <mailto:oss at c-mauderer.de <mailto:oss at c-mauderer.de>
>>> >> > <mailto:oss at c-mauderer.de <mailto:oss at 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.mauderer at embedded-brains.de
>>> >> > <mailto:christian.mauderer at embedded-brains.de>
>>> >> > > <mailto:christian.mauderer at embedded-brains.de
>>> >> > <mailto:christian.mauderer at embedded-brains.de>>
>>> >> > > > <mailto:christian.mauderer at embedded-brains.de
>>> >> > <mailto:christian.mauderer at embedded-brains.de>
>>> >> > > <mailto:christian.mauderer at embedded-brains.de
>>> >> > <mailto:christian.mauderer at 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
>>> >> > > >
>>> >> > >
>>> >> >
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20220715/cc03c8df/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cpukit-dev-can-Added-CAN-support.patch
Type: text/x-patch
Size: 17251 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20220715/cc03c8df/attachment-0001.bin>
More information about the devel
mailing list