
|
INFO - FAQ - CC2-Forum - CCPro-Forum |
|
||
|
Hallo, > es ist wirklich schlimm, wie Stefan seine Meinung als Wahrheit darstellt, und dabei hat er noch nicht einmal besonders viel Ahnung es ist wirklich schlimm, wie der Forumsadmin hier seine Position eklatant missbraucht und übelste Meinungsmache gegen meine Person macht. Er hängt mir dauern irgendwas an, oder suggeriert in seinen zunehmend nicht mehr sachlichen Posts Dinge wie ich würde CCPlus als Gebärdensprache bezeichnen. Er schreibt selber ich hätte wenig Ahnung von der Matiere, andererseits bezeichnet er z.B. seine OpenController als Bugfrei. Ich kenne keinen ernstzunehmenden Entwickler, der sagen würde ein großes Softwareprojekt sei bugfrei. OT: Nichtmal Airbus bezeichnet das System seiner Flugzeuge als Bugfrei, obwohl hier das Leben von Menschen dran hängt. Das ist grob fahrlässig und falsch. Durch sowas werden Bugs zu Features. Nur als Beispiel, wenn Du hier über den Begriff "Wahrheit", "Halbwahrheit" oder "verdrehen von Wahrheiten" sprichst. Im übrigen warst Du es, der die sachliche Diskusion verlassen hat und dieses Thema zu dem machte was es jetzt ist. > Wenn er nicht einmal weiß, ob ich beim CC1-OS-Projekt mitgemacht habe, dann hat er offensichtlich überhaupt keine Ahnung von diesem Projekt. Ich wusste nicht, dass es so wichtig für Dich ist, dass ich wissen muss, dass Du an dem Projekt mitgearbeitet hast. Natürlich ändert das die Tatsachen vollkommen, wenn Du jetzt bei den Projekt mitgarbeitet hast. Das CC1 OS Projekt kann man nicht bei Conrad kaufen. Die 1.1 kann man wohl bei Conrad kaufen. Wenn jetzt Programmierer dahin gehen und das bestehende System erweitern und eventuell sogar auf einer Drittseite zum Verkauf anbieten ist das ein Alternativer Controller zur 1.1. Die Controller werden parallel angeboten. Das sie den gleichen Tokencode verstehen macht den einen noch nicht zur offiziellen Weiterentwicklung die ich bei Conrad im Laden kaufen kann. Der Großteil der 1.1 User kennt das CC1 OS Projekt aller Wahrscheinlichkeit nicht. Um mal ein wenig wieder richtig Thema zu kommen: beide Controller halten sich an Konventionen (man würde wohl besser sagen sie sind kompatibel). > Sehr interessant ist es auch, wie ein gewisser Personenkreis mit Leuten umgeht, die sich nicht so gut ausdrücken können und ihre Argumente nicht ernst nimmt. Schon wieder eine Unterstellung? Dietmar was willst Du eigentlich mit diesen Unterstellungen bezwecken? > Alle Weiterentwicklungen für die 1.1 von mir und natürlich von diversen anderen Personen findet man unter anderem hier auf dieser Website, besonders in der Download Area. Ja das ist auch richtig so. Ich habe fälschlicherweise "Entwicklung" nicht "Weiterentwicklung" gelesen. > Besonders interessant ist der echte (!) BASIC-Compiler CCBAS2MC, mit dem man die CC1 um bis zu Faktor 250 beschleunigen konnte, nicht nur Faktor 30. Das wird sicher auch in der Zukunft eine Rolle spielen, denn da das Betriebssystem der Open-Control als ROM-Listing *offenliegt* wird es sicher möglich sein, diesen Compiler an die Open-Micro und Open-Mini anzupassen. Und auf diesen Kontrollern kann man größere Assemblerprogramme als nur die 255 Byte, die mittlerweile von der "neuen" C-Control zur Verfügung gestellt werden, laden! Der Faktor 250 bezieht sich auf 250 mal schnelleres Assembler als Basic auf der 1.1. Der Faktor 30 bezieht sich auf Basic der 2.0 und Micro im Vergleich zur 1.1. Wie schnell jetzt Assembler auf der 2.0 und Micro oder auch der Open Controller ist steht dagegen noch aus. Alle Vergleiche ziehe ich wiedermals zur 1.1. > Wenn 500 Stück fehlerhafte Einheiten verkauft wurden, dann hat die "neue" C-Control aber einen sehr schlechten Stand. Aus einigen Beiträgen hier im Forum kann man den Schluß ziehen, daß diese Kontroller immer noch in den Conrad-Filialen auf Kunden warten und wenn an 500 potentielle Kunden fehlerhafte Einheiten verkauft werden, dürfte es kaum möglich sein, dieses negative Image jemals aufzubessern. Die updateunfähigkeit der V 2.01 ist keineswes glücklich. Hält man sich die Stückzahlen vor Augen relativiert sich das Problem drastisch. Sollte es allerdings dann noch zu Problemen kommen kann man auf Lösungen zurückgreifen, die sich auf der Support Seite finden. Hinzu kommt die Möglichkeit Assembler einzubinden. So ist es z.B. auch möglichl auf der 2.01 Pointer per SYS Aufruf (und später einmal direkt durch BASIC++) zu verwenden. > Das muß nicht zwangsläufig so sein. Wenn man eine interpretierte Sprache mit einer compilierten vergleicht müßte man fairerweise auch die Größe des Interpreters hinzurechnen. Zumindest dann, wenn er Speicher belegt, der auch für Anwenderprogramme nutzbar wäre. Das ist wohl war. Eine zwar subjekte, wenn doch interessante Aussage von Henrik: Der auf 10 kByte beschränkte Programmspeicherplatz erlaubt tatsächlich deutlich größere Programme als der 32 kByte große Speicher des AVR-Mega. Das liegt daran, daß durch das Betriebssystem der C-Control schlicht Routinen des Betriebssystems genutzt werden, die im AVR bzw. dessen jeweils benutzter Programmiersrache als Makro in den Code eingefügt werden müssen. Der Faktor der Platzersparnis liegt je nach Programm zwischen 2 und 10. Auch unter Nutzung aller Tricks gelänge es mir nicht, sämtliche Funktionen meiner PC-Überwachung ( ~ 9kB in Basic++ als Token) auch nur ansatzweise in den 32 kB des AVR unterzubringen. > Was hat das damit zu tun, daß ich Thomas zitiere, um Stefans Behauptungen zu widerlegen? Weil ich zu Thomas nix gesagt habe, folglich kannst Du hier auch keine angeblichen Behauptungen von mir widerlegen. Ich habe zu Jens Posting geantwortet um durch Beispiel zu zeigen, dass modulare Programmierung keineswegs schwerer ist als die von CCBasic. Des weiteren machte Jens die (vermutlich) rhetorische Frage: > Die C-Control-1 V2.xx ist zwar schneller (und hatt sicherlich auch wehniger Fehler als die V1.1), ist sie aber deswegen auch besser??? was ich wie folgt kommentierte: > na wenn Sie schneller ist? Weniger Fehler als die 1.1 hat und darüber hinaus noch sehr sinnvolle Features wie Pointer und Extended Functions hat? Sie hat viel mehr Speicher als die 1.1. Im übrigen ist es absehbar, dass der Controller der 1.1 von Freescale auf kurz oder lang nicht mehr produziert wird. Der Umstieg auf einen neuen Prozessor ist ganz normaler technischer Fortschritt. Jens bezieht sich auf die 1.1 und nicht auf COP oder andere Alternativen. > Die Email, auf die Stefan sich bezieht, gibt er hier zu knapp wieder und reißt dadurch meine Bemerkung mal wieder aus dem Zusammenhang. Es ging darum, daß BASIC++ zur Kompilierung eines Sourcecodes stolze 60 Sekunden benötigte. Der OCBASIC-Kompiler war dagegen 187,5 mal schneller und das von Stefan verpönte CCBASIC sogar 375 mal schneller als BASIC++. Ich habe in der Email also nicht OCBASIC mit CCBASIC verglichen. Die 60 Sekunden konnte ich (wie schon im Posting gesagt und von Dir hier natürlich nicht zitiert) stark verkürzen. Hier der Auszug aus der Mail: > der angehängte Sourcecode benötigt insgesamt fast 60 Sekunden, um mit Basic++ auf einem PIII mit 600 MHz übersetzt zu werden. Der blaue Balken läuft in 25 Sekunden bis 100%, nach weiteren 10 Sekunden wird der Balken grau und nach insgesamt rund 60 Sekunden erscheint die Statusmeldung. Das konnte ich wie gesagt stark verkürzen. Das Nadelör bildet eh der Upload zum Controller. Da macht es keinen Unterschied, ob ich (jetzt) eine halbe Sekunde länger oder kürzer kompiliere. Übrigens hab ich bisher von BASIC++ Benutzern keine Kritik diesbezüglich bekommen. Mal was ganz anderes: Auch mBasic scheint Probleme mit dem von Dir gegebenen Code Beispiel gehabt zu haben. Dort hat die Kompilierung ähnlich lange gedauert. Versuch also jetzt nicht auch noch das Bild einer (alte) BASIC++ Version zu verzerren. Ich fahre fort: > Zum Vergleich: CCBASIC für DOS benötigt rund 0,16 Sekunden und das neue Open-Control/BASIC (siehe Infoside für Betatester zum OM-Projekt) kommt auf 0,32 Sekunden. Beim viermal größeren Sourcecode (32000 erzeugte Token) liegt OCBAS mit 1,2 Sekunden sogar leicht vor CCBASBIG. übrigens würde ich mich noch auf Deine Liste von BASIC++ Bugs freuen. Ich habe gehört Du würdest mir eine solche Liste verheimlichen. Gutgläubig wie ich bin geh ich aber selbstverständlich davon aus, das Gerücht würde nicht stimmen. > Damit hat Stefan wohl recht. Aber die FAQ ist in diesen Punkten nicht falsch, sondern veraltet. Immerhin liegt das letzte Update schon über ein Jahr zurück. Erst drei Monate später wurde BASIC++ zur offiziellen Sprache der "neuen" C-Control bestimmt. Und wie Stefan eigentlich feststellen sollte (aber halt: auf dem Auge ist er ja blind) steht in der FAQ auch noch nichts über die B-Control, die Open-Micro und die Open-Mini. (Vorweg: Ich verdiene kein Geld mit der 2.0 oder Micro). In Deiner FAQ steht zur 2.0 und Micro: "Aus den genannten Gründen muß ich derzeit vom Kauf dieser Kontroller abraten." (Vorsicht: Meinungsmache!). Als Gründe zählst Du u.a. das fehlen von Assembler auf. Außerdem sei die Unit nur von CCBasic programmierbar. Ersteres ist veraltet, letzteres ist falsch, da Du schreibst die 1.1 wäre in BASIC++ und mBasic programmierbar (also gab es diese Dialekte schon, desweiteren gab es zu dem Zeitpunkt schon seit langem z.B. die Extened Objekte in BASIC++). > Darüber sollte Stefan froh sein. Wieso? Es gibt bei der M Unit einen Controller, wo kein Update möglich ist: 2.01. Bei der Micro ist es die 2.00. Auf der Webseite steht alle anderen Controller wären updatefähig. Bisher gab es sogar schon ein Update. Im Zuge der Updates wurden nicht nur Bugs entfernt, sondern auch viele neue Features eingebaut (z.B. das Config 2 Register, Poiter, Timer Interrupt). Die neuen Features haben Entwicklungskosten verursacht, die sich bei der 2.02 nicht durch einen höheren Endkundenpreis bemerkbar gemacht haben. Bei der 2.03 sind die Features sogar für lau implementiert worden. Dafür hat es zwei Updates gebraucht (bei der M Unit). Alternativen werden deutlich beschrieben. Ich bezeichne anders als Du den von mir verwendeten Controller nicht als Bugfrei (wofür die OpenControl nebenbei deutlich mehr Updates brauchte). Gruß, Stefan Meine Homepage: http://www.fdos.de |
| Antwort schreiben |