Tag an alle, was haltet ihr von der Idee, von allen bekannten µP-/µC-Familien die besten Eigenschaften in einem CPLD bzw. FPGA zusammenzukloppen? Bitte sagt jetzt nicht, es sei zu viel Aufwand, würde zu Lange dauern,... Dies ist kein reeller Plan, nur eine Idee;-}
Schon die Diskussion über "die besten Eigenschaften" dürfte dazu führen, dass sich nicht die FPGAs sondern die Beteiligten kloppen.
Sorry aber besonders realistisch und besonders sinnvoll ist das wirklich nicht als Projekt fuer eine Einzelperson.
Mann könnte fast sagen dass das die dümmste Idee aller Zeiten ist! Wenn das jetzt nur so eine Idee wäre, dann wäre das cool, aber du willst es ja unbedingt als reeles Projekt machen. nenenenenenenenenenenenenenenenen phfvorrum
Dein Ansatz ist eigentlich schon ziemlich falsch. Mit einem CPLD bzw. FPGA könntest Du höchstens die rein digitalen Teile des Mikrocontrollers wie CPU, Timer, I/O's, BUS, IRQ-Logik ... abdecken. Einen beachtlichen Teil nehmen jedoch auch noch ein: Speicher (insbesondere Flash), Oszillatorschaltung, AD Wandler, Spannungsüberwachung / Reset (meist ausgeklügelter als im FPGA, da häufiger für batteriebetriebene Geräte verwendet), Schmitt-Trigger Eingänge, interne Pull-Ups/Pull-Downs für I/O's, ... Wenn Du Dir einen hardwaremässigen Emulator für einen Mikrocontroller ansiehst, kannst Du den Aufwand in etwa abschätzen. Das Vorhaben wäre mit Sicherheit kein Hobbyprojekt.
so eine bessere "EierLegendeWollMilchSau" als die Megas ist durch Kreuzung von PIC + ARM erst in der F100 Generation zu erwarten! gez. Mendel
Huch, ganz schön viele Reaktionen. Ihr nehmt meinen Post viel zu ernst. Es war nur mal eine Idee, kein Plan oder sogar Projekt, schon gar nicht für eine Einzelperson. Nein, ich bin momentan durch Hobby, Ausbildung,... mit verschiedenen Controllerfamilien konfrontiert. Bei allen sehe ich Stärken und Schwächen. Da kam mir einfach mal so spontan die Idee, alle Stärken zu vereinen. Als Basis dafür fiel mir als estes eine programmierbare Logik ein. Obwohl, so ein Massengrab aus 74er Bausteinen wäre auch nicht schlecht, am besten noch in TTL. Dann freut sich auch das Netzteil;-)
>Da kam mir einfach mal so spontan die Idee, alle Stärken zu vereinen.
Da kommt mir doch spontan die Frage, welche Stärken Du meinst.
Mir käme die Idee, die Stärken von Bananen und Erdbeeren zu vereinen.
Insbesondere, wie man ein geschmackliche Abstimmung findet, daß die
Schnecken mitgegessen werden können.
Hallo, das ist in der Regel auch das Prinzip, wie das die Prozessorentwickler machen. Sie werfen alles raus, was schlecht ist und kombinieren das, was gut ist. Das Problem ist aber, man erkennt nicht auf anhieb, dass bestimmte Sachen nicht zusammenpassen. Wenn man dann alles, was schön aus sieht (die besten Eigenschaften) in einem Topf wirft, dann kommt schnell Mist raus. Man hat dann 100 verschieden Adressierungsmodelle und das Gesamtkonzept geht verloren. Am Ende ist man dann bei einer Art Hochsprachen (Bytecode)-Interpreter angekommen. Wenn man schon einen FPGA nimmt, kann man doch gleich einen dynamisch rekonfigurierbaren Kern machen, dessen Befehlssatz sich Softwareabhängig erweitern lässt oder auch umschalten. Ein Verbesserungsvorschlag wäre auch, die Codeeffizienz zu erhöhen. Die Wahrscheinlichkeit, dass ein bestimmter Befehl auftritt ist kontextabhängig, also davon welche Befehle vorher standen. Außerdem gibt es Befehle, die generell seltener auftreten. Nun kann man seltene Befehle einfach zu gunsten der häufigen schlechter gestalten (Länge, Rechenzeit). Um die Gesamte Codeffizienz zu erhöhen, muss man dann schon Befehlsgruppen bilden oder Codezuordnung dynamisch ändern, abhängig vom vorigen Befehl. Je Größer die gebildeten Befehlsgruppen sind, um so besser ist die Speichereffizienz. Nun muss man halt abwegen, will man lieber höchste Codeeffizienz oder einen bezahlbaren Compiler bzw. eine Chance das in Assembler zu programmieren und schon beißt sich die Schlange in den Schwanz...
MC wrote: > Huch, ganz schön viele Reaktionen. > Ihr nehmt meinen Post viel zu ernst. Es war nur mal eine Idee, kein Plan > oder sogar Projekt, schon gar nicht für eine Einzelperson. Das heißt wir sollen gar nicht antworten? ;)
> Mir käme die Idee, die Stärken von Bananen und Erdbeeren zu vereinen. nennt sich Erdbeer Banana Daiquiri >Insbesondere, wie man ein geschmackliche Abstimmung findet, daß die >Schnecken mitgegessen werden können. Macht man mit einem großen Schuss Rum ;)
Aber einem ganz großen!!! Ach übrigens, schau mal im Supermarkt, Müller &Co haben seit neusestem diese komischen Frucht-Softdrinks. Im Prinzip sind das zermatschte Früchte (also Erdbeeren und Bananen) und haufenweise Zucker (sozusagen als Rum-Ersatz).
Das geht schon aus einem einfachen Grund nicht: Praktisch alle
Eigenschaften sind in Zielkonflikte verwickelt. Daher müsste man
zunächst mal entscheiden, auf welche Ziele man Wert legt. Genau hier
liegt dann der Hund begraben, warum es eben viele verschiedene
Prozessor-Familien mit unterschiedlichen Vor- und Nachteilen gibt.
> Mann könnte fast sagen dass das die dümmste Idee aller Zeiten ist!
Da findet man ganz bestimmt dümmere :-)
>> Mann könnte fast sagen dass das die dümmste Idee aller Zeiten ist!
Nein Nein Nein
wenn der Proz. für Deine (allg.) Anwendung schneller (leistungsfähiger)
ist und alle "IHN" brauchen werden wir sehr schnell Dein Ausgaben
refinanzieren.
Fred
Angenommen wird alles, die Frage ist nur, wann die Ergebnisse kommen (wie schon gesagt, nur eine Idee, kein Plan/Projekt). Also meine Kontonummer ist .... ;-) Über finanzielle Unterstützung der MC'schen Mikrocontrollerschmiede würde ich mich sehr freuen.
wunsch @ Matthias Lipinsky 64-Bit Risk CPU mit 1GHz getaktet (256 IO's) zum Preis von 10€ :) Carsten
Muss es denn funktionieren, oder darf's auch vom Laster gefallen sein?
Also ich find die Idee super. Die Datenbreite waere dann variabel, resp koennte als Optimierungsparameter verwendet werden. Wenn man zB 120 register braucht und dann noch 120 byte RAM, dann genuegt ein Byte zur Adressierung. Und wenn man nur 27 Befehle braucht, so sind die mit 5 Bit decodiert.
>Also ich find die Idee super. Die Datenbreite waere dann variabel, resp >koennte als Optimierungsparameter verwendet werden. Wenn man zB 120 >register braucht und dann noch 120 byte RAM, dann genuegt ein Byte zur >Adressierung. Und wenn man nur 27 Befehle braucht, so sind die mit 5 Bit >decodiert. Das wärs. Und Interessant wäre wenn du zusätzlich einen compiler entwickelst, der abhängig von den benötigten Ressourcen denn Prozessorkern synthetisiert und eben auch ein Programm. Der Compiler synthetisiert sich den Prozessorkern... Wird vermutlich sehr aufwendig;)
Die vielzitierte Eierlegende Wollmilchsau. Oink, Oink. An deren Züchtung scgin Gnerationen von Ings gescheitert sind. Was aber BWLer nicht daran hindert, permanent auf deren Entwicklung zu drängen. ;-) Falk
>BWLer ... permanent auf deren Entwicklung zu drängen.
Wieso Entwicklung? Verwendung reicht doch
@ Matthias Lipinsky (lippy) >>BWLer ... permanent auf deren Entwicklung zu drängen. >Wieso Entwicklung? Verwendung reicht doch Bezugsquelle?
>Bezugsquelle?
Das wüsste ich selbst gern.
Wenn es eine geben würde, wäre diese wohl zu teuer.
Vom Preis her könnte es die "eierlegende Wollmilchsau" bei Conrad geben. Owohl, eher doch nicht, da Conrad ja ne Apotheke ist: sehr teuer und nichts auf Lager
Eine schöne Projektidee wäre, den Prozessorkern zu entwickeln, der am wenigsten Gatter in einem CPLD braucht. Also: Was ist die kleinstmögliche Anzahl Gatter, die man braucht, um einen Prozessor zu realisieren? Wie sieht ein sehr einfacher Kern aus? Was braucht man? - Programmzähler - Arbeitsregister - Alu weiter ?
@MC: Daß die Idee, eine eierlegende Wollmilchsau zu erschaffen, eine ziemlich dumme Idee ist, ist bereits gesagt worden, aber ein Hauptgrund ist noch nicht genannt worden: Die Zielanwendung. Mach mal deine eierlegende Wollmilchsau und versuch dann damit z.B. einen Sat-Antennenschalter zu realisieren. Der ganze Schalter darf im Laden aber nur 10 Euro kosten. (4 LNB, einen Ausgang). Die Lösung im Schalter, der bei mir im Einsatz ist: ATTiny11. Ein ganz kleiner AVR, der im Bastlerversand gerade 65 cent kostet. 10000er Preis wahrscheinlich weit darunter. Jede Menge von den Dingen, die du vielleicht in deine Wollmilchsau integrieren willst, werden möglicherweise garnicht gebraucht. Es hat schon seinen Grund, warum z.B. Atmel in seiner AVR 8-Bit-Serie an die 40 Typen hat. So kann man sich den Controller aussuchen, der den besten Kompromiss aus Preis, Ausstattung und Leistung darstellt. Also gilt auch hier: Pflichtenheft für das zu erstellende Gerät erstellen und dann den passenden Controller auswählen. DEN Universalcontroller kann es deshalb schon garnicht geben. Allen BWLern zum Trotz. Gruß Jadeclaw.
Stichworte: -Turingmaschine Da reichen glaube ich 3 Zustände aus, hab ich mal irgendwann in der CT gelesen. Nur schnell ist das ganze nicht, man kann nicht alles haben immer nur einen Teil ;) -Brainf??k (da gibt es auch C-compiler für :) einen Brainf??k interpreter ist schnell geschrieben. (Nein ich werde es nicht machen :)
Ein wenig komplexer als eine Turingmaschine darf es schon sein. Eine Mindesanforderung wäre: - 8 Bit Addition - call & ret Ok, das ganze könnte man als Bit-Slice Prozessor realisieren. Nehmen wir mal an, das CPLD ist recht schnell und der Prozessor soll nur dazu dienen, langsame Kontrollaufgaben durchzuführen.
...dann nimm nen AVR ! ganz vergessen? der ist genau so entstanden: 2 studenten überlegten, was wäre optimal, was kann real mit so wenig gattern gebaut werden, dass es in nen fpga geht und testbar ist, welchen befehlssatz braucht man, damit alle zufrieden sind, asm + compiler.. usw. ergebnis war die at1200 , später dann die aufgebohrten mega usw. also genau das, was du (MC) machen willst. andere teams hatten komplexere 32-bit-vorstellungen, deren optimierte designs zb als dievrse arm-versionen zu sehen sind.. was genau willste nu neu+besser+billiger machen ????
eine Lebensweisheit: Alles Gute ist nie beisammen! gilt für uCs, Frauen, ... was Du willst.
>eine Lebensweisheit: Alles Gute ist nie beisammen! >gilt für uCs, Frauen, ... was Du willst. wo du recht hast...
>...dann nimm nen AVR ! >ganz vergessen? der ist genau so entstanden: >2 studenten überlegten, was wäre optimal, optimal nach ihren Vorstellungen... >Eine schöne Projektidee wäre, den Prozessorkern zu entwickeln, der am >wenigsten Gatter in einem CPLD braucht. sag ich doch die ganze Zeit
Düsentrieb wrote: > andere teams hatten komplexere 32-bit-vorstellungen, deren optimierte > designs zb als dievrse arm-versionen zu sehen sind.. Naja, der Prozessorkern entstammt einem Universalcomputer, der eigentlich mal (nach der Vorstellung der Gründer) hätte den IBM-PC ablösen sollen (Acorn RISC). Das hat nicht geklappt, aber weil der Prozessor selbst recht genial war, haben sie daraufhin das Design an andere lizensiert, und irgendwann haben dann diverse Hersteller ihre Peripherie herum gestapelt, um auch Microcontroller draus zu zimmern.
>Warum nicht mal einen weiblichen uC entwickeln?
ja, das isses doch:
+macht spontan völlig unlogische entscheidungen
+kennt die "wenn-aber-dann-doch-vielleicht" verknüpfung
+hat gelegentlich seine tage...
Was habt ihr gegen die Idee? Natürlich kann man nach seinem Geschmack locker einen µC in einem FPGA implementieren. Schwieriger wird es jedoch dafür einen passenden Compiler zu Entwickeln ;)
>Warum nicht mal einen weiblichen uC entwickeln?
großer Vorteil wäre die sehr einfache Produzierung von weiteren
Derivaten!!!
Durch die Vermischung der Eigenschaften der beiden Partner + die
Evolution bekommt man bestimmt spannende Derivate. Am besten wirds dann,
wenn die Dinger in die Pubertät kommen.
Eine Idee zu blockieren weil zu schwierig ist - veraltet. Geh auf den Baum zurueck. Ich denke auch ein Compiler sollte den Kern syntetisieren koennen. Wenn sich ein Problem auf einen Vorwahlzaehler mit 2 selektierbaren Vorwahlen reduzieren laesst, brauch ich den Rest nicht.
>> Warum nicht mal einen weiblichen uC entwickeln? > großer Vorteil wäre die sehr einfache Produzierung von weiteren > Derivaten!!! > +macht spontan völlig unlogische entscheidungen > +kennt die "wenn-aber-dann-doch-vielleicht" verknüpfung > +hat gelegentlich seine tage. Den zu debuggen wird bestimmt lustig ;-)
fpga... das kann jeder aber: http://www.cc86.org/~dkuschel/index2.htm und noch ein OS dazu, das ist hardcore... http://www.cc86.org/~dkuschel/index2.htm gruß, w.
Mensch, danke für den Link. Die Seite kenn ich zwar schon seit einigen Jahren, aber ich hab den Link nicht mehr gefunden.
Sowas gibt es doch schon. Zb. von Altera den Nios2, da kann man die Busbreiten festlegen, den RAM und den Controller (zB. internes RAM, SRAM oder SDRAM), und was einem sonst noch so einfällt (Zusatzhardware, selbstentwickelt oder fertig, 100 Timer oder 30 PWM Kanäle, usw.). Und es gibt sogar einen Compiler dazu (gcc portierung), den man mit dem CPU Design füttern und der einem dann Code generiert (C/C++). Ein wirklicher Durchbruch ist das Ding aber nicht. Und auf den kleinsten FPGA passt das Ding natürlich auch nicht, die kleinste Variante liegt so im Bereich um 2k Logikzellen auf Altera FPGAs. Das einzige was man wirklich verbessern könnte sind die Entwicklungswerkzeuge.
@ Johnny (Gast)
>Warum nicht mal einen weiblichen uC entwickeln?
Mit Fuzzy Logic . . .
Ein 8Bit-µC mit 32Bit Opcode ist etwas übertrieben, oder? Ich weiß, dass die AVRs 16Bit Opcode haben. Die PICs variieren von 12 bis glaub ich 24Bit (bei den 8Bittern).
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.