RTEMS CAN support Was: Hello World on BeagleBone

Thu Mar 12 07:31:59 UTC 2020

Hello Gedare and John,

I have long term interrest in (not only) RTEMS CAN
support. So I would help as time and energy allows
me. I want and must spent some holiday time out
of computers and school load. I would apply for
(co-)menthor. Send me invitation, please.

As for RTEMS CAN support, as I know there is no
single CAN driver model available over all BSPs
with CAN support implemented as I know. I need
to go through sources again to analyze actual state.
There is

  bsps/shared/grlib/can
  bsps/powerpc/gen5200/mscan
  bsps/arm/lpc176x/can
  bsps/arm/atsam/contrib/libraries/libchip/source/mcan.c

On RTEMS, I have experience only with gen5200 mscan
many years ago. The API was minimal but provided
required functionality.

I have offered cooperation on our LinCAN API porting
to RTEMS. The driver for Linux
  http://ortcan.sourceforge.net/lincan/
See 1.4. LinCAN Driver Architecture section from the manual
  http://cmp.felk.cvut.cz/~pisa/can/doc/lincandoc-0.3.5.pdf
The complete concept of our CAN/CANopen components support there
  http://cmp.felk.cvut.cz/~pisa/can/doc/ocera-canopen-ug.pdf
But the head of former Real-Time Systems group at our department
has no interrest to continue on work to make it really
usesfull when the EU funded project has finished.
So I have tried to keep it at least at the level usable
as demonstrator of technology and tool for our other
CAN related projects. On Linux side, Oliver Hartkopp and Pengutronix
SocketCAN is the mainline choice. It has more advanced
and easy to use API, CAN FD support etc. So I have helped
to reuse some LinCAN code for this project. As for RT side,
I have still some doubts if the choice is optimal ...
But we use SocketCAN on Linux as main target now for
almost all CAN related faculty activities
  http://canbus.pages.fel.cvut.cz/
and our CAopen support can use SocketCAN as the driver API
as well
  https://sourceforge.net/p/ortcan/ortcan-vca/ci/master/tree/libvca/vca_isocketcan.c
I have demonstrated that the project has some value still in 2017,
when I have setup DS-402 motion control CANopen profile device
from Zynq based MZ_APO board and other PiKRON designed hardware
and PiKRON provided PXMC motion control library
  https://www.linuxdays.cz/2017/video/Pavel_Pisa-CAN_canopen.pdf
The connection and use of RTEMS sponsored QEMU CAN support
was part of the presentation.
  http://cmp.felk.cvut.cz/~pisa/can/doc/rtlws-17-pisa-qemu-can.pdf
  https://github.com/qemu/qemu/blob/master/docs/can.txt
I have bachelor student working on our open source CTU CAN FD IP
core QEMU model now.
I have demonstrated, that I am alive still on LinuxDays 2019
when I have ported most of OrtCAN compnents to work on NuttX
  https://sourceforge.net/p/ortcan/ortcan-vca/ci/master/tree/libvca/vca_inuttx.c

So back to RTEMS, It would be great if there is some consensus
what is the CAN driver API preferred choice.
The grlib defines basic CANMsg type but even it is non consistent
because it defines it twice. It uses char for each flag instead
of bit and when CAN FD support is added then it would require
to make structure incompatible. SocketCAN API is BSD sockets
based and I think to complex. NuttX CAN API is functional
but too much configurable to squeeze it to less bytes for small
devices
  https://bitbucket.org/nuttx/nuttx/src/master/include/nuttx/can/can.h
But it is reasonable character device CAN API. NuttX is Apache
licensed now so even direct use for RTEMS could be OK including drivers.
LinCAN API can be extended to support CAN FD and provide even
internal FIFOs etc. LinCAN is GPL2 licensed with linking exception,
I have though about its RTEMS use from beginning. I have chance
to relicence it, it is partially based on older Linux CAN projects
to keep API partial compatibility but all is rewitted by me at least
onece. I expect no problem to negotiate change with our department
head now to cover even reference to it. But I am not sure if it is
the best option.

As for BeagleBone, it uses D_CAN based on BOSCH C_CAN.
Linux driver
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/c_can/c_can.c
NuttX driver
  https://bitbucket.org/nuttx/nuttx/src/master/arch/arm/src/am335x/am335x_can.c
We have worked on CCAN support for OKI ML9620 chip support
under BOSCH funding long time ago, so initial version of working
LinCAN support for CCAN (DCAN) exists there
  https://sourceforge.net/p/ortcan/lincan/ci/master/tree/lincan/src/c_can.c
I have lot of experience with DCAN on TMS570 on the rapid prototyping
platform done on EATON contract at former DCE RT group.
I have lead, guide and invested in diploma theses student to implemented
nice time triggered CAN support but due doctor Michal Sojka and professor
Zdenek Hanzalek order, only disfigured version could be published
as part of final theses text same as the whole work on Matlab/Simulink
target done mainly in a frame of diploma theses of foreign and local students
(often with my personal investment into guiding and code) has been closed
and without any response lostchance to gent into new life when
University of Trento has interrest to reuse it and continue on the work
and porting to TMS570LC4357 (be carefull who controls copyrights
of the project you are working on when you invest even personal time etc.
...).

https://dspace.cvut.cz/bitstream/handle/10467/70108/F3-DP-2017-Hofman-Martin-Implementace_casem_rizeneho_planovace_v_distribuovanem_bezpecnostne_kritickem_ridicim_systemu.pdf?sequence=1&isAllowed=y

Generally, I do not consider DCAN IP core indexed message objects API as
the ideal CAN IP core design, it has some reasons behind when used
for 8-bit CPUs. But CCAN/DCAN appears on many chips so its support
for RTEMS has a quite high value. I have access to BeaglBone,
we have designed some hardware with it at PiKRON for https://www.elektroline.cz/
and I can borrow some board. I have TMS570LS3137 kit with DCAN
and RTEMS BSP at home and some even that TMS570LC4357 HDK which
I would like to see with full RTEMS mainline support one day...
when there is no higher priority tsak to do. We have quite lot work
on switching education to distant one at university for example now.

If you decide where to put the text, I format it for Wiki.
Critical is decision about API. Then it is quite some load
of work but generally straightforward and with promissing results.

Best wishes,

Pavel Pisa

On Tuesday 10 of March 2020 23:12:23 Gedare Bloom wrote:
> I would be willing to mentor a CAN project. Perhaps another will come
> along. If your proposal truly shines, a mentor may be found.
>
> On Tue, Mar 10, 2020 at 3:18 PM John kongtcheu <johnkongtcheu at gmail.com> 
wrote:
> > Thank you for the information. I've been doing some research into the CAN
> > support and I think that it would definitely be a project that I would be
> > interested in. I am just a little curious though if there would be any
> > available mentors for this project, and if so would I have the green
> > light to start working on the first draft of the project? Thanks again
> >
> > On Mon, Mar 9, 2020 at 11:37 AM Gedare Bloom <gedare at rtems.org> wrote:
> >> Hi John,
> >>
> >> Thanks. Regarding BeagleBone Black (BBB) you should demonstrate that
> >> you can run RTEMS on the BBB during your proposal prep phase. You will
> >> need to dig to find out what remains to be done in this space. That
> >> said, there is a student with a proposal to advance Flattened Device
> >> Tree support so you would want to avoid that area. It's not clear to
> >> me what else remains to be done that is sufficiently interesting. I'd
> >> like to see if we can support the BBB with RTEMS "legacy" network
> >> stack and lwIP, then it could be a handy board for us as a project to
> >> use to test the networking infrastructure. This is related to
> >> https://devel.rtems.org/ticket/3850
> >>
> >> BBB is also a candidate for Controller Area Network (CAN) support (pun
> >> intended). Although we don't have active open project descriptions,
> >> that could be an area for expanding peripheral and library support. It
> >> does require some additional hardware to actually do any testing
> >> though. One can start with Qemu-emulated CAN support, which was added
> >> by a previous RTEMS GSoC student project.
> >>
> >> Gedare
> >>
> >> On Sun, Mar 8, 2020 at 11:30 AM John kongtcheu <johnkongtcheu at gmail.com> 
wrote:
> >> > ---------- Forwarded message ---------
> >> > From: John kongtcheu <johnkongtcheu at gmail.com>
> >> > Date: Sun, Feb 23, 2020 at 7:19 PM
> >> > Subject: Fwd: [PATCH] Hello World
> >> > To:
> >> > Cc: <devel at rtems.org>
> >> >
> >> >
> >> >
> >> > ---------- Forwarded message ---------
> >> > From: John kongtcheu <johnkongtcheu at gmail.com>
> >> > Date: Sun, Feb 23, 2020, 6:53 PM
> >> > Subject: Re: [PATCH] Hello World
> >> > To: Gedare Bloom <gedare at rtems.org>, <joel at rtems.org>,
> >> > <chrisj at rtems.org>
> >> >
> >> >
> >> > Hello Gedare
> >> > I'm currently interested in the beagleboard black bsp project as of
> >> > now. I'm interested in working with the peripherals regarding it.
> >> > Thank you,
> >> >
> >> > On Sun, Feb 23, 2020 at 6:31 PM Gedare Bloom <gedare at rtems.org> wrote:
> >> >> Hi John,
> >> >>
> >> >> Thank you. If you're planning to apply for GSoC as a student, please
> >> >> also send me by email your screenshot, CC to joel at rtems.org and
> >> >> chrisj at rtems.org
> >> >>
> >> >> Begin to look through the Open Projects for what kinds of projects
> >> >> might interest you, and ask questions here about whether/which
> >> >> projects might be good for you to work on an application.
> >> >>
> >> >> Gedare
> >> >>
> >> >> On Sun, Feb 23, 2020 at 4:20 PM John Kongtcheu 
<johnkongtcheu at gmail.com> wrote:
> >> >> > ---
> >> >> >  testsuites/samples/hello/init.c | 2 +-
> >> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >> >
> >> >> > diff --git a/testsuites/samples/hello/init.c
> >> >> > b/testsuites/samples/hello/init.c index 34ded37c55..13aa377d95
> >> >> > 100644
> >> >> > --- a/testsuites/samples/hello/init.c
> >> >> > +++ b/testsuites/samples/hello/init.c
> >> >> > @@ -22,7 +22,7 @@ static rtems_task Init(
> >> >> >  {
> >> >> >    rtems_print_printer_fprintf_putc(&rtems_test_printer);
> >> >> >    TEST_BEGIN();
> >> >> > -  printf( "Hello World\n" );
> >> >> > +  printf( "This is John Kongtcheu's Hello World \n Welcome to
> >> >> > RTEMS and Google Summer of Code 2020" ); TEST_END();
> >> >> >    rtems_test_exit( 0 );
> >> >> >  }
> >> >> > --
> >> >> > 2.17.1
> >> >> >
> >> >> > _______________________________________________
> >> >> > devel mailing list
> >> >> > devel at rtems.org
> >> >> > http://lists.rtems.org/mailman/listinfo/devel
> >> >
> >> > _______________________________________________
> >> > devel mailing list
> >> > devel at rtems.org
> >> > http://lists.rtems.org/mailman/listinfo/devel
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel