
|
INFO - FAQ - CC2-Forum - CCPro-Forum |
|
||
|
Hallo Stefan es ist wirklich schlimm, daß ich meine Zeit verplempern muß, um Deine Falschaussagen und Halbwahrheiten zu korrigieren. (Wieso bin ich eigentlich der einzige, der das tut? Was ist mit den anderen C-Control-Anwendern hier im Forum? Einige Aussagen von Stefan sollte man auch ohne viel Fachwissen als falsch erkennen.) > Eine Erweiterung bei der M Unit 2 ist schon aus technischen Gründen nicht möglich. [..] Mich wundert es daher, dass grade Du einen solchen Wert auf diesen Punkt legst, da dies ja ein entscheidener Vorteil der alten M Unit sei (die Standadmäßig weniger Speicher hatte). Fakt ist, es können mit der C-Control 1.1 Programme bis zu einer Größe von 64 KB benutzt werden. OCBASIC kann Programme bis zu dieser Größe kompilieren. Selbst die M-Unit 1.1 läßt sich umrüsten. Sogar mit einem bedrahteten EEPROM, da der I²C-Bus herausgeführt ist. Lustig ist auch, daß Du in diesem Zusammenhang von "Patchwork" redest, nur weil der Anwender einen Lötkolben zur Hand nehmen muß. Auch bei der 2.0er ist es nach wie vor sinnvoll, wenn der Anwender des Lötens mächtig ist. > Gleiches gilt für die OpenMicro. Im Kreis der Betatester haben wir bereits über die Möglichkeit diskutiert, wie auf der 1.1er den Tokencode optional in einem I²C-EEPROM abzulegen. Ganz so schlecht, wie Du das liebend gern darzustellen versuchst, ist das Konzept nämlich nicht. Auf der B-Control wird es nämlich wieder genau so realisiert und zusätzlich kann der Anwender wahlweise auf Tokencode im Flash umschalten, wodurch die B-Control deutlich schneller (huch!) als Deine 2.0er C-Control wird. > Hier muss sogar mit veränderten Eigenschaften der TIMER Funktionen gearbeitet werden. Nur auf der Original-1.1er, nicht im COP-Betriebssystem. Aber das ignorierst Du natürlich wieder einmal. > Nicht nachvollziehen kann ich warum der Downloadmodus nicht funktioniert, immerhin nutze ich bei BASIC++ den gleichen Modus für die 1.1, 2.0 und Micro. Klingt so, als ob Du C3C nie ausprobiert hättest. > Bitte wo verbiege ich da die Wahrheit? Das Du in Deine Beiträge Behauptungen einflechtest, denen man eventuell zustimmen kann, um Deine Falschaussagen, bzw. Halbwahrheiten zu kaschieren, macht die Sache nicht besser. > und mir z.B. unterstellst ich würde die Wahrheit verdrehen. Ich unterstelle nicht, ich habe bewiesen. > > vergleichst Dein BASIC mit der Programmiersprache und der Sprachenversion, die dir gerade an sinnvollsten erscheinst > Hallo? Seit Beginn der Diskusion rede ich nur von CCBasic und 1.1 auf der einen die 2.0 und modulare Programmierung (u.a. am Beispiel von BASIC++ oder C3C) auf der anderen Seite. Genau das meine ich. > dass ich CCBasic vornehmlich mit "modularem Basic" vergleiche Modulare Programmierung bedeutet unter anderem, daß einzelne Programmteile (zum Beispiel Unterprogramme) wiederverwendet werden können. So etwas läßt sich auch in CCBASIC realisieren. In OCBASIC sogar komfortabel mittels INCLUDE und auf der OM existieren sogar INLINE-Assemblerroutinen. > Und nun noch einige Dinge, die ich an CCBasic kritisiere und eben versuche darzustellen, dass grade diese Dinge CCBasic nicht einfacher machen, ... Du vergleichst im ernst CCBASIC mit Visual Basic und regst Dich über Inkompatiblitäten auf? Auch das Du immer wieder auf angebliche "Konventionen" pochst und die Meinung und Vorlieben der Anwender ignorierst macht dich nicht unbedingt beliebter. Du solltest Dich vielleicht wirklich einmal mit anderen Leuten, wie zum Beispiel denen im Mikrokontroller.Net-Forum, unterhalten. Da wird nämlich deutlich ideologiefreier diskutiert. Aufgefallen war mir dieser Thread im Forum, in dem über die Entwicklung eines BASIC-Interpreters diskutiert wird. Du wirst wahrscheinlich hinten rüber fallen, wenn Du hörst, daß mit Zeilennummern gearbeitet werden soll. Und nein, der Thread ist nicht von 1980, sondern beginnt im Jahre 2004. > Vieles hätte auch besser gelöst werden können Dann streite Dich doch bitte mit Martin Förster herum, aber nicht mit mir. Auch ich finde einige Dinge in CCBASIC nicht ideal, was Du (ich wiederhole mich) daran sehen kannst, daß ich Hilfsprogramme und ein "erweitertes CCBASIC" erstellt habe. Mein einziger Fehler war, daß ich vielleicht zu spät einen eigenen alternativen Compiler erstellt habe. Und Du gehst nicht darauf ein, daß der Sourcecode zu CCBASIC hier auf meiner Website seit Jahren zum Download angeboten wurde. Wenn also jemand mit CCBASIC unzufrieden gewesen wäre, hätte er es durchaus optimieren oder an eigene Bedürfnisse anpassen können. Ob diese Option für den "normalen" Anwender in frage kommt, ist natürlich zweifelhaft. Aber immerhin bieten die 1.1er und CCBASIC auch etwas für den Semi-Profi, der sich zutraut, eigene Compiler und Betriebssysteme zu schreiben, ohne auf den Komfort der einfachen BASIC-Programmierung zu verzichten. Da die 2.0er weitgehend undokumentiert ist, kann sie der 1.1er in dieser Hinsicht nicht das Wasser reichen. > Daher kann ich eben nicht nachvollziehen, wieso CCBasic einfacher wäre als modulare Programmierung. Das ist Deine Meinung. Andere C-Control-Anwender sind da offensichtlich anderer Meinung, da sie bereits, im Gegensatz zu Dir, mit Programmierung auf Homecomputern, GWBASIC und QBASIC vertraut waren. Etwas, über das wir uns bisher noch gar nicht unterhalten haben, ist die Möglichkeit der Simulation in CCBASIC und CCPLUS. Das ist sicher eine nicht unerheblicher Option, die für CCBASIC und CCPLUS spricht. Neben einigen bei den Anwendern offenbar sehr beliebte Internetseiten, auf denen die Programmierung aufführlich erklärt wird. Eine dieser Seiten ist die von Manfred Wilzeck. Dietmar Meine Homepage: http://ccintern.dharlos.de |
| Antwort schreiben |