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]

:^o 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

[DIE HARD]

Hallo...
Ist das nicht etwas übertrieben...so mit Rechtsanwalt
und Geschäftsleitung und Verbraucherschutz?

Das ist etwa so, als wenn man ein Auto kauft und
den Hersteller dann verklagen will, weil man kein
anderes Lenkrad einbauen kann.

Aber im Ernst: Wer unbedingt in Assembler programmieren will kann immer noch auf die alte
Version zurückgreifen. Find ich aber schade, weil
die neue Version sonst wirklich Vorteile hat und
eigentlich so schnell ist, dass diese Treiber auch
in BASIC geschrieben werden können.
Ausserdem würde mich interessieren welche Sachen denn
nun konkret programmiert werden sollen
ciao........

[Frank]

Hallo Leute,

nicht übertreiben. Also Begriffe wie "Verbraucherschutz und Rechtsanwalt" finde ich nun auch unpassend hier in der Diskussion. Schließlich wird man ja auch von niemanden gezwungen den neuen Controller zu kaufen.

Irgendwas hat sich der Entwickler schon auch bei gedacht. In erster Linie werden wohl absolute Einsteiger als Zielgruppe anvesiert. Die möchte man wohl auch nicht ewig halten, was auch oft nicht geht, denn ab einem bestimmten Wissensstand bevorzugt man dann doch individuelle Lösungen und die lassen sich nicht mehr so einfach an eine Firma binden.

Ich finde den Weg auch nicht sinnvoll Assembler auf einem Controller einfach wegzuschließen. Controller wurden in erster Linie für diese Sprache oder halt für einen Compiler entwickelt. Damit wird auch der Fortschritt blockiert. Man ist davon abhängig was die Entwickler mit dem Betriebsystem und knappen Resourcen machen, wie und wann sie es weiterentwickeln. Und ohne Konkurrenz wird dann auch die Entwicklungsabteilung nicht sonderlich motiviert werden die Software weiter zu verbessern. Sind dann die Verkaufszahlen nicht wie erwartet, dann ist fraglich ob die Programmiersprache überhaupt für neuen Aufgaben weiterentwickelt wird.

Aber das ist alles eine Entscheidung des Anbieters. Vielleicht können noch mal die Vorteile dieser Lösung von DIE HARD erläutert werden, so das wir sachlich ein PRO und CONTRA ersehen können.

[mikrokuhl]

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

[eDjango]

[-( Wie stehz mit einem Wettkampf, wer als erster die Sperre knackt? \:D/

[mikrokuhl]

Prinzipiell finde ich die Idee für ein Wettbewerb nicht schlecht, solange das auf legalem Boden bleibt. Man sollte auf das fragwürdige Verhalten von Conrad nicht Illegalem reagieren.

[DIE HARD]

Hallo....
Also nochmal:
Es gibt kein PRO für das Unterbinden von eigenen
Assemblerprogrammen. Und ich habe deutlich gesagt,
dass ich selbst darüber auch nicht glücklich bin.
Es ist einfach eine Notwendigkeit. Als Unbeteiligter
tut man sich leicht,diese Notwendigkeit zu bes-
treiten.
Oder überlasst ihr 1/2 Jahr Arbeitsleistung
unentgeltlich anderen, wenn Ihr davon lebt?

Und wenn man von diesem Detail einmal absieht (weil
höchstens 2% der Kunden betroffen sind) glaube ich
doch, dass CCBASIC einen grossen Schritt nach vorne gemacht hat.
Und was diesen Wettbewerb angeht:
Es steht jedem frei es zu versuchen. Nur, wenn es
gelingen sollte, darf der ROM Inhalt natürlich nicht
veröffentlicht werden.
Also ciao.....

[mikrokuhl]

DieHard: Ich finde es zumindest mal eine guten Zug von Dir, dass Du ganz offen sagst, dass es kein Pro dafür gibt, den Assembler in Zukunft für die Kunden abzuschneiden. Deinem Beitrag kann man also entnehmen, dass Du praktisch unter Zwang handelst. Aber was ist das fuer ein Zwang? Ist es Deine Firma, die auf dem Spiel zu stehen scheint? Ich frag mich nur, woher kommt denn diese panische Angst, dass ein Offenlegen des Betriebssystems nun plötzlich einen Unterauftragnehmer (Du sagtest Conrad hat die neue Generation nicht selbst gemacht, sondern outgesourced) pleite machen kann? Wurde das alte OS denn gegen den Willen der Firma offengelegt und man glaubt nun man könne den Umsatz auf diese Weise wieder etwas steigern? Und wenn das so kritisch ist, dann haette man das doch bei der alten Unit an der Zahl der Nachbauten und Plagiate auch merken müssen. Ist denn jemand bekannt, dass die alte Unit in grossem Stil kopiert wurde? Leute, meldet Euch mal wenn Euch sowas unter gekommen ist. Mich erinnert das Ganze etwas an die Diskussion um das Kopieren von Musik CDs und MP3s. Die grossen der Musikbranche sagen, es schadet massiv und bringt die kleinen Verlage in Schwierigkeiten. Es würden mehr CDs gebrannt als gekauft. Unabhängige Kenner der Branche sagen, erst das Kopieren verbreitet ein Stück und macht es zum Hit. Danach kaufen die Leute eine CD oder mehrere CDs von dem Interpreten, denn sie finden die Musik gut und wollen das Original mit Cover und Beilage. Sony und Warner Brother’s scheinen nicht bankrott zu gehen, ganz im Gegenteil. Und die kleinen Bands stellen ihre Musik aufs Internet, ganz umsonst, weil sie die Verbreitung brauchen. Ein paar große Verlage haben nun kopiergeschützte CDs rausgebracht. Die laufen nicht mehr auf allen Geräten, die Folge war, die Leute sind sauer, viele gaben die CDs zurück (stand in der Zeitung) und die Cracks kopieren einmal mit einer guten Soundkarte analog und danach digital und dann stellen sie die Songs in die P2P-Netze. Nichts ist gewonnen mit dem Kopierschutz außer dem Negativ-Image. Also mein Gefühl ist, die Angst ist völlig unbegründet und sogar riskant. Selbst wenn die interessierten C-Control Neukunden niemals Assembler programmieren, aber wenn es bei der C-Control nicht dabei ist, aber beim AVR-System vom Elektronikladen, dann kaufen sie eben den AVR. Das Nachsehen haben dann nur die Leute, die schon kräftig in die C-Control investiert haben und nun davon abhängen. Klar gehört enorm Mut dazu 6 Mann-Monate SW-Entwicklung offenzulegen, wenn es zudem vielleicht der einzige große Auftraggeber ist. Die Angst ist menschlich in so einem Fall, aber das ändert nichts daran, dass es mehr eine Phobie ist, als eine Angst die Dich schützt. Wenn Du auf einem 10cm breiten Balken balancieren musst, der auf dem Boden liegt, ist es kein Problem, aber in 50m Höhe geht jedem die Düse, ob wohl es physikalisch (bei Windstille) kein Unterschied ist. Das andere ist, Du darfst nicht vergessen wie viel Schweiß die heutigen Nutzer in die Plattform gesteckt haben und selbst wenn nur ein kleiner Teil Assembler benötigt, ist die Summe der Investitionen beträchtlich. Und dann einfach zu sagen, wenn diese „Minderheit“ ins Grass beisst, ist es nicht schlimm, dann ist das einfach moralisch nicht fair. Was passieren kann sieht man mit Linux. Der Marktanteil der kommerziellen Nutzung von Linux ist für Microsoft in der Zwischenzeit „sehr ernst zu nehmen“ und wie es ausgeht steht noch in den Sternen. Wer heute ein Redhat oder Suse das erste Mal einschaltet der staunt. Ich kenn auch viele, die nun rein aus ideologischen Gründen wechseln. Diese Community wächst und wächst und beflügelt sich selbst, während das Feinbild Microsoft an Grösse gewinnt. Ist das nicht ein viel grösseres Risiko für Dich??? Ich bitte Dich noch mal eindringlich, versuch Abstand zu Deiner bisherigen Position zu gewinnen, vergiss die ganzen Emotionen bisher (bin ich mit Schuld dran) und überleg Dir am besten mit ein paar unbefangenen Freunden ob diese Vorgehensweise sinnvoll ist und ob Du es mit Deinem Innersten langfristig vereinbaren kannst. Gruss mikrokuhl

[HeBo]

Hallo,
ist es nicht denkbar, das alte Betriebssystem einfach als offenes Betriebssystem für den neuen Mikrocontroller abzuändern und weiterzuführen, so etwa wie Linus Thorvalds das mit Unix getan hat?

Schönen Gruss HeBo

[mikrokuhl]

Mmmh...., keine schlechte Idee. Gefällt mir jedenfalls besser, als das neue geschlossene Betriebssystem zu „hacken“ um den SYSCODE Befehl durch einen Workaround reinzuflicken. Das heißt wir würden so quasi ein „Open-Control“ Betriebssystem mit „OC-Basic“ als open-source aus dem Alten OS entwickeln und auf den HC908 Prozessor anpassen. Wenn wir im ersten Schritt nur den Memory-Zugriff anpassen und mal die neuen extended Funktionen vorerst weglassen, dürfte das überschaubar sein. Den grösseren Speicher sollte man allerdings nutzen. So wie ich den 908 Prozessor verstehe, kann man ohne weiteres das gesamte Flash Memory löschen und ein neues Betriebssystem draufladen, auch wenn man das Flash wegen der Security Bits vorher nicht lesen kann. Das wäre dann wie ein Linux auf dem PC, nur leider geht der Dual-Boot nicht. Aber das wäre es Wert, wieder eine offene Plattform zu haben. Man könnte sogar Universitäten beteiligen, z.B. gibt es im Fachbereich Informatik immer Vorlesungen und Seminare über Betriebssysteme, da könnte man das als Praktikum aufsetzen. Das wäre eine schöne Aufgabe. Und da ist auch nix Illegales dran. Echt gut die Idee, muss mal intensiver drüber nachdenken... Danke für den hervorragenden Vorschlag!

[Dierk]

OpenControl
Ist doch meine Rede. Nun sind wir langsam schon in der Planung :)
Für so etwas braucht man auch keine Universitäten. Das geht normalerweiße von ganz alleine.
Das Projekt bei Sourceforge anmelden und beginnen.
Früher oder später werden es dann immer mehr Entwickler.
Dann kommen wir ja langsam an den Punkt, wo sich Conrad mal echt Gedanken machen sollte. Denn wenn einmal der Ball rollt, dann kann auch Conrad ihn nicht mehr aufhalten.

Gruß

[HeBo]

Hallo,
Ist das auch für Halb-Profi's geeignet? Und wo genau sollte man sich anmelden (Internet-Adresse) ?
Gruss HeBo

[Dierk]

Natürlich ist das auch für Halbprofis gedacht.
Der Begründer eines Open Source Projekts sollte sich halt ein wenig mit dem Projekt auskennen, die Basis für das Projekt schaffen, koordinieren können und natürlich Entwickler anwerben in Foren, Magazin-Artikel etc.

Open Source Adressen:
http://www.berlios.de/
http://www.sourceforge.net

Gruß

[eDjango]

Aber so ein SYSCODE wettbewerb wäre trotzdem interessant und der Conrad sollte ein Beschwerde Brief bekommen. Das mit dem andern Basic kann man parallel machen. Doppelt gemoppelt hält besser bekanntlich.

[Tappi]

Naja man sollte sowas nicht überstürtzen. Sicherlich lässt sich bezüglich der neuen M Unit 2.0 eine Lösung finden.

[Dierk]

Ja, überstürzen sollte man nie etwas. Aber wieso sollte man denn nicht etwas besseres machen?
Wenn Leute Lust und Zeit dazu haben....