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 <johnkongtc...@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 <ged...@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 <johnkongtc...@gmail.com> wrote: > >> > ---------- Forwarded message --------- > >> > From: John kongtcheu <johnkongtc...@gmail.com> > >> > Date: Sun, Feb 23, 2020 at 7:19 PM > >> > Subject: Fwd: [PATCH] Hello World > >> > To: > >> > Cc: <devel@rtems.org> > >> > > >> > > >> > > >> > ---------- Forwarded message --------- > >> > From: John kongtcheu <johnkongtc...@gmail.com> > >> > Date: Sun, Feb 23, 2020, 6:53 PM > >> > Subject: Re: [PATCH] Hello World > >> > To: Gedare Bloom <ged...@rtems.org>, <j...@rtems.org>, > >> > <chr...@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 <ged...@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 j...@rtems.org and > >> >> chr...@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 <johnkongtc...@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@rtems.org > >> >> > http://lists.rtems.org/mailman/listinfo/devel > >> > > >> > _______________________________________________ > >> > 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel