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 Stefan Tappertzhofen, Homepage - 29.10.2005 11:29)
 Als Antwort auf Re: C-Control am Ende? von André H. - 29.10.2005 7:15
Stefan Tappertzhofen nutzt:  CC1-M-Unit V1.2/2.0, Micro
Hallo,

> Stefan schreibt immer von "Patchwork".

Module auflöten halte ich für Patchwork. Programme zwischen IDE und Compiler schlaten halte ich für Patchwork.

> 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.

Diesen Bug gibt es laut Supportseite nur bei der 2.01. Auf der Supportseite gibt es sogar ein Alternativprogramm (ja ich halte nichts davon: das ist auch Patchwork,aber es gibt es). Von dem Controller wurden grade rund 500 Stück hergestellt und nicht alle Controller gingen an diese Kunden.

> genauso, wie der For-Schleifen-Bug der ersten CC1-Micro. Das nur mal als Anmerkung.

... der auch dokumentiert und bei der 2.01 entfernt wurde.

> 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.

Das wäre allerdings sehr übel gewesen. Die Anwender hätten sich komplett umstellen müssen, da das BASIC der CCPro gar nichts mit CCBasic zu tun hatte. Sie hätten von Freescale Assembler nacht AVR Assembler wechseln müssen und sie hätte keine Alternative zu CCPro Basic oder CCPro C gehabt.

> Es wurde das Thema Updates & Co bei der alten und neuen CC1 angesprochen und, daß
> es bei der CC1 V2.0 viel besser sei.

Ja. Auf Grund des Flash Speichers.

> 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.)

Und was hat das mit Updates zu tun? Außerdem habe ich Martin Förster keinen Vorwurf diesbezüglich gemacht.

> 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.

BASIC++ entstand als Freeware von mir auf der 1.1, da ich mit dem damaligen CCBasic unzufrieden war. Ich war nur modulare Programmierung gewohnt und wollte dies auf der C-Control ebenfalls ermöglichen.

> 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.

Das stimmt in der Tat. Du musst Dir vor Augen halten, dass es diese Umleitungen in dieser Form wegen CCBasic gibt. Es gab Überlegungen diese Umleitungen durch Token zu ersetzten. Bei BASIC++ wäre das kein Problem gewesen mal eben den Compiler für diese Spezielfälle umzumodellieren. CCBasic dagegegen wird nicht weiter entwickelt. Würde man z.B. bei einer M Unit 2.05 solche Tokens einfügen würde dies bedeuten, dass dieses Feature von CCBasic nicht angesprochen werden kann.

> Aber das wird mit Basic++ natürlich schön kaschiert, da der Nutzer von diesen Umleitungen
> natürlich wenig mitbekommt.

Die erzeugen Bytes werden klar dargestellt. Das einzige was BASIC++ macht ist es dem Nutzer diese Umleitungen (es steht ausdrücklich Umleitung und Extended Objekte in der Referenz) einfacher zu handhaben.

> 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.

Wie gesagt hätte man dann diese Dinge eben nicht mit CCBasic ansprechen können. Als diese Dinge entwickelt wurde gab es noch kein BASIC++

> 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.

Du kannst die I²C Routinen auch natürlich selber in Assembler für die 2.0 schreiben. Dann brauchst Du auch keine Umleitungen in Basic.

> Da wird davon geredet, daß die CC1 V2.0 nur Vorteile hätte und die CC1 V1.1 auf jeden Fall übertrumpft.

Ich habe einige Vorteile genannt und nicht gesagt sie hätte nur Vorteile.

Gruß,

Stefan

Meine Homepage: http://www.fdos.de

 Antwort schreiben

Bisherige Antworten:

Re: C-Control am Ende? (von André H. - 30.10.2005 19:53)