Entscheidung 0

Bereich für alle Themen zum Projekt Tams OpenSource Decoder.
Antworten
Benutzeravatar

Threadersteller
Andi
ICE-Sprinter
Beiträge: 5177
Registriert: Fr 20. Mai 2005, 23:39
Nenngröße: H0
Stromart: AC
Steuerung: CS 2 / CS 3
Wohnort: Alpenvorland
Deutschland

Entscheidung 0

#1

Beitrag von Andi »

Moin zusammen,

nachfolgend meine Gedanken zum Thema, wie das "Geschäftsmodell" für den Opensoure Decoder aussehen kann. Was ist Open-Source und was nicht?


Lizenmodell Opensoure Decoder:
==============================


Nach wie vor stellt sich mir die Frage, was an diesem Projekt ist Open-Source und welche Rolle spielt der (oder die) Hersteller oder anders gefragt welche Bedeutung spielt die Software und welche die Hardware (Decoder).

Der Begriff "Open-Source" bezieht sich (deshalb steckt auch das Wort Source im Begriff mit drin) auf Software.
Genauso ist die GPL (es war der Vorschlag von Kersten, das Projekt unter GPL zu stellen) eine Lizensierung von freier Software.
Um die Plattform auf der Open-Source-Software laufen soll (in der Regel Windows oder UNIX/LINUX, kann aber auch ne App oder noch was anderes sein)
brauchen sich die Open-Source-Teams nicht zu kümmern, sie ist einfach da und wird ständig aktualisiert und weiterentwickelt.

Bei unserem Projekt ist die Lage etwas anders. Die Plattform auf der die Software laufen soll existiert noch nicht bzw. ist noch nicht definiert.
Ich gehe davon aus, das die Entwicklung der Hardware nicht zum Umfang des Projektes dazugehört (wenn ich mich irre, dann korrigiert mich bitte).
Also werden wir Software für eine existierende Hardware entwickeln. Hier kommt Tams ins Spiel, der sich bereit erklärt hat einen seiner Decoder zum Selbstkostenpreis zur Verfügung zu stellen.
Dieser Decoder von Tams wird (mindestens bis zum ersten fertigen öffentlichen Release), die einzige Plattform sein, auf der die Software ablauffähig ist.

Nochmal zusammengefaßt würde das Lizenz-Modell für den Opensoure Decoder so aussehen:
- Die Software steht unter GPL und darf von jedem (Decoder-)Hersteller für seine Zwecke verwendet werden, wenn er sich and die GPL hält.
- Der Entwicklung der Hardware (Decoder) auf der die Decoder-Software läuft, gehört nicht zum Projekt.



Software-Architektur Opensoure Decoder:
=======================================


Auch wenn (erst mal) am Ende ein Tams-Decoder als Ergebnis des Projektes stehen wird, sollte die Software so geschrieben sein, das sie mit wenig Anpassungen auf einer anderer Hardware lauffähig ist.

Ich habe mir vorgestellt, die Software könnte wie auf dem folgenden Bild strukturiert sein:

Bild


Dazu folgende 2 Fragen an Kersten (weil ich denke er hat die meiste Erfahrung):

1. Ist das Modell realistisch?

2. Falls 1 mit ja beantwortet wird, dann die wichtigste Frage: Wie groß schätzt du den Aufwand für die roten Kästen?

Wenn der Hauptaufwand in die Hardwareanpassungen (rote Kästen) fließen würde, ist es mit mit der Verwendung der Software für eine andere Hardware Essig.



Frage an alle:

- Könnt ihr euch mit einer solchen Aufstellung (SW=Open-Source, HW=kommerziel) des Projektes anfreunden?
Schöne Grüße
Andreas

Bild
Hp2
Ehemaliger Benutzer

Re: Entscheidung 0

#2

Beitrag von Hp2 »

Gut, daß Du nochmals auf die rechtlichen Grundlagen eingehst.
Was jetzt nicht festgelegt wird, endet später im Streit.

Grüße


Hp2
Benutzeravatar

ktams
InterCity (IC)
Beiträge: 914
Registriert: Mo 2. Mai 2005, 14:05
Wohnort: Hannover
Alter: 62
Kontaktdaten:

Re: Entscheidung 0

#3

Beitrag von ktams »

Moin,
Das Modell ist zwar recht einfach, aber duchaus so machbar.
Der rote Teil ist recht einfach, wenn man ähnliche Prozessoren nimmt.
Auf unseren neuen Decodern ist ein Cortex M0 Prozessor drauf (32-Bit). Diese Sorte gibt es mittlerweile von vielen Firmen. Auch ähnliche Prozessoren von z.B. Microchip währen kein Problem. Problematisch wird es dann, wenn man das auch für z.B. 8-Biter machen möchte. Das ist in meinen Augen allerdings nicht mehr Sinnvoll, da die 32-Biter teilweise sogar weniger kosten. Der Nuvoton-Prozessor, der auf dem LD-G-34-PLUS drauf ist, ist z.B. billiger als der 8-Biter von Microchip, der jetzt auf dem LD-G-34 drauf ist.

Zur Hardware: Ich kann mir durchaus vorstellen, das es auchh dort ein Lizenzmodell geben kann (oder gibt), das dem Open SOURCE Modell ähnelt. Notfalls "erfindet" man so ein Modell.
Andererseits kann ich aber auch auf Wunsch Hardware bauen. Was nun gemacht wird, hängt auch von Entscheidung 1 ab.
Gruß Kersten Tams
Benutzeravatar

Threadersteller
Andi
ICE-Sprinter
Beiträge: 5177
Registriert: Fr 20. Mai 2005, 23:39
Nenngröße: H0
Stromart: AC
Steuerung: CS 2 / CS 3
Wohnort: Alpenvorland
Deutschland

Re: Entscheidung 0

#4

Beitrag von Andi »

Moin Kersten,

danke für die schnellen Antworten.
ktams hat geschrieben:..Das Modell ist zwar recht einfach, aber duchaus so machbar.
Der rote Teil ist recht einfach, wenn man ähnliche Prozessoren nimmt.
na klar ist das Modell einfach, es sollte ja auch nur dazu dienen, meine Frage verständlich zu formulieren und nicht als Basis für eine Implementierung dienen. Wenn es denn wirklich losgehen sollte, muß die Archtektur natürlich fundiert festgelegt werden
ktams hat geschrieben:Zur Hardware: Ich kann mir durchaus vorstellen, das es auchh dort ein Lizenzmodell geben kann (oder gibt), das dem Open SOURCE Modell ähnelt. Notfalls "erfindet" man so ein Modell. Andererseits kann ich aber auch auf Wunsch Hardware bauen. Was nun gemacht wird, hängt auch von Entscheidung 1 ab.
Gruß Kersten Tams
ich halte es weder für nötig noch für hilfreich die Hardware zu lizenzieren. Wenn die Software leicht auf verschiedenen "Plattformen" zum laufen gebracht werden kann, ist für mich die Welt in Ordnung. Bedenken, das ein Hersteller (also du) beteiligt ist, teile ich nicht. Im Gegenteil, ich bin mir sicher das das Projekt ohne Herstellerbeteiligung kaum Chanchen auf Erfolg hat. Auch so wird es noch schwer genug.
Schöne Grüße
Andreas

Bild

est2fe
EuroCity (EC)
Beiträge: 1142
Registriert: Do 7. Jun 2007, 17:17
Nenngröße: H0
Stromart: AC
Steuerung: 6021 IB1 MS1 MS2 CS2 CS3
Gleise: C + M

Re: Entscheidung 0

#5

Beitrag von est2fe »

Hallo Andi,

ich nehme mal an dass der rote LD Gxx-Block bisher nur die HW-Ausgänge (Motor-Treiber, Gegen-EMK-Eingang, FX-HW-Ausgänge (mit Überstrom-Erkennung)) anspricht.

Wenn dem so ist, dann fehlt bei deinem Bildchen noch Einiges. Es ist bisher sehr abstrakt gehalten.

Zwischen dem Gleis und den grünen Protokoll-Blöcken hast du Pfeile. Auch da muss so ein orangenes HW-Interface rein oder Pfeile direkt von oben zum HW-Layer. Zudem brauchen wir von den Protokollen (Track-Protokoll-IF) und der HW auch wieder so ein Interface oder Pfeile zur HW für die Rückmeldungen (Strompulse bei MM + DCC, RailCom-Ausgang, mfx-Rückmeldung, Inputs).

Und für die Zukunft (erweiterte HW) müssen auch noch zusätzliche Ein- und Ausgänge (ich werfe da jetzt einfach mal ein paar Begriffe in den Ring) Hall-Inputs vom Motor/Getriebe, SuSi, ZugBus, InduSi- und/oder km-Stein-Input, Kupplungssensorik, Funk-IF, Servo-Ausgänge für Pantos usw. usw. berücksichtigt werden. Die letzten Punkte (Zukunft) deckt aber schon, jetzt mal der Einfachheit halber, die allgemeine Verbindung zwischen HW-IF und den roten Blöcken ab.

Weiterhin fehlt mir noch so eine Art virtuelle Device-Driver-Schicht, welche auch (noch) nicht vorhandene HW-I/Os wegkapseln kann, damit die Grund-SW auf versch. HW-Ausführungen betrieben werden kann.

Jetzt höre ich mal auf, denn verstehen tun das nur noch ganz Wenige. Und, wie schon in meinem anderen Beitrag angesprochen, zuerst müssen wir mal kleine Brötchen backen, um Laufen zu lernen. Nur diese kleineren Brötchen würde ich schon gerne bei weiteren Projekten durch Plug-and-Play weiterverwenden können wollen.

Nun zur HW selber:

Also da hätte _ich_ zumindest schon gerne das Schaltbild der HW irgendwie haben wollen. Sonst kann man da ja keine richtige hardwarenahe SW-Entwicklung betreiben. Wenn man eine SW machen will/muss, wie z. B. eine Motorenansteuerung mit guter Regelung, jetzt mal egal ob Gegen-EMK und/oder Version-1-Sinus-Regelung), muss man notwendiger Weise recht HW-nah programmieren, schon wegen der dazu benötigten Geschwindigkeiten. Und da braucht man schon das Wissen, wie das aufgebaut ist. Ebenso verhält es sich mit der mfx-Rückmeldung, RailCom-Rückmeldung, Inputs für Hall/Getriebe usw. Von Sound spreche ich jetzt mal (noch) nicht. Es ist natürlich schön, wenn Kersten das alles wegkapselt. Aber dann hat man auch nur noch ganz bedingt Einfluss auf bestimmte Funktionalitäten, die man evtl. gerne in Zukunft mit der bestehenden HW haben möchte. Deswegen der Wunsch nach dem Schaltplan.

Gruß

est2fe
Benutzeravatar

ktams
InterCity (IC)
Beiträge: 914
Registriert: Mo 2. Mai 2005, 14:05
Wohnort: Hannover
Alter: 62
Kontaktdaten:

Re: Entscheidung 0

#6

Beitrag von ktams »

moin,
Schaltplan ist kein Problem. Wenn denn fest steht, was denn gemacht werden soll (siehe Entscheidung 1) hätte ich sowieso einen Plan für den passenden Decoder ins Netz gestellt. Das habe ich ja bei früheren Decodern auch schon gemacht. Es ist ja nur zum üben, bis es eine eigen Hardware gibt (es sei denn, wir sind damit zufrieden).
Gruß Kersten Tams
Antworten

Zurück zu „Tams OpenSource Decoder“