Talk:Raspberry Pi

Tutorial format

Hi,

For the scope of this tutorial, I was wondering if C would be a better language than C++. It's not as if the OO paradigm comes particularly useful while writing a simple tutorial, and C *can* be accepted as a language the whole community is (mostly) expected to know.

As for the actual tutorial, I've been thinking of doing away with the "provide files with comments" ideology. Most of the article just provides the files, and expects the end-reader to understand what's going on. It does give some explanation for a few files, but it's mostly feeble, at the best. It also provides stuff like user-space utilities and Makefiles, which aren't strictly required in the context of the tutorial. Note that this isn't local to this article, but pertains across the entire wiki.

What I suggest & propose is a more "classic" JamesM style tutorial -- one where small blocks of code are followed by simple explanations, without grouping everything together so that the end-user/reader can grasp it rather than simply copy-pasting. Small challenges (such as implementation of memset in asm?) can be provided to the user/reader, rather than being given in black&white. At the end, tarballs of each tutorial "level" can be provided, so that if someone has any problems, s/he can refer to them.

For ARM, there seems to be a lack of comprehensive coverage, as I suppose the community expects whoever is starting with an ARM kernel to be well versed with a simple x86-based kernel? I hope more articles/tutorials pop up for ARM, so that new dev'ers could directly start with the RISC architecture, rather than delve with x86.

Since Mrvn seems to be the only contributor for this Wiki article, if he has no problems, I'd be willing to fix the above-mentioned issues in the article. For the entire wiki, I won't be able to do so -- but if everyone from the community does their small bit, we might be able to bring the standard of all articles a bit.

Regards, --Shikhin 11:49, 18 January 2013 (CST)

NOTE: If the entire-wiki related talk could be moved to a better talk page, I've absolutely no problem with it. Also note that the above are my own humble views. I'm not trying to offend anyone, and if someone has a different view, we can talk it over (the author has clearly seen a lot of flame-talks ;).

I agree with the change of format. There is a lot of code, while simple memset()s can be implemented in C(++) and language independent. As for the language issue, any code snippets I feel should be C++. C++ simplifies code snippets because of the easy categorization by classes (or namespaces). I have written my OS in C++ and it makes code elegant. While there are good reasons to use C in an OS (compatibility), for tutorial snippets C++ won't come amiss, as it makes everything neater. It won't take much for anybody that knows C to understand C++. --Bellezzasolo 14:06, 19 January 2013 (CST)

I've already started to split the main article and moved the Hello World kernel into its own page (and changed it back to pure C). I also want to add a more object oriented C++ flavour of the same to show what you can do. This is mainly about programming style so it should be enough to demonstrate them with the Hello World kernel and UART.

Beyond that I want to step away from a step by step tutorial approach and concentrate on providing independent modules. Modules should be mostly standalone but probably will have some dependencies, e.g. nearly everything will use the UART. Modules would be things like a kprintf(), a framebuffer, activating interrupts, creating and activating page tables, USB/keyboard input, SC card access, ... The idea is that you start with the Hello World tutorial to get of the ground. Then you decide what to do next and look the module for that. You don't have to do framebuffer, you could do paging first.

When I started the page I wanted to just give a few code sniplets and comments and upload a tarball of the full source. But the wiki doesn't allow tarballs. So I uploaded the full files so people can download something that simply works. Maybe the code should live on github? Other ideas?

--Mrvn 19:38, 20 January 2013 (CET)