mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Parallax Propeller


Autor: Andreas Jakob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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=-8066179290...


Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie war noch die Frage ?

Autor: Andreas Jakob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die kommen vielleicht noch ;.)
Ja, ich weiss ...

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich vermute, die sind darauf optimiert, damit ne Propeller-Clock zu 
bauen :)


Peter

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wie war noch die Frage ?

Welche Frage? Oder unterliegst du dem Irrglauben, man dürfe hier nur 
Fragen posten?

Autor: Andreas Jakob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Andreas Jakob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ü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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also doch SPAM.

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Also doch SPAM.

Dein geschreibsel schon. Kannst du ja in Zukunft weglassen.

Ich fand vor allem den letzten Beitrag interessant ...

Mfg
Thomas Pototschnig

Autor: Michael Waiblinger (wiebel42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ob sie ihn dann wohl Turboprop nennen? ;)

Klingt auf jeden Fall spannend

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael Waiblinger (wiebel42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: u808 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>.. 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;)

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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

Autor: Andreas Jakob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Jakob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
Youtube-Video "Commodore 64 Demomania!"

Gruß,
Christian

Autor: antworter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Carbolo Crb (carbolo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kinnnnnners,

muss denn alles in der Luft zerrissen werden, was man selber nicht 
verwenden kann?

Gruss:

Z

Autor: antworter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 
?

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Carbolo Crb (carbolo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
> Youtube-Video "Commodore 64 Demomania!"

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 :-)

Autor: hackklotz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>- 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.

Autor: Tippgeber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmmm,

einen Propeller werd ich mir wohl mal zulegen, und zwar hierfür:

http://forums.parallax.com/forums/default.aspx?f=2...
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 ;-)

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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:
>> Youtube-Video "Commodore 64 Demomania!"

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

Autor: Carbolo Crb (carbolo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: u808 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist daran unfair? Was spricht dagegen sowas mit vielleicht nur 4 
CPUs aber dafür Grafik, Sound usw. zu machen?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Carbolo Crb (carbolo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: antworter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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>

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Carbolo Crb (carbolo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:-)))))))))

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

Autor: antworter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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).

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: antworter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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)...

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: antworter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas Kaiser (a-k):

Interessant und gut erklärt...

...wie immer :-)

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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).

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: auch_ein_Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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=2...

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

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja doll..
Ports auslesen und rüberschieben -- dafür braucht man UNBEDINGT nen µC 
..

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: neuer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Äää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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: Gast Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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) :) ...?

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: neuer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
....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.

Autor: david314 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Master Snowman (snowman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Andreas Jakob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: der x.-ste (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.)

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Carbolo Crb (carbolo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Carbolo Crb (carbolo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: antworter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: der x.-ste (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Carbolo Crb (carbolo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Carbolo Crb (carbolo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Christian Erker (Gast)
Datum:

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

Autor: Carbolo Crb (carbolo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:-) 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

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: David Madlener (david314)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Christian Erker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Carbolo Crb (carbolo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...mir fehlen die Worte......

Gruss:

Z

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Carbolo Crb (carbolo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/P...

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

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Carbolo Crb (carbolo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...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).

Autor: neuer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit dem sogenannten Hartz-4System(Linux) gibt es doch viele 
Unstimmigkeiten bei der Hardware.

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael P. (desilva)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Carbolo Crb (carbolo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael P. (desilva)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?...

Allerdings dort gibt es dort nur einmal die Woche ein Posting..oder auch 
nicht ..

Autor: Carbolo Crb (carbolo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael P. (desilva)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.