[Open-hard-software-event] Lokal für Freitag abends

Rene Leitner rene.leitner at gmx.net
Thu Oct 11 14:05:37 CEST 2012


Vielleicht können wir ein paar Themen bei einen kurzfristigen Stammtisch in München besprechen:

http://doodle.com/6vtesyg2ng6mkrpp


Schönen Gruß
Rene
-------- Original-Nachricht --------
> Datum: Thu, 11 Oct 2012 13:56:42 +0200
> Von: Michele Brocco <ssj2micvm at gmail.com>
> An: "Planung für das Open Hard&Software-Event" <open-hard-software-event at goldelico.com>
> Betreff: Re: [Open-hard-software-event]	Lokal für Freitag abends

> On 10/11/12, Lukas Märdian <luk at slyon.de> wrote:
> > On 10.10.2012 22:58, Christoph Mair wrote:
> >> Ich hab mal einen Vorschlag ins Etherpad geschrieben. Das Problem bei
> >> solchen Code-Sprints ist dass jeder der mitmachen will auch die
> >> entsprechende Hardware benötigt. Und dann stellt sich auch die Frage
> >
> > Man könnte ja erst mal mit den Basics beginnen, also so zu sagen ein
> > "Hello World" Modul bauen, dass jeder auf seinem Laptop laufen lassen
> > kann. Um erst ein mal zu lernen, wo man die Treiber im
> > Kernel-Source-Tree abzulegen hat, wie man es kompiliert und testet, ob
> > es besser ist ein internal oder external kernel module zu bauen (was
> > sind dir vor/nachteile), ...
> >> wie komplex das angestrebte Ergebnis sein soll. Ein "einfacher"
> >> I2C-Treiber oder was komplexes für den McBSP mit DMA-Unterstützung?
> >
> > Ich denke ein einfacher Treiber reicht vollkommen, denn der erste
> > schritt ist bekanntlich der schwierigste. Wenn's dann zu sehr ins Detail
> > geht muss sich schon jeder selbst mit seinem Problem befassen.
> >
> >> Und wo solls losgehen: beim Implementieren, beim Lesen vom Datenblatt
> >> (vermutlich am besten geeignet), beim Erläutern der HW-Schnittstellen
> >> und Funktionsweise (I2C, McBSP, DMA, usw).
> >
> > Ich denke die theoretische Funktionsweise des Bus muss man nicht mehr
> > unbedingt erklären, ich würde eher ein praktischen "learning by doing"
> > bevorzugen.
> >
> > Und wenn am Ende ein Modul da ist das ein bisschen zuckt, passt das
> > schon. Wenn dann noch Zeit ist wären die upstream Konventionen sicher
> > auch interessant, aber nicht notwendig.
> >
> >> Oder gibts ein spezifische Vorschläge was der Codesprint alternativ
> >> beinhalten sollte?
> >
> > Was sind die notwendigen Modul-init und Modul-deinit Funktionen?
> > Was sind Board-Files und wozu sind sie gut?
> > Was ist der Unterschied Vor-/Nachteil zum Device-Tree?
> >
> >
> Fände ich auch sehr gut! Auf der anderen Seite muss ich sagen, dass
> meines Erachtens das schwierigste ist, die wichtigsten Informationen
> aus dem Datenblatt herauszufiltern und ins Modul reinzubauen, während
> für die Thematik "wie schreibe ich ein Modul" genügend Tutorials
> online sind. Aber ob man da pauschal was sagen
> kann...hmmm...schwierig. Da können vielleicht die Kernel-Experten
> unter uns was dazu sagen ob sowas überhaupt möglich ist. Vermutlich
> eher nicht?
> _______________________________________________
> http://www.ohsw.de/
> Open-hard-software-event mailing list
> Open-hard-software-event at goldelico.com
> http://lists.goldelico.com/mailman/listinfo/open-hard-software-event


More information about the Open-hard-software-event mailing list