Ich hab grade ein nettes Video zum Propeller Mikrocontroller von Parallax gefunden. Wirkt zwar fast wie ein Werbevideo, zeigt aber einiges von der Leistungsfähigkeit dieses Microcontrollers : http://video.google.de/videoplay?docid=-8066179290369662383&q=parallax+propeller&total=22&start=0&num=10&so=0&type=search&plindex=3
Damit der Thread überhaupt noch sinnvoll wird, möchte ich mich dem Thema gleich mit einer Frage anschließen. Hat jemand damit schonmal gerarbeitet und kann davon was berichten? Ich hatte mich da mal eingelesen, war aber von dem Ding nicht besonders begeistert. Schien mir eher so, als wär das ganze Propeller-Konzept ein Workaround für die ultra-langsamen RISC-Prozessoren die sie da verwendet haben. Wenn ich mich richtig erinnere, gibts eine eigene - mit nix kompatible - Programmiersprache die interpretiert wird, oder man kann direkt in Assembler programmieren und trotzdem ist ein Core langsamer als ein PIC. So toll fand ich das alles nicht ... Ich hab mir das Video nicht angeschaut, aber die haben vermutlich wieder ihre BruteForce Video-Erzeugung angepriesen ... Gibts da andere Meinungen, die mich davon überzeugen können, dass die Dinger doch nicht so uninteressant sind wie ich glaube? :-) Mfg Thomas Pototschnig
Ich vermute, die sind darauf optimiert, damit ne Propeller-Clock zu bauen :) Peter
> Wie war noch die Frage ?
Welche Frage? Oder unterliegst du dem Irrglauben, man dürfe hier nur
Fragen posten?
>aber die haben vermutlich wieder ihre BruteForce >Video-Erzeugung angepriesen .. Das Video ist von Rolf Dieter Klein, der Name dürfte einigen bekannt sein, und nicht von Parallax. Ausserdem ist dass kein Bruteforce. Der Propeller hat in jeder der acht COGs schon die Basishardware für Videoerzeugung in Farbe und bunt :-) Sogar ein HF-Signal zum direkten einspeisen in den Antenneneingang kann erzeugt werden. Das Videosignal wird zwar dann softwaregesteuert erzeugt, aber das bringt ja erst die Flexibilität. > und trotzdem ist ein Core langsamer als ein PIC. Jeder COG hat 20 Mips bei 80 MHz. Wenn man vier COGs um einen Takt versetzt auf die I/Os loslässt, kann man bis zu 80 MHz I/O geschwindigkeit realisieren. Die COGs können sich gegenseitig steuern und synchronisieren. Dadurch ist die Rechenleistung in gewissen Grenzen skalierbar. Andreas
Übrigens ist das Nachfolgemodell bereits in Arbeit. Die Spezifikationen sind vielversprechend : 16 CPU Kerne mit einem Befehl pro Takt ! We are doing the mask layout now. We hope to run a test chip within several months. Roughly, here is what we are making: 16 cogs (single-clock instructions), 256KB RAM, 128KB ROM, with 8-contiguous-long accesses per hub read/write. We've got to get this version done, then later we can add analog functions to I/O pins The cogs still have 512 longs of RAM. No nice way to increase that. With 8-long read/writes, though, and the large-model paradigm, this 512-long limit will be less of an issue than with the current chip. With 16 cogs and a full-speed hub (not half-speed, like we have now), each cog will get hub access once every 16 clocks (16 instructions). To increase the main memory bandwidth, we will likely put 8 special long registers into each cog at maybe $1E8-$1EF which are read/write data conduits. This way, in your hub turn, you can read or write all 8 of these longs if you want. This will help large-model code and video apps, too. You can 'breathe' 8 times the main memory than a RDLONG/WRLONG instruction would allow. I'm pretty sure we're ahead of the BASIC Stamp curve, but things are still nascent in terms of potential. We have learned from three past experiences (selling PIC tools from 1990, selling BASIC Stamps from 1993, and selling SX tools from 1997) that it takes five whole years to get traction for a new product line. We are just over a year into this process with the Propeller now. We don't have any appreciable volume yet, though people are starting to make those inquiries. Our main metric of success, at this point, is seeing customers embrace it enthusiastically. This is the most satisfying phase of things, anyway.
>Also doch SPAM.
Dein geschreibsel schon. Kannst du ja in Zukunft weglassen.
Ich fand vor allem den letzten Beitrag interessant ...
Mfg
Thomas Pototschnig
Also für diese "gigantische" Grafik braucht man nicht 8x80 MHz.. das geht auch mit ner 1 MHz CPU und einem getrennten Grafikchip. (Siehe C64/A500, mit gekonnter Programmierung können die das auch) Ich finde es allgemein absurd jede Drecksarbeit in Software machen zu wollen.
Naja es hat schon was EINEN Chip zu haben den man dann irgendwann, vorwärts wie rückwärts auswendig kennt, und nicht erst wieder ein neues Datenblett braucht. Ausserdem wäre es besser dafür einen emulator zu schreiben, aus dem selben Grund.
>.. das geht auch mit ner 1 MHz CPU und einem getrennten Grafikchip.
...stimmt, aber es gibt heutzutage keine einfachen für den Hobbybastler
lötbaren Grafikcontroller, leider. Da finde ich den Propeller schon
super, einfach und flexibel. Ich würde die Videoerzeugung am liebsten
auch von einem ATmega machen lassen aber der ist einfach zu langsam um
vernünftige Auflösung und Refreshraten hinzubekommen. Ich sehe den
Propeller als Nischenprodukt an wo Videoausgabe gefordert wird und in
diesem Bereich braucht man ihn nicht schlecht reden. Einfach mal das
Demo vom Hydra Board auf der Propeller HP ansehen, wer mehr
Grafikleisung benötigt muß auf Pentium + Gforce umsteigen;)
> Also für diese "gigantische" Grafik braucht man nicht 8x80 MHz.. das > geht auch mit ner 1 MHz CPU und einem getrennten Grafikchip. (Siehe > C64/A500, mit gekonnter Programmierung können die das auch) Der kann dann halt auch nur exakt das, was in der Hardware fest verdrahtet ist. > Ich finde es allgemein absurd jede Drecksarbeit in Software machen zu > wollen. Ich nicht, denn dann kann man aus einer einzigen Hardware die verschiedensten Sachen rausholen, indem man einfach ein anderes Programm lädt.
>> Also für diese "gigantische" Grafik braucht man nicht 8x80 MHz.. das >> geht auch mit ner 1 MHz CPU und einem getrennten Grafikchip. (Siehe >> C64/A500, mit gekonnter Programmierung können die das auch) >Der kann dann halt auch nur exakt das, was in der Hardware fest >verdrahtet ist. Grafikchips sind im allgemeinen recht flexibel programmierbar, zumindest die die ich mir bisher angeschaut habe. >> Ich finde es allgemein absurd jede Drecksarbeit in Software machen zu >> wollen. >Ich nicht, denn dann kann man aus einer einzigen Hardware die >verschiedensten Sachen rausholen, indem man einfach ein anderes Programm >lädt. Es wiedert mich einfach an z.B. bei einem 20 MIPS Controller nen Großteil für ne Multiplexanzeige oder eine Videoausgabe zu verbraten... der Controller kann sinnvolleres tun, und was soll ein Grafikchip anderes machen als Grafik. Worauf ich mich einlassen würde wäre ein Microcontroller mit integriertem expliziten Grafikcontroller. (AVR32 hat sowas) Gruß, Christian
Wie u808 bereits erwähnte ist der Propeller, in der derzeitige Version, ein Nischenprodukt. Diese Nische füllt er aber perfekt aus. Flotte animierte Farbgrafik aus einer mal mal eben auf dem Steckbrett aufgebauten Schaltung geht halt nicht mit einem AVR32. Da muuss ein teures DevKit her. Mit dem Propeller benötigt man im einfachsten Fall einem Quarz ,3,3V, 3 Widerständen und einem Pegelwandler nach RS232.
> Es wiedert mich einfach an z.B. bei einem 20 MIPS Controller nen
8 x 20 Mips
Es sind 8 CPUs, du verbrätst nur die Rechenleistung von einer oder
zwei CPUs davon. Bleiben immer noch 120-140 MIPS
Ich hab mir die Demo angeschaut.. tut mir leid, das ist für die genannte Rechenleistung einfach nur erbärmlich. C64 --> 6502, 1 MHz, Grafikchip, Soundchip: http://www.youtube.com/watch?v=jXeMtKrqtFY Gruß, Christian
meine 2cent aus dem Off: > Bleiben immer noch 120-140 MIPS ...wenn man bei Assembler bleibt... ich zitiere mal Wikipedia: >the proprietary interpreted Spin programming language executes approximately >80,000 instruction-tokens per second on each core 80.000 pro Sekunde bei 80 MHz - das macht dann 1000 Takte pro "high level instruction". Autsch ! Mit diesem "Spin" kann man also wunderbar Rechenzeit vernichten. ...für eine sinnvolle Performancenutzung muß also Assembler her - was in meinen Augen auf einer Multicore-Architektur eine Zumutung und unzeitgemäß ist. TexasInstrument hat seinen MSP430 (als aktuelles Architekturbeispiel) auch auf die Benutzung von Hochsprachen hin entworfen - und dieser ist nun wirklich leichter zu handhaben als 8 "COGs".
Kinnnnnners, muss denn alles in der Luft zerrissen werden, was man selber nicht verwenden kann? Gruss: Z
>muss denn alles in der Luft zerrissen werden, was man selber nicht >verwenden kann? Was genau stört Dich an sachlichen Argumenten im Rahmen einer Diskussion ?
>muss denn alles in der Luft zerrissen werden, was man selber nicht >verwenden kann? Ein Controller mit Grafik und Sound in DIL40 IST interessant.. nur die Ausführung taugt nicht wirklich was. Gruß, Christian
Hallo Antworter, neben diesem Thread verfolge auch einige andere zu diesem Thema. Grundton: Propeller ist schlecht, schlecht und nochmals schlecht. Da werden Vergleiche gezogen, die mit sachlicher Argumentation nichts mehr gemein haben. Irgendwie werde ich das Gefühl nicht los, dass einige "Erleuchtete" die alles über uC wissen zu glauben nicht gewillt sind etwas dazuzulernen. Die meisten Argumente gegen d. Propeller kommen von Leuten vermutlich, die weder damit gearbeitet haben noch je einen Multicore (einen echten Multicore) programmiert haben. zu deinen sachlichen Argumenten: > ...wenn man bei Assembler bleibt... ich zitiere mal Wikipedia: >>the proprietary interpreted Spin programming language executes approximately >>80,000 instruction-tokens per second on each core > 80.000 pro Sekunde bei 80 MHz - das macht dann 1000 Takte pro "high > level instruction". Autsch ! > Mit diesem "Spin" kann man also wunderbar Rechenzeit vernichten. > ...für eine sinnvolle Performancenutzung muß also Assembler her - was in > meinen Augen auf einer Multicore-Architektur eine Zumutung und > unzeitgemäß ist. Definiere mal bitte "Sinnvoll" oder - besser - schaue mal die Befehlsliste an. Es dürfte klar werden, dass einige Befehle doch recht mächtig sind. Spin ist noch recht neu. Ich bin mir ziemlich sicher, dass der von den ersten C-compilern erzeugte Code auch nicht effizienter war. --> Also ist bei Spin Besserung zu erwarten. Multicore in asm zu proggen ist "eine Zumutung und unzeitgemäß" schreibst du - aha. Versuchs mal. Ich kann dir versichern, dass du überrascht sein wirst, vorausgesetzt a) du bist ein halbwegs fähiger Programmierer und b) du hast das Prinzip Multicore verstanden. Es ist ein Irrglaube, dass Multicore schwer zu verstehen ist. Es ist halt nur nicht mit "normaler" AVR oder PIC - Programmierung vergleichbar und erfordert deshalb eine Gewisse Bereitschaft zum Umdenken bzw. Lernen. Dies ist ja z.B. bei OOP auch nicht anders gewesen und geklappt hat es ja bei den meisten. Wem OOP zu neu ist, der kann sich auch sicherlich daran erinnern, als d. erste Licht aufging "aaaa, so funktioniert ein Pointer"..."aaaaaa, dazu ist also "struct" gut"... Beispiele gibt es genug. Kleines Beispiel: du hast in einer Applikation 4-5 Zeitkritische Aufgaben. Soetwas kommt in jedem größeren Projekt / Roboter etc. vor. Vorgehensweise traditionell: Immer komplexere Programmierung mit Interrupts, die nie Zeitgleich ausgeführt werden können. Wenn gleichzeitig 4-5 Interrupts kommen, dann muss man schon ein gewisses Level im Programmieren erreicht haben um diese vernünftig abarbeiten zu können. Der erzeugte Code wird definitiv nicht einfach zu verstehen sein. Weiter gehe ich darauf nicht ein, ich denke es ist klar worauf ich hinaus will. Interrupts vernünftig zu proggen erfordert ein recht hohes Maß an können und Erfahrung bzw. ein wie auch immer geartetes Betriebssystem. Vorgehensweise mit einer Multicore: Zeitkritische Aufgaben an einzelne Cog's verteilen. Geht mit wenigen Befehlen. Man hat absolut kein Stress mit Überschneidungen, Rechenzeitplanung etc. Den zeitunkritischen Rest programmiert man "normal", wie bei einem AVR/PIC auch. Die Welt "linear" auf einem uC Abzubilden finde ich - besonders für Anfänger- wesentlich Schwieriger, als einfach zu sagen: "Verteile deine Aufgaben auf einzelne Cog's und du bist einer Menge "Profi-Probleme" los." Weiter oben sah ich diesen Kommentar: > Ich hab mir die Demo angeschaut.. > > tut mir leid, das ist für die genannte Rechenleistung einfach nur > erbärmlich. > > C64 --> 6502, 1 MHz, Grafikchip, Soundchip: > http://www.youtube.com/watch?v=jXeMtKrqtFY :-) Ich bin mir sehr sicher, dass nach 20 Jahren mit der heutigen Propeller-HW wesentlich genialere Demos kommen. Wieder mal einen fähigen Programmierer vorausgesetzt. Aber davon wird es hier mehr als genug geben. Die Propeller sind noch recht neu und nicht fehlerfrei. Die ersten Atmels oder PICs waren es auch nicht. Aber so wie diese neue Features und Möglichkeiten boten, so ist auch der neue Propeller für neue Dinge gut. Man muss nur etwas kreativ sein und nicht nur mit seinem bisher erworbenen "Datenblattwissen" rumprahlen und dabei nur so weit kommen wie es unter "Application Notes" steht. Die Frage sollte daher statt "Ist der Propeller schlecht?" eher heissen "was kann ich mit diesem neuen Chip Neues machen?" Bin auf Vorschläge gespannt :-) Gruss: Z
@Zoltan R: Interessante Stellungnahme. Ich, 4ter Beitrag von oben, hatte vorher schon zugegeben, dass ich mit den Propellern noch nichts gemacht hab. Das liegt aber an mehreren Gründen: - ich lerne lieber Programmiersprachen und Controller-Architekturen, die sich mittlerweile etabliert haben. Bei C/C++ und ARM oder VHDL sehe ich die größten Zukunftsaussichten. - ich bin mit ARM7/9 und FPGA noch lang nicht an der Grenze um nach leistungsfähigeren Alternativen suchen zu müssen. - ich finde den Preis nicht so toll. Für 12EUR krieg ich schon fast 3* SAM7S64 Sind aber weiterhin alles subjektive Gründe. Das Problem ist, dass ich nicht weiß was ich mit dem Multi-Core-Propeller überhaupt anstellen soll. Mit ARM und FPGA hab ich alles was ich brauche und damit fahr ich bestens. Ich bin aber gespannt, ob es jemand schafft einen MP3-Decoder auf den Propeller zu implementieren. Wenn er 160Mips schaft, sollte das möglich sein. Meine ARM7 @48Mhz schaffens ja auch ;-) Wenn ich aber einen ARM mit >120Mips brauche, nehm ich einen Flashbasierten ARM9. Naja so oder so - ich brauch den Propeller nicht :-( Aber ich bin wirklich gespannt, was damit noch alles gebastelt wird! Mfg Thomas Pototschnig edit Und ich brauch auch die Propeller-"Grafikfähigkeit" nicht - mir ist die Auflösung und Farbtiefe nicht gut genug. Hab da mittlerweile was besseres in VHDL :-)
>- ich lerne lieber Programmiersprachen und Controller-Architekturen, >die sich mittlerweile etabliert haben. Das ist schön, allerdings bist du dann nicht sehr offen für Neues. Dich würde ich jedenfalls niemals als Entwickler einstellen, da du doch eher eine Innovationsbremse darstellst.
Hmmm, einen Propeller werd ich mir wohl mal zulegen, und zwar hierfür: http://forums.parallax.com/forums/default.aspx?f=25&m=197711 http://mydancebot.com/products/viewport/11/ Noch 4 74VHCT541 zum Pegelwandeln dran, ein 232-Mäxchen von TI, nen Quarz... Wenn die FPGA-Fraktion auch mal so was handliches hinkriegen täte ;-)
In mancher Hinsicht ist der Propeller eine Art FPGA für Leute die keine FPGAs mögen. Harte Echtzeitbedingungen im Submikrosekundenbereich sind normalerweise nur programmierbarer Logik zugänglich, nicht jedoch Controllern. Mit dem Propeller ist das anderes. Das eben gezeigte Beispiel passt da genauso rein wie die Erzeugung von Videosignalen. Die hässliche Seite liegt in der Programmierung. Dass Spin viel von dem wegnimmt, was die Hardware leistet, wurde schon genannt. Aber auch der Stil ist teilweise schaurig. Gängige Praxis bei der Parameter-Übergabe zwischen Spin und Assembler ist die Adresse eines Bündels von Variablen, die mehr oder weniger zufällig hintereinander im Speicher liegen. Und C oder Perl an kryptischer Formulierungskunst übertreffen zu wollen ist für mich kein Zeichen von Weisheit.
> Die hässliche Seite liegt in der Programmierung.
Ich bin kein Programmier-Profi, aber im Internet läßt sich für fast
jeden Prozessor/Controller ein freier C-Compiler finden ... da ist es
wohl nur eine Frage der Zeit, bis das auch für den Propeller verfügbar
sein wird?
hackklotz wrote: >>- ich lerne lieber Programmiersprachen und Controller-Architekturen, >>die sich mittlerweile etabliert haben. > > Das ist schön, allerdings bist du dann nicht sehr offen für Neues. Dich > würde ich jedenfalls niemals als Entwickler einstellen, da du doch eher > eine Innovationsbremse darstellst. Das seh ich anders. Ich bin in der lage schnell und effizient zu arbeiten. Wenns notwendig wird arbeite ich mich halt mal schnell in was neues ein. Man muss aber auch immer genau wissen, wofür man irgendetwas braucht, wie z.B. den Propeller. Es ist sicher nicht falsch Technik zu verwenden, die nicht gleich wieder in 2 Jahren ausstirbt. Wenn du einer bist, der von Woche zu Woche zu neuen unausgereiften Sachen hüpft, dann möchte ich bei dir auch garnicht arbeiten. Mfg Thomas Pototschnig
>Weiter oben sah ich diesen Kommentar: >> Ich hab mir die Demo angeschaut.. >> >> tut mir leid, das ist für die genannte Rechenleistung einfach nur >> erbärmlich. >> >> C64 --> 6502, 1 MHz, Grafikchip, Soundchip: >> http://www.youtube.com/watch?v=jXeMtKrqtFY >:-) Ich bin mir sehr sicher, dass nach 20 Jahren mit der heutigen >Propeller-HW wesentlich genialere Demos kommen. Wieder mal einen fähigen >Programmierer vorausgesetzt. Aber davon wird es hier mehr als genug >geben. >Die Propeller sind noch recht neu und nicht fehlerfrei. Tut mir leid, aber ein Multicore 8x20 MHz HAT EINFACH BESSER ZU SEIN ALS EIN C64 aus den 80ern. Und das gefälligst ab Markteinführung... bisher überzeugt mich nix von dem Ding.
Hi Christian, ich sehe schon, feine Ironie ist nicht ganz dein Ding :-) Deshalb mal anders formuliert: WORAN erkennst du, dass der Propeller schlechter ist ??? Du meinst nicht ernsthaft, dass du aus einer einfachen Demo auf die Leistungsfähigkeit schliessen kannst..... Gruss: Z
> Tut mir leid, aber ein Multicore 8x20 MHz HAT EINFACH BESSER ZU SEIN ALS EIN C64 aus den 80ern. Und das gefälligst ab Markteinführung... bisher überzeugt mich nix von dem Ding. Die Demos von denen ich mir bisher den Code in die IDE geladen habe, benutzten noch nicht ein mal die Hälfte der Cogs, also dürfte noch eine Menge Potential auszuschöpfen sein. Die bekannten C64 und Amiga Demos waren am Anfang auch nicht so beeindruckend ,die Coder mußten auch erst verstehen die Hardware effizient auszunutzen. Ich hätte mir gewünscht schon vor einem Jahr von dem Propeller erfahren zu haben. Ich hätte mir eine Menge Versuche für meine Haussteuerung und der dafür benötigten TFT Ansteuerung erspart. Vom Geode Board über FPGA und Atmel mit ISA Grafikkarte war alles dabei, dagegen ist der Propeller für mich die "Eierlegende Wollmilchsau". Stromsparend ,ausreichend schnell, VGA kompatibel, kaum Aussenbeschaltung, für diesen Zweck ideal.
>Deshalb mal anders formuliert: >WORAN erkennst du, dass der Propeller schlechter ist ??? Du meinst nicht >ernsthaft, dass du aus einer einfachen Demo auf die Leistungsfähigkeit >schliessen kannst..... Wenn ein Hersteller eine Demo veröffentlicht geh ich davon aus das er mir im eigenen Interesse die gesamte Leistungsfähigkeit zeigt... Außerdem erwarte ich von einem 8fach 20 MHz 32bit Multicore auch bei suboptimaler Programmierung bessere Ergebnis als von einer Einzel-CPU 8bit 1 MHz die etwa 30 Jahre alt ist. >Die Demos von denen ich mir bisher den Code in die IDE geladen habe, >benutzten noch nicht ein mal die Hälfte der Cogs, also dürfte noch eine >Menge Potential auszuschöpfen. Was ich den Devkits allerdings SEHR zu gute halten muss sind die gedruckten Handbücher. Ich HASSE PDFs. Weiterhin falls dieses Spin wirklich eine Interpretersprache ist.. WAS SOLL DER MIST? Interpreter sind für mich der Inbegriff von Leistungsverschwendung, weswegen ich z.B. auch die Sprache JAVA verachte. Wenn es aber unbedingt sein muss, schau ich mir das Teil bei Gelegenheit an, der Preis ist ja nicht übermäßig drastisch. Gruß, Christian
@Christian Erker: > Außerdem erwarte ich von einem 8fach 20 MHz 32bit Multicore auch bei > suboptimaler Programmierung bessere Ergebnis als von einer Einzel-CPU > 8bit 1 MHz die etwa 30 Jahre alt ist. Jetzt wirst du aber unfair. Wie schon ein paar Leute erwähnt hatten, hatte der C64 den VIC, den der Propeller nicht hat. Ich denke aber, dass der Propeller sogar in der Lage sein sollte den gesamten C64 mit allem drum und dran emulieren zu können. Der größte Vorteil am Propeller ist halt dann, dass man nicht mehrere Controller für verschiedene Aufgaben, wie SID, VIC, CIA usw, braucht sondern dass das alles ein Propeller kann - nur eben verschiedene COGs. Wie ich schonmal geschrieben habe, muss man nur wissen wofür man den Propeller braucht und das wäre ein Anwendungszweck für ihn. Die andere Alternativen sind entweder ein C64-On-A-Chip (ála C64DTV) in VHDL oder mit einem der schnelleren ARM. Aber für sowas würde sich der Propeller wirklich anbieten und wenn ich sowas vorhätte, wäre das der Grund mich da einzuarbeiten. Mfg Thomas Pototschnig
Was ist daran unfair? Was spricht dagegen sowas mit vielleicht nur 4 CPUs aber dafür Grafik, Sound usw. zu machen?
Der Propeller wurde nicht dafür designt, um Homecomputerprozessoren und deren zugerhörige Grafikchips zu ersetzen. Versuch doch mal, mit dem C64 eine Anwendung wie die http://mydancebot.com/products/viewport/11/ zu realisieren ...
Naja die Werbung suggeriert das als Spielemaschine... und nach den kriterien hab ich es beurteilt. Als Echtzeitmaschine mit graphischer Oberfläche wäre das aber durchaus interessnt!
Christian, bei allem Respekt, aber aus deinen bisherigen Kommentaren scheint es für mich so, dass du weder Erfahrung im professionellem Programmieren hast noch die Leistungsfähigkeit einer Hardware realistisch beurteilen kannst. Kein einziger deiner Kommentare trug etwas Sinnvolles zur Diskussion bei. Soll jetzt kein persönlicher Angriff sein, aber was du hier loslässt zeugt von nichts anderem. Lies dir doch mal BITTE in Ruhe d. Datenblatt vom Propeller durch und verstehe es. Hier findest du für den Anfang genug Material: http://www.parallax.com/propeller/downloads.asp Empfehlen kann ich dir auch ein gutes JAVA-Buch, da findest du auch einige für dich anscheinend fremde Konzepte. Das schöne daran: das dort gelernte kannst du auch im Bereich der uC´s nutzen (wenn auch nicht alles). Ausser dich beteiligt sich hier jeder mit fachlichen Beiträgen, es wäre mal Zeit dich dabei anzuschliessen. Man kann jede Meinung vertreten, aber dann sollte man auch in der Lage sein seine Meinung fachlich zu begründen und nicht irgendwelche Vergleiche ohne jede Grundlage heranziehen. Nichts für Ungut, aber wir sind alle erwachsene Menschen und sollten deshalb in der Lage sein uns auch so zu benehmen. Gruss: Z
ImageCraft has started development of the the ICCv7 for Propeller C STD compiler tools, scheduled to be released by the end of 2007. Das Ding ist schnell und bald auch in C zu programmieren, dann kann hier auch keiner mehr meckern.
>Nichts für Ungut, aber wir sind alle erwachsene Menschen und sollten >deshalb in der Lage sein uns auch so zu benehmen. Na was denn nun ? >Kinnnnnners, muss denn alles in der Luft zerrissen werden, (1) Mal im Ernst, ich stimme Christian zu großen Teilen zu. Vielleicht wurde der Propeller gerade durch die Konsolenjünger in ein komisches/unvorteilhaftes Licht gerückt - denn gerade in dem Bereich verschafft er dem Zuschauer 80er Jahre flashbacks. Von einem aktuellen Design wird nunmal ein "aha-Effekt" erwartet - und kein DejaVu... (2) Wenn Spin tatsächlich eine interpretierte Sprache ist, ziehe ich mit jeder Verteufelung mit und werfe die ersten 8 Steine (für jeden COG einen) <zwinker>
> Wenn Spin tatsächlich eine interpretierte Sprache ist,
Ist sie. Das ist aber nicht zwingend ein Problem. In vielen Fällen ist
nur ein kleiner Teil der Anwendung performancekritisch.
Propeller-Anwendungen/Module sind deshalb oft ein Mix aus Spin und
Assembler.
:-))))))))) zu 1, Der Aha-Effekt ist schon da, es setzt nur manchmal etwas später ein. Such dir doch mal eine ziemlich aufwendige AVR-Schaltung und implementiere es Testweise in Gedanken in einen Propeller. Du wirst erstaunt sein, was alles in den einen einzigen Chip reinpasst. Wie oben schon gesagt: die wirklich guten Sachen stehen nicht in AppNotes sondern entstehen meist bei der Lösung konkreter Probleme. zu 2, Ja, es ist eine interpretierte Sprache. (/ich ducke mich schon mal vor den Steinen) Wie aber in meinem Beitrag etwas weiter oben: asm ist eine wunderbare Sache, wenn manns kann. Andererseits: was ist an interpretierten Sprachen schlecht? Es beinhaltet sehr mächtige Befehle, die in asm einiges an Schweiss kosten würden. Anfänger kommen damit denke ich gut klar und erfahrene Leute werden asm vermutlich bis erscheinen eines C-Compilers eh vorziehen. Ohne jetzt in die Diskussion CISC oder RISC abzudriften wäre ich an einer Erklärung interessiert. Gruss: Z
>In vielen Fällen ist nur ein kleiner Teil der Anwendung performancekritisch. >Propeller-Anwendungen/Module sind deshalb oft ein Mix aus Spin und Assembler. Ist der Mix so einfach zu benutzen ? Interpretierte Sprache mit Assembler mixen hört sich für mich ziemlich außergewöhnlich an... Wie dem auch sei, für mich persönlich ist die Hemmschwelle bzgl. des Einarbeitungsaufwandes zu hoch (Spin und Propeller-ASM lernen) - da war der Umstieg von AVR auf ARM7 schon verlockender (beides gcc).
> Ist der Mix so einfach zu benutzen ? Interpretierte Sprache mit > Assembler mixen hört sich für mich ziemlich außergewöhnlich an... Wie schon erwährt: Die Parameterübergabe zwischen Spin und Assembler ist etwas unsauber gelöst. Dem liesse sich mit einer einfachen Spracherweiterung von Spin abhelfen (structs/records). Ansonsten hängt es starkt von der persönlichen Flexibilität ab. Wenn man schon etliche andere Assemblersprachen benutzt hat, ist das auch nicht weiter schwierig. Wenn's die Erste ist, dann wohl schon. > Wie dem auch sei, für mich persönlich ist die Hemmschwelle bzgl. des > Einarbeitungsaufwandes zu hoch (Spin und Propeller-ASM lernen) - da war > der Umstieg von AVR auf ARM7 schon verlockender (beides gcc). Propeller-ASM ist eher einfach zu programmieren.
> Andererseits: was ist an interpretierten Sprachen schlecht?
Für mich sind Mikrocontroller gerade deshalb interessant, weil man sich
auf diesen "optimierungstechnisch" austoben kann (Ramverbrauch,
Stromverbrauch, Geschwindigkeit etc.).
Mit interpretierten Sprachen bleibt hingegen immer ein großer Teil der
Performance und Resourcen auf der Strecke.
In meinen Augen war "C" immer die perfekte Lösung für etwas komplexere
Mikrocontroller, denn Dank der Hochspracheneigenschaften hat man recht
kompakte Quelltexte und aufgrund der Hardwarenähe ist eine Optimierung
gut möglich.
...trotz allem ist es interessant, was für Projekte die
Propeller-Fraktion so hervorbringt (außer dem Konsolenkram)...
> Ist der Mix so einfach zu benutzen ? Interpretierte Sprache mit > Assembler mixen hört sich für mich ziemlich außergewöhnlich an... Muss man im Kontext der Maschine sehen. Jeder der 8 Prozessoren kann entweder im globalen Speicher ein Spin-Programm ausführen, oder im lokalen Speicher Assembler-Code. Es handelt sich daber also genau genommen nicht um einen Spin/ASM-Mix, sondern um diverse korrespondierende Threads, die entweder in Spin oder in Assembler geschrieben sind. Ein Hintergund dieser Methode ist schlicht Flexibilität. Geräte wie die AVR,MSP430,PIC Controller haben stets eine mehr oder weniger grosse Sammlung von spezialisierten Funktionsmodulen. UART,SPI,I2C,ADC,Timer,... Der Propeller hat davon einzig ein paar passend ausgebaute Timer und ein bischen Schieberei für Video. Alles andere erledigt man, indem man einen Prozessor den entsprechenden Job gibt (z.B. ADC: Timer plus ein bischen externes Hühnerfutter ergibt einen einfachen Delta/Sigma-ADC). Kann gut sein, dass man damit sogar einen Lowspeed CAN-Controller per Software hinbekommt.
>Muss man im Kontext der Maschine sehen. Jeder der 8 Prozessoren kann >entweder im globalen Speicher ein Spin-Programm ausführen, oder im >lokalen Speicher Assembler-Code. Es handelt sich daber also genau >genommen nicht um einen Spin/ASM-Mix, sondern um diverse >korrespondierende Threads, die entweder in Spin oder in Assembler >geschrieben sind. >Ein Hintergund dieser Methode ist schlicht Flexibilität. Geräte wie die >AVR,MSP430,PIC Controller haben stets eine mehr oder weniger grosse >Sammlung von spezialisierten Funktionsmodulen. >UART,SPI,I2C,ADC,Timer,... >Der Propeller hat davon einzig ein paar passend ausgebaute Timer und ein >bischen Schieberei für Video. Alles andere erledigt man, indem man einen >Prozessor den entsprechenden Job gibt (z.B. ADC: Timer plus ein bischen >externes Hühnerfutter ergibt einen einfachen Delta/Sigma-ADC). Kann gut >sein, dass man damit sogar einen Lowspeed CAN-Controller per Software >hinbekommt. Ich habe mich ev. etwas blöd ausgedrückt, dass muss ich einwandfrei zugeben. Und vermutlich auch die Realität etwas hingebogen um meine Meinung zu untermauern ... tut mir leid. Ich kann mich eben einfach nicht mit solchen Lösungen anfreunden, ich hab lieber dezidierte Funktionseinheiten mit einzelnen Peripheriechips, oder meinetwegen auch einzelnen Controllern. Mir graust es einfach davor die Erzeugung eines Videosignals in Software zu lösen, ich kann das nicht wirklich begründen, es erscheint mir schlichtweg "pfuschig". Einem guten Grafikcontroller brauch ich nur zu initialiesieren auf Bildgröße, Auflösung, Wiederholrate etc. Dann kann ich entweder Bilder in den Speicher schreiben, oder eben auch Text- und Grafikfunktionen nutzen. Meiner Meinung nach ist das "Drecksarbeit" die man einer CPU einfach nicht zumutet. CPU übernimmt eher Leitung + Verwaltung und Rechenaufgaben, wobei ich selbst da gerne ein FPU habe. Ich bin halt geizig mit Speicher + Rechnenleistung, selbst wenn ich genug davon habe, es tut mir einfach weh das einfach so zu verschwenden. VIelleicht ist es auch einfach eine gewisse Faulheit, rudimentäre Dinge selbst zu erledigen. Darum stört mich auch an vielen Mikrocontrollern der fehlende externe Daten-/Adressbus (bei größeren Projekten). Ein, MOVE.B WERT,(Adresse Per-Register) ist mir einfach lieber als Portsetzerei. Wenn mein Stapel FH-Prüfungen vorbei ist, werde ich mir allerdings einmal das Datenblatt des Propellers ansehen. Vielleicht werde ich ja doch noch "bekehrt".. immerhin hat ein Freund von mir es geschafft das ich auch mal C für AVR ausprobiere. Zur "professionellen Programmierung" .. ich habe eine Vorlesung "Software-Engeenering" an der FH. Ich muss zugeben, von Verwaltbarkeit und Wartbarkeit bringen diese Konzepte viel, und auch eine gewisse Struktur ist gewahrt. Resourcenschonend und hardwareausnutzend bis zum letzten bisschen ist was anderes. Weiterhin zu dieser "Spin-Language". Wieso ein Interpreter, und kein Compiler? Wegen der Verwaltung auf verschiedene COGs.. wenn jedoch ein Programm (Spin oder ASM) fest einem COG zugeordnet ist.. warum bitte kein Compiler? Wenn das jemand sinnvoll begründen kann, bin ich gerne bereit mein Gemaule zurückzunehmen, sonst sehe ich das weiter als dreckige Pfuschlösung an. Ich habe mich auch mehr darüber lustig gemacht, wie diese Grafik dort regelrecht als "revolutionär" dargestellt wurde. Ich denke wenn das wirklich 8x20 MIPS sein sollten, sollte zumindest niederauflösendes Softwarerendering kein Problem darstellen. Gruß, Christian
> Weiterhin zu dieser "Spin-Language". Wieso ein Interpreter, und kein > Compiler? Ich stecke nicht im Kopf von Parallax drin. Tatsache ist jedoch, dass dies in der Architektur festgelegt ist. Die Prozessoren können nur Code in ihrem lokalen Speicher ausführen, und der ist mit ca. 500 Worten für Code und lokale Daten nicht überwältigend gross. Grössere Programme, die folglich im globalen Speicher stehen, müssen also in irgendeiner Weise interpretiert werden. Man hätte das auch anders konstruieren können. Aber so wie sich Parallax entschieden hat geht es nun nicht anders.
Man sollte sich von der Vorstellung verschwendeter Rechenzeit lösen. Natürlich macht einem Parallax das nicht grad leicht, weil sie ja damit werben. Sollte man aber nicht so ernst nehmen. Seit es Mikrocomputer gibt, besteht ein gewissen Trend, Hardware-Funktionen per Software zu lösen. Meistens kostet das mehr Strom als die ursprüngliche Hardware-Lösung und grössere Chips. Oft ist das allerdings billiger als die Hwrdare-Lösung, weil man bei einer Software-Lösung die exakt gleiche Technik für viele Zwecke nutzen kann, die spezialisierte Hardware nur für einen. Ein Beispiel dafür ist ein Timer-Baustein wie der XR2240. Heute ausgestorben, weil man das gleiche billiger mit einem ATTiny hinkriegt. Für den Job initialisiert der grad mal einen seiner Timer und legt sich dann wieder schlafen. Der XR2240 war ein Nischenprodukt und nie ganz billig, der Tiny ist ein Massenprodukt, kaum teuerer als eine Briefmarke. Das wirkliche Problem vom Propeller liegt neben der schwachen Spin-Leistung woanders. Wenn das Problem wächst, über 32KB globalen Speicher hinauswächst, ist für's erste Schluss. Parallax hat zwar Abhilfe in der Entwicklung, aber das wird noch geraume Zeit dauern. Auf andere Controller portieren ist nicht drin, da muss die Lösung von Grund auf neu konzipiert werden, bis hin zu FPGA statt/zusätzlich zum Controller. Dito wenn Parallax die Segel streichen sollte. Wer also damit ein ernsthaften Produkt entwickelt, mit dem er längere Zeit Geld verdienen will, der geht ein grosses Risiko ein. Diese Regel gilt zwar mehr oder weniger für alle neuen Produkte, aber aufgrund der ziemlich abweichenden Architektur in Hard- und Software ist die Distanz hier doch arg gross.
>Seit es Mikrocomputer gibt, besteht ein gewissen Trend, >Hardware-Funktionen per Software zu lösen. Meistens kostet das mehr >Strom als die ursprüngliche Hardware-Lösung und grössere Chips. Oft ist >das allerdings billiger als die Hwrdare-Lösung Was für meine Privatbasteleien eine eher untergeordnete Rolle spielt, solange es im "zivilen" Rahmen bleibt >, weil man bei einer Software-Lösung die exakt gleiche Technik für viele >Zwecke nutzen kann, die spezialisierte Hardware nur für einen. Im gewerblichen Umfeld ist das ein gewichtiges Argument, muss ich zugeben. FÜr mich selbst verfolge ich eher die Philosophie "lieber eine Sache richtig, als 1000 Sachen halbgar" >Ein Beispiel dafür ist ein Timer-Baustein wie der XR2240. Heute >ausgestorben, weil man das gleiche billiger mit einem ATTiny hinkriegt. >Für den Job initialisiert der grad mal einen seiner Timer und legt sich >dann wieder schlafen. Der XR2240 war ein Nischenprodukt und nie ganz >billig, der Tiny ist ein Massenprodukt, kaum teuerer als eine >Briefmarke. Das ist absolut korrekt, und für solche Zwecke würde auch ich inzwischen jederzeit einen kleinen µC einsetzen. >Wenn das Problem wächst, über 32KB globalen Speicher hinauswächst, ist >für's erste Schluss. Ich wage einmal zu behaupten, das dies bei Anwendung die der Leistung dieses Chips "würdig" sind, sehr schnell passiert. Einige statische Bilder in PAL-Auflösung und aus die Maus. Das ist auch ein Grund warum ich Harvard-Architekturen ebenfalls nicht für das Maß der Dinge halte. Klar, für kleinere µC-Anwendungen geht das, aber man hat immer nen gewissen statischen Code im Flash stehen, und keine Chance ev. etwas zur Laufzeit nachzuladen. Ich bevorzuge da lieber von Neumann-Architekturen, auch wenn sie langsamer sein mögen (was bei neueren meines Wissens nicht einmal mehr der Fall ist). Dennoch setze ich gerne AVRs ein, bisher ging alles damit. Das es mir nicht uneingeschränkt gefällt ist eine andere Sache. Sehr nahe an meine Traum-CPU kommt die 68xxx Baureihe. Ein großer Adressbereich für alles, sehr leistungsfähige Adressierungsarten, nahezu perfekt orthogonaler Befehlssatz mit wenigen, dafür sehr leistungsfähigen Befehlen. Die Kehrseite der Medallie sind allerdings ziemlich große Ausführungszeiten, bei Coldfire hat sich das deutlich verbessert, dafür hat der Befehlssatz einiges an Orthogonalität verloren, wegen der Beschränkung auf max. 48bit Opcodelänge. Wobei, wann braucht man schon einen MOVE.l 0xXXXXXXXX, 0xXXXXXXXX .. gut, eine Variable aus dem Speicher in ein Peripherieregister schreiben... wobei man dort eher mit Pointern in einem Adressregister arbeiten würde, da man so sehr schön Blocks schieben kann. Mit Coldfire wollte ich auch einmal etwas machen :) Gruß, Christian PS: Ich weiss das meine "Prinzipien" z.Zt. nicht in Mode sind, aber wenn man heutige Software sieht, lahm, wuchtig und kann auch nicht grundlegend viel mehr .. bin ich mir relativ sicher das ich nicht ganz verkehrt liege.
> Das ist auch ein Grund warum ich Harvard-Architekturen ebenfalls nicht > für das Maß der Dinge halte. Yep, full ack. Ist der ärgerlichste Teil an den AVRs. MSP430 im Gehäuse der AVRs wäre mir auch lieber. Leider haben so eben beide ihre Nachteile. > Ich bevorzuge da lieber von Neumann-Architekturen, auch wenn > sie langsamer sein mögen Ebenso. Mir geht es da allerdings eher um die Adressräume. Wieviel Busse einer hat ist mir erst einmal egal, auch bei Harvard lässt sich das trennen. > Sehr nahe an meine Traum-CPU kommt die 68xxx Baureihe. Ein großer > Adressbereich für alles, sehr leistungsfähige Adressierungsarten, nahezu > perfekt orthogonaler Befehlssatz mit wenigen, dafür sehr > leistungsfähigen Befehlen. Nuja... die 68000-Familie hat die komplexeste Befehlscodierung aller mir bekannten Architekturen. Da hat noch die Ausnahmeregelung ihre eigene Ausnahme. Und mit 68020 hatte Motorola in Sachen Komplexität voll daneben gegriffen. Kein Compiler hat das je nutzen können. Ok, ich hab's damals auch nicht sofort eingesehen. Aber mittlerweile erscheint mir eine Architektur vgl. MIPS oder Alpha wesentlich eleganter und für Compiler ist das ohnehin besser. Jedenfalls müsste MSP430 dein Ding sein. Näher dran geht kaum. > Mit Coldfire wollte ich auch einmal etwas machen :) Coldfire leidet schwer unter der Abstammung von 68000. Musste halt ursprünglich zur CPU32 subset-kompatibel sein. Folglich passte nichts mehr zusammen. In neueren Versionen ist das etwas besser geworden, aber "aus einem Guss" wird diese Architektur nie wirken können.
> Im gewerblichen Umfeld ist das ein gewichtiges Argument, muss ich > zugeben. FÜr mich selbst verfolge ich eher die Philosophie "lieber eine > Sache richtig, als 1000 Sachen halbgar" Software = halbgar, Hardware = durchgebraten? Was machst du dann noch mit AVRs rum? Dafür gibt's doch FPGAs.
>Nuja... die 68000-Familie hat die komplexeste Befehlscodierung aller mir >bekannten Architekturen. Da hat noch die Ausnahmeregelung ihre eigene >Ausnahme. Und mit 68020 hatte Motorola in Sachen Komplexität voll >daneben gegriffen. Kein Compiler hat das je nutzen können. Ok, ich hab's >damals auch nicht sofort eingesehen. Aber mittlerweile erscheint mir >eine Architektur vgl. MIPS oder Alpha wesentlich eleganter und für >Compiler ist das ohnehin besser. Ich habe den 68008 in ASM programmiert, und es war einfach sehr bequem. Von Ausnahmeregeln weiss ich nichts, besonders wenn man sich die Opcodes mal genauer ansieht. Zwischen MOVE D1,A0 (formell unzulässig) und MOVEA D1,A0 besteht im Opcode kein Unterschied! Ansonsten sind einige Befehle lediglich "Bequemlichkeitserweiterungen" .. Ich denke diese Sachen die MOVE/MOVEA ADD/ADDA hatten den Sinn ASM-Code lesbarer zu machen, aber der Assembler den ich nutzte hat problemlos ADD oder MOVE mit Adressregister als Ziel angenommen, das wurde von Motorola AFAIK sogar so vorgesehen. ADDQ D0,#1 zum beispiel, man könnte das auch mit ADD DO,#1 machen, allerdings ist der Befehl 16 bit länger und braucht dadurch einen (zwei) Holzyklus mehr. Etwas ärgerlich ist bsp. AND/ANDI. Aber sonst seh ich nix mit gewaltigen Ausnahmen, kannst du mir mal ein Beispiel nennen? Ein Buszyklus hat damals zwar 4 Takte gebraucht, was aber schon bei der Grundversion mit 8 MHz Speicher mit nicht mehr als 250 ns Zugriffszeit erfordert hat, das war Anfang der 80er sehr schnell. Wie jeder Prozessor ohne Speicher auf dem Chip wird der 68000 vom Bus gebremst. Das macht auch bei einfachen Operationen einen Großteil der Ausführungszeit aus. Multiplikationen/Division waren allerdings lahm bis sehr lahm, allerdings verglichen zu Softwarelösungen immer noch eine Verbesserung. MSP430 werde ich mir mal ansehen. Gruß, Christian
>Software = halbgar, Hardware = durchgebraten? Was machst du dann noch >mit AVRs rum? Dafür gibt's doch FPGAs. AVRs haben die von mir benötigten Funktionen in Hardware auf dem Chip... ..das Programm macht nur Sachen, die wirklich ein Programm erfordern. Natürlich mache ich auch diverse Sachen in Software, Interfacing einer PS/2 Tastatur z.B.. das geht mit einem Interrupt auf die erste Taktflanke, der dann das Zeichen liest. Das kostet nicht allzuviel Rechenleistung und ist auch in Software kein unnötiger Aufwand. Lieber hätte ich jedoch eine Hardwarelösung die mir die Seriell-Parallelwandlung abnimmt und mich den gesamten Scancode abholen lässt. Ich wollte sowas mal mit einem 6850 machen. Und zu FPGAs .. die Dinger sind cool, hab ich bereits mit gearbeitet, hier machen sich allerdings die Kosten schon bemerkbar. Gruß, Christian
> Ich habe den 68008 in ASM programmiert, und es war einfach sehr bequem. > Von Ausnahmeregeln weiss ich nichts, besonders wenn man sich die Opcodes > mal genauer ansieht. Die zulässigen Adressierungsarten waren recht verschieden. Das hatte zwar alles Hand und Fuss (kein PC-rel als Ziel und so), war aber nicht wirklich orthogonal. Erst recht nicht trivial zu decodieren. Und Basis von allerlei weiteren Befehlen, die sich in illegalen Adressierungen und Opmodes versteckten, wie beispielsweise MOVEP = Bit-Befehl auf Adressregister. Die Steigerung bei 68020 dann: CALLM = ANDI mit dort unbenutzem Opmode, RETM = CALLM auf Register. Wobei CALLM ohnehin ein Abirrung der ganz besonderen Art war, und schnellstens wieder in der Versenkung verschwand. Dem Anwendungsprogrammierer konnte das schnuppe sein. Der Maschine nicht. Es ist ausgesprochen schwierig, den 68020 Instruction Stream schnell zu decodieren. Weit komplexer als x86 in allen Ausprägungen. Bei 68000 liess sich die Länge des Befehls noch aus dem ersten Wort ableiten, wie kompliziert auch immer (LINK = 3 Worte, codiert als NBCD Ax und damit eigentlich 1 Wort lang). Bei 68020 liess sich nun die Länge des zweiten Operanden von MOVE erst ermitteln, nachdem die Länge der Codierung vom ersten Operanden ermittelt war. Mit der superskalaren 68060 wurden diese Probleme offensichtlich, und die Befehle zur Zweiklassengesellschaft. Solche die sich schnell decodieren liessen, und solche bei denen das nicht ging. All das trug zum Tod der 680xx-Serien ausserhalb der Controller-Szene bei. Dieser Spuk erinnert auch an die legendäre VAX, die u.A. dafür berüchtigt war, dass manche komplexe Befehle von Kennern sorgfältig vermieden wurden, weil sie in Einzelteilen benutzt schneller waren. Mit der virtuellen Adressierung lief das ähnlich. Wenn man Befehle hat, deren Lese- und Schreib-Operanden sich teilweise überlappen können, wird virtueller Speicher zum Vabanqe-Spiel, denn entweder prüft man mit grossem Aufwand alle Varianten vorher, oder man geht den sehr langsamen Weg von Motorola und unterbricht den Microcode mittendrin - eine sehr seltene Methode. Solche Ecken sind dann auch berüchtigt für hartnäckige Bugs (NS32000 lässt grüssen).
Das ist eben immer die Frage, ich meine der 68000er wurde einfach auf bequeme Programmierung ausgelegt, während heute eher auf gute Maschinenverständlichkeit wert gelegt wird, was aber bei ASM-Programmierung etwas Hirnverknoten erfordert in gewissen Fällen. Mir ging die Programmierung in 68k-ASM sehr leicht von der Hand. Klar, wenn man mit Gewalt sucht findet man immer etwas zum rumkritteln :) Aber gegenüber zeitgenössischen Architekturen war der 68000 einfach überlegen. Und die Programmierung in ASM IST bequem.. ich habe für mich persönlich noch nichts angenehmeres gefunden. Das eine Architektur nach 15 Jahren eben langsam veraltet ist, lässt sich nicht wirklich vermeiden. Wobei der 68000 durch konsequente 32bit Fähigkeit, bedenkt man die Entwicklung in den 70ern (Release 1979), schon recht zukunftssicher ausgelegt wurde. Irgendwann sind aber die Reserven erreicht, und Erweiterungen werden "pfuschige" Not- und Tricklösungen. Aufgefallen ist das mir auch beim ATmega644, der schon einen "Extended-IO-Space" verwendet, da die Reserven der 64 Adressen der IN/OUT Befehle einfach erschöpft sind. Die x86 Architektur meiner Meinung nach übrigens auch seit langem Alteisen, das ist inzwischen ein riesiges Flickwerk, was aber niemand stört da man ja nur noch in Hochsprachen programmiert.. eine bequeme Assembler-Programmierung ist einfach nicht mehr notwendig im industriellen Umfeld..(das ich gerne ASM programmiere interessiert ja niemand) ich denke aber das die Performance ohne die Altlasten um einiges besser sein könnte. Natürlich kann man nicht einfach eine weltweit etablierte Architektur auf den Müll werfen, dass wäre ein wirtschaftlicher Selbstmord, wenn die alte Software nicht mehr lauffähig wäre. Natürlich könnte man wie Apple beim Wechsel auf PowerPC einen Emulationsmodus für die alte Architektur einbauen, nur ist dieser naturgemäß langsam, und Software für die neue Architektur wird extrem rar sein. Das führt dazu, dass sich keine Käufer finden, auch wegen des hohen Preises, eben wegen der geringen Stückzahlen. Deshalb wird auch keine Software entwickelt usw.. kurz: Man hat keine Chance. Ausführbarkeit der alten Software auf der neuen Architektur führt wieder zu einem Flickwerk, ist also keine Lösung des Problems. Auf dem µC-Markt ist es anders, da der Anwender die Software i.D.R. selbst erstellt, und das im industriellen Umfeld meist auf Hochsprachenebene, wodurch, wenn man hardwarenahe Funktionen in Bibliotheken auslagert mit einer genormten Schnittstelle, eine Portierung nur aus der Anpassung dieser Bibliotheken besteht, die eigentliche Problemlösung ist weiter verwendbar. Auch sind Embedded-Systeme eher überschaubar, also ist es in vertretbarer Zeit möglich, sich in eine neue Architektur einzuarbeiten, auch auf ASM-Ebene. Daher haben dort auch neue Architekturen, und damit Innovation bessere Chanchen. Man vergleiche die MIPS/W moderner Embedded-Anwendungen mit denen der PC-CPUs. Dennoch ist eine 68000er CPU für mich immer noch etwas "schönes", ich programmiere gerne in ASM, es ist mein Hobby, ich mag es einfach mit Bitschubsen komplexe Probleme zu lösen und das mit einem gegenüber Hochsprachen unschlagbar kleinen Speicher- + Resourcenbedarf. Ein "angenehmer" Befehlssatz macht auch Spass, hingegen ist z.B. PIC in ASM nur etwas für wahre Masochisten. Ähhh.. haben nicht über irgendeine Paradontose-CPU oder so gesprochen? Da war doch mal was .. sind wir wohl abgedriftet. Gruß, Christian
> Daher haben dort auch neue Architekturen, und damit > Innovation bessere Chanchen. Anders liessen sich Architekturen wie MAXQ2000 kaum erklären. Auf mich wirkt das Ding, als hätte sich der Konstrukteur mal im Suff durch spekulative Rechnerarchitekturdiskussionen gewühlt und die versehentlich ernst genommen. Nach dem Ding warte ich eigentlich nur noch auf die echte Turing-Maschine.
> Klar, wenn man mit Gewalt sucht findet man immer etwas zum rumkritteln Eine Frage der Perspektive. Wer einen C Compiler durchwühlt und auf den Kopf stellt, der hat u.U. eine etwas andere Sicht als ein normaler ASM-Anwender. > Aber gegenüber zeitgenössischen Architekturen war der 68000 einfach > überlegen. Gegenüber der VAX eigentlich nicht.
>> Klar, wenn man mit Gewalt sucht findet man immer etwas zum rumkritteln >Eine Frage der Perspektive. Wer einen C Compiler durchwühlt und auf den >Kopf stellt, der hat u.U. eine etwas andere Sicht als ein normaler >ASM-Anwender. Hab ich was anderes gesagt, ich programmiere eben in ASM weils mir Spass macht und da mag ich einen leistungsfähigen Befehlssatz. >> Aber gegenüber zeitgenössischen Architekturen war der 68000 einfach >> überlegen. >Gegenüber der VAX eigentlich nicht. Naja das war aber schon ein größeres Rechnersystem, das kannst nicht direkt mit einem Mikroprozessor vergleichen. Es gab wohl auch VAX-Mikroprozessoren, aber nicht auf dem freien Markt, dafür ist das kein Konkurrent aus meiner Sichtweise. Gruß, Christian
Christian Erker wrote: > Taktflanke, der dann das Zeichen liest. Das kostet nicht allzuviel > Rechenleistung und ist auch in Software kein unnötiger Aufwand. Lieber > hätte ich jedoch eine Hardwarelösung die mir die Das USI einiger Tinys könnte das, vieleicht gehts auch mit SPI, ansosnten gibts auch bei den 74HC's chips die Seriell/Parrallel wandeln können.
Hallo, ich habe mir jetzt das mal alles hier durchgelesen. Einerseits haben manche Recht - die Werbung zielt auf die "mächtige" Grafik. Das ist aber Quatsch. Für "echte" Spiele gibt es andere Systeme. Aber: Ich setze den Propeller in Echtzeitsystemen ein. So simpel und einfach war es noch nie. Der Assembler hat mächtige Befehle, ist simpel, und angepasst auf die Struktur. Ein Echtzeitsystem mit einem Cog für eine vollduplex V24 zur Diagnose (ohne Beeinträchtigung von Interupts!) und 2-4 Cogs für echt schnelle Sensorabfragen, die immer funktionieren, egal wie der Rest läuft... das ist schon begeisternd. Auch wenn ich jetzt seit 1983 fast täglich Assembler programmiere auf verschiedenen Systemen (Pic, Atmel, x86, NEC, Motorola etc.) bin ich von dem Teil begeistert. Klar, der neue mit 16 Cogs und anderem Timing ist interessanter, aber das ist schon mal ein Anfang. Übrigens, ich habe noch keine einzige Grafik mit dem Chip ausgegeben, diese Funktion habe ich noch nicht benutzt. Aber ich könnte mir vorstellen, das er zur intuitiven Bedienung mit einem kleinen Touchscreen-LCD ideal wäre. Einen ganz großen Vorteil sehe ich in der Dip40 Version, weil da schieße ich in sekunden eine neue Schaltung zusammen und kann testen. Also ich denke, ich kenne viele EMR, aber der Propeller hat schon seine Berechtigung und sollte weiter entwickelt werden.
> Grafikchips sind im allgemeinen recht flexibel programmierbar, > zumindest die die ich mir bisher angeschaut habe. Wie du es auch drehst und wendest, ein programmierbarer Chip ist immer flexibler als einer mit fester Funktionalität. Nenn mir mal einen, der z.B. Pixelgrafiken in Echtzeit drehen und skalieren kann, sich auf Lochraster löten läßt und zusammen mit einem Mikrocontroller in derselben Preisregion liegt, wie der Propeller. > Es wiedert mich einfach an z.B. bei einem 20 MIPS Controller nen > Großteil für ne Multiplexanzeige oder eine Videoausgabe zu verbraten... Dann muß es dir ja ganz übel gehen, wenn du eine PC-Grafikkarte siehst. Da sitzen Controller mit 128 parallelen Recheneinheiten drin, die zwar meist keine MIPS, aber dafür jeweils mehrere Hundert MFLOPS haben. > der Controller kann sinnvolleres tun, und was soll ein Grafikchip > anderes machen als Grafik. Warum muß es denn unbedingt ein dedizierter Chip sein, der nur Grafik kann, teurer ist und weniger Flexibilität bietet? @auch_ein_Gast: > ich habe mir jetzt das mal alles hier durchgelesen. Einerseits haben > manche Recht - die Werbung zielt auf die "mächtige" Grafik. Das ist > aber Quatsch. Für "echte" Spiele gibt es andere Systeme. Auch welche, die man als Hobbybastler einfach so auf eine Lochrasterplatine löten und mit Minimalbeschaltung laufen lassen kann?
>> Grafikchips sind im allgemeinen recht flexibel programmierbar, >> zumindest die die ich mir bisher angeschaut habe. >Wie du es auch drehst und wendest, ein programmierbarer Chip ist _immer_ >flexibler als einer mit fester Funktionalität. >Nenn mir mal einen, der z.B. Pixelgrafiken in Echtzeit drehen und >skalieren kann, sich auf Lochraster löten läßt und zusammen mit einem >Mikrocontroller in derselben Preisregion liegt, wie der Propeller. Etwas vernünftiges darf mehr kosten.. und heute erwarte ich einfach mehr als nen Spielkonsole anno 197x. >> Es wiedert mich einfach an z.B. bei einem 20 MIPS Controller nen >> Großteil für ne Multiplexanzeige oder eine Videoausgabe zu verbraten... >Dann muß es dir ja ganz übel gehen, wenn du eine PC-Grafikkarte siehst. >Da sitzen Controller mit 128 parallelen Recheneinheiten drin, die zwar >meist keine MIPS, aber dafür jeweils mehrere Hundert MFLOPS haben. Eine CPU ist eine CPU Eine GPU ist eine GPU Ein Soundchip ist ein Soundchip... Peripheriechips sind einfach Arbeitssklaven an die man Drecksarbeit deligieren kann, und muss sich nicht selbst mit rumärgern. >> der Controller kann sinnvolleres tun, und was soll ein Grafikchip >> anderes machen als Grafik. >Warum muß es denn unbedingt ein dedizierter Chip sein, der nur Grafik >kann, teurer ist und weniger Flexibilität bietet? Weil damit einfach deutlich bessere Ergebnisse erzielt werden. Ein Kuhfladen bleibt ein Kuhfladen, egal wie flexibel man ihn formt und wie billig er ist. @auch_ein_Gast: >> ich habe mir jetzt das mal alles hier durchgelesen. Einerseits haben >> manche Recht - die Werbung zielt auf die "mächtige" Grafik. Das ist >> aber Quatsch. Für "echte" Spiele gibt es andere Systeme. >Auch welche, die man als Hobbybastler einfach so auf eine >Lochrasterplatine löten und mit Minimalbeschaltung laufen lassen kann? Auch ein System mit CPU, mehr Speicher, Soundchip und wwi. würde ohne weiteres in ein DIL40 passen wenn man nur wollte. Und die Ergebnisse SIND dann besser. Man könnte ja weiterhin mehrere Cores machen, welche dann die wichtigen Sachen erledigen. Der Propeller könnte es auch besser.. wenn nicht irgendein minderbemittelter Idiot auf die Schnapsidee mit einer INTERPRETER-Sprache gekommen wäre. Kurzfassung: Ich geb erst Ruhe wenn mir jemand eine Anwendung zeigt bei der man etwas von den 8x80 MHz merkt! Gruß, Christian
> Kurzfassung: Ich geb erst Ruhe wenn mir > jemand eine Anwendung zeigt bei > der man etwas von den 8x80 MHz merkt! Du solltest endlich mal die links anklicken, die Dir schon weit oben gepostet wurden ... http://forums.parallax.com/forums/default.aspx?f=25&m=197711 > Your Propeller is now a 80Mhz Scope! Viewport v1.1 lets > you measure all 32 IO pins every clock cycle. Viewport > still gives you all the flexibility and power of a PC > based digital scope, but now also supports triggers and > a logical state analyzer mode to view all 32 bits on > one screen.
Naja doll.. Ports auslesen und rüberschieben -- dafür braucht man UNBEDINGT nen µC ..
Entschuldigt bitte meinen Beitrag eben .. ich war einfach noch zu verärgert. Klar, dieses Projekt ist interessant, und mit diesem Chip auch gut zu lösen. Aber was mich gewaltig stört ist, es ginge einfach besser, es wird eine Menge Potential verschenkt einfach. Ersteinmal braucht das Teil deutlich mehr Speicher, Anwendungen die eine 8x80 MHz CPU erfordern sind einfach keine Programme mit ein paar KB. Dann sollte es zumindest ein wenig dezidierte Peripherie haben, die ja immer noch flexibel ausgelegt sein kann, besonders im Punkt Grafik und Sound. Es zwingt einen ja niemand diese zu nutzen, und das Mehrfachbelegung von Pins funktioniert beweisen sämtliche heutige µC-Familien. Klar wird der Chip dann teurer, aber eben auch leistungsfähiger. Was mich am meisten ärgert ist die INTERPRETIERTE Sprache, warum zum Teufel kein Compiler? Das Speicherargument zählt nicht, man kann ja kompilierten Code zur Laufzeit laden. Kurzfassung: Interessantes Konzept, aber Realisierung mangelhaft. Gruß, Christian
Christian Erker wrote: > Eine CPU ist eine CPU > Eine GPU ist eine GPU > Ein Soundchip ist ein Soundchip... Schon lange nicht mehr. Eine GPU ist inzwischen ein universell einsetzbarer Prozessor, der für bestimmte Berechnungen eben schneller ist als eine klassische CPU. Sehr viel grafikspezifisches steckt da nicht mehr drin. > Ersteinmal braucht das Teil deutlich mehr Speicher, Anwendungen die eine > 8x80 MHz CPU erfordern sind einfach keine Programme mit ein paar KB. Sagt wer? Die bisher genannten Projekte scheinen alle ganz gut mit den paar kB auszukommen. Ich finde das Konzept interessant, statt einem Prozessor mit vielen komplexen Peripherieeinheiten mehrere einfache, aber schnell getaktete Prozessoren zu verwenden. Allein schon weil man sich dann nicht auf die oft fehlerhaften und eingeschränkten Implementierungen des Herstellers verlassen muss. > Klar wird der Chip dann teurer, aber eben auch leistungsfähiger. Und jeder Nutzer zahlt überflüssige Hardware mit, wenn er keine Soundausgabe, keine Grafikausgabe, usw. braucht. > Entschuldigt bitte meinen Beitrag eben .. ich war einfach noch zu > verärgert. Ich verstehe nicht ganz warum du du dich hier so reinsteigerst. Hat dich als Kind ein Propeller gebissen, oder wo kommt diese Abneigung her?
ich habe mir das hydra-board gekauft, weil ich nur grafik und sound mit einem ship realisieren möchte. das board ist erste sahne (nichts für leute die kein geld haben). das videosignal(natürlich in farbe) zu proggen und zu begreifen inclusive sound ist mein ziel. ich möchte alles darüber kennenlernen und nachproggen. das stichwort ist nachproggen. die progsprache dazu, spitze. die grafiksachen im film, der hier disktiert ist nur ein bruchteil der leistung, herr klein verfälscht total das hydraboard. er hat sich mit diesem board auch nicht richtig auseinandergesetzt. man merkt auch manchmal, wie stümperhaft er den einschalter sucht usw. der man ist für eine beschreibung des hydarboard ungeeignet. lol.. ist auch schon alt. ich habe lange gesucht um so etwas fertiges zu bekommen, welches auch so einfach nachvollziehbar ist. für meinen roboter nehme ich den ATMEGA32, für steuersachen (ir,relais,ultra) ist mir der propeller unterfordert, dafür kann man die einfachen ATEMEGA nehmen. jedes teil hat seine spezialitäten und hat seinen preis natürlich. wer sich nur 10euro leisten kann, für den ist das nichts, der soll seine alten platinen weiter auslöten und schlachten und seine sachen zusammnefriemeln. manche lernen ja nichts anderes kennen , weil die schulen und unis auch nur noch schrott haben aus den 50zigern. und bei 5million arbeitlose trifft man halt den einen oder anderen der nur diskutiert über ein teil, was er sich niemals leisten kann.
Ääähhmmm was soll den der Letzte Beitrag hier von "neuer"?? Hier geht es nicht um dekadenz, mein Auto ist größer als Deins weil ich mehr Geld habe... Das ist wiederlich sorry. Hier geht es um Technik und wie weit sie sinnvoll ist für welche Aufgaben. Ich hab mir auch mal den Propeller angesehen besser gesagt in erster Line das Datenblatt und komme auch in erster Line auf eine sehr Ähmlich Meinung wie Christian Erker. Ich werde mir vermutlich demnächst trotzem mal so ein Teil kaufen und es genauer unter die Lupe nehmen, aber mir kamen da ähnliche Fragen auf wie Chrstian, es ist in der tat ein recht interesanter ansatz, aber er taugt irgendwie nur für Hobby bastler und nicht für den Professionelen einsatz. Ich kan mir nur schwer vorstellen das jemand so einen Controller in eine Waschmaschine einbaut (ok dafür ist er wohl ein bischer oversized) aber ihr wist was ich meine.... :) Der Interpreter, der wenige Speicher und auch das Speicherkonzept. Wenn ich es richtig gelesen habe (bitte nicht gleich hauen wenn ich nicht genau genug gelesen habe) aber das Programm befindet sich wohl in einem externen seriellen EEPROM und wird dan ins RAM kopiert und von da ausgeführt..... Klingt alles sehr abenteuerlich.... Ich weiß nicht ob der Markt für so ein Produkt da ist... Wie gesagt für den einen oder anderen Hobbybastler mags Interessant sein aber für die Industrie glaube ich kaum.
> Ich kan mir nur schwer vorstellen > das jemand so einen Controller in eine Waschmaschine einbaut (ok dafür > ist er wohl ein bischer oversized) aber ihr wist was ich meine.... :) Was spricht dagegen?
>> Ich kan mir nur schwer vorstellen >> das jemand so einen Controller in eine Waschmaschine einbaut (ok dafür >> ist er wohl ein bischer oversized) aber ihr wist was ich meine.... :) >Was spricht dagegen? Nun ja wie gesagt die Ausführung macht keinen professionellen Eindruck. z.B. wer schützt den das eigentliche programm wenn es zusammen mit den daten im RAM steht davor das es sich durch einen Fehler selber zerschießt.. Wozu brauche ich acht dieser COGs ?? Wenn ich ein system baue in dem ich mehrere cores haben will, will ich was recht kompexes und aufwändiges aufbauen, evtl. auch etwas besonders sicher/stabil laufendes. Dazu taugt aber der rest nicht. Wie auch Christian schon gesagt hat den Interpreter raus werfen (macht nun wirklich keinen prof. Eindruck einen Interpreter auf einem Controller zu implementierern). Weiterhin das Speicherkonzept ändern über ein GROSSES Flash. Ich würde hier mal MIN. 128k erwarten. Wir reden hier von 8 x 32bit cores... da ist selbst 128k noch wenig. Entweder richtig oder garnicht ... :)) und über gemeinsamen "shared" RAM und noch mal ausreichend RAM für jeden COG selbst und ich meine mehrere kB pro COG und nicht nur ein paar Byte. Und der Kram mit die software über ein externes serielles EEPROM in RAM kopieren.... was soll das???? Ich baue ja in einen Ferari auch keinen 20 Liter Tank ein (bezogen auf Speicher) und fahre dann mit Diesel für den Interpreter) :) ...?
Mir kommt es so vor, als ob der CELL Vorlage für den Propeller war. Auch hier die SPEs mit ziemlich brachialer streaming Leistung in ihrem kleinen Speicher (512 kiB) und dazu ein realtiv langsamer, in-order, PPC ähnlicher Kern fürs allgemeine. Vielleicht wollte hier jemand Trittbrettfahren, zumindest Konzeptionell? Der Propeller ist IMO ziemlich seltsam. Mehrere unabhängige Kerne mit jeweils 20 MIPS, die dann z.B. mit ein bischen UART und Überwachungsfunktionen Däumchen drehen dürfen? Wen es vor riesige Probleme stellt, das zusammen mit anderen Dingen in einen AVR zu bekommen, soll halt mehrere nehmen... Die aktuellen Preise sind IMO Markteinführungspreise. Gewinne wirft das mit Sicherheit nicht ab. Wer allerdings die Funktionen [i]wirklich[/i] braucht, kann sich ja glücklich schätzen, dass es dieses Stück Hardware gibt.
....Hier geht es um Technik und wie weit sie sinnvoll ist für welche Aufgaben.... hier im forum geht es um hobbys und nicht anderes. hier geht es nicht um ernsthafte aufgaben. schau dich doch mal im forum um, so wie hier bastelt kein ernstzunehmender techniker oder ing. ausser er ist krank oder arbeitslos oder hat langeweile. wer studiert hat techniker oder ing, der weiss alles, der beschäftigt sich nicht mit so ein kleinscheiss wie hier. hier sind hobbysten und nichts anderes. hier bastelt auch keiner eine waschmaschiene in serie. hier im forum sind nur 3,50 euro leute die da was hinfriemeln , mit einem zu heissen lötkolben oder sich eine platine suchen zur ersatzteilgewinnung. hier sind einfache leute am basteln...lol...dazu gehöre ich auch. nur mein einkauf hat höhere summen.
Wem beim Lesen des Datenblatts nicht der Adrenalinspiegel angestiegen ist, hat einfach nicht verstanden was das Teil kann. Allein der Stromverbrauch ist der Hammer für ein solches System. Wisst ihr eigentlich wie schwer es ist solche Reaktionszeiten mit einem Real Time Betriebssystem hinzubekommen? Und beim Propeller muss man sich mit so etwas nicht einmal herumschlagen! Das steckt inhärent in der Architektur drin, nie mehr Latenzzeiten, keine Probleme mehr mit Prioritäten von Interrupts, keine Stack overflows durch unglücklich verschachtelte Interruptroutinen, usw. Eine systemweit gültige Systemzeit auf die durch ein einfaches Register zugegriffen werden kann, keine Probleme mehr mit komplizierter Synchronisation zwischen verschiedenen Chips! Man braucht ein, zwei oder drei serielle Schnittstellen? Oder vielleicht eine I2C? Oder vier? Lieber drei SPI? Vielleicht einen Fernseher, VGA-Monitor oder Handy-TFT ansteuern? Mit Zigbee oder einem nrf2401 drahtlos gehen? Lieber gleich die HF selbst erzeugen? Oder ein kompliziertes Schallmuster für Phased Array Ultraschall ausgeben? Gleichzeitig Schrittmotoren oder Servos ansteuern? Und nebenbei noch einen Resolver oder Inkrementalgeber auslesen? Eine Taste abfragen oder doch lieber gleich eine ganze Tastatur? Und das alles als Objekte im Programm einfach einbinden, das ist die eigentliche Stärke des Propellers (und der Programmierumgebung von Parallax). Wie oft fehlt einem für eine bestimmte Anwendung eine Peripherieeinheit, die einfach nicht da ist (z.B. beim ATmega128 die zweite SPI Schnittstelle...). Und das mit dem fehlenden Flash hat natürlich einen Grund. Mit Flash bekommt man nicht die hohen Taktfrequenzen hin und selbstmodifizierender Code ist auch nicht drin. Aber wer hat was gegen den kleinen EEPROM? Ich musste früher EPROMs mit dem Schraubenzieher aushebeln und im UV-Bad löschen, reprogrammieren und wieder einstöpseln... Aber nörgelt nur weiter rum, ich jedenfalls hab schon Pläne für das Teil :)
Ich zweifle nicht daran das das Konzept durchaus genial ist ... ... nur mit auch nur kleinen Änderungen ging einfach mehr, und das ist es was mich soo ärgert. Eine geniale Idee mit so Scherzen wie Interpreter usw. versaut. Sagt mir einen Grund wieso kein Compiler? Ich zweifle in keinster Weise an das Teil flexibel ist, und wenn es jetzt schon recht leistungsfähig ist, was ging dann erst ab wenn ein gescheiter Compiler verwendet würde? Das laden des Codes von extern ist kein Problem für mich, das ist sogar eine durchaus saubere und übliche Lösung, was mich interessieren würde: Ist es möglich weiteren Code zur Laufzeit nachzuladen? Meine vorherige völlige Ablehnung beruhte darauf, das der Chip 100% als Spieleplattform beworben wurde, und da versagt er nun mal auf ganzer Linie. Gruß, Christian
lese hier seit beginn mit... die letzten beiden postings kann man gut als zusammenfassung aller ansehen ;) @david314: bist du ein vertreter von Parallax? @Christian: sehe ich auch so: hammer teil, nur im letzten moment versaut! wer weiss, vielleicht haben sie die implementierung extern gegeben (SW-leute, die von HW keine ahnung haben - von denen kenne ich genügend, leider)
Zitat Chip Gracey, Entwickler des Propeller : About design quality: The Propeller was an entirely "full-custom" effort. Every polygon of the Propeller's mask artwork was made here at Parallax. We designed our own logic, RAMs, ROMs, PLLs, band-gap references, oscillators, and even ESD-hardened I/O pads. All these structures were first fabricated on test chips and then thoroughly evaluated, often resulting in design changes. This yielded an ideal set of known-good blocks, which could be confidently applied to the overall design. Then, the whole chip was fabricated and subsequently tested at many levels. This allowed us to fix any problems resulting from integration and to fine-tune the clocking systems that are key to the Propeller's low power consumption. The final chip, which is the only version we've ever sold, is the third iteration of this whole-chip process and has no known problems. In order to perform all this testing and tuning, we built up our own lab that gave us the “hands” and “eyes” that we needed to work on our chip. First, we invested in a Micrion FIB (focused ion beam) machine that allowed us to perform microscopic surgery, so that we could check failure hypotheses and make experimental modifications. Think “wire cutters”, “soldering iron”, and “solder” for the sub-micrometer wiring inside the chip. The other big thing we acquired was a Schlumberger e-beam prober -- essentially a scanning electron microscope which can use its electron beam to measure voltages on those same tiny wires while the chip runs at full-speed. Think “7GHz, non-loading, 10nm-tip, contactless oscilloscope”. These machines are almost Star Trek in their technology, and they get you all the way down to where you need to be in order to see and fix problems. We were able to purchase these machines, used, for only 0.5% of what they cost new. The real investment, though, turned out to be the six months it took to get them running, and to learn how to use them. Now, we can even do our own maintenance on them, which is not trivial. All this was a huge adventure, in itself, but invaluable in getting the Propeller's silicon perfected. The Propeller was given the kind of thorough design treatment that almost no other chips receive today. It used to be that every chip was full-custom, and all of its transistors and wiring were designed by hand, for the point of application. As semiconductor technology shrunk, though, the prevailing design methodology shifted away from this kind of specialization, toward generalization and abstraction, so that designs of greater complexity could be practically realized. The modern design methodology centers around hardware description languages, IP block reuse, and the automated placement and interconnection of potentially billions of gates. The end silicon result is invariably an incomprehensible rat’s nest of wiring, standard cells, and IP blocks, usually none of which were designed by the engineers applying them. This methodology is certainly a boon for very complex designs, but it has become the standard approach for designing almost any chip containing logic today. The differences between the old and new methodologies can be accurately characterized by a software analogy: Imagine a program written entirely in assembly language. It takes a long time to write, but it is fast, compact, and reliable by virtue of its directness. Now imagine a program written in some high-level language which leverages objects acquired from elsewhere. It is relatively easy to write, but compiles into something big and slow, and may have some undesirable characteristics that are out of your control. For chips, the old method means small dies, high speed, low power, and exacting performance, whereas the modern method tends to generate bigger dies, lower speed, more heat, and sometimes bugs from IP which you have no control over. I'm sure you get the idea. Most important: So, all I’ve said so far amounts to just this: Through an exceptional effort, we made the Propeller as electrically robust and efficient as we could. This, still, is not the core quality issue, but a supporting one. The core quality of the Propeller really resides in its architecture. The architecture is what took the first six years of development to iron out, and the architecture is what engages people. All the effort that went into the silicon implementation was to ensure that this core quality was ideally housed. The story of the Propeller's architecture would be a book, in itself, but to get an idea of the plot, you can visit the Propeller discussion forum and witness the excitement of people doing things they never thought possible. They are finding the Propeller to be a great vehicle for invention and discovery, as well as the means to realize complex embedded systems that are not possible with any other chip. A few forum members have even said that the Propeller has drawn them back into software and electronics after long absences. We will publish a datasheet soon with quite a bit of characterization data in it. It should give customers more confidence about using the chip, but for many it will mainly serve to validate what they already know from experience and readily attest to on the forum -- that the Propeller is tough, reliable, and low-power. It’s no illusion, and no accident. We plan on a very long sales life for the Propeller and we have no intention of diluting the concept with many slight variants, for which you'd inevitably be getting end-of-life notices for after a few years. This is good news for customers, because they are the ones who are going to be making investments in programming that will, in sum, dwarf the energy that we spent developing the Propeller. We made a platform that is, hopefully, deserving of their coming efforts.
@ Christian Erker: Es wird einen C-Compiler geben; das wurde schon mehrmals bestätigt. Mir scheint allerdings, dass er nicht kostenlos sein wird. Es gibt aber noch weitere, freie Entwicklungssoftware für den Propeller. Bist also nicht auf den Spin-Interpreter angewiesen :-) . Ich habe übrigens schon einige Systeme mit diesem Chip gemacht; ich finde ihn schon nett, allerdings doch noch etwas zu teuer. Mein letztes Projekt war ein System mit Ethernet, 240x128er-Farb-TFT, Dreh-Encoder, drei SPI-Chips. Die Hardware war mit dem Propeller ziemlich simpel zu stricken, und Spin war mehr als ausreichend, um die Anwendung zu schreiben. Ich habe (noch) keine einzige Zeile Assembler benutzt. Alles in Allem bin ich durchaus zufrieden mit dem Chip als solches, würde mich aber über mehr Anwendungsspeicher freuen. Aber das soll ja auch bald kommen; wie ich gelesen habe, 256kByte. Ich möchte auch nicht unerwähnt lassen, dass es z. B. auch für die PSOCs von Cypress ziemlich lange gedauert, bis es einen C-Compiler gab. Und bis heute ist in deren Entwicklungs-Studio nur Assembler drin. Darum lautet mein Rat: Nicht immer nur mosern, das Ding hat dieses nicht, das Ding hat jenes nicht, das Ding kann dieses nicht, das Ding kann jenes nicht. Kein Chip ist vollkommen, weder von der Hardware- noch von der Softwareseite. Bleib einfach bei Deinen Chips, und alles ist gut :-) . Und ich bin sicher, wenn man sich mal ernsthaft mit den AVR-Teilen auseinandersetzt, wird man auch ziemlich viele Haare in der Suppe finden. Hat hier aber schon mal jemand über AVRs gemosert? Stephan.
Ich finde es eigentlich katastrophal, daß Leute, die sich für tolle Entwickler und Fachleute halten, über die vermeintlichen Mängel des Chips mosern und vor Arbeitsaufnahme zunächst perfekte Bedingungen zu verlangen, statt die Möglichkeiten zu sehen. Einen guten Entwickler zeichnet aus, daß er aus gegebenen Möglichkeiten das Nötige (nicht unbedingt das Optimum) herausholt. Wenn ich Projektleiter wäre, würde ich david314 oder Stephan einstellen. Christian, Du hättest mit Deinen Ansichten keine Chance bei mir, sorry. (Ich bin kaufmännischer Geschäftsführer eines Unternehmens, allerdings nicht in der Elektronikbranche und betreibe Elektronikbastelei als Entspannungshobby.)
"Hat hier aber schon mal jemand über AVRs gemosert?" Lies doch einfach die Postings. Natürlich wird jede Menge über die AVRs gemosert. Das fängt doch schon mit den fehlenden Interrupt-Prioritäten an, die man "teuer" per Software nachrüsten muss.
>Ich finde es eigentlich katastrophal, daß Leute, die sich für tolle >Entwickler und Fachleute halten, über die vermeintlichen Mängel des >Chips mosern und vor Arbeitsaufnahme zunächst perfekte Bedingungen zu >verlangen, statt die Möglichkeiten zu sehen. Was ist an den Mängeln vermeintlich, sie sind definitiv vorhanden und für mich, der als Bastler freie Wahl hat, ein Hinderungsgrund. >Einen guten Entwickler >zeichnet aus, daß er aus gegebenen Möglichkeiten das Nötige (nicht >unbedingt das Optimum) herausholt. Dazu sehe ich mich durchaus in der Lage, nur wie weiter unten beschrieben, als Bastler hab ich niemand der mir Möglichkeiten setzt, und damit sehe ich keine Notwendigkeit zu solchen Lösungen. >Wenn ich Projektleiter wäre, würde ich david314 oder Stephan einstellen. >Christian, Du hättest mit Deinen Ansichten keine Chance bei mir, sorry. Du hast einen gewichtigen Punkt vergessen... die Situation eines Bastlers ist eine völlig andere, als die eines Entwicklers in einem Unternehmen. Als Bastler hab ich relative Wahlfreiheit welche Technologie ich nutze, und da sehe ich als mein gutes Recht an, die für diesen Zweck am besten geeignete auszuwählen. Der Markt ist groß genug, wer meine Bedürfnisse nicht befriedigt, hat eben Pech gehabt, kaufe ich bei der Konkurrenz welche mir ein besser geeignetes Produkt liefern kann. Nennt sich Marktwirtschaft. In einem Unternehmen ist dies natürlich etwas anderes, oft gibt es eine etablierte Technologie, für das Entwicklungswerkzeuge und erfahrenes Entwicklungspersonal vorhanden ist. Eine Umstellung ist hier mit erheblich größerem Aufwand verbunden, weswegen man natürlich versucht, diese zu vermeiden und Probleme mit den gegebenen Möglichkeiten zu lösen. Ich finde es nicht gut, wie man hier versucht mich dazu zu zwingen dieses Teil gut zu finden. Kurz gefasst, der Propeller mag für manche Anwendung ideal sein, nur sind dies eben nicht MEINE Anwendungen, weswegen ich ihn nicht nutzen würde. Gruß, Christian
Am Anfang des Threads hatte ich schon Angst, das der Propeller hier nur durch den Dreck gezogen wird. Aber wie ich sehe gibt es hier auch jede Menge Leute die sich ähnlich wie ich Gedanken machen, als was man den Chip einsetzen könnte. Potential hat es genug, und im Gegensatz zu einigen Beiträgen ist die Realisierung in meinen Augen auch nicht schlecht. Selbst die Interpreterspache - böse,böse,böse :-) - sehe ich als gelungen an, endlich ein Hersteller der versucht neue Wege zu gehen. Keiner wird gezwungen in Spin zu proggen, asm geht ja auch. @ Christian Erker: Ich denke du bist ein "unbelehrbarer". Das ist keinesfalls negativ gemeint, aber es strifft die Sache schon ziemlich genau. Am Anfang des Threads habe ich es noch versucht dir eine andere Sichtweise zu zeigen, auch danach kamen hier von anderen Autoren viele sehr gute Beiträge. Du bist sozusagen Beratungsresistent. Feste Meinungen aber kaum Grundlagen. In meiner Firma würde ich dich auch nicht einstellen, aber sei unbesorgt, ich kenne etliche Unternehmen die ähnlich wie du Arbeiten. Eine Stelle nach Deinem Studium zu finden dürfte somit kein Problem darstellen. Du bist der Typ von Mensch, der selbst am Eierlegenden Wollmichsau nur rummeckert. Das ist nicht schlecht, nur eben passt es weniger zu einer, der in der Entwicklung tätig ist. Kleiner Tipp am Rande: bewerbe dich mal wenn du fertig bist im technischen Einkauf. Da wirst du zwar keine Freunde haben, aber dein Chef wird dich königlich bezahlen. Du scheinst mir der perfekte Typ dafür zu sein. Gruss: Z
> In einem Unternehmen ist dies natürlich etwas anderes, oft gibt es eine > etablierte Technologie, für das Entwicklungswerkzeuge und erfahrenes > Entwicklungspersonal vorhanden ist. Eine Umstellung ist hier mit > erheblich größerem Aufwand verbunden, weswegen man natürlich versucht, > diese zu vermeiden und Probleme mit den gegebenen Möglichkeiten zu > lösen. Das heißt also, dass weiterhin der PIC16F84 oder die kompatiblen Nachfolger 16F628 in der Firma verwendet wird. Aber doch dann kein Propeller. Irgendwie hat Parallax schlechte Karten ... Firmen wollen ihn nicht und Privatleute wollen ihn auch nicht. Ganz weit oben stand aber schonmal, dass die Erfahrung von Parallax ist, dass es rund 5 Jahre braucht bis die Akzeptanz da ist. Hoffentlich überstehen die es :-) Mfg Thomas Pototschnig
Christian, wir haben uns mit den Comments überschnitten. Entscheide dich doch mal, was bist du? Ein Hobbybastler? Stell dich dann nicht als Profi dar, denn dazu hast du zu wenig Substanz in deinen Beiträgen. Welche "Mängel" sind denn deiner Ansicht nach "definitiv" vorhanden????? Du glaubst nicht ernsthaft dass ein Chiphersteller nur für dich persönlich einen Chip entwirft, nur weil du nicht in der Lage bist umzudenken? Sorry, aber eigne dir erst mal genug Fachwissen an, bevor du über etwas herziehst was du gar nicht verstehst. Gruss: Z
@ Carbolo Crb: Es fällt einem schwer, Deine Argumente (die übrigens eher Meinungen entsprechen) ernst zu nehmen, wenn Du die Leute grundsätzlich persönlich angreifst.
> Ich finde es nicht gut, wie man hier versucht mich dazu zu zwingen
dieses Teil gut zu finden.
Nein, zwingen wollte ich Dich nicht. Sicherlich hast Du als Bastler die
freie Wahl. Aber Du hast ja im Fach studiert, wenn ich das weiter oben
richtig entnommen habe, bist also kein Bastler im herkömmlichen Sinne so
wie ich.
Mir macht deshalb Deine grundsätzliche Herangehensweise erhebliche
Bedenken. Daran solltest Du arbeiten, wenn Du als Entwickler Erfolg
haben willst.
Das Ding ist da, es ist ein Angebot und man muß prüfen, wofür es
nützlich sein kann. Gerade irgendeine besondere Fähigkeit dieses Dings,
geschickt genutzt, könnte vielleicht den kleinen Wettbewerbsvorteil
ausmachen, der über Erfolg und Nichterfolg der Firma entscheidet. Da
hilft es nicht, nur zu sehen, wozu das Ding nicht gut ist, (auch das
ist wichtig, keine Frage, man muß die Grenzen kennen.) sondern ob ich es
mir nützlich machen kann. Destruktives Denken ist leider sehr weit
verbreitet, aber selten nützlich.
@antworter (Gast) Recht hast du, ich werde manchmal etwas angreifend. Sorry Christian. Allerdings bin ich der Meinung, dass man erst dann eine Meinung über etwas bilden sollte, NACHDEM man sich eingelesen hat und alles versteht. Vorher irgendwelche festgefahrenen Sprüche loszulassen ist in meinen Augen unprofessionell. Womit wir auch schon am springenden Punkt wären. Gruss: Z
>Christian, wir haben uns mit den Comments überschnitten. Entscheide dich >doch mal, was bist du? Ein Hobbybastler? Stell dich dann nicht als Profi >dar, denn dazu hast du zu wenig Substanz in deinen Beiträgen. Ich passe mein Niveau eben dem Rest an, und das ist zum größten Teil reines in den Himmel loben. > Welche "Mängel" sind denn deiner Ansicht nach "definitiv" vorhanden????? - Interpretersprache - Zu wenig Speicher - Grafikunterstützung bezieht sich zu sehr auf Software, zumindest eine gewisse Hardwareunterstützung wäre wünschenswert. >Du glaubst nicht ernsthaft dass ein Chiphersteller nur für dich persönlich >einen Chip entwirft, nur weil du nicht in der Lage bist umzudenken? Wer sagt das ich nicht in der Lage bin umzudenken. >Sorry, aber eigne dir erst mal genug Fachwissen an, bevor du über etwas >herziehst was du gar nicht verstehst. OK, nun reicht es mir aber gewaltig, ich lasse mich hier nicht beleidigen! Ich bin Student der Elektro- und Informationstechnik im 4. Semester. Ich habe bereits programmiert auf: Valvo 2650, Motorola 6809, Motorola 68008, Freescale 68HC12, AVR8 und beginne gerade mit AVR32. Jeder dieser Architekturen hat ihre Vor- und Nachteile. Ich habe bis auf den AVR32 jede dieser Architekturen in Assembler programmiert, den AVR8 zusätzlich in C, den AVR32 hab ich erst wenige Tage unter den Fingern und arbeite mich gerade in die Programmierung unter Linux ein. Unter Hochsprachen habe ich Erfahrung in C/C++ und Pascal, sowie unter Derivaten dieser Sprachen. Weiterhin habe ich Grundkenntnisse in VHDL, leider hatte ich noch keine Gelegenheit diese weiter auszubauen. Ich verstehe das Konzept des Propellers sehr wohl, und ich halte es wie oben bereits erwähnt für ein geniales Konzept. Leider hat die Realisierung die oben erwähnten (aus meiner Sicht) gravierenden Mängel. Gruß, Christian
> Ich bin Student der Elektro- und Informationstechnik im 4. Semester.
Ok, alles klar. Wir setzen diese Diskussion in einigen Jahren mal
rückblickend fort.
Gruss:
Z
So, hiermit hast du endgültig bewiesen, das ich dich nicht im gerinsten ernstnehmen muss, Alleswissender Gott...
:-) nein, kein alleswissender Gott, aber 10 Jahre Berufserfahrung in der Industrie NACH meinem Studium. Frage: Da du so viele verschiedene Architekturen programmiert hast: waren in deinen bisherigen Projekten z.B. auch mal umfangreiche Zeitkritische Interruptroutinen mit Prioritätsüberschneidungen dabei? Diese ohne BS geregelt bekommen? Wie hätte man dieses Problem mit einem Propeller wohl gelöst? Thema "definitive Mängel" : - Interpretersprache: C-Compiler in Arbeit,asm möglich. Interpretersprachen haben eigene Vorteile. Selbst in uC. Siehe weiter oben in etlichen Beiträgen. - zu wenig Speicher: was hindert dich mehr Speicher anzubinden? (Sag jetzt bitte nicht dass der Propeller nur bis 32k adressieren kann, man hat genug andere Möglichkeiten.) - Grafikunterstützung bezieht sich zu sehr auf Software, zumindest eine gewisse Hardwareunterstützung wäre wünschenswert. ?? wozu? Gruss: Z
>Da du so viele verschiedene Architekturen programmiert hast: waren in >deinen bisherigen Projekten z.B. auch mal umfangreiche Zeitkritische >Interruptroutinen mit Prioritätsüberschneidungen dabei? Diese ohne BS >geregelt bekommen? Bin ich gerade dabei und eine gut funktionierende Lösung ist nahe. Ich kann darüber allerdings nichts genaueres sagen... >Grafikunterstützung bezieht sich zu sehr auf Software, zumindest eine >gewisse Hardwareunterstützung wäre wünschenswert. ?? wozu? Damit es nach 2007 aussieht statt nach 1977... Gruß, Christian
1977 ist schon eine Weile her und die hätten sich gefreut so etwas wie den Propeller gehabt zu haben. Der entscheidende Punkt bei diesem Controller ist doch, dass er ein unbeschriebenes Blatt ist! Er hat eben keine spezialisierte Hardware und das macht ihn so vielseitig. Hast du schon mal einen Microcontroller gehabt, der so wandlungsfähig ist wie dieser und gleichzeitig so schnell und stromsparend? Man programmiert ihn um und schon ist er etwas völlig anderes. Die Erfahrung mit vielen verschiedenen MCUs und CPUs hat mir gezeigt, dass irgendwie immer etwas fehlt oder faul ist. Entweder zuwenig UARTs/I2Cs/SPIs oder nicht genug Timer/PWMs/CCUs oder so schlechte ADCs, dass einem schon beim Lesen der Spezifikation übel wird, oder furchtbar segmentierten Speicher oder gar keinen RAM und und und... Versuch mal z.B. beim AVR intuitiv eine Sinustabelle aus dem Flash zu lesen, das macht Spaß :) Am Ende sucht man sich irgendeine besch...eidene Lösung, pappt Peripherie dran (was die Boardfläche und Kosten erhöht), denkt sich umständliche Software-Lösungen für fehlende Hardware aus, die natürlich deine Latenz- und Debugzeiten erhöhen (Bitbanging am Oszilloskop beobachten macht sooooviel Spass) usw. Hast du mal z.B. versucht einen kleinen 8-Bitter, wie z.B. die AVRs, als schnellen(!) Datenlogger einzusetzen? Einfach einen ADC über SPI mit ein paar hundert kHz samplen lassen und dann die Daten auf eine SD-Karte schaufeln. Hört sich einfach an, gell? Geht aber in die Hose, weil das Teil hat nur einen SPI Port und während man auf die SD-Karte schreibt kann man keine Samples mehr ziehen. Das gibt natürliche häßliche Gaps in deinem Datenstrom und für Bitbanging ist das Teil mit seinen 16MIPs zu langsam, falls man zwischendurch noch ein paar andere sinnvolle Dinge machen will. Also nimmt man sich sich zwei kleine AVRs und kommuniziert über einen selbstgestrickte parallelen Bus. Nicht sehr elegant? Klar, aber sonst bleibt nur ein ARM und dann hast du wieder jede Menge an Peripherie die du eigentlich nicht brauchst und schon hast du Zeit damit verschwendet genau die richtige MCU für deine Anwendung zu suchen, damit der Preis stimmt. Ich hab schon soviele Stunden damit verbracht die Datenblätter von Atmel, Phillips, ST, TI, usw. zu durchforsten und immer(!) mußte ich Kompromisse eingehen, denn wie wir alle wissen hat jeder Hersteller seine eigenen Vor- und Nachteile. Was den Interpreter angeht kann ich die Kritik nicht verstehen, ihr habt doch bestimmt auch alle Java-fähige Handys!? Wenn es einem zu langsam ist, dann benutzt man eben Assembler, durch die inhärente Multitasking-Struktur hat man sich ja schon die ganze Bürokratie erspart. Und bevor es einem zu langsam ist, sollte man nicht anfangen sich zu beschweren... Natürlich ist der Propeller nicht für alle Anwendungen geeignet, das ist doch allein schon wegen des Speichers klar. Worum es hier geht sind Anwendungen mit extrem harten Anforderungen an die Echtzeitfähigkeit und ein neues Paradigma für Multitasking-Betriebssysteme. Schon mal über Betriebssicherheit nachgedacht? Der Propeller ermöglicht ohne Probleme den Aufbau redundanter Systeme und zwar ohne Synchronisierungsprobleme Halleluja Und nein, ich bin kein Angestellter von Parallax und werde nicht für meine Postings bezahlt, hab nur zu lange in der Raumfahrt gearbeitet, da sind die Anforderungen an Reaktionszeiten und Zuverlässigkeit etwas...extremer :)
Ja, dafür wurde der aber in keinster Weise beworben. >Hast du schon mal einen Microcontroller gehabt, der so wandlungsfähig ist wie >dieser und gleichzeitig so schnell und stromsparend? Man programmiert >ihn um und schon ist er etwas völlig anderes. Man kann auch nen Core in ein FPGA implentieren .. oder auch mehrere. Dann kann man auch die nötige Hardware dazubauen, und diese ist dann auch Hardware. So etwas halte ich für eine bessere Lösung, klar bei den aktuellen Preisen des Propellers ist es teurer und DIL gibt es auch selten, das aber auch nur wegen fehlender "wertvoller" (d.H. von der Industrie ausgehender) Nachfrage. Und bei einem FPGA kannst mir jetzt NICHT mit geringer Flexibilität kommen... >Versuch mal z.B. beim AVR intuitiv eine Sinustabelle aus dem >Flash zu lesen, das macht Spaß :) Kann ich gerne machen.. ich sehe aber kein Problem, Pointer-Register gibts, Postinkrement gibts... aber wie gesagt, ich probiers nachhaer einmal :) >Hast du mal z.B. versucht einen kleinen 8-Bitter, wie z.B. die AVRs, als >schnellen(!) Datenlogger einzusetzen? Dafür sind die auch nicht gedacht. >Einfach einen ADC über SPI mit ein paar hundert kHz samplen lassen und >dann die Daten auf eine SD-Karte schaufeln. Hört sich einfach an, gell? In diesem Falle würde ich einen parallel-ADC nutzen und gut ists. >Also nimmt man sich sich zwei kleine AVRs und kommuniziert >über einen selbstgestrickte parallelen Bus. Nicht sehr elegant? Wieso nicht. Ist auch Multicore wie der Propeller. >Was den Interpreter angeht kann ich die Kritik nicht verstehen, ihr habt >doch bestimmt auch alle Java-fähige Handys!? Ich habe ein 10€-Handy das mir völlig ausreicht da es die relevanten Funktionen (Telefonieren, SMS) zuverlässig und gut beherrscht. Jave ist aber etwas anderes, da sorgt der Interpreter für Portabilität, wenn man aber für ein bestimmtes System programmiert, ist das schlicht unnötig. >Wenn es einem zu langsam ist, dann benutzt man >eben Assembler, durch die inhärente Multitasking-Struktur hat man sich >ja schon die ganze Bürokratie erspart. Und bevor es einem zu langsam >ist, sollte man nicht anfangen sich zu beschweren.. Zum X-ten mal, die Spinlanguage ist NICHT Bestandteil meiner Kritik. Nur warum bitte kein Spin-COMPILER! >Worum es hier geht sind Anwendungen mit extrem harten Anforderungen an die >Echtzeitfähigkeit und ein neues Paradigma für >Multitasking-Betriebssysteme. Natürlich geht das gut wenn man Cores zu soetwas abstellt, nur drehen dann einige die meiste Zeit sinnlos Däumchen. Ich denke halt ein FPGA mit vielen Logikzellen im DIL-Gehäuse und mit Flashconfig sowie einer kostenlosen Entwicklungsumgebung .. DAS würde ich bejubeln, ohne Einschränkung. Für den der mehr Pins braucht eben im PLCC-Gehäuse, da gibts Fassungen für mit 2,54er Rastermaß Gruß, Christian
> Was den Interpreter angeht kann ich die Kritik nicht verstehen, ihr habt > doch bestimmt auch alle Java-fähige Handys!? Wenn es einem zu langsam ist, > dann benutzt man eben Assembler Ich bin eigentlich ganz froh, dass ich mittlerweile nicht mehr auf Assembler-Ebene runter muss. In C programmiert es sich viel effizienter. Aber der Einwand mit dem Spin-Interpreter gilt eigentlich nicht, da es nur eine Frage der Zeit ist bis eben ein Compiler rauskommt. Dann hat sich das mit der "Assembler-Ebene" schon wieder erledigt. Für hardcore-Echtzeit-Systeme mag der Propeller wirklich unschlagbar sein. Für mich persönlich hat er allerdings keinen relevanten Nutzen, da ich eher in Richtung Embedded-Linux mich weiterentwickeln will und vor allem von der Lowleve-Hardware-Frickelei loskommen will. Ich möchte einen Controller, der tausend Funktionen und mehr hat und ich möchte mich aber nicht mehr um die Peripherie selber kümmern müssen, sondern alles dem Betriebssystem überlassen. Der Propeller kommt da leider nicht in Frage. Er ist aber auch für eine ganz andere Zielgruppe ausgerichtet. Die Videos suggerieren, dass die Zielgruppe die Video-Game-Programme sind - auch das Hydra-Board ist genau auf den Verwendungszweck ausgelegt. Ich weiß nicht ob das wirklich so ein gutes Image ist. Er kann eigentlich mehr als nur Video-Games, aber wie schon damals bei diversen Heim-Computern hat die Werbung und damit verbunden das Image zum Erfolg oder zur Niederlage des Produkts beigetragen. Ist auf jedenfall sehr mutig mal die Mainstream-Schiene zu verlassen und was ganz neues ins Feld zu werfen ... Mfg Thomas Pototschnig
Bin gespannt wie das dann realisert ist. C Compiler für die COGs - kein Problem. Nur ist das nicht alles, denn aus 8x 512 Worten wird oft kein Gesamtprogramm. Und direkt aus dem globalen Speicher lässt sich kein compiliertes Programm ausführen. Irgendeinen Workaround wird also nötig, ob nun Interpreter oder Overlay-Swapping oder was auch immer.
Also das große Problem, was mich persönlich davon abhält ist, dass es keine freien Entwicklungswerkzeuge zu geben scheint. Sonst scheint das Teil wirklich spannend zu sein. Wenn mal jemand einen freien Assembler geschrieben hat welcher auf normalen PCs läuft, dann wird das Teil sicherlich populär werden.
ich benutze ein propellerboard für die fbas-farbdarstellung(linien-grafik und zeichen). gesteuert wird das propellerboard von einem atmega32 der eine art cpu darstellt und ein tastasturanschluss hat.
Christian Berger wrote: > Also das große Problem, was mich persönlich davon abhält ist, dass es > keine freien Entwicklungswerkzeuge zu geben scheint. > Sonst scheint das Teil wirklich spannend zu sein. Wenn mal jemand einen > freien Assembler geschrieben hat welcher auf normalen PCs läuft, dann > wird das Teil sicherlich populär werden. Es gibt natürlich eine frei verfügbare Entwicklungsumgebung (Propeller Tool), leider nur für Win. Es kann sowohl Spin als auch Assembler. Für beide gibt es mittlerweile sehr gute englische Tutorials im Netz. Hier die Downloadseite: http://parallax.com/ProductInfo/Microcontrollers/PropellerDownloads/tabid/442/Default.aspx Hier findet sich eine Sammlung an Spin-Objekten: http://obex.parallax.com/ Der Propeller ist zur Zeit hier in Deutschland recht unbekannt, vermutlich liegt es teilweise auch an der riesigen Übermacht der AVR's :-). Die Umstellung auf einen 32-bitter fällt offensichtlich AVR-Fans sehr schwer. Es ist halt ein grundlegend anderes Konzept, das einiges an Umdenken erfordert. Dafür sind ganz andere Dinge realisierbar. Um dies zu ändern bin ich gerade dabei, ein modulares Entwicklungsboard für den Propeller fertigzustellen mit den meist benötigten Komponenten direkt onboard (2*16 LCD, 3,3V und 5V Spannungsregler, 5 Taster, FT232-USB-Wandler, Coprozessor usw.) An Erweiterungsmodulen sind bisher fertiggestellt: USB-Host, Netzwerkschnittstelle, 868 MHz Funk, 8-Fach Relaisboard, Steckboard mit Pegelwandlern. Weitere sind in Vorbereitung. In etwa 4 Wochen wird das Board veröffentlicht bzw. zu kaufen sein; im Moment baue ich dazu gerade eine Webseite mit Dokumentation und deutscher Programmiereinführung. Ein entsprechendes Forum wird ebenfalls bereitgestellt. Falls Interesse besteht, so kann ich gerne ein kurzes Rundmail schicken, sobald alles Online ist. Dazu bitte ein kurzes PM mit E-Mailadresse an mich. Gruss
Carbolo Crb wrote: > Es gibt natürlich eine frei verfügbare Entwicklungsumgebung (Propeller > Tool), leider nur für Win. Es kann sowohl Spin als auch Assembler. Für > beide gibt es mittlerweile sehr gute englische Tutorials im Netz. Die Software mag vielleicht kostenlos sein, frei ist sie jedoch nicht. Ich müsste mir jetzt extra dafür einen Windows-Rechner kaufen. > Um dies zu ändern bin ich gerade dabei, ein modulares Entwicklungsboard > für den Propeller fertigzustellen mit den meist benötigten Komponenten > direkt onboard (2*16 LCD, 3,3V und 5V Spannungsregler, 5 Taster, > FT232-USB-Wandler, Coprozessor usw.) Coprozessor? > Falls Interesse besteht, so kann ich gerne ein kurzes Rundmail schicken, > sobald alles Online ist. Dazu bitte ein kurzes PM mit E-Mailadresse an > mich. > > Gruss Woher bekommt man die Chips überhaupt in Deutschland?
Christian Berger wrote: > Die Software mag vielleicht kostenlos sein, frei ist sie jedoch nicht. > Ich müsste mir jetzt extra dafür einen Windows-Rechner kaufen. :-) bei mir am PC (etwa 6 Jahre alt) wohnen Ubuntu und WinXP ganz friedlich nebeneinander. Alternativ geht es mit einem Emulator wie WMware o.ä. auch sehr einfach. Als dritte Möglichkeit wären die Windows-Live-CDs zu nennen, z.B. BartPE > Coprozessor? Ja, Coprozessor. Ist für die Steuerung des LCD zuständig, bzw. für die Taster. Ein paar LEDs hängen auch noch dran und zum Spannung messen kann man es auch verwenden. So spare ich am Propeller jede Menge Pins. Das Board kann bei voller Funktionalität 30-pins des Propeller bereitstellen... > Woher bekommt man die Chips überhaupt in Deutschland? Wird z.B. auch bei mir im Shop zu kaufen sein.
Carbolo Crb wrote: > Christian Berger wrote: > >> Die Software mag vielleicht kostenlos sein, frei ist sie jedoch nicht. >> Ich müsste mir jetzt extra dafür einen Windows-Rechner kaufen. > > :-) bei mir am PC (etwa 6 Jahre alt) wohnen Ubuntu und WinXP ganz > friedlich nebeneinander. > > Alternativ geht es mit einem Emulator wie WMware o.ä. auch sehr einfach. > > Als dritte Möglichkeit wären die Windows-Live-CDs zu nennen, z.B. BartPE Für alles bräuchte ich jedoch eine Windows-Lizenz. Und die kostet so viel, dass die Hardware nicht mehr ins Gewicht fällt. Inzwischen sind wir ja so weit, dass Du mehrere PCs für den Preis einer Windows-Lizenz bekommst. >> Coprozessor? > > Ja, Coprozessor. Ist für die Steuerung des LCD zuständig, bzw. für die > Taster. Ein paar LEDs hängen auch noch dran und zum Spannung messen kann > man es auch verwenden. So spare ich am Propeller jede Menge Pins. Das > Board kann bei voller Funktionalität 30-pins des Propeller > bereitstellen... Ahh, verstehe. >> Woher bekommt man die Chips überhaupt in Deutschland? > > Wird z.B. auch bei mir im Shop zu kaufen sein. OK, kannst Du dass dann hier schreiben, wenn Du so weit bist?
...Ich müsste mir jetzt extra dafür einen Windows-Rechner kaufen..... schmeiss dein bastel-linux runter und du holst dir eine lizenz für windows.(geiz is geil).
Mit dem sogenannten Hartz-4System(Linux) gibt es doch viele Unstimmigkeiten bei der Hardware.
Bitte missbraucht diesen Thread nicht auch noch für eine Windows <-> Linux Diskussion, er musste schon für so vieles herhalten (68000, VonNeumann - RISC usw.). Hier geht es um den Propeller Chip. Es wäre natürlich wünschenswert auch Programmierumgebungen in Linux und MacOS zu haben. Einige Leute arbeiten auch schon daran, so gibt es einen Assembler in Java geschrieben, Code-Downloader in Python, und auch eine Java-VM versuchen gerade einige zu realisieren. Es wurde in früheren Beiträgen oft die Frage aufgeworfen, wieso der Propeller diese SPIN Interpreter Sprache verwendet. 1). Das muss er ja nicht, das ist einfach die Sprache die Parallax gratis zur Verfügung stellt. 2). ist SPIN keine reine Interpreter Sprache, der Source wird in einen Bytecode compiliert, der dann von einer SPIN-VM (Virtual Machine) ausgeführt wird. Sehr ähnlich wie Java. Das spart erheblich Speicher, und ermöglicht den Bytecode im grösseren globalen RAM zu haben, da in das kleine Cog-RAM nicht viel hineinpassen würde. Das Cog-RAM ist aber bestens geeignet um Assembler-Programme auszuführen. Die Chips bekommt man übrigens z.B. beim Elektronikladen oder beim europäischen Parallax Distributor Zeko (www.zerko.ch). Gruss Andi
Angehängte Dateien:
-
MeinPropeller.jpg
71 KB
Natürlich gibt es den Propeller auch bei digi-key, wenn man da gerade was bestellt... Bei 5 Stück glaube ich 9,50, ev. noch plus MWst. Ich (und andere auch) beantworten gerne ALLE Fragen zum Propeller. Es gibt da keine Geheimnisse, Unklarheiten oder Gründe, über irgendetwas spekulieren zu müssen... Richtig ist jedoch auch, dass es faktisch keine deutsche Szene gibt... Man braucht kein "Board". Ich mache seit einiger Zeit kleine Kurse, und wir fangen immer mit dem Anfang an. Wenn ich jetzt hier ein "Bildchen" poste, dann ist das mit aller Absicht äußerst simpel und primitiv gehalten :-)
Michael P. wrote: > Richtig ist jedoch auch, dass es faktisch keine deutsche Szene gibt... Damit mal ein Anfang gemacht wird: http://www.cool-robotix.de/forum Dieses Forum sollte ursprünglich erst in einigen Wochen als Diskussionsplattform für mein Entwicklungsboard online gehen, daher sind die Kategorien noch eher auf diesen Zweck zugeschnitten. Das kann ich in den nächsten Tagen gerne ändern. Das Forum stelle ich für sachliche Diskussionen rund um den Propeller gerne zur Verfügung. Gruss
Danke, Carbolo, aber natürlich gibt es deutsche Foren, in denen über den Propeller diskutiert wird: http://propellerforum.sps-welt.de/index.php oder http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=34024&postdays=0&postorder=asc&start=29 Allerdings dort gibt es dort nur einmal die Woche ein Posting..oder auch nicht ..
Hallo Michael, den ersten Forum kenne ich natürlich auch, es ist jedoch leider so gut wie tot. Liegt vielleicht ein bisschen auch daran, dass der Propeller für den Admin uninteressant geworden ist? Der D40-1 steht im Shop schon eine ganze Weile als "Ausverkauft". Die Diskussion bei Roboternetz ist auf jeden Fall interessant und lesenswert, aber wie du schon sagtest etwas am verebben. Der Propeller ist wohl ohne einem Board á lá RNcontrol_1.4 bzw. RNFRA für den normalen User schwierig zu verwenden. Daher habe ich selbst ja auch ein Entwicklungsboard entwickelt, damit eine Anwendung wie z.B. ein Webserver mit 2-fach USB-Host nicht am Steckbrett aufgebaut werden muss... Für "einfache" Anwendungen ist der Propeller oft etwas überdimensioniert und ein AVR tut es dann genauso. Wie oben schon gesagt: ich stelle mein Forum gerne zur Verfügung und würde mich freuen wenn dort fachliche Diskussionen geführt werden. Damit könnte dort auch Wissen über etwas professionelle Anwendungen auf Deutsch gesammelt werden, in denen der Propeller etwas mehr macht als nur einige Servos o.ä. anzusteuern. Gruss
Boards sind natürlich wichtig. Eine größere Auswahl "belebt die Konkurrenz" :-) Auch der OP dieses Threads hat ein kleines Board entwickelt, das man (als Leerplatine) irgendwo kaufen kann; die original Parallax Boards sind ausgezeichnet und kosten zwischen 25 und 125 Dollar. Im angegebenen Roboternetz-Link haben Hanno Hupmann und Sigo jeder ganz schnelle ein minimales eigenes Board geätzt. Ich selbst baue sowas meist innerhalb einer Stunde auf einer Lochstreifenplatine (25 Cuts, am Besten mit einer kleinen Kegelfräse, 40p Fassung, 4 2x20p Buchsenleisten, noch ein paar kleine Anschlüsse, die eine oder andere LED, vielleicht ein Spannungsregler...) Manchmal dauert es dann eben ZWEI Stunden... Für den ABSOLUTEN Anfänger ist ein fertiges Board besser, weil er sofort mit "Software" (oder was er dafür hält) anfangen kann. Für den Profi auch, weil der gar nicht die Zeit für einen doofen Aufbau hat. Wie auch immer: NICHTS am Propeller ist irgendwie komplizierter als an einem MegaAT; das Meiste ist bedeutend einfacher!
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.