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

Rene Leitner rene.leitner at gmx.net
Thu Oct 18 09:43:43 CEST 2012


Hi,

okay dann würde ich sagen ist es der 23.10., habt ihr Ideen wo wir hin gehen können?

Als Zeit würde ich 18Uhr vorschlagen, ist das okay für euch.

Schönen Gruß
Rene
-------- Original-Nachricht --------
> Datum: Thu, 11 Oct 2012 14:05:37 +0200
> Von: "Rene Leitner" <rene.leitner at gmx.net>
> 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

> 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
> _______________________________________________
> 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