Die neue C-Control I Generation (M-Unit 2.0) - Das Ende???

[mikrokuhl]

Ich will hier mal zu meinen ersten Erfahrungen mit der neuen Generation der C-Control I Plattform berichten, was für diejenigen interessant sein könnte, die sich überlegen von der bisherigen Generation 1.0 her umzusteigen oder mit der neuen Generation einzusteigen. Kurz gesagt: Die 2. Generation (M-Unit 2.0) präsentiert sich mir sehr enttäuschend soweit. Der Hintergrund ist vorwiegend ideologischer Art: Conrad Electronic hat sich offensichtlich entschlossen von dem bisher beispielhaften Kurs der offenen Plattform abzuweichen und zum protektionistischen Stil a la Bill Gates überzugehen. Die 2. Generation ist eine „geschlossene Platform“ auf der es nur „authorisierte“ Treiber geben wird. Außerdem sieht die angepriesene Leistungssteigerung in meinen ersten Experimenten eher dürftig aus.

Bisher gibt es nur die M-Unit in der neuen Generation 2.0. Diese ist mit einem neuen Board-Layout neuem Programmer-Interface und neuen Peripherie-Einheiten ausgestattet. Allerdings ist der Beschreibung zu entnehmen, dass in 2005 eine M-Unit 1.2 folgen soll, die pin-kompatibel mit der alten M-Unit 1.0 sein soll. Schaut man sich die Prozessor-Unit und die Beschreibung dazu an, fällt sofort auf, dass es keinen Hinweis auf den verwendeten Prozessor mehr gibt. Allerdings ist die CC-Basic Software CCEW32D mit nur minimalem Aufwand abgeändert worden und erscheint sogar mit gleichem Versionshinweis (Version 1.33, programmiert von M.Hieke und M.Förster, Copyright von 1997). Die ersten CCBasic-Programme der Generation 1.0, die ich getestet habe, liefen problemlos auf der Generation 2.0. Was aber sofort auffällt ist, dass der SYSCODE Include-Befehl nicht mehr in der Befehls-Beschreibung auftaucht, der SYS-Befehl jedoch existiert noch. Wenn man dann die Dokumentation genau liest, so findet man bei der Beschreibung der Unterschiede zur M-Unit 1.2 die Bemerkung: „bei der M 1.2 können nur "autorisierte" Maschinenprogramme als Treiber geladen werden“. Das gilt offensichtlich auch für die bereits erhältliche M-Unit 2.0. Probiert nämlich dennoch den SYSCODE Befehl zu verwenden, hat man den Eindruck, dass die Compilierung und Übertragung in die C-Control Unit wie gehabt funktioniert (lediglich eine andere Start-Adresse ist anzugeben). Startet man jedoch die M-Unit 2.0 wird das geladene Assembler Programm nicht ausgeführt. Das heisst unterm Strich, es gibt keine Möglichkeit mehr Assemblerroutinen in CC-Basic einzubinden. Damit geht der etscheidente Geschwindigkeitsvorteil für Maschinenprogramme verloren. Vermutlich will sich Conrad damit das Geschäft mit Systemtreibern sichern. Ausserdem wird die Verwendung der C-Control-I Platform für Ausbildungszwecke damit völlig uninteressant, da man keinen Bezug zur Hardware mehr herstellen kann (was bei der ersten Generation der wesentliche Vorteil war). Conrad schneidet sich damit selbst ins Fleisch, da die Ausbildung in Schulen usw. bisher eine Schlüsselfunktion für die Verbreitung hatte.

Dies ist eine absolut enttäuschende Kehrtwende von der bisher sehr offenen Plattform-Politik der Conrad Electronic. Ich bin überzeugt, dass wenn es so bleibt, dass dies auch den Tod der Plattform bedeutet. Denn wenn keine Community entsteht, die eine neutrale Bewertung und Entwicklung freier Software vorantreibt, ist der Nutzen für die meisten Anwender zu gering und das Risiko für eine Investition in eine Sackgasse zu hoch. Die Akzeptanz insbesondere bei der Linux/GNU/open source und sonstigen ideologisch denkenden Freak-Gemeinde wird ebenfalls von Null ins negative übergehen und aller Wahrscheinlichkeit nach mit Hinweis auf Bill Gates verhöhnt werden.

Zum Prozessor fällt auch sofort auf, dass der Aufdruck abgefräßt wurde und durch eine Aufkleber mit bisher 3-stelliger Zahl ersetzt wurde. Die Code-Kompatibilität zusammen mit wenigen neuen Befehlen und erweiterten Variablenzahl, sowie die Integration des seriellen EEPROMs auf den Chip deutet auf einen 68xx Prozessor hin. Schaut man sich dann noch die Pinbezeichnungen an, wird allerdings ziemlich klar, dass es sich mit aller Wahrscheinlichkeit um einen MC68HC908 Prozessor handelt (68HC08 Familie). Der Quarz wurde durch einen 32MHz Oszillator-Baustein ersetzt und damit müsste der Bustakt 8MHz sein. Das Gehäuse ist ein QFP44, das man bei Freescale (früher Motorola) für 8MHz Typen findet. Es wird daher auch nicht lange dauern, bis die Freak-Gemeinde das Produkt durchschaut hat. Eine derartige Verschleierungspolitik ist erfahrungsgemäss völliger Unsinn.

Die ersten Messungen bei Abarbeitung des TOG Befehls in einer Schleife ergaben bei mir eine Periodendauer von 80usec im Gegensatz zur M-Unit 1.0 mit 2.6msec. Lässt man die alte M-Unit mit eine Assembler Routine toggeln, kommt man dagegen auf 7usec , also mehr als 10mal schneller, so dass man für geschwindigkeitskritische Anwendungen, die man bisher mit Assemblerroutinen erledigt hat nun mit einem Rückschritt in der Generation 2.0 rechnen muss, weil man zu CC-Basic Routinen gezwungen wird. Ein absolut trauriges Ergebnis!

Man kann nur hoffen, das diese Taktik nur solange beibehalten wird, bis das Produkt vollends fertig entwickelt ist (neue Software etc.) und dann die Öfffnung der Plattform erfolgt. Andernfalls bedeutet das das Ende der C-Control I Plattform.

Glückwunsch zu dieser teils. subjektiven Feststellung.
Um Objektiv die CC1 V2 zu beurteilen, muß man viele Hintergründe zu dieser Unit wissen.
(Die Zähle ich jetzt aber nicht alle auf.)

Natürlich ist die CC1 V2 noch nicht ausgereift. Sie ist schließlich eine Neuentwicklung.
Der µC ist ein HC08-Derivat. Das ist aber schon seit längerem bekannt.
Der Aufkleber auf den µC, der statt der Bezeichnung drauf ist, ist eine Versionsbezeichung.

Daß keine ASM-Routinen möglich sind, stimmt so nicht.
Daß man keine eigene ASM-Routinen ausführen kann liegt zu einem darin,
daß so sehr einfach das OS ausgelesen oder gar überschrieben werden könnte !
Da die neue CC1 V2 ein externes Projekt ist und nicht mehr direkt im Hause Conrad entstand,
war wahrscheinlich dies der Grund dafür das OS so zu schützen.
Dies hat aber garnichts damit zu tun, daß Conrad sich eine goldene Nase an Systemroutinen verdienen will.
Diese werden frei erhältlich sein.
Stell Dir einmal als Entwickler vor, andere könnten das OS auslesen und würden einen Produktserie
auf der Basis der neuen CC1 V2 verwirklichen wollen.
Da wäre es doch sehr einfach sich einfach selbst µC zu flashen, statt die Unit bei Conrad zu kaufen.
Und das sollte eben verhindert werden.
Bei der alten CC1 war dies nicht so einfach.
Und wenn jemand wirklich dringenst einen ASM-Treiber braucht, kann er diesen u.U.
vom Entwickler der CC1 V2 assemblieren lassen.
Ich würde jedoch auf keinem Fall selbst versuchen alte HC05-Routinen in die neue unit zu laden.
Der ASM-Speicher beginnt nämlich nicht mehr bei &h100 !

Nachtrag:

.., die sich überlegen von der bisherigen Generation 1.0 her umzusteigen oder mit der neuen Generation einzusteigen.

Die alte CC1-Generation ist die Version 1.1, nicht 1.0 !
V1.0 war die ganz alte CC1, die man nur mit einer PLUS-ähnlichen grafischen
Programmierumgebung programmieren konnte.

[mikrokuhl]

Es ist interessant zu hören, wie schnell man von Conrad (oder eben dem externen Partner) oder aus Beidem nahestehenden Lager reagiert. Das lässt hoffen! Ich muss zu meinem Beitrag nachtragen, dass ich durchaus Respekt vor dem Problem einer Markteinführung in einem konkurrierenden Umfeld habe. Mir ist auch klar, dass die zweite Generation der C-Control I bei weitem noch nicht fertig ist, das merkt man bereits an der im Gegensatz zur alten Software CD-ROM sehr dürftigen Ausstattung der neuen SW CD-ROM, sowie der äusserst sparsamen Bedienungsanleitung. Ich gehe davon aus, dass das bald korrigiert wird. So gesehen ist der erste Wurf der M-Unit 2.0 wahrscheinlich vor allem an die Anwender gerichtet, die Erfahrung mit der ersten Generation haben, ein Laie der heute mit einer M-Unit 2.0 beginnt, wird es nicht gerade leicht haben mit der Dokumentation.

Aber gerade deswegen ist es marketing-technisch gerade äusserst unklug, den SYSCODE-Befehl einfach wegzunehmen und in die Anleitung zu schreiben, dass nur „autorisierte Treiber“ ausgeführt werden können. Das trifft genau den erfahrenen Anwender besonders hart, der bereits viel Mühe investiert hat. Und das heisst doch ganz klar, dass der normale Anwender kann keine eigenen Assembler Routinen mehr entwickeln kann. Oder steh ich nun völlig neben der Kappe? Es ist doch keine Option für die effektive Programmierung, wenn ich meine Assembler Routine zu Conrad zum compilieren schicken muss! Wie soll man da denn debuggen? Und was nützt es mir auch wenn Conrad seine Treiber Listings veröffentlicht? Das ist in den seltensten Fällen, das was ich selbst auch Programmieren will ! Und wo bleibt der Lerneffekt, wenn ich die C-Control in der Ausbildung einsetzen will? Wenn ich anhand der C-Control erklären und üben will, wie ein Maschinen Programm funktioniert? Also diese Kommentare sind äusserst schwach! Tut mir leid.

Das einzige was ich glauben kann, ist das man sich um den Softwareklau Gedanken macht. Vielleicht waren die Erfahrungen mit der völligen Offenlegung des ROM Listings im Internet sehr negativ. Allerdings ist mir bisher kein „non-Conrad Derivat“ bekannt (kennt jemand eines?) . Der Preis der Original Conrad Version ist äusserst schwer mit einem Plagiat zu unterbieten. Da ist ja schon die Platine teurer, es sei den man hat Connections nach Taiwan oder China. Es ist sicher richtig, das man bei der Software IP eine Gratwanderung machen muss, zwischen guter Verbreitung und Kopierschutz, der jede Verbreitung verhindert. Aber die Erfahrung zeigt doch, dass eine abgeschottete SW nur dann konkurrieren kann, wenn sie einen deutlichen Abstand zur Konkurrenz hat. Und so viel Abstand ist nun auch nicht gerade vorhanden, der Wert der C-Control liegt doch vielmehr im konkurrenzlos günstigen Preis und der guten Verfügbarkeit!

Und nun doch mal ganz konkret: Ich habe ja geschrieben, dass ich die andere Startadresse für Treiberroutinen wohl bemerkt habe, sie ist ja auch mit dem noc existierenden SYS Befehl dokumentiert. Das Problem ist doch aber, dass der Anwender keinen SYSCODE Befehl mehr hat, um selbst entwickelte Assembler Routinen einzubinden. Wenn das doch geht, dann bitte ich um eine Erklärung wie. Für alle geschwindigkeits-relevanten Anwendungen sind Assembler Routinen wichtg. Viele Anwender haben auch Bibliotheken mit Assembler Routinen erstellt, die mit der M-Unit 2.0 nun nicht mehr verwendet werden können. Viel Mühe und Zeit ist da kaputt und es kommt enorm Frust auf. Das wäre für die Einführung alles andere als ein guter Start. Dass das Einbinden von eigenen Assemblerroutinen technisch irgenwie geht, ist mir klar, nur sollte der Anwender informiert werden wie. Wenn diese Erklärung nicht kommt, dann heisst das ich kann nur noch „autorisierte Routinen“ einbinden. Die Frage wäre dann, wie kommt man zu einer „autorisierten Routine“ oder zur „Autorisierung“? Wenn hier die Antwort ist, dass man die Autorisierung durch Conrad erwerben muss, dann ist doch klar was gespielt wird, oder? Dass sich die externe Firma gegen den Klau des Operating Systems schützen muss kann ich ja verstehen. Aber dann haben sie einen verdammt schlechten Job gemacht, wenn sie das nur durch Abblocken von anwender-erstellten Routinen schaffen. Und da Conrad auf Kundenzufriedenheit ausgerichtet sein sollte, sollte Conrad solange Nachbesserung fordern, bis das Problem gefixt ist. Dafür bin ich auch gerne bereit zu warten. Nur wäre es verdammt traurig, wenn die neue C-Control I Generation an diesem Problem scheitert. Und dass das der Conrad Elektronic egal ist, kann ich mir einfach nicht vorstellen!

[DIE HARD]

Hallo....

Tatsache ist, dass die wenigsten Anwender selbst in Assembler
programmieren.
Tatsache ist auch, dass das Betriebssystem mit Demos und Doku
einen Entwicklungsaufwand von rund 6 Mann-Monaten gekostet hat.
Ich würde dafür mal so etwa Kosten von min 80000 Euro ansetzen.
Diese Kosten müssen sich ja in 2-3 Jahren amortisieren.
Wie soll das gehen, wenn das OS jedem zugänglich ist, jeder
für ca. 5Euro den Controller kaufen kann und sich für 1 Euro
einen Programmer für das OS basteln kann?
Bei der alten Generation war das etwas anders.Das war ein
Maskenprozessor - Maskenkosten 8000 Euro, Mindestmenge 50000 Stück
und der OTP war fast so teuer wie eine M-Unit
-> Für den Bastler war damit der Aufwand zu hoch selbst einen OTP
zu programmieren
-> Für Kunden die teilweise 1000 Stück im Jahr abnahmen war eine
Maske vom Preis nicht diskutabel.

Vielleicht verstehst du jetzt, warum das mit den SYS-Modulen so ist.

Was die Zertifizierung dieser Module angeht,bin ich prinzipiell
bereit die Treiber zu schreiben, wenn es allgemein gebrauchliche
Anwendungen sind.
Im Einzelfall berechne ich die Prüfsumme, wenn das Program getestet ist.
Das Programm müsste dann mit einem B6 @ 16 MHz erfolgen.
Aber ganz im Ernst, um welche Treiber geht es denn oder Bibliotheken,
wie du sagst?
Ich habe versucht das OS so vielseitig zu machen, dass die
Standard-Anwendungen abgedeckt sind.

Ich bin über die Geschichte mit den SYS-Modulen nicht glücklich,
aber ich behaupte mal es ist nicht anders zu machen.

cio.....

[Frank]

Hallo,

ich finde es nett das ihr so offen über diese Problemchen diskutiert. Aber ich muss mikrokuhl recht geben. Es ist nie gut wenn man die Freiheiten für die Anwender derart stark einschränkt. Man stelle sich mal vor Microsoft und Intel lassen keine Assembler Programmierung mehr zu. Das wäre unvorstellbar, auch wenn Assemble rbeim PC eine noch weit geringere Bedeutung besitzt als bei Controllern.

Ich gebe offen zu da sich mal ein großer Fan der C-Control war, aber mit der Erfahrung wächst auch der Anspruch. Siche rwollen Anwender am Anfang nix mit Assembler zu tun haben. Aber irgendwann kommt der Tag wo es doch notwendig wird. Es ist doch etwas dempremierend wenn man soviel Zeit und Energie in ein Projekt steckt und dann plötzlich vor einer Schanke steht.
Natürlich verstehe ich auch die Seite von Conrad. Die Entwicklung des Betriebsystemes ist aufwendig und muss man schützen.
Aber ist denn der Weg mit einem eingebauten Betriebsystem denn nun wirklich der Richtige? Ein Controller ist kein PC, ein Controller hat nur wenig Resourcen. Warum muss man diese für ein Betriebsystem verschwenden?
Warum steckt Conrad nicht das Geld in die Entwicklung eines guten C-Compilers und Basic-Compilers, speziell für das eigene Board. Dieser könnte wie alle Softwareprodukte urheberrechtlich geschützt und verkauft werden. Das Board könnte dann ganz ohne Betriebsystem angeboten werden.
Aber es hätte enorme Vorteile:
- Es würden nur die Routinen im Speicher des Controller landen die auch wirklich gerade von dem Programmierer benutzt werden
- Die Programme sind durchweg um ein vielfaches schneller
- Die Programmiersprache kann immer ausgebaut werden, wobei Anwender durch neue Funktion und Conrad durch Updategebühren bereichert werden
- Assembler wäre in keiner Weise eingeschränkt, im gegenteil man könnte es sogar in der Sprache integrieren

Bei Atmel wird das doch alles vor gemacht, hier gibt es viele Compiler, auch kostenpflichtige.
Ich bin kein Conrad oder C-Control Gegner, nur waren für mich irgendwann die Möglichkeiten erschöpft. Sollte Conrad auch wieder ein leistungsfähigeres offeneres System auflegen, wäre das auch für mich und viele erfahrenere Bastler wieder interessant. Es kann doch nicht im Intresse von Conrad sein das erfahrenere User irgenwann wechseln.
Ich hoffe das wird nur als konstruktive Kritik verstanden.

Gruß Frank

[mikrokuhl]

Danke für die konstruktive Beteiligung an dem Beitrag! Faire Geste des gegnerischen Lagers. Ich will die neue Generation wirklich nicht madig machen, im Gegenteil, ich habe immer noch die Hoffnung, dass das Blatt sich wendet, wenn die Community entsprechend eindeutig reagiert. Aus meiner Sicht war der ganz große Vorteil der vorigen Plattform, dass man beide Optionen hatte und beliebig hin und her konnte. Für einen Quick-Hack konnte man Basic nehmen und wenn’s mit der Speed ernst wurde oder man sonst was exotisches machen wollte nahm man Assembler. Der Assembler half auch ungemein so gewisse Dinge in Basic zu verstehen. Und beides bekam man für einen enorm günstigen Preis. Wo ich z.B. meine Energie reingehängt habe sind digitale Filter für Audio. Und die hängen echt an der Abtastrate, da ist nicht viel mit Basic zu machen. Da ich das Zeug an bestimmte Applikationen laufend anpassen muss, ist das einfach kein Modell, da was generisches zu machen und „autorisieren“ zu lassen. Ich glaube ihr unterschätzt die Zahl derer, die Assembler genutzt haben. Und wie bereits gesagt, das war bei der alten M-Unit auch genial für die Ausbildung. Das Zeug ist doch auch deswegen in den Schulen genutzt worden um Assembler Beispiel zu zeigen (oder warum gab’s denn die 10er Packs)? Ein Lehrer hat sicher keine Lust zu zeigen wie man IP’s zu Tode schützt (vielleicht doch im BWL Unterricht).

Ich versteh auch die Rechnung nicht mit den Maskenkosten. Klar, man braucht da eine bestimmte Stückzahl sonst rechnet sich das nicht. Aber warum habt ihr nicht genauso ne Masken ROM Variante des HC908 für die M-Unit 2.0 genommen? Außerdem, wenn ich das Ding nachbauen will, brauch ich außer dem Controller immerhin noch ‚ne Platine und Komponenten die ich bestücken muss. So billig und schnell wie bei Conrad krieg ich das nicht so schnell hin. Sonst muss ich auch wieder mehr als 1000 Plagiate auf kriminelle Art verhökern.

Ihr dürft auch den Ärger nicht unterschätzen, den das erzeugt wenn der Freak aus der Community nach dem Kauf feststellt, das ist bewusst unterbunden. Das hat doch psychologischen Charakter. Zum Beispiel meinte der Gast letzthin, die Chips seinen nur durchnummeriert. Da brauch ich kein Rastermikroskop um festzustellen, das der Aufdruck mit viel Aufwand manuell abgefräst wurde. Die Oberfläche ist nun so rauh, dass der Aufkleber kaum hält. Er würde auf der „unbehandelten Oberfläche“ viel besser halten. Das ist Käse aus Marketing Sicht. Man sieht, da fehlt das Selbstbewusstsein und irgeneiner hat Muffe ohne Ende. Sonst macht man so was nicht. Habt Ihr nicht die Diskussion mitverfolgt als Intel anfing die Pentiums durch zu nummerieren? Was hat das gekostet als sie das wieder zurücknehmen mussten (ein kompletter Pentium Maskensatz kostet mehr wie ne Million). Das war doch sträflich unklug, das kann man in der c’t und sonst wo nachlesen.

Ich mach ‚nen Vorschlag liebe Leute: Diskutiert das doch nochmal in eurem Tech Center-Team bzw. mit Eurem Outsourcing Partner und Euren Marketing Leuten und macht noch mal eine neue Bewertung (vielleicht auch mit einer kleinen Umfrage). Euer Move ist völlig zu verstehen aber es kann doch auch sein, dass man da ein paar „Markt-psychologische Dinge“ nicht ganz bedacht hat. Das ist ja nicht weiter schlimm, es ist nur eine Einschätzung im Voraus gewesen, die sich nun halt in der Realität mit den Kunden etwas anders zeigt. Das passiert ja offensichtlich auch bei Intel. Und Ihr müsstet ja ausser der Doku und vielleicht der CD nicht viel ändern. Und ihr müsst den Mut haben das einzugestehen. Lasst doch mal einen Marketier nach Beispielen suchen wo das „Zumachen einer Plattform“ negative Folgen hatte (Attrac und MD von Sony gegen MP3, etc.) und dann haltet noch mal dagegen, was Euch das Schützen nicht nur emotional aus Entwickler-Sicht sondern business-related wert ist. Am Ende zählt doch, dass Du als Profi-Entwickler Dein Gehalt bekommst und nicht ob unter 1Mio Usern einer Deinen Code illegal nutzt, oder? Und um Conrad’s Umsatz mach ich mir nur dann Gedanken, wenn Ihr die Fan Gemeinde sauer fahrt, nicht wegen ein paar Nachbauten, wenn das Ding ansonsten brummt. Also gib Dir ‚nen Stoss Junge und quatsch mal mit Deinen Chefs, den Kopf bekommst Du deswegen nicht gewaschen, solange Du früh genug selbst damit kommst.

[Dierk]

Ich stimme mikrokuhl voll und ganz zu.
C-Control wird gekauft, da es für unprofessionelle Bastler einfach zu handhaben ist.
Mein Kollege, der täglich Pics, Atmels etc... in C programmiert, schüttelt nur den Kopf, wenn ich für einen Kunde dieses C-Control programmiere.
Wenn wirklich jemand (irgendeine größere Firma) C-Control abkupfern will, dann macht er das auch. Nennt sich dann C-Control kompatibel und kann dann warscheinlich noch mehr wie die originale Unit.
Das ist in der Vergangenheit oft genug passiert (IBM, Microsoft....)

Außerdem gibt es auch noch eine Open Source-Gemeinde, die genau in solchen Situationen enstehen wird, wenn irgendjemand durch seine Monopolstellung versucht, ein viel genutzes Produkt entweder zu verteuern oder die wenige Türchen, die vorhanden sind, zum individuellen Anpassen des Produkts, verschließt.

Meiner Meinung nach ist diese Conrad-Politik einfach dumm!

Gruß
Dierk

[HeBo]

Hallo,
Ich bin Anfänger und neu hier. Ich habe mir bei Conrad das Buch von B.Kainka: Messen, Steuern und Regeln mit dem C-Control Basic System gekauft und dazu eine M-Unit 2.0, weil ich dachte das ist das modernere System um den Umgang mit Mikrokontrollern zu erlernen. Das Buch ist sehr gut beschrieben und die meisten Basic Beispiele haben nach ein wenig Probieren gut funktioniert. Aber mit den Beispielen zur Assemblerprogrammierung bin ich beinahe verzweifelt. Dieser Beitrag scheint eine Erklärung zu sein. Im Katalog steht nichts davon. Das ist nicht sehr kundenfreundlich. Man sollte einen Brief an die Geschäftsleitung schreiben!
Gruss HeBo

[eDjango]

Na da mach mal! Vebraucherschutz und Rechtsanwalt hilft auch.

Aber mal was anderes, warum schaltet ihr die MCU nicht in den Monitor Mode (IRQ auf 8V) und packt einen Programmer ins RAM, der den eigenen Code irgendwohin schiebt wo man hinspringen kann. Siehe auch:

http://www.eckhard-gosch.de/controller/controll.htm