Das Open-Control-Projekt - Die Alternative zur C-Control-I


Das Forum zur C-Control-1
Welche C-Control-Varianten existieren?
Übersicht - Suchen - Neueste 50 Beiträge - Neuer Beitrag - Login - Registrieren
INFO - FAQ - CC2-Forum - CCPro-Forum 

 Re: C-Control am Ende? Kategorie: Verschiedenes (von André H. - 29.10.2005 7:15)
 Als Antwort auf Re: C-Control am Ende? von Stefan Tappertzhofen - 29.10.2005 1:58
Hallo @all,

Leute, langsam komme ich aus dem Lachen nicht mehr raus.
Und zwar darüber, wie Stefan sein Basic--, oh Sorry, Basic++ und die CC1 V2.0 "verteidigt". *lol*

Stefan schreibt immer von "Patchwork".
Wie nennt man dann Software, die halbwegs und ungetestet zusammengeschustert wurde?
Denn das ist für mich Patchwork.
Über CCTools bekomme ich von meinem mittlerweile fast 1300 Kunden einiges zu hören.
(Wohlbemerkt, ich bin ein Ein-Mann-Betrieb.)
Viele dieser Kunden benutzen eine C-Control II und haben vorher mit der C-Control I (V1.1) gearbeitet.
Mit einigen hatte ich schon gesprochen, da sie evtl.  die CC1 V2.0 ausprobieren und
evtl. in Projekten verwenden wollten. Ich hatte diesen nach meinen Entäuschungen
der Bugkiste CC1 V2.0 davon abgeraten.
Allerdings hatte jeder dieser Kunden dennoch eine CC1 V2.0 gekauft.
Ratet mal, was passiert war. Richtig, sie waren größtenteils von der CC1 V2.0 nicht gerade erfreut.
Diese Rückmeldungen hatte ich zu einem großen Teil von gewerblichen Kunden.
Was aber u.a. den meisten aufgestoßen war, war der seeeeeeeeehr peinliche Byteport2-Bug.
Das zeigt, daß ein Produkt so gut, wie garnicht getestet wurde.
Denn, wenn einem bei einer Entwicklung etwas so grunlegendes, wie dies nicht aufällt ...
Dieser Bug wurde nämlich von den Usern entdeckt, bevor er seitens des Entwicklers publik
gemacht wurde, genauso, wie der For-Schleifen-Bug der ersten CC1-Micro. Das nur mal als Anmerkung.
Da fällt mir ein: Aus guter Quelle kann ich sagen, daß die CC1 V2.0 eher ein Unfall
als wirklich geplant war. Die CCPro sollte eigentlich der Nachfolger der CC1 werden.
Jetzt ist die CCPro aber eine dritte, eigentständige C-Control-Variante.

Da fällt mir nochetwas ein:
Es wurde das Thema Updates & Co bei der alten und neuen CC1 angesprochen und, daß
es bei der CC1 V2.0 viel besser sei.
So, und nun ratet mal, wer die ganzen Jahre für die C-Control I, und besonders
für www.c-control.de zuständig war ? Richtig DIE HARD, der Ersteller der CC1 V2.0,
als er noch im CTC bei Conrad war.
Martin Förster kann man keinen Vorwurf machen. Als es noch das C-Control-Center gab,
hat er dort tatkräftig im CC1-Forum (als auch im CC2-Forum) gepostet,
wurde aber von ein paar dämlichen Schwachköpfen dort, sagen wir, grob behandelt,
sodaß er nichtmehr dort gepostet hatte. Somit ging er der CC1-Gemeinde verloren.
(Allerdings nicht ganz der CC2-Gemeinde, da er mein Forum auf CC2Net.de mitliest
und hin und wieder etwas gepostet.)


Stefan, Du schreibst immer, es ginge nur um die CC1 V1.1 und CCBasic, da alles andere
Patchwork sei bzw. inoffiziell.
So, wie verhält sich das mit Basic++ ?
Wurde Basic++ von Conrad bzw., besser gesagt, von Die Hard in Auftrag gegeben oder
einfach nur für lau zur "offiziellen Programmiersprache" gemacht, wo eindeutig Die Hard profitiert.
Denn so kann man das Patchwork - schönes Wort ;-) - der CC1 V2.0 gut vertuschen.
Denn allein die Printumleitungen sind in dieser Art schon Patchwork.
Gegen eine Printumleitung selbst, spricht nichts. Aber wie man diese schafft, kann
man geteilter Meinung sein.
Ich halte nichts davon, daß man z.B. für eine Startbedingung am I²C-Bus
print "#START#"; schreiben muß.
HALLO!! Das sind 9 Byte vom Programmspeicher für eine simple Startbedingung.
Und, da man davor meist die Printumleitung mit print "#ON_IIC#"; und zusätzlich
mit print "#STOP#";, da das LCD gegen jeder Konvention die Ports mit dem I²C-Bus teilt,
einleiten muß, kommt man auf satte 26 Byte, wenn man auf den I²C-Bus zugreifen will.
Aber das wird mit Basic++ natürlich schön kaschiert, da der Nutzer von diesen Umleitungen
natürlich wenig mitbekommt.
Wäre nur ein Fünkchen beim OS der CC1 V2.0 mitgedacht worden, wären für alle Zusatzfunktionen,
wie I²C-Bus, LCD etc. eigene Tokens vorgesehen worden, wie es z.B. auch beim
CC1-OS-Project der Fall sein sollte und beim OC-Projekt für andere Funktionen der Fall ist.
Aber, es mußte ja dieses "Patchwork" mit den Printumleitungen her.
Allein dadurch schafft man mit den 9,5kB der CC1 V2.0 weniger, als mit den 8kB der CC1 V1.1,
auch wenn man dort die Routinen für I²C, welche dann in ASM sind, sowie für das LCD laden muß.
Fertige Routinen gibt es schließlich. Der Anwender muß hier nichts neu erfinden.

So, und jetzt noch etwas aus einer "höheren Liga" zu diesem Thema:

Da ich inoffiziell der offizielle Supporter der C-Control II bin, grinse ich schon die ganze Zeit,
in der ich den Thread verfolge.
Da wird davon geredet, daß die CC1 V2.0 nur Vorteile hätte und die CC1 V1.1 auf jeden Fall übertrumpft.
Von möglichen Useroptimierungen an der CC1 V1.1 um mehr Speicher oder geschwindigkeit
zu erhalten, wird nur als "Patchwork" bezeichnet.
HALLO ! Wir reden von µControllern, nicht von Wachmaschinen.
Wie wird denn das genannt, wenn man einen µController selbst zusammenlötet,
oder für einen ersten Prototypen etwas auf Lochraster lötet. Ist das auch Patchwork ??

Wenn es solche Diskussionen bei der C-Control II gegeben hätte ode rgeben würde, hätte
ich den glauben an die Welt schon längst verloren.
An der C-Control II sieht man, wie ein µController-Produkt wirklich entwickelt wird.
Es wurde alles durchdacht. Der Nutzer hat alle Möglichkeiten der Welt.
Es war von Anfang daran gedacht worden OS-Updates zu ermöglichen.
(Hier ein dickes Dankeschön an Martin Förster, einer der Entwickler der C-Control II.)
Wohlbemerkt gibt es hier mittlerweile OSOPT V3.0, die mittlerweile 5 OS-Version.
Und die sechste, "OSOPT V3.1" mit nochmals deutlichen Geschwindigkeitssteigerungen
seit OSOPT_V2 ist bereits in Arbeit.
Es benutzen deutlich über 90% der CC2-Nutzer die aktuellen Dateien von CC2Net.de .
Das nurmal angemerkt, um von vornherein auszuschließen, daß jemand behauptet,
nur wenige würden sich Dinge von CC2Net.de benutzen, da die Site schließlich "privat" sei.
Sperren oder Beschränkunegn von ASM gab es nie. Nur am Anfang etwas schlecht dokumentiert.
Aber das war einmal.
Selbst die CC1 V2.0 steckt die CC2 leicht in die Tasche, entgegen den Behauptungen
des Entwicklers, die "CC1 V2.0 sei schneller als die CC2".
Das ist absoluter und mehrfach widerlegter Schwachsinn, da es nicht darauf ankommt,
wie schnelle die schlellste Instruktion ist, sondern was man mit den Tokens oder VM-Codes
alles anstellen kann. Man kann auf verschiedenen Plattformen nur Programme vergleichen,
aber keine einzelnen Instruktionen. Sonst vergleich man nur Äpfel mit Birnen.
Aber, um auf den Vergleich von unserem zähen Knochen nochmals zurückzukommen:
Als er die CC1 V2.0 mit der CC2 verglichen hat, hatte er wahrscheinlich
eine nackte Unit genommen (mit den 4 offenen Interrupteingängen ohne angeschlossenen Pull-Ups)
und darauf die erste OS-Version mit den ältesten Modulen.
Vergleichstests erstellt man aber immer mit den aktuellsten Versionen.

Nun aber zurück in Richtung CC1 and compatible:
Die Open-Control, also die Open-Micro, Open-Mini und eine evtl. Open-Unit haben sehr großes Potential,
welches ich gerne unterstütze.
Viele verfolgen das Projekt, obwohl es noch in der Betaphase ist.
Kein Wunder. C-Control-Intern ist seit dem Ableben des C-Control-Centers die Site zum Thema
C-Control I und wird es hoffentlich auch bleiben. (Hier ein dickes Danke an Dietmar)
Es gibt aber auch Leute, die es belächeln und meinen, es sei nur ein Bastlerprojekt.
Glaubt mir, aus erster Hand, was Hardware angeht, ist das garantiert nicht so. ;-)


So, das war mein bißchen Dampf, den ich ablassen wollte.

MfG André H.



 Antwort schreiben

Bisherige Antworten:

Re: C-Control am Ende? (von Stefan Tappertzhofen - 29.10.2005 11:29)
    Re: C-Control am Ende? (von André H. - 30.10.2005 19:53)