Parallax Propeller

Wie war noch die Frage ?

Die kommen vielleicht noch ;.)
Ja, ich weiss ...

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

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.

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

>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

>- 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 ;-)

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

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

> 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

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!

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>

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

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

@Andreas Kaiser (a-k):

Interessant und gut erklärt...

...wie immer :-)

>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

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

>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

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

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

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

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

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

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

>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

So, hiermit hast du endgültig bewiesen, das ich dich nicht im gerinsten 
ernstnehmen muss, Alleswissender Gott...

>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

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

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.

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