GSOC application

[Gedare Bloom]

On Sun, Apr 2, 2017 at 9:09 AM, Gedare Bloom <gedare at rtems.org> wrote:
> On Sun, Apr 2, 2017 at 5:17 AM, Christian Mauderer
> <christian.mauderer at embedded-brains.de> wrote:
>>
>>
>> ----- Ursprüngliche Mail -----
>>> Von: "faizan khan" <faizan10114 at gmail.com>
>>> An: devel at 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 at 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.mauderer at 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 at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel