Kanalisieren - bitte!

Bereich für alle Themen zum Projekt Tams OpenSource Decoder.
Antworten
GeP
Ehemaliger Benutzer

Kanalisieren - bitte!

#1

Beitrag von GeP »

Hallo Mitmacher und Interessierte,

Bei nun deutlich über 100 Beiträgen wird es sicher Zeit die Zusammenarbeit mal etwas zu organisieren.
Ein Vorteil von OpenSource ist dass man eine genaue Planung machen kann und nicht mit vielen Features und neuen (meist nur werbewirksamen) Gimmicks überraschen muss. Zeitdruck gibt es auch nicht.
Ein Projekt kann fundiert aufgebaut werden.


Dazu mein Vorschlag:
Wir bilden drei Gruppen mit folgenden Tätigkeiten.
1) Sammeln von Anregungen zum Leistungsumfang.
2) Organisation der Programmierung.
3) Test, Fehlerbeseitigung und Dokumentation.

Jede dieser Gruppe kann zunächst aus einer Person bestehen. Später kann der Federführende weitere Leute in seine Gruppe holen und Arbeiten delegieren. Das ist sogar wünschenswert.
Das Forum bestimmt diese Personen die geeignet scheinen und die natürlich Spaß an der Aufgabe haben.
Das kann ziemlich schnell gehen ;-)


Im Einzelnem zu

1) Featureliste
Wer Vorschläge oder Wünsche hat gibt diese an den Verantwortlichen.
Dieser sammelt alles und stellt eine Liste zusammen.
Die Liste ist damit automatisch bereinigt und enthält keine mehrfachen Nennungen oder nur leicht unterschiedliche Wünsche.

Die Liste wird turnusmäßig veröffentlicht (bzw. bei Bedenken zunächst im geschlossenen Forum verbreitet).
Die einzelnen Punkte bekommen eine Bewertung, es wird eine Priorität zugeordnet. Diese bestimmt was in welcher Reihenfolge in die FW (=Firmware) übernommen werden soll und was damit an die Programmierung gegeben wird.

Im Laufe der Entwicklung werden sich zu den Vorschlägen auch Fehlermeldungen gesellen.
Diese werden mit einer hohen Priorität versehen.


2) Programmierung
Dies ist sicher der schwierigste Teil.
Hier müssen Vorgaben insbesondere zur Struktur und zu den Software-Schnittstellen der Module untereinander gemacht werden.

Im Einzelnen wird dann der Programmierauftrag an interessierte Mitarbeiter vergeben.

Ein weiterer Punkt für diese Gruppe ist eine Art Organisation und "Timeline" einzuhalten.
So ist es nicht sinnvoll Lösung "B" zu implementieren wenn diese auf Lösung "A" aufsetzt und "A" noch nicht mal begonnen wurde.

Fertiger Code wird zu einem Pre-Release zusammengefasst und dieses an Gruppe 3) übergeben.
Die Testergebnisse fliessen von dort zurück an Gruppe 2)
Dieser Zyklus ("Turn-Around") wiederholt sich so lange bis die FW fehlerfrei zu sein scheint.

Ist dieser Stand erreicht wird ein endgültiges Release an die Community freigegeben.
Meldungen über doch noch vorhandene Fehler und "Ungenauigkeiten" fliessen an Gruppe 1).
Fehlerbehebungen finden dann erst im nächten Release statt!! Für ganz Eilige kann ein Pre-Release erstellt werden.


3) Test
Die Gruppe 3) erhält von 2) ein weitgehend fertiges Pre-Release.
Diese wird in die Decoder geflasht und es werden die einzelnen Features getrennt wie auch im Zusammenspiel getestet.
Dabei sollten die Tester ihrer Fantasie freien Lauf lassen und alles Mögliche und auch anscheinend Unmögliche testen.
Gefundene Fehler werden exakt im Umfeld beschrieben. Die Beschreibung muss ausreichen um einen Fehler reproduzieren zu können. Die Mitglieder von 3) tauschen sich aus und versuchen gegenseitig die gefundenen Fehler zu reproduzieren.

Gleichzeitig stellt diese Gruppe eine Dokumentation über den Stand der FW zusammen.
Dort werden die einzelnen Features und deren Zusammenwirken beschrieben.
Dieses darf auf keinen Fall den Programmierern überlassen werden !!! (Die wissen schon warum ;-) )

Auch Fehler werden in einer Bugliste vermerkt - ggf. mit Umgehungsmöglichkeiten ("Work-Around").


Wie fangen wir an?

Aufgabe von Gruppe 3) wäre es die notwendige Hardware und die Dokumentation über diese zu besorgen.
Wenn ich Kersten Tams richtig verstanden habe ("Hardware: Ich stelle die Hardware zur Verfügung.") wäre es der erste Schritt diese Hardware zu besorgen.

Da die FW unabhängig von der Hardware sein sollte wäre hier für Gruppe 2) zunächst über die Struktur der Software nachzudenken.
Ohne jetzt das "Open Systems Interconnection Reference Model" (kürzer "ISO-7-Schicht-Modell") abbilden zu wollen - einige Anleihen sollten wir machen.

Zunächst haben wir eine Hardware-Schicht die für die Kommunikation da ist. Dort wird beschrieben wie Daten zu kodieren und physikalisch umzusetzen sind um fehlerfreie Kommunikation zu erreichen.
Dazu gehören z.B. die "Booster" und in den Loks die Elektronik die die Signale vom Fahrstrom trennt.
Es könnten auch Funkmodule oder irgend welche anderen Übertragungsmechanismen sein.
Ein Teil der FW setzt nun die Informationen in verwertbare Daten um oder in ein für die physikalische Übertragung gedachtes Format wenn Informationen gesendet werden sollen.

Dort setzt die inhaltliche Interpretation der Signale auf. Das sind die "Protokolle" wie z.B. DCC.
Diese Schicht muss die konkreten Befehle und das "Drumherum" eines Protokolls verallgemeinern und diese in einer Art internen Befehlssatz wandeln.

Auf diesen internen Befehlssatz hört schließlich die eigentliche programmtechnische Umsetzung der einzelnen Funktionen (Features). Auch werden Ergebnisse wieder in diesem Befehlssatz formuliert.

Darauf setzt jetzt eine Hardware-Abstraktions-Schicht auf die diese Befehle in die Ansteuerung der physikalisch vorhandenen HW umsetzt (das sind sozusagen die "Treiber").


Ich hoffe sehr hier vielleicht einige Anregungen gegeben zu haben ein solches Projekt auch erfolgreich umzusetzen. Das hört sich zwar alles sehr kompliziert an, ist es aber gar nicht.

An die Software-Fachmänner unter Euch:
Um die Übersicht zu erhalten und um der Einfachheit halber habe ich nicht alles schulbuchmäßig beschrieben.
Ich bitte mir die ein oder andere Ungenauigkeit nachzusehen, es ging mir darum für jedermann verständlich zu bleiben.

Viele Grüße
Gerd
at90s
Ehemaliger Benutzer

Re: Kanalisieren - bitte!

#2

Beitrag von at90s »

Von mir auch ein Hallo an alle in der Runde hier.

Ich bin derjenige, welcher mit Christoph von "Fichtelbahn", schon DCC Decoder zum Eigenbau entwickelt hat (zu finden unter http://www.fichtelbahn.de/ oder http://www.toralfwilhelm.de/mde/mde.htm). Unsere Decoder sind so aufgebaut, das der komplette Selbstbau mit wenigen Bauteilen möglich ist. Das schränkt aber stark die technischen Möglichkeiten ein und wir haben vor nicht all zu langer Zeit auch schon darüber nachgedacht, eine moderne Version als OpenSource neu zu entwickeln und nur die Hardware fertigen zu lassen. Jetzt zu Gerd seinem Post: ich denke "Kanalisieren" ist schon gut, aber anfangen sollte man doch schon beim Funktionsumfang. Kersten hat übrigens nur den ARM vorgegeben, alles andere ist auch da noch offen.
Ich denke man sollte einen neuen Post öffnen und dort mal Funktionswünsche sammeln. Des weiteren sollte man das Budget abfragen. Wie teuer darf der Decoder denn überhaupt werden. Hier könnte man dann auch gleich noch konkrete Mitarbeiter sammeln. Ich denke gute Programmierer und Hardware Spezies die auch aktiv mitarbeiten wollen und können, wachsen nicht wie Sand am Meer.

Gruß Willi,
der bei Hard- und Software mitmachen würde.
Christoph ist sicher für Doku und Service zu haben.
rainerwahnsinn
Ehemaliger Benutzer

Re: Kanalisieren - bitte!

#3

Beitrag von rainerwahnsinn »

at90s hat geschrieben:Von mir auch ein Hallo an alle in der Runde hier.

...Ich denke man sollte einen neuen Post öffnen und dort mal Funktionswünsche sammeln. Des weiteren sollte man das Budget abfragen. Wie teuer darf der Decoder denn überhaupt werden....
Hallo Willi,

ist schon sehr beeindruckend was die 2 Links so bereithalten! Man fragt sich gleich, ob das selbe Rad hier wirklich nochmal neu gebaut werden muss... Eher aus technischen Erwägungen heraus?
Nach diesen Erfahrungen bin ich jedenfalls sehr auf auf deine und Christophs Empfehlungen gespannt! :charles:

Bzgl. Funktionswünsche stehe ich momentan noch etwas aufm Schlauch. Könnten die Funktionen letzendlich viel anders ausfallen, als wie beim DCCtrain Dekoder, oder den G / W-Dekodern von Tams, oder weiterer Hersteller ?

Hmh, die Mehrheit "will" wahrscheinlich nur einen Dekoder, weil der Digitalbetrieb einfach einen voraussetzt. Und hat sich dann damit abzufinden, das neben dem Lichtumbau auch noch ein Motorumbau hinzukommt.
Um dafür aber auch teure Lokdekoder einbauen zu können. Und noch mehr Geld, wenn er Zusatzfunktionen will (Funktionsdekoder).

Vielleicht macht es Sinn mal zu konkretisieren, welche Zielgruppe man womit genau beglücken möchte? :popcorn:

Viele Grüße
Rainer...W
at90s
Ehemaliger Benutzer

Re: Kanalisieren - bitte!

#4

Beitrag von at90s »

rainerwahnsinn hat geschrieben: ist schon sehr beeindruckend was die 2 Links so bereithalten!
Danke!
rainerwahnsinn hat geschrieben: Man fragt sich gleich, ob das selbe Rad hier wirklich nochmal neu gebaut werden muss... Eher aus technischen Erwägungen heraus?
Ja, unsere Decoder sind technisch eher 0815 Decoder. Bis jetzt lag aber auch der Fokus auf Nachbaubarkeit mit Home - Möglichkeiten, was die Funktionen langsam an die Grenze der Hardware treibt. Bei einer moderneren Neuentwicklung ist da sicherlich ein Profidecoder möglich, wenn noch ein paar fähige Köpfe bei der Soft- und Hardwareentwicklung mitmachen.
rainerwahnsinn hat geschrieben: Nach diesen Erfahrungen bin ich jedenfalls sehr auf auf deine und Christophs Empfehlungen gespannt! :charles:
Bzgl. Funktionswünsche stehe ich momentan noch etwas aufm Schlauch. Könnten die Funktionen letzendlich viel anders ausfallen, als wie beim DCCtrain Dekoder, oder den G / W-Dekodern von Tams, oder weiterer Hersteller ?
Hmh, die Mehrheit "will" wahrscheinlich nur einen Dekoder, weil der Digitalbetrieb einfach einen voraussetzt. Und hat sich dann damit abzufinden, das neben dem Lichtumbau auch noch ein Motorumbau hinzukommt.
Um dafür aber auch teure Lokdekoder einbauen zu können. Und noch mehr Geld, wenn er Zusatzfunktionen will (Funktionsdekoder).
Vielleicht macht es Sinn mal zu konkretisieren, welche Zielgruppe man womit genau beglücken möchte? :popcorn:
Ich denke mit einem aktuellem 32bit ARM (egal ob den von Kersten vorgeschlagenem Nuvoton oder einem STM oder NXP) ist genug Rechenpower und Speicher vorhanden, um alle Digitalprotokolle die es momentan gibt, ausreichend und beliebig konfigurierbare Funktionsausgänge eine vernünftige Motorreglung und auch eine Soundausgabe direkt in einem Decoder unterzubringen. Fähige Programmierer vorausgesetzt.
Das muss auch nicht alles auf einmal passieren, die Software kann sicherlich nach und nach entstehen (bei OpenSource jagt einen ja niemand).
Was aber zuerst feststehen sollte, ist eine HARDWARE-PLATTFORM und darauf muss man sich erst einmal verständigen. Diese wird sicherlich so hoch integriert werden, das ein kompletter Selbstbau nicht realistisch ist. Ich könnte mir eine Platine mit unterschiedlicher Bestückung, für verschiedene Decoder Versionen vorstellen. Notfalls kann man da denn selbst mal das eine oder andere Bauteil noch nachbestücken oder wechseln. Grundsätzlich wird das aber so klein, das man das fertigen lassen muss (es sei denn wir bauen Decoder für LGB, da passt auch ein Industrie-PC rein :lol: ).

Ich stell mal hier ein paar Eckdaten rein, nur mal so zur Diskussion:
- Platinengröße maximal 15x20mm
- UB max. 27-30V
- 2-3A Gesamtstrom (einzelne Funktionsausgänge je 500mA, Motorstrom 1,5-2A) Kurzschlussfest!
- 4 - 6 Funktionsausgänge mit Treiber (alles was an Prozessor Pins übrig bleibt als weitere Funktionsausgänge ohne Treiber möglich)
- Soundausgang (Lautsprecher eventuell gleich mit Treiber)
- Akku Puffer
- Rückmeldungen (z.B. Railcom)
- extra Dateneingang (z.B. für IR-Empfänger oder Funkempfänger)
- Anschluss MICRO SD Karte (ob man die direkt auf dem Decoder unterbringt ist fraglich) dann könnte jeder ohne spezielle Hardware seine eigenen Sounddateien in beliebiger Größe benutzen.

Welche Funktionen man dann programmiert, stell ich erst einmal bewusst zurück.

Viele Grüße
Willi
rainerwahnsinn
Ehemaliger Benutzer

Re: Kanalisieren - bitte!

#5

Beitrag von rainerwahnsinn »

at90s hat geschrieben: Grundsätzlich wird das aber so klein, das man das fertigen lassen muss (es sei denn wir bauen Decoder für LGB, da passt auch ein Industrie-PC rein :lol: ).
Hallo Willi,
umgekehrt! Ein V200 Casemod für meine Grafikschleuder, dass wäre echt cool :lol:

Na ja, für die Bereitstellung der Dekoderhardware wird wohl schon kompetent gesorgt. Und Open Source heisst ja nicht,
dass man die Software nicht auch (vor)fertigen lassen könnte, wofür doch einiges spricht...

Der Knackpunkt scheint mir mehr die Protokollthematik zu sein. Es werden immer mehr Protokolle statt weniger.
Die (alle) einem Dekoder aufzupropfen, wird kaum einen stabilen, wartbaren und somit kostengünstigen Dekoder zum Ergebnis haben.

Wer sagt aber, dass die Gewährleistung aller Protokolle zwingend im Lokdekoder angesiedelt sein muss?

Sonst volle Zustimmung auch bei deinen Eckdaten. :P

Viele Grüße
Rainer...W
at90s
Ehemaliger Benutzer

Re: Kanalisieren - bitte!

#6

Beitrag von at90s »

rainerwahnsinn hat geschrieben: Der Knackpunkt scheint mir mehr die Protokollthematik zu sein. Es werden immer mehr Protokolle statt weniger.
Die (alle) einem Dekoder aufzupropfen, wird kaum einen stabilen, wartbaren und somit kostengünstigen Dekoder zum Ergebnis haben.
Wer sagt aber, dass die Gewährleistung aller Protokolle zwingend im Lokdekoder angesiedelt sein muss?
Hallo Rainer,

nö, das sollte das aller kleinste Problem sein, solange die Protokolle ordentlich dokumentiert sind, kann man die auch alle mit einbauen. Ob man die dann auch alle aktiv haben muss, das würde ich aber auch schon aus Stabilitätsgründen bezweifeln. Man kann die aber per CV oder ähnlichen zu/abschaltbar machen.

Als Vergleich, sieh Dir mal das hier an: http://www.mikrocontroller.net/articles/IRMP. Da geht es zwar um IR - Protokolle, aber das ist vom Softwareaufwand ähnlich (und das läuft problemlos auf 8bit Hardware).

Gruß Willi
GeP
Ehemaliger Benutzer

Re: Kanalisieren - bitte!

#7

Beitrag von GeP »

Hallo Leute,

wir sollten schon etwas konsequenter vorgehen!

Mit meinem Beitrag wollte ich erreichen dieses Projekt etwas geordneter anzugehen. Wir sollten uns in diesem Thread auch möglichst auf das Organisatorische beschränken.

Der Leistungsumfang des Decoders ergibt sich aus dem gewünschten Funktionsumfang. Dieser muss also erst einmal festgelegt werden.
Es ist zu früh jetzt über den Decoder zu reden wenn wir noch nicht wissen was er alles können soll.
Wenn es schon einen Decoder gibt der zumindest einen Teil der vorrauss. gewünschten Leistung hat kann dieser erst einmal genommen werden - und sei es nur als Platzhalter.
"Ich denke man sollte einen neuen Post öffnen und dort mal Funktionswünsche sammeln."
Das scheint mit nur der zweitbeste Vorschlag.
Bereits im initialen Therad wurden viele Funktionswünsche genannt. Innerhalb eines Threads ist das aber sehr unübersichtlich. Mehrfache Nennungen oder Wünsche die zwar unterschiedlich formuliert sind aber das selbe ausdrücken sind nicht vermeidbar. Und niemand wird sich die Mühe machen jedes Mal wieder vielleicht einige 100 Posts darin durchzulesen.

Bitte lest nochmals den ersten Beitrag dieses Threads.
Aus meinen Erfahrungen mit anderen OpenSource-Projekten scheint das der beste - wenn nicht sogar der einzig gangbare Weg zu sein.

Also: Wer ist bereit die Feature-Liste zu pflegen?

Viele Grüße
Gerd
Antworten

Zurück zu „Tams OpenSource Decoder“