Die neue C-Control I Generation (M-Unit 2.0) - Das Ende???
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.
Re: Die neue C-Control I Generation (M-Unit 2.0) - Das Ende?
Nachtrag:
Zitat:
Zitat von mikrokuhl
.., 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.
Bitte um Erklärung zur autorisierten Treiberoutine!
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!
Audiosignalverarbeitung mit M-Unit 2.0
eDjango: Hast Du Erfahrung mit dem Bootloader, kannst Du uns dazu was erzählen?
Eigentlich wäre mir lieber, wenn Conrad den Assembler ganz normal weiterunterstützen würde, mit Support und ohne das grosses Häckmäck nötig ist. Die sollten doch an der Kundenzufriedenheit interessiert sein und nicht an so einem Gezerfe!
Ich bin ein Stück weiter gekommen mit der Erforschung der M-Unit 2.0 für die Audio Signalverarbeitung, allerdings wieder mit negativem Ergebnis. Während man mit der M-Unit 1.0 in Assembler die systeminternen Interrupts abschalten konnte um ein zeitgetreues, äquidistantes Abtasten und Verarbeiten von Audiosignalen zu erreichen, ist dies nun bei der M-Unit 2.0 wegen des Fehlen des Assemblerzugangs nicht mehr möglich. Benutzt man anstelle von Assemblerroutinen unten stehendes simples Programm in CCBasic 2.0 erkennt man zwar, dass die M-Unit 2.0 von der Geschwindigkeit durchaus einige kHz erreichen könnte, aber durch die systeminternen Unterbrechungen nicht in der Lage ist, konstant in einem festen Zeitraster dem Eingangssignal Abtastwerte zu entnehmen. Das untenstehende Programm soll das Eingangssignal mit dem AD-Wandler abtasten und es gegen einen Schwellwert in der Mitte vergleichen. Das Vergleichsergebnis wird dann als Digitalsignal wieder ausgegeben (Minimalprogramm). Speist man nun mit einem Sinusgenerator ein Signal im Bereich von einigen 100Hz ein sollte es theoretisch zu einem Rechtecksignal mit ca. 50% Tastverhältnis am Ausgang umgeformt werden, solange der Controller folgen kann. Sobald der Controller nicht mehr folgen kann, sollte sich das Tastverhältnis verändern. Schließt man nun ein Oszi an, sieht man jedoch sofort das unstetige Abtasten, selbst bei niedrigen Frequenzen, am instabilen Ausgangssignal. Schließt man über einen Vorwiderstand einen Kopfhörer an, kann man direkt das Gezappel sogar direkt hören. Schuld daran ist vermutlich das unstetige Abarbeiten der CCBasic 2.0 Routinen mit internen Interrupts vom Timer usw. das man nun nicht mehr in Griff zu bekommen ist. Damit ist auch jede andere Art niederfrequenter Echtzeit-Signalverarbeitung unmöglich !
Oder hat jemand eine Idee wie das unter CCBasic doch irgendwie stabil gehen könnte?
DEFINE Eingang AD[1]
DEFINE Ausgang Port[8]
DEFINE Wert Byte
DEFINE Schwelle 128
#Loop
Wert = Eingang
IF Wert > Schwelle THEN Ausgang = 1 ELSE Ausgang = 0
GOTO Loop
