| Re: Darf man Prozessorports mit einem Stecker verbinden ? Kategorie: Verschiedenes (von Alex - 19.09.2006 19:04) | ||
| Als Antwort auf Re: Darf man Prozessorports mit einem Stecker verbinden ? von André H. - 19.09.2006 11:52 | ||
| ||
|
Hallo André und Michi, erstmal danke für eure Antworten! Unter dem Stichwort Robby hab ich die CC2 dann doch gefunden, thx!!! Allerdings ist das schlechtes Marketing bei Conrad, dass so klein und ohne Zusammenhang in den Katalog zu quetschen.... Naja^^ Dank eurer Ausführungen werde ich die CC2 auch weiterhin einsetzen, allein wegen dem Support hier und denn vielen geilen^^ und sinvollen Erweiterungen von CCTools nebst Funktionsammlungen! Dank an Andre mal an dieser Stelle, der sich bestimmt nen Haufen Stress deswegen macht hier! Die CC1 allerdings (in der Urfom), hab ich so nicht mehr im Katalog gefunden. Aber ich werde trotzdem eine davon im INet beim C bestellen und dann in einen Projekt als Datenlogger einstetzen^^ Denn erstens finde ich das Application Board der CC1besser, als das neue für die M-Unit 2.0. Und zweitens brauch ich dann keine extra Schnittstellenplatine für das Auslesen des Datenloggers^^ Aber Danke! Auch an die Community hier! > Hallo Michi, > > Ein Teil der Antworten findest Du in meiner Antwort für Alex. > > > Eigentlich mü�te man seröserweise zwei Dinge zukunftssicher machen: > > (Man denke daran, da� eine C-Control Steuerung auch noch in mehr als 20 Jahren laufen kann- > > eine sogar "kurze" Zeit für Steuerungen - sehen wir uns einmal Heizungen an oder Hausschaltkästen, > > meistens ist alles mindestens 30 Jahre alt) > > Naja, über 20 Jahre würde man nicht schaffen. > Schonmal versucht für eine 20 Jahre alte Heizung eine Ersatzregelung zu bekommen? ;-) > Hier mu� meist ein Universalregler her, der optisch natürlich nicht zu alten Heizung passt. ;-) > > > * Erstens eine Entwicklungsumgebung auf (weit ?) mehr als ein Jahrzehnt lauffähig erhalten. > > Keine einfache Aufgabe, wenn es in einem Jahrzehnt keinen Windows PC mehr geben wird, wie wir ihn > > derzeit kennen. Eigentlich bleibt einem nichts anderes, als einen PC zu versteinern, auf dem noch die > > Entwicklungsumgebung läuft, bevor die heutigen Windowser endgültig XPired sind. > > Ich glaube kaum, da� sich künftigen Windoofsversionen "weigern" werden, > 32Bit-Anwendungen auszuführen. > Sie werden zwar nicht optimal laufen, was aber bei einer IDE eher ohne Belang ist. > (In Bezug auf Kompilier und Ladezeiten) > > Und für den Fall, da� Billy-the-Kid-Gates Windows irgendwann vom Markt gefegt werden sollte. > Gibt es einerseits solche netten Dinge, wie VMware, andererseits entwickeln viele > bereits an kompatiblen Alternativen, wie ReactOS. > Und im Zweifelsfall haben die meisten noch einen alten Rechner rumstehen. ;-) > Aber, BTW, selbst Win98SE läuft problemlos auf einem AthonXP3400+. > Es gibt sogar ein inoffizielles SP zu Win98SE, was ich jedem Win98SE-Nutzer nahelegen kann. > (Die Win98SE Fan-Gemeinde ist grö�er, als man denkt. ;-) ) > > > > * Zweitens den Nachschub an CC2 aufrecht erhalten. Das geht in kleinem Ma� vielleicht über > > Gebrauchtverkäufe. > > Kann ich nur verneinen. Nur wenige, die eine CC2 haben, geben diese freiwillig wieder her. *grins* > > > Ein viel attraktiverer Weg wäre, eine kompatible aber etwas leistungsgesteigerte CC2 in Serie > > gehen zu lassen. Das wäre wohl erst sinnvoll, wenn Conrad die Lieferung einstellt. Rechtlich kann > > es eigentlich kein Problem sein (das wäre aber natürlich zu prüfen), da die Schaltung eigentlich nur die > > Ports des Prozessors hinausführt, und Speicher anschlie�t. > > Mit einem Stecker verdrahtete Ports sind wohl eher nicht schützenswert. > > In diese Richtung geht mein Notfallplan in der Schublade. > Hardwaretechnisch hätte man rechtlich nichts zu befürchten. > Jedoch seitens der Software schon. Denn die IDE samt Compiler, sowie die Rechte > am OS liegen weiterhin bei Conrad. Auch betrifft das die OSOPT-Reihe, da diese > nur geänderte original-OS-Versionen sind. D.h. der Löwenanteil bleibt original. > Und Optimierungen aller Routinen ändert daran nichts. Nur ein komplettes Neuschreiben, > ohne dem original-OS als Vorlage, würde das ändern. > Dann wären da aber noch der Compiler und die IDE. Diese mü�ten auch komplett neugeschrieben > werden. Dann wäre man rechtlich aus dem Schneider. > > > Wenn Conrad kein Interesse mehr an der CC2 hat, könnte man ja durchaus friedlich zusammenleben > > oder sogar Geschäfte miteinanden machen. > > Ich hatte schonmal vorsichtig angefragt, in welcher Gegend der Preis für die Rechte > der CC2 lägen. Das wäre dann irgendwo im 6-stelligen Bereich. > Daher strebe ich hier auf jeden Fall zuerst eine Zusammenarbeit mit Conrad an, > bevor ich eigene Wege gehe, und ein C164CI, XC164 oder gar XC167-Controllerboard herstelle. > > > > Vielleicht finden sich vor Ableben der CC2 ein paar beherzte, die eine kompatible CC2 designen ? > > Ohne jetzt genau die Technik zu analysieren, könnte ich mir vorstellen, da� z.B. ein C167 schneller > > aber kompatibel sein könnte. Was ist mit dem TriCore, der angeblich �hnlichkeiten mit der C16x > > Serie hat ? > > Wenn es ein komplettes Redesign der CC2 geben sollte, > dann kommen Controller der XC166-Serie in Betracht. > Aber soweit ist es noch nicht. > Für ein solches Redesign würde locker ein Jahr draufgehen.(Wenn nicht mehr) > Ich würde vorerst nur ein kleines kostengünstiges Redesign anstreben, > damit man genug Zeit für eine Weiterentwicklung hat. > Das würde hei�en: Weiterhin den C164CI, jedoch ein Herausführen des Daten/Adressbusses > für "feine" Erweiterungen mit vollem Bustakt. ;-) > Denn die jetzige CC2 ist für 16 Segmente ausgelegt. Es sind davon aber nur 9 vorhanden. > Also bleiben noch 7 Segmente für Erweiterungen. > Weiterhin müsste die IDE um ein paar Funktionen erweitert werden. > > Ach ja, da viele immer wieder meinen "go to ATMega": > Die C166-Serie und nachfolgende haben ebenfalls eine RISC-Architektur. > Allerdings mit dem Unterschied, da� es keine seperaten Busse für Befehle und Daten gibt, und somit > extern haufenweise Speicher angeschlossen werden kann. (RAM/FLASH/EEProm) > Der C164CI hat beispielsweise eine 4-Stage-Pipeline, was optimierten Code schön schnell macht. ;-) > Die XC166er-Serie hat sogar eine 5-Stage-Pipeline. > > MfG André H. > | ||
Antwort schreiben Antworten: | ||