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. - 30.10.2005 19:53)
 Als Antwort auf Re: C-Control am Ende? von Stefan Tappertzhofen - 29.10.2005 11:29
Hallo Stefan,

> Module auflöten halte ich für Patchwork.

Aha, also sind alle Lötarbeiten Patchwork ?
Oder wo soll die Grenze gezogen werden ?
Es gibt keine Plug&Play-Projekte, wo nur zusammengestöpselt wird, und es geht.
Hoppla, bei der guten alten CC1-Unit das EEProm zu tauschen, ist das auch Patchwork
oder vielleicht doch ein Upgrade ?
Oder sind Upgrades prinzipiell Patchworks ?
Wie sieht es mit zusammengelöteten Prototypen aus ?
Oder ist vielleicht alles, was man mit nackten Controllern aufbaut auch Patchwork ?
Ich hoffe, Du erkennst worauf ich zum Thema Hardware und Patchwork hinaus will, oder?

> Programme zwischen IDE und Compiler schlaten halte ich für Patchwork.

Und was sind dann z.B. C-Parser, die es in den meisten Projekten gibt, um eben
die Besonderheiten bei z.b. µC zu berücksichtigen ?
Kann man eigentlich in C ohne Parser programmieren ?

Warum soll dann ein Parser in Basic Patchwork sein und bei C nicht ?

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

Korrekt, das ist nicht nur Patchwork, sondern der größte Pfusch, der mir je untergekommen ist.
Wie gesagt, zeigt das, daß so gut, wie keine Zeit in das Testen des ersten OS der CC1 V2 ging.
Das ist für mich schlimmer, als jeder von Dir genannter "Patchwork".

Und, warum wird, wenn es nur 500 hergestellt Controller der ersten Version hergestellt wurden,
Kunden nicht angeboten diese direkt upzudaten.
Oder ist bei den Controllern der OS-V2.01 vielleicht ein write-Protect-Bit gesetzt.
Es wäre zugegebenermaßen ein hoher logistischer Aufwand und ein kleines Verlustgeschäft,
jedoch ist hin und wieder Kundenzufriedenheit doch wichtiger, als genervt abwandernde Kunden.
Wenn ich denke, wieviel Kunden ich schon direkt am Telefon geholfen habe und was da an Zeit draufging ...
Aber, ich würge nicht einfach Kunden ab, sondern nehme mir eben die Zeit.
Die Kunden sind dafür dankbar und empfehlen mich daher gerne weiter, da dies
mehr beeindruckt, als irgendein Feature.
Und, wie ich schon längst feststellen musste, macht sich dies bezahlt.


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

Und, was nutzt mir und vielen anderen das ?
Null-Komma-Garnichts.
Ich habe es bisher nicht eingesehen und werde ich auch nicht, warum ich mir neue Controller
kaufen soll um ein einigermaßen Bugbereinigtes Produkt zu erhalten, welche
in einer Testphase, wenn es diese gegeben hätte, innerhalb 10 Minuten entdeckt worden wären.
Aber, wer weiß. Vielleicht waren die Bugs bereits bekannt und aus Zeitdruck wurde
einfach wissentlich ein Fehlerhaftes Produkt hergestellt.


> > 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.
Richtig. Allerdings wäre das Basic dann echtes Basic gewesen. uups.
Das Problem bei Conrad ist mittleriweile leider, daß die rechte Hand nicht weiß, was die linke tut.
Darum war die CCPro erst als Nachfolger der CC1 gedacht, aber, da jemand erkannte,
daß man mit dieser sehr viel mehr anstellen könnte, kam irgendjemand auf die irrwitzige Idee
diese als Ersatz der CC2 einzusetzen.
Allerdings gibt es noch keinen AVR-Controller, der dem Konzeot der CC2 und den damit
verbundenen Ressourcen das Wasser reichen kann.
Selbst in Punkto Geschwindigkeit bieten AVRs keinen wirklichen Vorteil, wenn darauf auch
ein Multithreading OS läuft. (Das ist jetzt nicht auf die CCPro bezogen, sondern allgemein.)
Die CC2 ist das letzte wirklich durchdachte und sehr gut verwirklichte Projekt, das big C
in Auftrag gegeben hatte.,
Nur am Support haperte es etwas. Und hier komme ich ins Spiel ...
Und, da Du ja ein Fan von Modularer Programmierung bist:
Die Sprache C2 ist eine echte modulare objektorientierte Sprache, wie man sie sich wünscht,
da man jedes Modul mit "Modulname.Ressource/Funktion" ansprechen kann.
Konflikte sind damit ausgeschlossen.
So etwas vermisse ich bei einigen Programmiersprachen, auch bei Basic+-.


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

Sorry, das ist jetzt etwas Haarspalterei.
Es gibt kein CCPro Basic oder CCPro C.
Der Controller wird in echtem Basic und echtem C programmiert.


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

Danke, daß Du jetzt auch bei mir anfängst, Dinge aus dem Zusammenhang zu reißen.
Der Satz war als Einleitung für das Nachfolgende gedacht, nicht dafür, um kommentiert zu werden.
Wenn, dann lies bitte ganze Absätze als ganzes und nicht satzweise !

Denn, das Folgende gehört zusammen:
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.


Ich wollte damit andeuten, da man bei Dir herauslesen kann, daß es bei der CC1 nie irgendwelche
Updates verbesserungen oder Support gegeben habe, und das alles bei der CC1 V2 viel besser sei,
daß ein und die selbe Persion bei Conrad (gut jetzt nicht mehr "bei") für die C-Control I V1.1
zwecks Support zuständig war, die auch die CC1 V2 zusammengeschustert hat.


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

Meine ich doch.
Warum profilierst Du Dich dann mit der CC1 V2.0 ?
Du hast nichts davon.
Du hast davon eher einen Schaden, da Du scheinbar über den Tisch gezogen wurdest.
Denn, ich würde niemals für lau jemanden die Rechte an etwas geben, der daraus
reinen profit zieht.

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

Was hat das damit zu tun.
Meinst Du nicht, daß jemand auf die Idee kommen konnte, evtl. beiden zu implementieren.
Das OS wäre davon nicht merklich größer geworden. Nur die Sprungtabelle
und ein paar Bytes für die Routinen. Und schon hätte man ein schönes Feature.
Aber das passiert, wenn jemand und wirklich kommerziellen Praxisbezug etwas schreibt.
Ãœbrigens, kann man in CCBasic mit sehr leichten Tricks jede Art von Tokens generieren.
Das hat Dietmar, soviel ich weiß, auch in seiner Sammlung.
</Sarkasmus>Aber halt, das fällt ja bei Dir unter Patchwork und ist somit absolut gg. Todesstrafe Tabu.</Sarkasmus>

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

Womit der Nutzer sich wundert, wofür so viele Token verwendet werden ...
Somit ändert das eben nichts an dem Pfusch mit den Prinumleitungen.

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

Sorry, aber das wäre nur eine faule Ausrede.
Wäre es schlimm gewesen, offiziell für CCBasic einen Parser herauszugeben ?
Ich denke nicht. Denn Parser sind kein Patchwork, auch wenn Du allen das Gegenteil glaubhaft machen möchtest.


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

Du wirst lachen.
Ich wollte von Uwe die Möglichkeit, die internen I²C-Bus-Routinen direkt mittels kurzer ASM-Aufrufe
ohne diesen blöden Prinumleitungen, die beim I²C-Bus wirklich mehr als fehl am Platz sind, direkt ansprechen.
Als Antwort auf das erste Mail hieß es zum Thema ASM-Routinen kein Problem.
Ich solle diese ihm schicken und er Asemblier mir diese, damit diese mit der CC1 V2 funzen.
Auf das erste Mail, bei denen die ASM-Routinen nichts anderes machen sollten, als
die I²C-Routinen mittels Start(addr), write(data), read(ack) und Stop anzusprechen,
bekam ich die Antwort, daß er den Sinn von den Routinen nicht verstehe, da man hierfür
"sehr bequem" die Printumleitungen verwenden könne.
auf weitere Mails an Uwe bekam ich bis heute nie eine Antwort.
Tja, auch eine Antwort.


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

So liest es sich aber zwischen den Zeilen.

MfG André H.

 Antwort schreiben

Bisherige Antworten: