University project - recommendations?

[Dominik Taborsky]

On Sat, 29 Nov 2014 04:44:53 +0100, Gedare Bloom <gedare at rtems.org> wrote:

> On Fri, Nov 28, 2014 at 4:17 PM, Dominik Taborsky <bremby at seznam.cz>  
> wrote:
>> Hello,
>>
>> I am a university student and am looking for a school project. I am
>> interested in RTEMS and so I thought I could help out with development.
>> The project should take several "school months". It should also involve
>> the kernel space, not user space.
>>
> Welcome!

Thanks! :)

>
> What areas are you most interested in working on? Are you interested
> in something that might continue beyond your project? Do you want to
> be more into core kernel development, hardware abstraction,
> "middleware" (networks, drivers, etc)? Based on the three projects you
> posted, I'm guessing the latter, something that operates between the
> kernel and the hardware.

I am just as much interested in core kernel dev. It actually might be  
easier than to follow some HW specification.

I'm trying to say I can cope with following spec. and probably could  
develop a driver. But is there anything in the core kernel that might need  
upgrading?

Also, is there something (other than support) that makes vxWorks more  
preferable to space industry than RTEMS?

>
> What is your expected hours/wk to spend on this? That will help in
> gauging the level of effort you should undertake.

I'm guessing about 10 hours/week for for about 6 months, but that may vary  
a lot. I still have some school to attend to and other work, though.

>
>> I have browsed through the wiki/trac and I found these 3:
>> 1) CFI-standard flash device interface,
>> 2) CEXP integration,
>> 3) TCP stack rewrite.
>>
> I don't know that CEXP integration is that interesting anymore. One of
> the key features of CEXP is dynamic loading, which is not supported
> through the RTEMS linker and loader projects (RTL). You might ask
> Chris Johns if there are projects available for RTL.

Chris is subscribed to this ML so he can reply now. Or should I address  
him directly?

>
> The TCP stack has mostly been refreshed from BSD by now. I'm not sure
> about its status.

That was actually the least preferred. :)

>
> Improving the support for devices and especially frameworks for
> drivers is a timely project with good potential. See the recent
> commits that added cpukit/dev/i2c. You might try writing some drivers
> for i2c devices to fit the new framework. Sebastian Huber may have
> more info for you. The difficult part in this is testing.

For testing I'd need the actual hardware, wouldn't I?

>
> We had a GSoC student (Andre Marques) look at some I/O device
> frameworks as part of the raspberrypi effort too, so you might look
> for those conversations or contact him directly.
>
>> I don't have any experience with implementing TCP, but I have some
>> experience with data structures on block devices (manipulating MBR and  
>> GPT
>> labels). But I don't know how much of help my experience is.
>>
>> I have hard time guessing time requirements for these, so can anyone  
>> give
>> me a hint how complex these are? Or can you give me any other project
>> assignments?
>>
> Estimating time is hard! Especially without much context for your
> availability or skills. :) In general, I'd suggest scoping out a
> project with many smaller milestones so that you can make good
> progress, even if you don't get to the end, you should have a nice set
> of accomplishments.

I am fluent in C and C++, understand the main data structures and  
asymptotic time complexity, have experience with code optimalization,  
multithreading, recently I implemented basic mutexes for school course,  
have done my bachelor thesis on MBR and GPT manupulation in HelenOS (see  
helenos.org). I'm also playing with Aria G25 from Acme Systems, Arduino  
Pro mini and have my own Raspberry Pi. I likely  forgot something, so feel  
free to ask specifically. Please also note I've never done any work inside  
kernel before - but that doesn't stop me! :)


Again, any more input will be greatly appreciated! Just come at me and  
tell me what you'd like have implemented or reworked and I shall look into  
it! :)


Dominik


>
> Gedare
>
>> Any input is welcome.
>>
>> Best regards,
>> Dominik Taborsky
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel