On Sun, Apr 2, 2017 at 9:09 AM, Gedare Bloom <ged...@rtems.org> wrote: > On Sun, Apr 2, 2017 at 5:17 AM, Christian Mauderer > <christian.maude...@embedded-brains.de> wrote: >> >> >> ----- Ursprüngliche Mail ----- >>> Von: "faizan khan" <faizan10...@gmail.com> >>> An: devel@rtems.org >>> Gesendet: Sonntag, 2. April 2017 00:44:27 >>> Betreff: GSOC application >> >>> Hi everyone, >>> >>> I know I am late to the party but just got my confirmation letter. I have 2 >>> years of experience porting device drivers for Nucleus RTOS. I wanted to >>> know about the list of projects. >>> >>> https://devel.rtems.org/query?status=!closed&desc=1&keywords=~SoC&report=10 >>> >>> Is this all of it. I can easily take care of #2891, bbb, I have already >>> ported bbb bsp for nucleus. Just to understand the project. All I have to >>> do is port the device drivers mentioned and fix any hardware bugs in the >>> test coverage, right??? >>> >>> >>> cheers, >>> Faizan >>> >>> _______________________________________________ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >> >> Hello Faizan, >> >> I think that there are quite some more projects that are not converted to >> TRACK. See https://devel.rtems.org/wiki/Developer/OpenProjects >> If you are interested in one of the projects, just contact the possible >> mentors or ask on the mailing list. >> > There are definitely other good projects to consider that haven't had > as much attention as the BB projects. Also note that you should > complete https://devel.rtems.org/wiki/GSoC/GettingStarted and begin to > prepare your proposal immediately. Your best bet is to find a project > matching your interest/skills that has a suitable amount of > information posted about it, since you are not likely to get a lot of > feedback on your proposal before the deadline. > P.S. if you propose a BB project, you should also complete the GettingStarted using whichever BB board you have.
> For the BB projects, I suspect the Framebuffer or CAN would be good > directions to push. Framebuffer support exists in a few scattered > BSPs, but we could use a consistent approach and more uniform API for > framebuffer devices. For CAN there was a project a couple years ago > that made some progress in simulating CAN with Qemu, but never got to > the point of getting a CAN package to integrate easily with RTEMS. > There was a follow-up proposal by the same student for the project, > but we did not accept it [1]. > > [1] > https://docs.google.com/document/d/12T2Sd9vDBGfMhlansaW0Ti2OmtrpRPgAXxdPuOHbM78/edit?usp=sharing > >> Please also note that there are already some other students interested in >> some of the projects (especially the ones that are already converted to TRAC >> tickets): https://devel.rtems.org/wiki/GSoC/2017 >> >> Kind regards >> >> Christian >> >> -- >> -------------------------------------------- >> embedded brains GmbH >> Christian Mauderer >> Dornierstr. 4 >> D-82178 Puchheim >> Germany >> email: christian.maude...@embedded-brains.de >> Phone: +49-89-18 94 741 - 18 >> Fax: +49-89-18 94 741 - 08 >> PGP: Public key available on request. >> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >> _______________________________________________ >> 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
