Forum: Mikrocontroller und Digitale Elektronik Wofür Propeller von Parallax ?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Mike ... (Gast)


Lesenswert?

Ich war überrascht von der Neuankündigung des Propeller 2, war davon 
ausgegangen das die schon ewig pleite sind.
Wo wird der controller eingesetzt und warum?
Welche Daseinsberechtigung hat er noch?
Nutzt ihn hier noch jemand?
Welche Vorzüge hat er?

:
von Stefan F. (Gast)


Lesenswert?

Die Vorzüge wird dir sicher der Hersteller in epischer Breite 
beschrieben. Hast du mal in seine Doku geschaut?

Nach meinem Kenntnisstand zum Propeller (1) wird der ausschließlich von 
wenigen Hobbybastlern verwendet, die glauben, damit sei Multitasking 
viel einfacher und besser umsetzbar, als auf die herkömmliche Art.

Ist es natürlich nicht. Zwar bringt der Chip einen praktischen Task 
Scheduler mit, aber der bietet zu wenig Einstellmöglichkeiten um den 
Chip sinnvoll auszunutzen und die Probleme des gemeinsamen Datenzugriffs 
nebenläufiger Threads löst er gar nicht. Aber genau das ist der 
komplizierteste Teil.

Alle Produkte, wo ich diesen Chip drin gesehen habe, waren 
Experimentier-Boards für Bastler. Offenbar ist dieser Chip so 
interessant wie eine achtköpfige Schlange, aber auch genau so 
unattraktiv für die reale Anwendung.

(Disclaimer für die beiden Lügen-Jäger: Das ist meine persönliche 
Meinung. Ich behaupte nicht, hiermit eine wissenschaftlich korrekte 
Wahrheit zu vertreten.)

von Tim  . (cpldcpu)


Lesenswert?

Stefan ⛄ F. schrieb:
> Die Vorzüge wird dir sicher der Hersteller in epischer Breite
> beschrieben. Hast du mal in seine Doku geschaut?

Wenn man sich die Story von Parallax anschaut, dann ist klar, dass die 
ihr Geld mit dem Bestandsgeschäft verdienen (Education). Wenn die ihre 
Designs einfach auf irgendeinen Standard CM4 portieren würden, würde das 
Geschäft einfach weiter laufen...

Der Propeller 2 ist wohl eher eine Art Hobbyprojekt des Gründers. Warum 
auch nicht? Man kann mit einem kleinen und dedizierten Team auch ICs 
entwickeln, und das häufig zu einem Bruchteil der Kosten bei einer 
großen Firma.

: Bearbeitet durch User
von Wühlhase (Gast)


Lesenswert?

Ich hab mir den mal angesehen weil ich überlegt habe, mich ernsthaft in 
das Teil einzuarbeiten. Es ist bisher bei den Überlegungen geblieben, 
aber das liegt nicht am Propeller. Ich fand das Konzept sehr 
interessant.

Wenn ich das damals richtig verstanden habe war die Intention hinter dem 
Design, sich seine Controllerperipherie selber schnitzen zu können. Wenn 
du insgesamt nur geringe Anforderungen hast, aber ein besonders 
leistungsfähiges Peripherieelement brauchst das es sonst nur in größeren 
Controllern gibt, bist du mit dem Konzept vom Propeller besser dran. Ich 
denke da z.B. an den High-Resolution-Timer von ST, oder wenn du zwei 
spezielle Kommunikationskanäle brauchst die es in dieser Kombination 
nicht oder nur in größeren Controllern gibt.

von Tim  . (cpldcpu)


Lesenswert?

Wühlhase schrieb:
> Wenn ich das damals richtig verstanden habe war die Intention hinter dem
> Design, sich seine Controllerperipherie selber schnitzen zu können. Wenn
> du insgesamt nur geringe Anforderungen hast, aber ein besonders

Ja, so etwas ähnliches gibt es auch von XMOS und von Padauk. XMOS hat 
sich in der Audio-Nische etabliert. Padauk scheint nur wenige typen mit 
mehreren Cores/Threads zu haben, ein wirklicher Durchbruch scheint es 
nicht zu sein.

von c-hater (Gast)


Lesenswert?

Tim  . schrieb:

> Der Propeller 2 ist wohl eher eine Art Hobbyprojekt des Gründers.

Immerhin scheint er ja doch noch irgendwie damit fertig geworden zu 
sein. Das war komplett an mir vorbei gegangen, ich dachte, das Teil wäre 
immer noch in der "Entwicklung", was es ja so ungefähr seit 2007/2008 
war, als es das erste Mal angekündigt wurde...

Wie auch immer, ich werde mir das auf jeden Fall mal genauer anschauen, 
insbesondere unter dem Aspekt, inwieweit die offensichtlichen 
konzeptionellen Schwächen des ersten Propeller ausgemerzt wurden.

Aber selbst, wenn das perfekt passen würde: der Preis für das Teil ist 
weit jenseits von Gut und Böse. $150 für ein "Evalboard", was außer dem 
Controller  selber so gut wie nichts enthält, das ist schon heftig und 
läßt darauf schließen, dass der Controller viel zu teuer ist, um im 
Wettbewerb bestehen zu können, selbst wenn er wirklich gut brauchbar 
wäre.

Aber ich denke sowieso, dass das Konzept keine wirkliche Chance hat, da 
es mittlerweile schon in der Unterstufe der µC recht verbreitet Teile 
mit "FPGA"-Units gibt, die eine andere (meist schnellere und bessere) 
Lösung für das gleiche Problem bieten können, was der Propeller 
adressiert, nämlich die Bereitstellung frei programmierbarer Einheiten 
statt fest "verdrahteter" Peripherie. Und auch die "fest verdrahtete" 
Peripherie hat sich doch massiv gewandelt, seitdem die Propeller-Idee 
geboren wurde. Inzwischen ist die vielfach so wandelbar und anpassbar 
geworden, dass sie fast alles Denkbare an Funktionalität erschlagen 
kann, insbesondere, wenn man sie auch noch mit diesen eingebauten 
"FPGA"-Einheiten kombiniert.

Also zusammengefaßt: Ich glaube, dass der Propeller2 keine große Zukunft 
haben wird, weil es das Problem einfach nicht mehr gibt, was das 
Propeller-Konzept lösen sollte.

von Stefan F. (Gast)


Lesenswert?

Alleine schon die Idee, ihn mit einer ganz speziellen Programmiersprache 
zu programmieren die nur auf diesem einen Controller läuft, halte ich 
für ein No-Go.

Selbst um Java und LUA (auf Mikrocontrollern) ist es ziemlich ruhig 
geworden.

von Olaf (Gast)


Lesenswert?

> Nach meinem Kenntnisstand zum Propeller (1) wird der ausschließlich von
> wenigen Hobbybastlern verwendet, die glauben, damit sei Multitasking
> viel einfacher und besser umsetzbar, als auf die herkömmliche Art.

Naja, echtes Multitasking mit dedizierten Cores ist schon besser wenn
du sehr spezielle sehr timingkritische Anwendungen hast. Wo du die Wahl 
hast es entweder mit einem Propeller hinzubekommen oder ein FPGA (teuer) 
zu nehmen. Vergleich das mal mit der TPU bei einem 68332 oder den im 
vergleich dazu armseligen Versuchen von Silabs/Gecko Interaktion ohne 
laufenden Core zu ermoeglichen.

Und wenn du siehst das NXP sich ja auch die Muehe macht Controller mit 
mehreren Cores zu entwickeln dann wird es dafuer Anwendungen geben. Ich 
kenne sogar eine aber ohne NDA kann ich darueber nicht reden. .-)

> Alleine schon die Idee, ihn mit einer ganz speziellen Programmiersprache
> zu programmieren die nur auf diesem einen Controller läuft, halte ich
> für ein No-Go.

Ich auch wenn man es aus dem Blickwinkel eines 
Durchschnittsprogrammierers sieht. Aber wenn die Alternative FPGA heisst 
wo du eine Haelfte in Verilog und die andere in der Spraches deines 
Softcores programmierst dann kann das wieder interessant werden. Ich 
wuerde nicht davon aussehen das in so einem Propeller fette 
Monsteranwendungen programmiert werden.

Allerdings denke ich auch das sowas wie der Propeller es schwer haben 
wird. Das passt nicht zum aktuellen Zeitgeist von Abschreibern und 
Codecopy.

Olaf

von Hallo (Gast)


Lesenswert?

Vielleicht nur so ein obsoletes Ding wo die Energie-überschäumenden 
Jungspunde sich austoben können.

von (prx) A. K. (prx)


Lesenswert?

Gängige Compilersprachen passen nicht gut auf die Architektur und 
spezielle Sprachen führen zu einer Insellösung. Um Assembler für einige 
Module kommt man wohl kaum herum.

Nicht skalierbar. Die sehr spezielle Architektur führt zu sehr 
speziellen Lösungen. Reichen die Ressourcen nicht, fängt man anderswo 
praktisch von vorne an.

Wer sich beruflich darauf einlässt, muss schon ein sehr spezielles 
Szenario im Auge haben, das nur damit wirklich gut und günstig lösbar 
ist. Die meisten Entwickler (-Büros) werden sich lieber eine oder zwei 
Controller-Familien ausgucken, mit denen sie in weitem Bereich arbeiten 
können, von klein bis gross. Vereinfacht Knownow-Aufbau und erleichtert 
Code-Reuse.

Lösungen auf viele Threads aufzuteilen kann bei manchen Aufgaben 
notwendig werden. Allerdings handelt man sich dadurch eine Klasse von 
Problemen ein, die man ohne diese Technik nicht hätte. Nebenläufigkeit 
hat Nebeneffekte, das ist ja schon bei einfachen Interrupts der Fall, 
erst recht bei parallelen Threads.

von Robert K. (Firma: Zombieland) (rko)


Lesenswert?

Stefan ⛄ F. schrieb:
> Nach meinem Kenntnisstand zum Propeller (1) wird der ausschließlich von
> wenigen Hobbybastlern verwendet, die glauben, damit sei Multitasking
> viel einfacher und besser umsetzbar, als auf die herkömmliche Art.
und der Vorteil liegt klar auf der Hand, zumal es ja gute Projekte gibt:
https://hive-project.de/

> Ist es natürlich nicht. Zwar bringt der Chip einen praktischen Task
> Scheduler mit, aber der bietet zu wenig Einstellmöglichkeiten um den
> Chip sinnvoll auszunutzen und die Probleme des gemeinsamen Datenzugriffs
> nebenläufiger Threads löst er gar nicht. Aber genau das ist der
> komplizierteste Teil.
das Teil ist vor allen Dingen für Retro-Emulatoren gut und dann macht es 
durchaus auch Sinn.

von Rainer V. (a_zip)


Lesenswert?

Vielleicht sollte man erwähnen, dass der "II" ein Forth-System 
mitbringt, sodaß man mitnichten in der Sprache von Parallax 
programmieren muß. Ob das ein Versuch ist, eine weitere Fangemeinde zu 
erobern, kann ich nicht abschätzen, aber wer jemals mit Forth interaktiv 
mit einem Controller gearbeitet hat, könnte sich da schon angesprochen 
fühlen. Daß die Hardware preislich sowohl Bastler als auch Profis nicht 
gerade lockt, muß trotzdem kein KO-Kriterium sein!
Gruß Rainer

von Zero V. (Firma: Freelancer) (gnd)


Lesenswert?

Auf den ersten Propeller bin ich reingefallen. Alles schien erstmal 
ziemlich cool bis ich dann den Chip aufm Breadboard hatte und nicht mehr 
klar kam. Da gab es diese komische Sprache, SPIN glaube ich und der C 
Compiler war nicht verfügbar.

von Andi (Gast)


Lesenswert?

Der Propeller 2 ist zwar vom Propeller 1 abgeleitet, aber ausser dem 
Konzept der parallelen Prozessoren und dem gemeinsamen grossen RAM hat 
er nicht mehr viel mit dem Ur-Propeller zu tun.
Es gibt jetzt viel mehr RAM und viel schnellere Prozessoren, aber das 
ist nicht so entscheidend, das wirklich spezielle am P2 sind die 
Analogfunktionen in jedem der 64 Pins. Die heben ihn auch
deutlich von FPGAs ab. Jeder Pin hat einen Highspeed DAC eingebaut, der 
bei 8-Bit Auflösung mit bis zu 300 MHz wandeln kann, oder bei 16 Bits 
mit etwa 1 MHz. Ausserdem eine SigmaDelta ADC Einheit mit Sinc2 und 
Sinc3 Hardwarefiltern, die z.B. eine Audio Wandlung mit 18 Bit und 384 
kHz zulassen. Gesteuert werden diese Analogfunktionen von einer Smartpin 
Zelle pro Pin, die sich vielfältig Konfigurieren lässt und neben Dingen 
wie DDS für die DACs auch so profane Periferie wie PWM, SPI oder UART, 
aber auch USB (FS und LS) ermöglicht, man muss dafür nicht mehr 
Prozessoren opfern, und alles in Software machen, wie beim P1.

Eine DMA ähnliche "Streamer" Einheit ermöglicht Video, VGA, und 
beschränkt auch HDMI Ausgabe, sowie den Transfer zwische RAM und Ports 
mit voller Geschwindigkeit, z.B. für Logic Analyzer oder DSO 
Anwendungen.
Eine Cordic Einheit ist zuständig für präzise trigonometrische und 
logarithmische Funktionen, Quadratwurzel, aber auch Multiplikation und 
Division, alles in Integer oder Festkomma, eine FPU gibt es nicht.

Ausser in Spin2 kann man den P2 schon heute in C, BASIC und Forth 
programmieren, auch ein MicroPython wurde schon gesichtet, und C++ ist 
über den Umweg eines Risc-V Emulators möglich, wenn es denn sein muss.

Allerdings stammt nur 'Spin' von Parallax selbst, und auch das ist noch 
eher spärlich mit Bibliotheken für die zahlreichen Features 
ausgestattet. Auch die Dokumentation zum neuen Propeller ist noch sehr 
rudimentär, und Parallax ist da auf die Mithilfe der recht aktiven 
Community angewiesen, da die Firma doch ziemlich geschrumpft ist in den 
letzten Jahren. An der ganzen Entwicklung des Propeller 2 war die 
Community beteiligt, alle Ideen des Entwicklers wurden diskutiert, und 
man konnte durchaus mitreden. Dadurch, und weil Parallax nichts mit 
Fremdkapital finanzieren wollte, hat es auch etwas länger gedauert.

Der Chip ist natürlich ein Nischenprodukt, und das war auch immer klar. 
Parallax könnte niemals mit den grossen Prozessorherstellern mithalten, 
und versucht es auch gar nicht.
Der Preis mag für viele Anwendungen zu hoch sein, aber verglichen mit 
XMOS z.B. ist da kein grosser Unterschied. Entwicklungsboards muss es 
natürlich noch günstigere, und bessere geben, damit sich mehr Leute auf 
den
Chip einlassen.

von Olaf (Gast)


Lesenswert?

> Der Chip ist natürlich ein Nischenprodukt, und das war auch immer klar.

Ich glaub das wollen sie auch so. Ich konnte jedenfalls gerade kein
Datenblatt von dem Teil finden. Das fand ich sehr erstaunlich.

Olaf

von Nick M. (Gast)


Lesenswert?

Damals[tm] hab ich für mich was mit dem Propeller gemacht. Es war ein 
Modbus-Interface für das Handrad meiner Fräsmaschine.
Der Propeller ist von der Idee her ganz interessant und nur desshalb hab 
ich es mit ihm gemacht. Die ursprünglich dafür vorgesehene Sprache 
"Spin" hab ich probiert, aber dann bleiben lassen. Das ist dann doch zu 
verquer. Formatierungsabhängige Sprachen sind mir zu blöd.
Es gab damals einen C-Compiler zu kaufen (Imagecraft), der hat sich aber 
wieder zurückgezogen aus dem Markt wg. nicht wirtschaftlich.
Jedenfalls war der Compiler brauchbar (hatte aber auch Fehler die 
umschiffbar waren).
Mit Spin oder C hat man nicht gemerkt, dass jeder Kern nur 256 (??) 
Worte Speicher hat, das wurde immer vom Kernspeicher nachgeladen.
Programme bei denen die Daten als Strom durchlaufen lassen sich ganz gut 
parallelisieren (wie Transputer). Diese shared Memory ist leicht zu 
handhaben, man muss halt semaphoren setzen.

Ah, dann hab ich noch was gemacht, wurde aber nie ganz fertig:
Eine Zündungsteuerung für Mehrzylindermotoren. Die hatte ziemlich 
absurde Randparameter (Drehzahl, Zylinderzahl), einfach weil es ging.
Da hab ich wesentliche Teile in Assembler geschrieben. Der Befehlssatz 
ist sehr angenehm für handcodierten Assembler, so schön wie 68000er. Und 
in den 256 (??) Worten bringt man viel unter.

Problem bei dem Ding ist:
Es gibt nur eine Variante. Speicher aus? Was anderes verwenden!

Fürs Hobby oder nur aus reinem Interesse ist das wirklich mal spannen 
auszuprobieren. Kommerziell: Finger weg, ausser man hat eine ganz 
spezielle Aufgabe.


Da würde ich lieber einen XMOS verwenden. Es scheint aber, dass XMOS die 
Weiterentwicklung seiner Prozessoren eingestellt hat. Letztes Jahr 
wollte ich ein Projekt damit machen, aber es gab nicht mal mehr 
DevBoards. In XDev nachgefragt ist eine maximal schwammige Antwort von 
offizieller Seie gekommen die mich davon abgehalten hat noch irgendwas 
mit den Prozessoren zu machen. Leider ist die IDE von XMOS auch 
stehengeblieben, Bugs werden da nicht mehr beseitigt. Die IDE läuft auch 
nur wirklich unter Linux, MacOS und Win haben Speicherprobleme.

Ich hab nebenbei auch die Propeller II Entwicklung verfolgt. Da gab es 
paar Leute die den Entwickler immer neue schräge Sachen aufgequatscht 
haben. Und inzwischen ist das wohl ein arges Kommitee-Design geworden. 
Von Anfang an wurde das parallel auf einem FPGA implementiert (Board >> 
1000 €). Irgendwelche Sachen gehen besser, die Taktfrequenz schein 
deutlich höher zu sein. Aber das gleiche Problem: Nur eine Variante.

von René K. (king)


Lesenswert?

Nick M. schrieb:
> Mit Spin oder C hat man nicht gemerkt, dass jeder Kern nur 256 (??)
> Worte Speicher hat, das wurde immer vom Kernspeicher nachgeladen.

Kernspeicher???
https://de.wikipedia.org/wiki/Kernspeicher

von Nick M. (Gast)


Lesenswert?

René K. schrieb:
> Kernspeicher???

Du kannst gerne selbst versuchen das Rätsel aufzulösen. Es hilft, sich 
mit der Architektur des Propeller zu beschäftigen.

von Carl D. (jcw2)


Lesenswert?

René K. schrieb:
> Nick M. schrieb:
>> Mit Spin oder C hat man nicht gemerkt, dass jeder Kern nur 256 (??)
>> Worte Speicher hat, das wurde immer vom Kernspeicher nachgeladen.
>
> Kernspeicher???
> https://de.wikipedia.org/wiki/Kernspeicher

Eigentlich Hub-Memory (32k geshared). Im Gegensatz zu Cog-Memory (1k 
oder 256 32-Bit Worte)

: Bearbeitet durch User
von c-hater (Gast)


Lesenswert?

Andi schrieb:

> das wirklich spezielle am P2 sind die
> Analogfunktionen in jedem der 64 Pins. Die heben ihn auch
> deutlich von FPGAs ab. Jeder Pin hat einen Highspeed DAC eingebaut, der
> bei 8-Bit Auflösung mit bis zu 300 MHz wandeln kann, oder bei 16 Bits
> mit etwa 1 MHz. Ausserdem eine SigmaDelta ADC Einheit mit Sinc2 und
> Sinc3 Hardwarefiltern, die z.B. eine Audio Wandlung mit 18 Bit und 384
> kHz zulassen. Gesteuert werden diese Analogfunktionen von einer Smartpin
> Zelle pro Pin, die sich vielfältig Konfigurieren lässt und neben Dingen
> wie DDS für die DACs auch so profane Periferie wie PWM, SPI oder UART,
> aber auch USB (FS und LS) ermöglicht, man muss dafür nicht mehr
> Prozessoren opfern, und alles in Software machen, wie beim P1.

Na gut, dann konkurriert das Teil also weniger mit FPGAs als vielmehr 
mit DSPs. Auch die haben allerdings mittlerweile Einzug in viele übliche 
µC-Architekturen gehalten.

Und dazu kommt: bei praktisch allen aktuellen µC-Familien gibt es zwar 
auch integrierte ADCs, aber praktisch sind die alle mehr oder weniger 
huppse, wenn auch noch Genauigkeit eine Rolle spielt. Der Störnebel der 
räumlich sehr nahen MCU-Kerne mit extremen Transienten (praktisch der 
gesamte Leistungsumsatz geschieht nur an den Taktflanken) verhindert, 
dass damit wirklich genaue Einzelmessungen gemacht werden können.

Und das wird vermutlich beim P2 nicht viel anders sein. Auch Parallax 
muss sich wohl am Ende den Gesetzen der Physik beugen.

von René F. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Nach meinem Kenntnisstand zum Propeller (1) wird der ausschließlich von
> wenigen Hobbybastlern verwendet, die glauben, damit sei Multitasking
> viel einfacher und besser umsetzbar, als auf die herkömmliche Art.

Das möchte nicht in meinen Kopf reingehen, für die paar Bastler wird es 
sich doch garantiert nicht lohnen einen eigenen Chip fertigen zu lassen, 
und mit den geringen Preisen < 10€ pro Chip scheint sich das Teil doch 
gut genug zu verkaufen. Ich gehe davon aus, das es einige Produkte damit 
gibt, vielleicht keine Massen-Consumer-Ware aber doch Produkte mit 
halbwegs rentablen Stückzahlen.

von c-hater (Gast)


Lesenswert?

René F. schrieb:

> und mit den geringen Preisen < 10€ pro Chip

Das war vielleicht mal gering, heute ist es das nicht mehr. Schau mal in 
den Markt, was du für 10€ heutzutage für Rechenknechte kaufen kannst...

Der einzige Grund, 10€ für einen P1 auszugeben dürfte sein, dass eine 
fertige Lösung für ein bestimmtes Problem damit existiert. Alles andere 
ergibt keinen wirtschaftlichen Sinn.

von Andi (Gast)


Lesenswert?

c-hater schrieb:
> Und dazu kommt: bei praktisch allen aktuellen µC-Familien gibt es zwar
> auch integrierte ADCs, aber praktisch sind die alle mehr oder weniger
> huppse, wenn auch noch Genauigkeit eine Rolle spielt. Der Störnebel der
> räumlich sehr nahen MCU-Kerne mit extremen Transienten (praktisch der
> gesamte Leistungsumsatz geschieht nur an den Taktflanken) verhindert,
> dass damit wirklich genaue Einzelmessungen gemacht werden können.
>
> Und das wird vermutlich beim P2 nicht viel anders sein. Auch Parallax
> muss sich wohl am Ende den Gesetzen der Physik beugen.

Ja, der Analogteil wurde auch mit Rücksicht darauf als 'Custom-Silicon' 
designt, und Gruppen von 4 Pins haben je einen eigenen 
Spannungsversorgungspin erhalten, so dass man diese einzeln entkoppeln 
kann.
Trotzdem erreicht der ADC "nur" eine Genauigkeit von etwa 13.5 Bits für 
absolute Spannungsmessungen. Für dynamische Signale, wie Audio, geht die 
Auflösung aber bis 18 Bits.

---
Übrigens hat schon der P1 512 Worte Programmspeicher pro Prozessor 
gehabt, und nicht 256, der P2 hat einen zusätzlichen RAM Block von 512 
Worten, der auch zur Programmausführung benutzt werden kann. Ausserdem 
kann nun Programmcode auch vom grossen Hauptram direkt ausgeführt 
werden, nur Sprünge benötigen dabei etwas mehr Zeit, da ein FIFO 
nachgeladen werden muss.

von chris_ (Gast)


Lesenswert?

Bis jetzt fehlt hier noch der Link:

https://www.parallax.com/propeller-2/

Die Seite braucht aber ewig zum laden.

von Egon D. (Gast)


Lesenswert?

(prx) A. K. schrieb:

> Lösungen auf viele Threads aufzuteilen kann bei
> manchen Aufgaben notwendig werden. Allerdings
> handelt man sich dadurch eine Klasse von Problemen
> ein, die man ohne diese Technik nicht hätte.

Ich würde es eher umgekehrt formulieren: Das
unerschütterliche Festhalten am Begriff des
Algorithmus, der sequenziell ausgeführt wird, ist
schon seit mindestens 20 Jahren ein Anachronismus.
Man handelt sich dadurch Probleme ein, die man ohne
diese Technik nicht hätte :)

von Stefan F. (Gast)


Lesenswert?

Ich wollte gerade mal schauen wie viel der Chip kostet, konnte aber nur 
das teure Eval Board finden. Hat der Chip keinen darüber hinaus gehenden 
Sinn, als evaluiert zu werden?

von (prx) A. K. (prx)


Lesenswert?


von Stefan F. (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Problemlos zu finden: $14.95

Ach, danke. Ich hatte bei Mouser und Digikey nach P2X8C4M64P-ES gesucht.

Ist viel billiger als ich befürchtet hatte.

von mh (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Problemlos zu finden: $14.95

Hast du zufällig auch ein "nicht docs.google" Datenblatt gefunden?

von c-hater (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:

> Ist viel billiger als ich befürchtet hatte.

Aber trotzdem immer noch viel teuerer als angemessen für die Leistung...

von F. M. (foxmulder)


Lesenswert?

Tim  . schrieb:
> Der Propeller 2 ist wohl eher eine Art Hobbyprojekt des Gründers. Warum
> auch nicht? Man kann mit einem kleinen und dedizierten Team auch ICs
> entwickeln, und das häufig zu einem Bruchteil der Kosten bei einer
> großen Firma.

Genau, ist doch schön wenn mal jemand andere Konzepte usw. probiert, der 
Markt regelt es doch sowieso.
So sinnlos wird das Teil auch nicht sein, sonst gäbe es die Firma ja 
nicht.

Muss ja nicht immer alles ST oder Microchip sein.
Ich bin in dem Konzept auch nicht so sehr drinnen, allerdings könnte der 
Propeller schon für manche Nischenanwendung sinnvoll sein, vorallem auf 
CORDIC scheint hier ein direkter Fokus liegen.
Also evtl. VR Geschichten oder Roboter.
Ein paar Industriekunden muss es jedenfalls geben, sonst kann ich mir 
das kaum vorstellen.

von chris_ (Gast)


Lesenswert?

von c-hater (Gast)
28.12.2020 15:50
>Aber trotzdem immer noch viel teuerer als angemessen für die Leistung...

Kommt auf das Problem an. Mit dem Propeller lassen sich zeitsynchrone 
Designs realisieren, die mit konventionellen Prozessoren so gut wie 
nicht realiserbar sind.

von Nick M. (Gast)


Lesenswert?

A. K. schrieb:
> Ich bin in dem Konzept auch nicht so sehr drinnen, allerdings könnte der
> Propeller schon für manche Nischenanwendung sinnvoll sein,

Ich kann nur empfehlen, sich den mal anzuschauen. Leider nicht für den 
Preis von $150 für ein EvalBoard. Der ist interessant. Z.B. gibt es 
keine Interrupts und keinen USART (wie beim XMOS auch).

Einen kommerziellen Einsatz würd ich mir aber dreimal überlegen.

von (prx) A. K. (prx)


Lesenswert?

Ich hatte mir den ersten Propeller angesehen, als er neu war. Fazit: 
Interessante Lösung auf der Suche nach einem passenden Problem. Der 
verwandte Ansatz von XMOS gefiel mir besser.

von Nick M. (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Interessante Lösung auf der Suche nach einem passenden Problem. Der
> verwandte Ansatz von XMOS gefiel mir besser.

Nur hat der XMOS auch so seine Problemchen:
Man kann nicht direkt auf das Shared Memory zugreifen.
Untereinander können die Prozessoren nur mit zwei Methoden 
kommunizieren. Die eine ist schnell und verbraucht sehr begrenzte 
Resourcen, die Andere ist arg langsam.
Ich hab die Namen der Methoden vergessen.

von c-hater (Gast)


Lesenswert?

chris_ schrieb:

> Kommt auf das Problem an. Mit dem Propeller lassen sich zeitsynchrone
> Designs realisieren, die mit konventionellen Prozessoren so gut wie
> nicht realiserbar sind.

Hmm...

Kannst du für so etwas ein Beispiel liefern? Muss jetzt nicht die 
Umsetzung sein, sondern nur eine Art "Prinzipschaltbild", welches das 
Problem beschreibt.

von Nick M. (Gast)


Lesenswert?

c-hater schrieb:
> Kannst du für so etwas ein Beispiel liefern?

Während ein Prozessor z.B. über die Schnittstelle Daten einliest, kann 
ein zweiter parallel schon anfangen die Daten in einzelne Datensätze zu 
zerlegen und die bis jetzt schon vollständig erhaltenen vom nächsten 
Prozessor ausführen lassen.

von c-hater (Gast)


Lesenswert?

Nick M. schrieb:

> Während ein Prozessor z.B. über die Schnittstelle Daten einliest, kann
> ein zweiter parallel schon anfangen die Daten in einzelne Datensätze zu
> zerlegen und die bis jetzt schon vollständig erhaltenen vom nächsten
> Prozessor ausführen lassen.

Sowas kann man mit jedem gängigen µC mit nur einem Core machen, indem 
man die Interrupts der Peripherie benutzt. Also das allein kann's ja nun 
wirklich nicht sein.

von Einer K. (Gast)


Lesenswert?

Es gibt ja noch mehr Ansätze, welche auf massive Parallelverarbeitung 
setzen
Z.B. http://www.greenarraychips.com/home/products/index.html
Aber der scheint den wirtschaftlichen Arsch auch nicht hoch zu bekommen

von Nick M. (Gast)


Lesenswert?

c-hater schrieb:
> Also das allein kann's ja nun
> wirklich nicht sein.

Sagt dir Transputer und Occam was?
Nein? Dann lies das bitte auf Wikipedia nach.
Ja? Warum frägst du nach Beispielen?

von Nick M. (Gast)


Lesenswert?

Arduino Fanboy D. schrieb:
> Es gibt ja noch mehr Ansätze, welche auf massive Parallelverarbeitung
> setzen

Interessant!

von MCUA (Gast)


Lesenswert?

Ein CPU-Kern mit x-facher Geschwind. kann eine CPU mit x Kernen 
ersetzen, wenn für ContextSwich, ISR usw, nicht zu viele Clocks 
verschwendet werden.
Unbedingt mehr Kerne macht man nrm. nur, wenn man mit der f am Anschlag 
ist.

von Gerhard O. (gerhard_)


Lesenswert?

chris_ schrieb:
> von c-hater (Gast)
> 28.12.2020 15:50
>>Aber trotzdem immer noch viel teuerer als angemessen für die Leistung...
>
> Kommt auf das Problem an. Mit dem Propeller lassen sich zeitsynchrone
> Designs realisieren, die mit konventionellen Prozessoren so gut wie
> nicht realiserbar sind.

Inwieweit wäre dann eine FPGA Lösung eine theoretische sinnvolle 
Alternative zum Propeller wenn es darauf ankommt? Irgendwie finde ich 
den FPGA Ansatz prinzipiell sauberer.

Wie oft kommen solche Fälle vor wo ein schneller uC nicht mehr klar 
kommt? Was mich betrifft hatte ich noch nie Anwendungen zu erstellen die 
ein schneller uC nicht bewältigen konnte. Aber meine Anwendungen sind 
alle in Richtung Kommunikation und MSR.

Ich kannte in der Stadt eine Firma wo Propeller serienmäßig kommerziell 
eingesetzt wurden. Allerdings wurde dem Ingenieur (Firmeninhaber) 
nachgesagt es wäre eine persönliche eigenwillige Marotte von ihm 
gewesen. Die Kollegen wollten eigentlich von dem Teil eher nichts wissen 
und entwickelten lieber mit konventionellen uC.

von Nick M. (Gast)


Lesenswert?

Gerhard O. schrieb:
> Inwieweit wäre dann eine FPGA Lösung eine theoretische sinnvolle
> Alternative zum Propeller wenn es darauf ankommt? Irgendwie finde ich
> den FPGA Ansatz prinzipiell sauberer.

Daher kommt ja die Aussage, dass das wie ein FPGA ist. Wobei jeder der 
das sagt weiß, dass es maßlos übertrieben ist. Gilt auch für den xmos.
Man hat halt 8 Prozessoren die entweder völlig autark oder auch beliebig 
zusammen arbeiten können.
Das ist nie so schnell wie FPGA, das ist nie so wirklich parallel wie 
FPGA, das ist nie so kombinatorisch wie FPGA. Aber jeder der C 
programmieren kann bekommt das hin. Beim xmos ist es etwas schwieriger, 
das XC braucht etwas Einarbeitung.

Also hängt der Propeller (oder der xmos) irgendwo zwischen µC und FPGA. 
Aber deutlich näher am µC als am FPGA. xmos ist etwas näher am FPGA, 
aber auch nicht mal auf halber Strecke.

von Malte _. (malte) Benutzerseite


Lesenswert?

c-hater schrieb:
>> Während ein Prozessor z.B. über die Schnittstelle Daten einliest, kann
>> ein zweiter parallel schon anfangen die Daten in einzelne Datensätze zu
>> zerlegen und die bis jetzt schon vollständig erhaltenen vom nächsten
>> Prozessor ausführen lassen.
>
> Sowas kann man mit jedem gängigen µC mit nur einem Core machen, indem
> man die Interrupts der Peripherie benutzt. Also das allein kann's ja nun
> wirklich nicht sein.
Eigentlich jedes Problem, wo man zwei sehr zeitkritische Protokolle 
gleichzeitig bearbeiten muss.
Ich hatte mal einen USB AtXmega Programmer basierend auf einem Atmega 
nachgebaut (fertiges Projekt). Das ganze basierte auf Software USB und 
einem Programmierprotokoll in Software. Nur funktioniert der USB Stack 
(VUSB) nur, wenn der Interrupt auch innerhalb von ~10 Taktzyklen mit der 
Bearbeitung beginnt. Umgekehrt verliert der Xmega nach wenigen µs ohne 
Takt (der USB Interrupt braucht länger) die Verbindung. Das angeblich 
fertige Projekt reichte um in 30% der Fällen zumindest die Xmega 
Signaturbits zu lesen - an eine Programmierung war damit nicht zu 
denken.
Nach zu vielen Stunden und Versuchen das Xmega Protokoll im Interrupt 
des USB Handlers mit Assembler weiter auszuführen, bin ich zu dem 
Schluss gekommen, dass man zwei AVRs bräuchte. Jeder der ein 
zeitkritisches Protokoll handelt und ein zeitunkritisches Protokoll 
zwischen den beiden. Hier wäre ein Chip mit mehr als einem Kern genau 
richtig gewesen. Alternativ hätte man das ganze natürlich auch mit purer 
Rechenleistung erschlagen können.
Am Ende hab ich aber einfach für 30€ einen fertigen Xmega Programmer 
gekauft.

von Nick M. (Gast)


Lesenswert?

Gerhard O. schrieb:
> Irgendwie finde ich den FPGA Ansatz prinzipiell sauberer.

Übersehen darauf noch einzugehen.

Kommt drauf an wo man steht. Es geht schon was mit parallelen 
Prozessoren. Wenn Reaktionszeit kritisch ist (Hausnummer 100 ns) kommt 
man noch tw. hinterher. Muss man sich aber schon gut überlegen. Beim 
FPGA ruft das nur ein müdes Lächeln hervor.
Wenn man gleichzeitig rechnen kann / muss, wirds beim FPGA schwieriger / 
teuerer.

Prinzipiell lässt sich deine Frage nicht beantworten. Fallspezifisch 
schon.

von mh (Gast)


Lesenswert?

Malte _. schrieb:
> Das ganze basierte auf Software USB und
> einem Programmierprotokoll in Software. Nur funktioniert der USB Stack
> (VUSB) nur, wenn der Interrupt auch innerhalb von ~10 Taktzyklen mit der
> Bearbeitung beginnt. Umgekehrt verliert der Xmega nach wenigen µs ohne
> Takt (der USB Interrupt braucht länger) die Verbindung. [...] Hier wäre ein Chip 
mit mehr als einem Kern genau
> richtig gewesen. Alternativ hätte man das ganze natürlich auch mit purer
> Rechenleistung erschlagen können.
Oder man könnte einfach einen 0815-µC mit USB in Hardware nehmen?

von Nick M. (Gast)


Lesenswert?

Gerhard O. schrieb:
> Was mich betrifft hatte ich noch nie Anwendungen zu erstellen die
> ein schneller uC nicht bewältigen konnte. Aber meine Anwendungen sind
> alle in Richtung Kommunikation und MSR.

Ich hab spaßeshalber (für eine Bewerbung) einen PID-Regler mit FF0..FF2 
und roll up auf xmos implementiert. Der hat 750 kHz geschafft. Ich denk 
der Wert dürfte überzeugen.

von Lothar (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> damit sei Multitasking viel einfacher und besser umsetzbar

Es gibt nur zwei Möglichkeiten, zwei Threads echt nebenläufig zu machen, 
und das ist AMP ohne OS mit zwei Kernen mit Shared Memory - oder das 
Propeller Konzept

Da sich das Propeller Konzept nicht durchgesetzt hat, bleiben nur noch 
zwei Kerne, und daher finden sich inzwischen in allen uC Familien dafür 
welche mit zwei Kernen z.B.

https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mcus/lpc5500-cortex-m33:LPC5500_SERIES

Mit DMA oder ART geht keine echte Nebenläufigkeit.

von Nick M. (Gast)


Lesenswert?

Lothar schrieb:
> das ist AMP ohne OS mit zwei Kernen mit Shared Memory

Wie wird denn da der gemeinsame Zugriff aufs RAM geregelt? Mir geht es 
hier nicht um nicht-atomare Zugriffe.
Was ich meine ist das interlaced, wird eine CPU angehalten, ist das dual 
ported RAM oder wie läuft das?
Denn "shared memory" kann man ja auch mit nur einer CPU und mit 
Task-switching (ohne FSM) machen.

von Lothar (Gast)


Lesenswert?

Nick M. schrieb:
> Wie wird denn da der gemeinsame Zugriff aufs RAM geregelt?

Hier geht es um einen älteren Dual-Core uC - hat sich aber nichts 
geändert:

https://www.nxp.com/company/blog/an1117-ipc-on-lpc43xx-managing-inter-processor-communications-in-the-dual-core-lpc4300:BL-AN1117-IPC-ON-LPC43XX

von Wühlhase (Gast)


Lesenswert?

c-hater schrieb:
> Nick M. schrieb:
>
>> Während ein Prozessor z.B. über die Schnittstelle Daten einliest, kann
>> ein zweiter parallel schon anfangen die Daten in einzelne Datensätze zu
>> zerlegen und die bis jetzt schon vollständig erhaltenen vom nächsten
>> Prozessor ausführen lassen.
>
> Sowas kann man mit jedem gängigen µC mit nur einem Core machen, indem
> man die Interrupts der Peripherie benutzt. Also das allein kann's ja nun
> wirklich nicht sein.

Nein. Gänge µCs mit einem Kern kannst du nur von jeder der Aufgaben nur 
eine erledigen lassen. Entweder Daten einlesen oder Daten verarbeiten 
oder Daten ausgeben. Aber niemals gleichzeitig.

War hier nicht vor einigen Wochen ein Thread, wo jemand einen "gängigen 
µC" als SPI-Slave laufen lassen wollte? Wenn ich mich recht erinnere 
haben ihm die meisten davon abgeraten, er solle das bitte möglichst 
anders lösen.

Der Propeller wäre für so etwas jedoch richtig gut. Da kann sich ein 
Kern ganz gemütlich auf die Lauer nach dem Chip-Select-Signal legen und 
der Rest kann nach Belieben seinen zeitkritischen Aufgaben nachgehen.

Es ist ja nicht so, daß Interrupts nie stören würden und man da stets 
immer jederzeit darauf reagieren mag. Ich verstehe die Gegenwehr, die 
das bei einigen auszulösen scheint, absolut nicht.
Kennt ihr nur einen Hammer und seid mit Schrauben überfordert?

von mh (Gast)


Lesenswert?

Wühlhase schrieb:
> Nein. Gänge µCs mit einem Kern kannst du nur von jeder der Aufgaben nur
> eine erledigen lassen. Entweder Daten einlesen oder Daten verarbeiten
> oder Daten ausgeben. Aber niemals gleichzeitig.

Das ist ne ziemlich extreme Aussage. Und ich würd sagen, die ist extrem 
falsch.

Wühlhase schrieb:
> War hier nicht vor einigen Wochen ein Thread, wo jemand einen "gängigen
> µC" als SPI-Slave laufen lassen wollte? Wenn ich mich recht erinnere
> haben ihm die meisten davon abgeraten, er solle das bitte möglichst
> anders lösen.

Ich frage mich, warum es dann µC gibt, die SPI-Slave in Hardware machen. 
Was spricht dagegen?

Wühlhase schrieb:
> Der Propeller wäre für so etwas jedoch richtig gut. Da kann sich ein
> Kern ganz gemütlich auf die Lauer nach dem Chip-Select-Signal legen und
> der Rest kann nach Belieben seinen zeitkritischen Aufgaben nachgehen.

Der Propeller ist also gut, weil er ein Problem löst, das man auch 
anders, einfacher und günstiger lösen kann?


Um auf einen etwas älteren Post zurück zu kommen.
Andi schrieb:
> Es gibt jetzt viel mehr RAM und viel schnellere Prozessoren, aber das
> ist nicht so entscheidend, das wirklich spezielle am P2 sind die
> Analogfunktionen in jedem der 64 Pins. Die heben ihn auch
> deutlich von FPGAs ab. Jeder Pin hat einen Highspeed DAC eingebaut, der
> bei 8-Bit Auflösung mit bis zu 300 MHz wandeln kann, oder bei 16 Bits
> mit etwa 1 MHz. Ausserdem eine SigmaDelta ADC Einheit mit Sinc2 und
> Sinc3 Hardwarefiltern, die z.B. eine Audio Wandlung mit 18 Bit und 384
> kHz zulassen. Gesteuert werden diese Analogfunktionen von einer Smartpin
> Zelle pro Pin, die sich vielfältig Konfigurieren lässt und neben Dingen
> wie DDS für die DACs auch so profane Periferie wie PWM, SPI oder UART,
> aber auch USB (FS und LS) ermöglicht, man muss dafür nicht mehr
> Prozessoren opfern, und alles in Software machen, wie beim P1.
Der P2 kann also ~60 ADCs oder DACs haben? Das wäre praktisch, aber 
irgendwie glaub ich das nicht.

von Egon D. (Gast)


Lesenswert?

mh schrieb:

> Entweder Daten einlesen oder Daten verarbeiten
>> oder Daten ausgeben. Aber niemals gleichzeitig.
>
> Das ist ne ziemlich extreme Aussage. Und ich würd
> sagen, die ist extrem falsch.

Nun ja, auf einer sequenziellen Maschine ist die
Aussage sogar per definitionem richtig.

von (prx) A. K. (prx)


Lesenswert?

Und dann wären da noch Maschinen mit rein sequentiellen Programmen, aber 
parallel arbeitender I/O. Also die weitaus meisten Controller, denn 
schon eine simple eingebaute UART kann gleichzeitig rein wie raus.

Der Unterschied zu Propeller oder XMOS liegt in deren Fähigkeit, 
I/O-Module in Software zu implementieren, womit man sich auch Aufgaben 
nähern kann, für die es keine Hardware-Module gibt, und die 
konventionelle Mikrocontroller mangels Echtzeit-Tempo nicht zuwege 
bringen. Sonst müsste man ein FPGA verwenden.

Krasses Beispiel ist Ethernet in Software bei XMOS. Das ist zwar in 
diesem Fall eigentlich Unfug, weil man mit einem echten Ethernet-Modul 
besser dran ist, zeigt aber, was damit geht.

: Bearbeitet durch User
von Egon D. (Gast)


Lesenswert?

(prx) A. K. schrieb:

> Und dann wären da noch Maschinen mit rein sequentiellen
> Programmen, aber parallel arbeitender Hardware. Also
> die weitaus meisten Controller, denn schon eine simple
> eingebaute UART kann gleichzeitig rein wie raus.

Hmpf.

Eine UART ist aber nicht "programmierbar" im Sinne der
Turing-Vollständigkeit -- auch wenn sie natürlich
zahlreiche Betriebsarten kennt, unter denen man
auswählen kann.

Andernfalls wird jeder Prozessor mit Hardware-Multiplizierer
zum massiv parallelen System -- bedenke nur, wieviele
Halb- und Volladder da parallel arbeiten...


> Der Unterschied zu Propeller oder XMOS liegt in deren
> Fähigkeit, I/O-Module durch Software implementieren,
> womit man sich auch Aufgaben nähern kann, für die es
> keine Hardware-Module gibt, und die Mikrocontroller
> mangels Echtzeit-Tempo nicht zuwege bringen.

Das waren ja wohl die Punkte, um die es hier ging.

Das übliche Programmiermodell geht halt von einer
sequenziellen Maschine aus, aber letztlich zeigt
sich m.E. an allen Ecken und Enden, dass das
ergänzungswürdig ist.

von Gerhard O. (gerhard_)


Lesenswert?

Interessanter Thread.

Eigentlich kommt es im praktischen Kontext vielleicht eher darauf an 
datenintensive Peripherien wie USB, Ethernet, USARTS, U.Ä. mit 
entsprechenden Puffern auszurüsten, so daß multithreaded Betrieb mittels 
DMA und Interrupts bequem abgearbeitet werden können ohne den 
eigentlichen uC Instruktionsablauf zu sehr zu bedrängen.

Deshalb wären auch bekannte existierende uC mit Multi-Core a la 
Propeller, aber mit schon bekannten Cores und Werkzeugen praktisch 
gesehen für größere Anwendungen eine bessere Lösung um die Arbeitslast 
den Anforderungen gemäß aufteilen zu können. Was es da diesbezüglich in 
diese Richtung schon gibt ist mir im Augenblick nicht bekannt weil ich 
bis jetzt noch keinen Grund hatte viel über den Tellerrand zu schauen.

Bis jetzt war es mit RTOS und Cortex Core immer bequem möglich 
Multitasking befriedigend durchsetzen zu können. Mehr als gleichzeitige 
Bearbeitung von TFT, USB und Ethernet und sonstigen nativen IO brauchen 
wir eigentlich nicht. Und die erwähnten Funktionen werden ja alle von 
dedizierter HW erledigt, so daß der Haupt-Prozessor damit bequem 
klarkommt. Einmal brauchten wir ein großes CPLD um genügend Bus 
Funktionen zu haben. Sonst gab es nie Engpässe.

Naja, wir haben ja alle mit den verschiedensten Anforderungen umzugehen 
und ist dann immer sehr individuell zu bewerten. Ist ja gut, daß es so 
viele verschiedene Möglichkeiten gibt, obwohl gerade das die Qual der 
Wahl verschlimmern kann.

Wünsch Euch all noch einen guten Rutsch ins neue Jahr!

Gerhard

: Bearbeitet durch User
von Einer K. (Gast)


Lesenswert?

mh schrieb:
> Wühlhase schrieb:
>> War hier nicht vor einigen Wochen ein Thread, wo jemand einen "gängigen
>> µC" als SPI-Slave laufen lassen wollte? Wenn ich mich recht erinnere
>> haben ihm die meisten davon abgeraten, er solle das bitte möglichst
>> anders lösen.
>
> Ich frage mich, warum es dann µC gibt, die SPI-Slave in Hardware machen.
> Was spricht dagegen?

z.B. die 8 Bit AVR?
Prächtig, als Master.
Unangenehm als Slave.

Denn das Päuschen, zwischen 2 Byte, welches der Master einlegen muss, 
damit die Slave ISR das Datentransferregister beschreiben/lesen kann, 
das stört.
Unangenehm.

Beitrag #6528396 wurde vom Autor gelöscht.
von mh (Gast)


Lesenswert?

Arduino Fanboy D. schrieb:
> z.B. die 8 Bit AVR?

Es gibt noch eine Welt außerhalb von AVR ...

Egon D. schrieb:
> Eine UART ist aber nicht "programmierbar" im Sinne der
> Turing-Vollständigkeit -- auch wenn sie natürlich
> zahlreiche Betriebsarten kennt, unter denen man
> auswählen kann.

Wo ist das Problem, wenn die UART macht was man möchte? Warum nen ganzen 
Kern mit ner Software UART belegen, wenn ich auf einem anderen µC nen 
Hardware UART haben kann (UART ist hier nur ein Beispiel)?

von Rainer V. (a_zip)


Lesenswert?

Vielleicht erinnern sich die die "alten Hasen" noch an den Hype der 
Parallelrechner...Parsytec z.B... da wurden Megacluster zusammen 
geklöppelt und leider mußten auch Programme geschrieben werden, die mit 
der massiven Parallelisierung etwas anfangen konnten. Das war eindeutig 
eine Sackgasse...und ging auch nicht in die Richtung, zeitkritische 
Peripherie gleichzeitig zu handeln. Man versprach sich einfach 
schnellere Bearbeitung des (Rechen-)Problems. Klappt ja auch...bis der 
eine Prozess Ergebnisse des anderen benötigt...und da ist im Prinzip das 
Serielle wieder durch die Hintertür drin! Theoretisch, falls es 
geeignete Algorithmen gibt, kann ich natürlich die vorletzte  und die 
letzte und...Stelle von PI auf einem eigenen Core berechnen lassen, aber 
letztlich ist es doch nur blöd! Eben weil die meisten Algorithmen nach 
dem simplen Schema "n + 1 = n" arbeiten. Mir bliebe jetzt auch nur noch 
die parallele Peripherie, aber ohne Idee für einen konkreten 
Anwendungsfall :-)
Gruß Rainer

von Egon D. (Gast)


Lesenswert?

mh schrieb:

> Egon D. schrieb:
>> Eine UART ist aber nicht "programmierbar" im Sinne
>> der Turing-Vollständigkeit -- auch wenn sie natürlich
>> zahlreiche Betriebsarten kennt, unter denen man
>> auswählen kann.
>
> Wo ist das Problem, wenn die UART macht was man möchte?

Keins.
Wenn man eine UART hat und eine UART braucht, ist alles
paletti.


> Warum nen ganzen Kern mit ner Software UART belegen,

Gegenfrage: Warum sich zwischen UART, SPI, I2C, USB, ...
entscheiden müssen, wenn man einfach ein oder zwei
Kerne entsprechend programmieren kann?

Wenn freie Programmierbarkeit keine praktischen
Vorteile hat -- warum sind dann Gatterschaltungen
nahezu ausgestorben, Mikrocontroller aber
allgegenwärtig?

von mh (Gast)


Lesenswert?

Egon D. schrieb:
> Gegenfrage: Warum sich zwischen UART, SPI, I2C, USB, ...
> entscheiden müssen, wenn man einfach ein oder zwei
> Kerne entsprechend programmieren kann?

Gegengegenfrage: Warum muss ich mich dazwischen entscheiden?
Antwort: Muss ich nicht, ich nutze einen µC der mehrere von den 
Schnittstellen in Hardware hat (Ok, USB nur einmal, aber davon hab ich 
noch nie mehr als eine gebraucht)

von Egon D. (Gast)


Lesenswert?

Rainer V. schrieb:

> Vielleicht erinnern sich die die "alten Hasen" noch
> an den Hype der Parallelrechner...Parsytec z.B... da
> wurden Megacluster zusammen geklöppelt und leider
> mußten auch Programme geschrieben werden, die mit
> der massiven Parallelisierung etwas anfangen konnten.

Und das ist heute in der Top500 der Supercomputer anders?


> Das war eindeutig eine Sackgasse...

Ach ja.


> und ging auch nicht in die Richtung, zeitkritische
> Peripherie gleichzeitig zu handeln.

So.
Und was ist eine aktuelle Graphik"karte" mit ihren
mehreren hundert oder tausend parallel arbeitenden
Prozessorelementen?

Richtig: Ein massiv paralleles System.
Und das in jedem Standard-PC. Schöne "Sackgasse".

INMOS, Parsytec usw. waren m.E. einfach ihrer Zeit
voraus -- und hatten vielleicht auch nicht die
richtige Vorstellung von dem Marktsegment, das sie
erfolgreich besetzen können.

Soweit ich weiss, ist Parsytec primär deshalb baden
gegangen, weil der T9000 ewig nicht lieferbar war und
wohl auch "vaporware" geblieben ist...


> Theoretisch, falls es geeignete Algorithmen gibt,
> kann ich natürlich die vorletzte  und die letzte
> und...Stelle von PI auf einem eigenen Core berechnen
> lassen, aber letztlich ist es doch nur blöd!

Du weisst, warum (unter anderem) die Enigma gebrochen
werden konnte?

Durch Parallelisierung.


> Eben weil die meisten Algorithmen nach dem simplen
> Schema "n + 1 = n" arbeiten.

Du weisst, was eine sich selbst erfüllende Prophezeiung
ist?
Das ist zum Beispiel, wenn man fast die ganze Informatik
auf dem Begriff des Algorithmus aufbaut, diesen durch
die Turing-Maschine (eine sequenzielle Maschine!) definiert
und sich dann wundert, wieso die Studenten nur sequenzielle
Abläufe programmieren können!

von Nick M. (Gast)


Lesenswert?

Ich möchte den xmos // Propeller-Zweiflern // Kritikern nochmal 
nahelegen sich ein bisschen mit dem Transputer zu beschäftigen. Das 
Konzept ist sehr ähnlich zum xmos, ist aber deutlich älter. Kommerziell 
konnte auch er sich auf Dauer nicht durchsetzen, da lag es aber wohl 
eher an der Sprache Occam.
Dennoch wurde der Transputer in der Rüstung und für die Video / 
Bildbearbeitung verwendet. Die Kommunikationskanäle findet man im xmos 
so auch wieder, sogar über mehrere Chips hinweg (was beim Transputer 
wesentlich war). Beim xmos lassen sich auch beliebige cluster bilden die 
untereinander (chip to chip) mit schnellen Kanälen kommunizieren. Man 
kann also so lang parallelisieren, bis die Kommunikation nicht mehr 
hinterherkommt. Beim Propeller geht das so nicht.

Und schaut euch da die Namensliste der Anwender an, nicht bloß paar 
Hobbyisten die sich irgendwas erträumen.

https://de.wikipedia.org/wiki/Transputer

Ich weiß nicht ob ich mir das einbilde, aber ich glaub einer der 
Entwickler des Transputers ist der Gründer von xmos (aber jetzt nicht 
mehr dort dabei).

von Egon D. (Gast)


Lesenswert?

mh schrieb:

> Egon D. schrieb:
>> Gegenfrage: Warum sich zwischen UART, SPI, I2C,
>> USB, ... entscheiden müssen, wenn man einfach
>> ein oder zwei Kerne entsprechend programmieren
>> kann?
>
> Gegengegenfrage: Warum muss ich mich dazwischen
> entscheiden?

Du musst nicht.
Du kannst auch immer ein deutlich luxuriöseres
System kaufen und einen Teil der Hardare ungenutzt
lassen.

Das beantwortet meine Frage aber noch nicht: Wenn
spezialisierte Hardware so toll ist -- warum ist
dann für komplexe Aufgaben Gatterlogik am Aussterben,
während programmierbare Systeme überall zu finden sind?

Beitrag #6528497 wurde von einem Moderator gelöscht.
von Tim  . (cpldcpu)


Lesenswert?

Nick M. schrieb:
> Ich möchte den xmos // Propeller-Zweiflern // Kritikern nochmal
> nahelegen sich ein bisschen mit dem Transputer zu beschäftigen. Das
> Konzept ist sehr ähnlich zum xmos, ist aber deutlich älter. Kommerziell

Das ist Schwachsinn, sorry.

Die Idee hinter XMOS ist die gleiche, die hinter SMT (Simultaneous 
Multithreading) steckt, welches es seit dem Pentium 4 auch in PC 
Prozessoren gibt: Es gibt für jeden Thread ein eigenes Registerfile aber 
nur eine Pipeline, die reihum die Threads abarbeitet.

Der Transputer ist eine echte Multiprozessormaschine.

von mh (Gast)


Lesenswert?

Egon D. schrieb:
> Du kannst auch immer ein deutlich luxuriöseres
> System kaufen und einen Teil der Hardare ungenutzt
> lassen.
Wie definierst du luxuriös? Wie teuer ist nochmal ein Propeller?

Egon D. schrieb:
> Das beantwortet meine Frage aber noch nicht: Wenn
> spezialisierte Hardware so toll ist -- warum ist
> dann für komplexe Aufgaben Gatterlogik am Aussterben,
> während programmierbare Systeme überall zu finden sind?

Es hat deine erste Frage beantwortet ... Ok dann auf zur zweiten Fragen 
...
Es war mir nicht bewusst, dass Gatterlogik am Aussterben ist. Besteht 
der Parallax nicht auch zum Großteil aus Gatterlogik?

von Nick M. (Gast)


Lesenswert?

Tim  . schrieb:
> Das ist Schwachsinn, sorry.

Wenn du dich nicht selbst informieren willst, mach ich es ausnahmsweise 
mal für dich und die Mitleser:
"XMOS wurde im Juli 2005 von Ali Dixon, James Foster, Noel Hurley, David 
May und Hitesh Mehta gegründet, unter anderem mit Startkapital der 
Universität Bristol. Der Name XMOS lehnt sich an Inmos[1] an, einige 
grundlegende Konzepte fanden bereits beim Transputer Anwendung.[2] "

Inmos war Transputer.

Hurra!
Jetzt hab ich auch wieder gefunden wer am Transputer und der xmos-CPU 
gearbeitet hat: David May
https://en.wikipedia.org/wiki/Inmos

von Rainer V. (a_zip)


Lesenswert?

Egon D. schrieb:
> Richtig: Ein massiv paralleles System.
> Und das in jedem Standard-PC. Schöne "Sackgasse".

Ja, egon, es ist eben ein paralleles System an der Stelle, wo es "schon 
passt", wie der Österreicher gern sagt. Parsytec war seinerzeit unser 
Nachbar im Technologiezentrum und was mir vom Fachsimpeln auf dem Flur 
in Erinnerung geblieben ist, war der große Mangel an "parallelen" 
Algorithmen. Natürlich war auch die reine Hardware ein Alptraum...und 
"Code-knacken" kann natürlich in einzelne Prozesse verlagert werden...du 
kriegst aber erst ein Ergebnis, wenn du alle Einzelergebnisse 
zusammenführen konntest! Man erkennt den Unterschied :-)
Gruß Rainer

von Wühlhase (Gast)


Lesenswert?

mh schrieb:
> Wühlhase schrieb:
>> War hier nicht vor einigen Wochen ein Thread, wo jemand einen "gängigen
>> µC" als SPI-Slave laufen lassen wollte? Wenn ich mich recht erinnere
>> haben ihm die meisten davon abgeraten, er solle das bitte möglichst
>> anders lösen.
>
> Ich frage mich, warum es dann µC gibt, die SPI-Slave in Hardware machen.
> Was spricht dagegen?

Z.B. die Tatsache daß du ständig eine Unterbrechung hast auf die du sehr 
wenig Einfluß hast und die du kaum nach hinten legen kannst. Wenn der 
Master mit 3MHz Daten anfordert und du die evt. vorverarbeiten willst, 
z.B. FFT o.ä., dann hast du nicht mehr allzuviel Zeit für andere Dinge.

Ich arbeite gerade an etwas mit Leistungselektronik, ein bisschen 
Datenauswertung, etwas Regelung, und später soll das Teil mal noch 
kommunizieren können und auf Anfrage ein paar Daten liefern. Die ganze 
Kommunikation einfach auf einen - gerne auch kleineren - Kern auslagern 
wäre durchaus praktisch und allemal sauberer, als seinen schönen 
Regelalgorithmus unvorhergesehen unterbrechen zu müssen. Ein Kern macht 
Datenakquise und -verarbeitung, einer regelt entspannt und einer kümmert 
sich um das Kommunikationsgeraffel...wäre eine technisch saubere Lösung, 
die mir gut gefallen würde. Ja, geht auch mit einem F3. Trotzdem würde 
mir das Propellerkonzept besser gefallen.


mh schrieb:
> Wühlhase schrieb:
>> Der Propeller wäre für so etwas jedoch richtig gut. Da kann sich ein
>> Kern ganz gemütlich auf die Lauer nach dem Chip-Select-Signal legen und
>> der Rest kann nach Belieben seinen zeitkritischen Aufgaben nachgehen.
>
> Der Propeller ist also gut, weil er ein Problem löst, das man auch
> anders, einfacher und günstiger lösen kann?

Nun, das war EIN Beispiel - und sogar für ein reales Problem das hier 
kürzlich auftauchte. Der Propeller ist nicht interessant weil man damit 
besser einen SPI-Sklaven bauen kann, sondern weil man damit weitaus 
flexibler ist um z.B. einen SPI-Sklaven zu bauen. Mal davon abgesehen 
daß das Teil differentielle Ausgänge hat könntest du z.B. auch so etwas 
wie den LTM900x-14 ansteuern. Ja, das Teil ist eigentlich für FPGAs 
gedacht, aber das kann einem egal sein.

Mir deucht, einige sollten mal wieder einen Controller ohne RTOS 
verwenden. :)

von Rainer V. (a_zip)


Lesenswert?

...und rein interessenhalber...welcher Programmieralgorithmus ist mehr 
als eine Touringmaschine? Bin echt gespannt! Aber vielleicht auch nur zu 
doof...
Gruß Rainer

von Nick M. (Gast)


Lesenswert?

Rainer V. schrieb:
> Natürlich war auch die reine Hardware ein Alptraum...und
> "Code-knacken" kann natürlich in einzelne Prozesse verlagert werden...du
> kriegst aber erst ein Ergebnis, wenn du alle Einzelergebnisse
> zusammenführen konntest! Man erkennt den Unterschied :-)

Kurz:
Die ganzen massiven Multiprozessoren-Rechner sind kompletter Unfug.

Und wieder: Man konnte es zuerst auf µC.net lesen. Die Fachwelt braucht 
wohl noch 7 Jahre bis sie es kapieren.

von mh (Gast)


Lesenswert?

Wühlhase schrieb:
> Z.B. die Tatsache daß du ständig eine Unterbrechung hast auf die du sehr
> wenig Einfluß hast und die du kaum nach hinten legen kannst. Wenn der
> Master mit 3MHz Daten anfordert und du die evt. vorverarbeiten willst,
> z.B. FFT o.ä., dann hast du nicht mehr allzuviel Zeit für andere Dinge.
Wenn man die Daten verarbeiten will, muss man die Rechenleistung dafür 
haben, das ist klar. Das gilt aber auch für einen Propeller, wenn der 
auf einem Kern auf die SPI Schnittstelle warten muss, kann er die Daten 
auf diesem Kern nicht verarbeiten.

Wühlhase schrieb:
> Ja, geht auch mit einem F3. Trotzdem würde
> mir das Propellerkonzept besser gefallen.
Das ist deine Meinung, da kann man nichts gegen sagen.

Wühlhase schrieb:
> Nun, das war EIN Beispiel - und sogar für ein reales Problem das hier
> kürzlich auftauchte. Der Propeller ist nicht interessant weil man damit
> besser einen SPI-Sklaven bauen kann, sondern weil man damit weitaus
> flexibler ist um z.B. einen SPI-Sklaven zu bauen.
Das Argument funktioniert aber nur, wenn du etwas brauchst, das nicht 
genauso auf einem herkömmlichen µC funktioniert, ob in Hardware oder 
Software.

Wühlhase schrieb:
> daß das Teil differentielle Ausgänge hat könntest du z.B. auch so etwas
> wie den LTM900x-14 ansteuern. Ja, das Teil ist eigentlich für FPGAs
> gedacht, aber das kann einem egal sein.
Das ist doch tatsächlich mal ein echter Vorteil, wenn man sowas braucht.

Wühlhase schrieb:
> Mir deucht, einige sollten mal wieder einen Controller ohne RTOS
> verwenden. :)
Mir deucht, einige sollten weniger mutmaßen.

Rainer V. schrieb:
> ...und rein interessenhalber...welcher Programmieralgorithmus ist mehr
> als eine Touringmaschine? Bin echt gespannt! Aber vielleicht auch nur zu
> doof...
> Gruß Rainer
Hier nicht wirklich relevant, aber du solltest mal bei den 
Quantencomputer gucken gehen, wenn dich das wirklich interessiert.

von (prx) A. K. (prx)


Lesenswert?

Nick M. schrieb:
> Kommerziell
> konnte auch er sich auf Dauer nicht durchsetzen, da lag es aber wohl
> eher an der Sprache Occam.

Weshalb damals auch andere Compiler entstanden, darunter ein C Compiler, 
der auf mein Konto ging. Die Hardware war zwar etwas sehr mit Occam 
korreliert, aber bekanntere Sprachen liessen sich durchaus 
implementieren. Das wars nicht.

Der Transputer war prima für Unis. Neue Ideen eignen sich immer gut für 
Unis, geben mehr her als ausgetretene Pfade. Mindestens eine 
kommerzielle Anwendung fand er sogar auch, allerdings entgegen seiner 
Natur als Einzelprozessor, auf AVMs ISDN S2M Karten.

Der einzelne Transputer war vom Tempo her ok, aber nicht überragend. 
Erst im massiven Verbund wurde er wirklich interessant. Aber es dauert 
eine ziemliche Weile, bis man mit solchen parallelen Strukturen 
konstruktiv arbeiten kann. In dieser Zeit hätte der Transputer sich 
hardwareseitig weiterentwickeln müssen. Indes, der Nachfolger verzögerte 
sich und verzögerte sich ..., wohl zu ambitioniert für ein kleines 
Unternehmen.

von (prx) A. K. (prx)


Lesenswert?

Tim  . schrieb:
> Die Idee hinter XMOS ist die gleiche, die hinter SMT (Simultaneous
> Multithreading) steckt, welches es seit dem Pentium 4 auch in PC
> Prozessoren gibt: Es gibt für jeden Thread ein eigenes Registerfile aber
> nur eine Pipeline, die reihum die Threads abarbeitet.

Der Peripherieprozessor der CDC 6600 aus den 60ern arbeitete ähnlich wie 
XMOS. 10 Kontexte, reihum abgearbeitet. Allerdings hatte jeder Kontext 
seine eigenen 4K Worte RAM.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

(prx) A. K. schrieb:
> Indes, der Nachfolger verzögerte
> sich und verzögerte sich ..., wohl zu ambitioniert für ein kleines
> Unternehmen.

Die Architektur war allerdings für damalige Verhältnisse nur schwierig 
weiterzuentwickeln. Eine Stack-Architektur hat oft inhärente 
Abhängigkeiten von Folgebefehlen. Sowas wie Pipelining von aufeinander 
folgenden Multiplikationen ist damit ziemlich witzlos. Oder zumindest 
ausgesprochen schwierig, wie Intel feststellen musste, als sie die 8087 
FPU im Pentium beschleunigten.

Ein weiteres Problem war die Prozess-Synchronisation innerhalb der 
Cores. Es gab kein effektives Verfahren zur Synchronisation beliebiger 
Prozesse. Also sowas einfaches wie eine Mutex für gemeinsamen Speicher - 
nada. Damit muss man erst einmal zurecht kommen.

: Bearbeitet durch User
von Egon D. (Gast)


Lesenswert?

Rainer V. schrieb:

> Egon D. schrieb:
>> Richtig: Ein massiv paralleles System.
>> Und das in jedem Standard-PC. Schöne "Sackgasse".
>
> Ja, egon, es ist eben ein paralleles System an der
> Stelle, wo es "schon passt", wie der Österreicher
> gern sagt.

Zugestanden. Aber was beweist das?

GraphikAUSgabe ist gut parallelisierbar; also ist das
der Punkt, an dem massiv parallele Hardware den Weg
in den Mainstream gefunden hat.
Aber steht schon fest, dass es die EINZIGE gut
parallelisierbare Aufgabe ist? Was ist z.B. mit
Bewegtbildcodierung, oder mit Texterkennung?

Es gab immer wieder Versuche, Numerik auf Graphik-
prozessoren zu betreiben. So, wie ich das verstehe,
hängt es weniger an den Algorithmen oder der Hardware,
sondern an geeigneten Werkzeugen.


> Parsytec war seinerzeit unser Nachbar im
> Technologiezentrum

Tatsächlich? Du warst im TCC -- WIMRE auf der
Annaberger Straße? Was hast Du da so getrieben?
Ich habe im selben Städtchen an der Uni studiert...


> und was mir vom Fachsimpeln auf dem Flur in Erinnerung
> geblieben ist, war der große Mangel an "parallelen"
> Algorithmen.

Ich bestreite den Fakt gar nicht -- aber ich finde
ihn in Anbetracht der Tatsache, dass die sequenzielle
Maschine die Informatik jahrzehntelang beherrscht hat,
auch nicht weiter verwunderlich.

> und "Code-knacken" kann natürlich in einzelne Prozesse
> verlagert werden...du kriegst aber erst ein Ergebnis,
> wenn du alle Einzelergebnisse zusammenführen konntest!
> Man erkennt den Unterschied :-)

Ehrlich gesagt: Nein -- ich verstehe nicht, worauf Du
hinauswillst.

von Egon D. (Gast)


Lesenswert?

(prx) A. K. schrieb:

> Der einzelne Transputer war vom Tempo her ok, aber
> nicht überragend. Erst im massiven Verbund wurde er
> wirklich interessant.

Du magst mich korrigieren, wenn ich mich irre, aber
das Alleinstellungsmerkmal am Transputer war m.E. die
Kombination aus lokalem RAM (das unterscheidet ihn vom
gewöhnlichen Mikroprozessor), externem Bus (das unter-
scheidet ihn vom Mikrocontroller) und on-Chip-Links
(das unterscheidet ihn von allem).


> Aber es dauert eine ziemliche Weile, bis man mit
> solchen parallelen Strukturen konstruktiv arbeiten
> kann.

Das ist m.E. der Knackpunkt. Das Programmiermodell war
einfach zu ungewohnt, der Leidensdruck noch nicht hoch
genug und die Vorteile noch nicht überzeugend genug.


> In dieser Zeit hätte der Transputer sich hardwareseitig
> weiterentwickeln müssen. Indes, der Nachfolger verzögerte
> sich und verzögerte sich ...,

Die Ankündigung vom T9000 las sich gut, aber dann...

von Tim  . (cpldcpu)


Lesenswert?

Nick M. schrieb:

> "XMOS wurde im Juli 2005 von Ali Dixon, James Foster, Noel Hurley, David
> May und Hitesh Mehta gegründet, unter anderem mit Startkapital der
> Universität Bristol. Der Name XMOS lehnt sich an Inmos[1] an, einige
> grundlegende Konzepte fanden bereits beim Transputer Anwendung.[2] "
>
> Inmos war Transputer.
>
> Hurra!
> Jetzt hab ich auch wieder gefunden wer am Transputer und der xmos-CPU
> gearbeitet hat: David May
> https://en.wikipedia.org/wiki/Inmos

Ja und? Nichts von dem weist darauf hin, dass es sich um eine 
vergleichbare Architektur handelt.

von rrdes (Gast)


Lesenswert?

Tim King hat ja auch nur das Amiga Betriebsystem entworfen.
Und dann noch Transputer. Kinderkram

von Lothar (Gast)


Lesenswert?

Wühlhase schrieb:
> Ein Kern macht Datenakquise und -verarbeitung, einer regelt
> entspannt und einer kümmert sich um das Kommunikationsgeraffel...
> wäre eine technisch saubere Lösung

Genau so wird das mit den Multicore Cortex-M gemacht - hier z.B. 1x M4 
und 2x M0

https://www.mikrocontroller.net/part/LPC4370

http://thomasweldon.com/tpw/lpc4370/lpc4370tutorial1/index.html

von chris_ (Gast)


Lesenswert?

>Egon D. schrieb:
>> Eine UART ist aber nicht "programmierbar" im Sinne der
>> Turing-Vollständigkeit -- auch wenn sie natürlich
>> zahlreiche Betriebsarten kennt, unter denen man
>> auswählen kann.

>Wo ist das Problem, wenn die UART macht was man möchte? Warum nen ganzen
>Kern mit ner Software UART belegen, wenn ich auf einem anderen µC nen
>Hardware UART haben kann (UART ist hier nur ein Beispiel)?

Immer diese "Touring-Vollständigkeit". Mikrocontroller sind es mangels 
unendlichem Speicher definitiv nicht. Das sie es wären ist ein weit 
verbreiteter Irrtum.

von chris_ (Gast)


Lesenswert?

Egon D. schrieb:
>Du weisst, was eine sich selbst erfüllende Prophezeiung
>ist?
>Das ist zum Beispiel, wenn man fast die ganze Informatik
>auf dem Begriff des Algorithmus aufbaut, diesen durch
>die Turing-Maschine (eine sequenzielle Maschine!) definiert
>und sich dann wundert, wieso die Studenten nur sequenzielle
>Abläufe programmieren können!

Egon, ich bin genau Deiner Meinung. Ich finde es erstaunlich, dass es so 
wenig Leute gibt, die das erkennen.

Was den Propeller angeht: Dort liegt das Geheimnis der zeitlichen 
Präzision in der "Propeller" Architektur. Es läuft ein Zeiger auf die 
Speicher der 8 Cores im Kreis und in jedem 8.ten Zyklus hat der Core 
Zugriff auf den gemeinsamen Speicher. Der einzelne Kern läuft ohne 
Interrupts absolut deterministisch.

Die Architektur hat auch Einschränkungen: Die einzelnen Cores haben 
wenig Speicher, was den Einsatz von C-Compiler schwieriger macht bzw. 
die Geschwindigkeit runter bremst, wenn der C-Code im Shared-Memory 
steht.

Schade, dass es keinen 16-Core M0-ARM mit Propeller Prinzip und ohne 
Interrupts gibt.

von chris_ (Gast)


Lesenswert?

>Parsytec war seinerzeit unser
>Nachbar im Technologiezentrum und was mir vom Fachsimpeln auf dem Flur
>in Erinnerung geblieben ist, war der große Mangel an "parallelen"
>Algorithmen

Das dürfte wohl eher der damaligen Zeit geschuldet gewesen sein.
Probleme, die mit parallelen Algorithmen zu lösen sind dürften wohl 
deutlich zahlreicher als andere sein.

Beipiele:
FEM-Simulation
Wetter Simulation
Spiele Simulation
Partikel Simulation
Graphik-Shading

Automobile:
Man kann gleichzeitig fahren, Radio hören, den Blinker einschalten, den 
Abstandregler benutzen, den Bremsassistent benutzen, den 
Einparkassistent, den Rückfahrultraschall, die Motorsteuerung usw ....
Alles parallel arbeitende Embedded-Systeme.

von chris_ (Gast)


Lesenswert?

Ah, ganz vergessen: Das große Thema KI ... massiv parallel.

von Nick M. (Gast)


Lesenswert?

Tim  . schrieb:
> Nick M. schrieb:
>> Der Name XMOS lehnt sich an Inmos[1] an, einige
>> grundlegende Konzepte fanden bereits beim Transputer Anwendung.[2] "

> Ja und? Nichts von dem weist darauf hin, dass es sich um eine
> vergleichbare Architektur handelt.

Wirklich nichts? Nicht mal grundlegende Konzepte?

von Wühlhase (Gast)


Lesenswert?

mh schrieb:
> Wühlhase schrieb:
>> Nun, das war EIN Beispiel - und sogar für ein reales Problem das hier
>> kürzlich auftauchte. Der Propeller ist nicht interessant weil man damit
>> besser einen SPI-Sklaven bauen kann, sondern weil man damit weitaus
>> flexibler ist um z.B. einen SPI-Sklaven zu bauen.
> Das Argument funktioniert aber nur, wenn du etwas brauchst, das nicht
> genauso auf einem herkömmlichen µC funktioniert, ob in Hardware oder
> Software.

Von deiner Übergeneralisierung mal abgesehen: Jedes Sachargument sollte 
doch so funktionieren...oder nicht? Jedes Konzept hat Stärken und 
Schwächen, und mir ist kein Konzept bekannt das in jedem Fall und unter 
allen Umständen das Beste ist. Kennst du eins?

Niemand hier hat je behauptet, daß das Propellerkonzept immer und 
überall überlegen ist, sondern nur das es Probleme gibt die sich mit dem 
Propellerkonzept besser lösen lassen als mit dem Wald- und 
Wiesenkonzept. Niemand hat gesagt, daß es mit einem herkömmlichen µC gar 
nicht gehen würde.

Ich persönlich habe gern mehrere Werkzeuge im Werkzeugkasten, um 
Probleme zu lösen. Allein deshalb gebe ich alternativen Konzepten gerne 
mal eine Chance und schaue sie mir wohlwollend an.
Klar kann ich einen Nagel (um mal bei der Metapher zu bleiben) auch mit 
einem Ziegelstein in die Wand donnern, aber in meinen Augen wäre das 
Stümperei.
Ich nehme lieber das eigens für diese Problemklasse entworfene Werkzeug: 
einen Hammer. Und dann natürlich nicht die 15kg-Abbruchramme, und auch 
nicht das 50g-Präzisionshämmerchen, Gummihammer oder Fäustel - welche 
ich nach Möglichkeit trotzdem habe. Und nichts davon werde ich benutzen, 
wenn es um Probleme der Klasse 'Schraube' geht.

Ich persönlich brauche nicht erst ein Problem, das sich nur mit dem 
Propeller lösen läßt und auf einem normalen Mikrocontroller gar nicht zu 
machen wäre. Mir reicht es schon, wenn sich ein Problem zwar mit beiden, 
aber auf dem Propeller besser lösen läßt (wie auch immer man 'besser' 
definieren mag). Dann denke ich zumindest mal darüber nach, es zu 
benutzen, oder ich befasse mich mit dem Teil einfach schon deshalb, um 
mal etwas anders machen zu können. Ob es brauchbar ist, wird sich dann 
in Zukunft zeigen.

von MCUA (Gast)


Lesenswert?

Ein CPU-Kern kann Perif.teile (bsp. Interface usw) nicht ersetzen, weil 
die erreichbare CPU-f dafür zu gering ist.
Mit 100 MHz FFs lässt sich keine 100 MHz CPU-f erreichen.

von Stefan F. (Gast)


Lesenswert?

mh schrieb:
> Wo ist das Problem, wenn die UART macht was man möchte? Warum nen ganzen
> Kern mit ner Software UART belegen, wenn ich auf einem anderen µC nen
> Hardware UART haben kann (UART ist hier nur ein Beispiel)?

Ich denke, dass die Entwickler des Chips Schnittstellen im Sinn hatten, 
die weniger weit verbreitet sind und deswegen oft in Software 
implementiert werden müssen.

Beitrag #6528795 wurde von einem Moderator gelöscht.
von void (Gast)


Lesenswert?

mh schrieb:
> Der P2 kann also ~60 ADCs oder DACs haben? Das wäre praktisch, aber
> irgendwie glaub ich das nicht.

Stimmt auch nicht. Die Aussage von Andi war bewusst irreführend. Der P2 
hat 4 DACs, von denen sich jeder auf 1/4 aller IO Pins mappen lässt.
Steht auch so im Datenblatt hust wenn man das Dokument in dem nicht 
Mal der Bereich der Versorgungsspannung beschrieben steht und in dem die 
volle DAC Funktionalität es auf genau 3 Sätze bringt so nennen darf.

von mh (Gast)


Lesenswert?

Wühlhase schrieb:
> mh schrieb:
>> Wühlhase schrieb:
>>> Nun, das war EIN Beispiel - und sogar für ein reales Problem das hier
>>> kürzlich auftauchte. Der Propeller ist nicht interessant weil man damit
>>> besser einen SPI-Sklaven bauen kann, sondern weil man damit weitaus
>>> flexibler ist um z.B. einen SPI-Sklaven zu bauen.
>> Das Argument funktioniert aber nur, wenn du etwas brauchst, das nicht
>> genauso auf einem herkömmlichen µC funktioniert, ob in Hardware oder
>> Software.
>
> Von deiner Übergeneralisierung mal abgesehen: Jedes Sachargument sollte
> doch so funktionieren...oder nicht?
Was genau habe ich übergeneralisiert? Was genau ist "so funktionieren"?

Wühlhase schrieb:
> Niemand hier hat je behauptet, daß das Propellerkonzept immer und
> überall überlegen ist, sondern nur das es Probleme gibt die sich mit dem
> Propellerkonzept besser lösen lassen als mit dem Wald- und
> Wiesenkonzept. Niemand hat gesagt, daß es mit einem herkömmlichen µC gar
> nicht gehen würde.
Bis jetzt ist die Liste mit konkreten Beispielen, die auf dem Propeller 
besser gelöst werden können relativ dünn. Ich kann mich an kein 
überzeugendes Beispiel in diesem Thread erinnern.

Wühlhase schrieb:
> um mal bei der Metapher zu bleiben
Warum immer diese schlechten Metaphern? Ein Ziegelstein ist das perfekte 
Werkzeug, um einen Nagel in die Wand zu hämmern, wenn der Ziegelstein 
gerade in Reichweite ist und der passende Hammer 10€ kostet, im nächsten 
Baumarkt in 2h Entfernung.

Stefan ⛄ F. schrieb:
> mh schrieb:
>> Wo ist das Problem, wenn die UART macht was man möchte? Warum nen ganzen
>> Kern mit ner Software UART belegen, wenn ich auf einem anderen µC nen
>> Hardware UART haben kann (UART ist hier nur ein Beispiel)?
>
> Ich denke, dass die Entwickler des Chips Schnittstellen im Sinn hatten,
> die weniger weit verbreitet sind und deswegen oft in Software
> implementiert werden müssen.
Möglich, aber welche? Ich habe kein Problem mit den Propeller und Co, 
aber ich sehe bis jetzt keinen Grund sie einzusetzen. Ich würde mich 
freuen, wenn jemand ein konkretes gutes Beispiel hat.

von Stefan F. (Gast)


Lesenswert?

Schnittstellen in Software zu implementieren, bringt zweifellos mehr 
Flexibilität, als HW Module vom Hersteller zu verwenden. Aber diese zu 
entwickeln kostet auch Zeit und bringt die Gefahr mit sich, unnötige 
Fehler zu machen. Dann sollte man auch bedenken, dass neue Kollegen sich 
mit selbst gebautem Code (versus Standard-Hardware) schwer tun, 
insbesondere wenn er komplex ist.

Das gleiche Dilemma hat man ja auch bei der Frage: Nehme ich eine 
Bibliothek, oder programmiere ich es selber neu? Nehme ich ein Framework 
wo ich von 1000 Funktionen nur 20 scheinbar triviale brauche, oder 
schreibe ich mir diese 20 trivialen Funktionen selbst. Wie hoch ist das 
Risiko, dass sie am Ende doch nicht so trivial sind, wie anfangs 
gedacht? Wie hoch ist das Risiko, dass meine Leute das Framework 
missverstehen und dadurch schwerwiegende Fehler machen, die erst Wochen 
nach der Inbetriebnahme auffallen (z.B. bei der Abrechnung von 
Kommunikations-Diensten).

Was mache ich, wenn sich nach Monaten der Entwicklung herausstellt, dass 
die Anlage in der technischen Umgebung des Kunden nicht funktioniert, 
weil es dort irgendeine Sonderlocke gibt, die von der gewählten 
Hardware/Bibliothek/Framework nicht unterstützt wird? Das ist oft der 
Moment, wo man sich wünscht: Hätte ich es doch alles selbst 
programmiert, dann hätte ich es auch voll im Griff. Soll man demnächst 
wirklich alles selbst machen, während der Rest der Welt weiterhin diese 
Standardkomponenten verwendet? Wer bezahlt solche Fehlentscheidungen?

von Olaf (Gast)


Lesenswert?

> Ich denke, dass die Entwickler des Chips Schnittstellen im Sinn hatten,
> die weniger weit verbreitet sind und deswegen oft in Software
> implementiert werden müssen.

Gut denkbar. Man denke nur an die Verrenkungen die notwendig sind um die 
kranken Neopixel anzusteuern. Oder du brauchst SPI mit einer exotischen 
Wortgroesse. Und es gibt in der Industrie eine reihe von sehr schraegen 
Bussen von denen noch nie einer gehoert hat der nicht zufaellig damit 
arbeitet.

> Gegenfrage dazu: Warum soll ich eine Schnittstelle selber entwickeln,
> wenn ich sie fertig kaufen kann? Wer bezahlt denn die Arbeitszeit?

Ich kenne eine Anwendung wo I2C in Software drin ist weil das einfacher 
war als die Hardware im Chip komplett zu durchschauen. Oder ich hab auch 
schon mal einen IRDA-Master komplett selber geschrieben weil mir gegen 
Ende eines Projektes aufgefallen ist das der STM32 da einen echt 
schraegen Bug in der Hardware hatte.

Aber manchmal macht es auch einfach Spass ungewoehnliche Hardware zu 
nutzen und ungewohnte Wege zu beschreiten. Ich staune da immer ueber die 
griesgraemigen Besserwisser die gleich Schaum vor dem Mund bekommen.

Schaut mal hier ab 2:17:

https://www.youtube.com/watch?v=31xA9p3pYE4

Dem was Fefe da sagt kann ich nur 100% zustimmen. Eine der Folgen, wir 
haben halt viele Leute die sind von ungewohnte Konzepten oder neuen 
Ideen gleich ueberfordert. Die noergeln dann sofort anstatt es als 
Spielwiese zu begreifen.

Die eine Haelfte denkt, oh das ist ja interessant, was kann ich daraus 
machen?

Die andere Haelfte: Iiih! Das ist ja gar nicht wie immer, das geht gar 
nicht.

Olaf

von mh (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Schnittstellen in Software zu implementieren, bringt zweifellos mehr
> Flexibilität, als HW Module vom Hersteller zu verwenden.

Das ist aber, wie gesagt, nur ein Vorteil, wenn man diese Flexibilität 
auch braucht.

Olaf schrieb:
>> Ich denke, dass die Entwickler des Chips Schnittstellen im Sinn hatten,
>> die weniger weit verbreitet sind und deswegen oft in Software
>> implementiert werden müssen.
>
> Gut denkbar. Man denke nur an die Verrenkungen die notwendig sind um die
> kranken Neopixel anzusteuern. Oder du brauchst SPI mit einer exotischen
> Wortgroesse. Und es gibt in der Industrie eine reihe von sehr schraegen
> Bussen von denen noch nie einer gehoert hat der nicht zufaellig damit
> arbeitet.

Dann ist der Propeller aber nur im Vorteil, wenn man es nicht genauso 
einfach auf einem herkömmlichen µC umsetzen kann.

Olaf schrieb:
> Ich kenne eine Anwendung wo I2C in Software drin ist weil das einfacher
> war als die Hardware im Chip komplett zu durchschauen. Oder ich hab auch
> schon mal einen IRDA-Master komplett selber geschrieben weil mir gegen
> Ende eines Projektes aufgefallen ist das der STM32 da einen echt
> schraegen Bug in der Hardware hatte.
Und der Propeller ist sicher bugfrei?

Olaf schrieb:
> Aber manchmal macht es auch einfach Spass ungewoehnliche Hardware zu
> nutzen und ungewohnte Wege zu beschreiten. Ich staune da immer ueber die
> griesgraemigen Besserwisser die gleich Schaum vor dem Mund bekommen.
> [...]
> Die andere Haelfte: Iiih! Das ist ja gar nicht wie immer, das geht gar
> nicht.
Das kannst du gerne machen. Du kannst auch gerne jeden, der nach einem 
praktischen Nutzen fragt, beleidigen.

von Stefan F. (Gast)


Lesenswert?

Wünschenswert wäre, das der Propeller für so ziemlich alle Standard 
Schnittstellen entsprechende Software-Module mit bringt, die gründlich 
getestet wurden.

Ich habe leider die Erfahrung gemacht, dass Hardware-Hersteller sich mit 
Software eher schwer tun. Und das nicht nur im Mikrocontroller-Umfeld.

von chris_ (Gast)


Lesenswert?

>Ich habe leider die Erfahrung gemacht, dass Hardware-Hersteller sich mit
>Software eher schwer tun. Und das nicht nur im Mikrocontroller-Umfeld.

Das ist beim Propeller anders, weil er ein echtes Freak-Projekt. Die 
Freaks sind im Schnitt Leute ab 40 mit 20 Jahren Berufserfahrung.

von Wühlhase (Gast)


Lesenswert?

mh schrieb:
> Was genau habe ich übergeneralisiert? Was genau ist "so funktionieren"?

Lies doch deinen eigenen Post noch einmal. Und zum zweiten: Jedes 
(Sach)Argument geht allgemein von bestimmten Annahmen aus (hier: Man 
nehme eine Alternative, wenn es damit besser geht).


mh schrieb:
> Bis jetzt ist die Liste mit konkreten Beispielen, die auf dem Propeller
> besser gelöst werden können relativ dünn. Ich kann mich an kein
> überzeugendes Beispiel in diesem Thread erinnern.

Dem Beispiel mit dem ADC vorhin hast du doch zugestimmt?


mh schrieb:
> Warum immer diese schlechten Metaphern? Ein Ziegelstein ist das perfekte
> Werkzeug, um einen Nagel in die Wand zu hämmern, wenn der Ziegelstein
> gerade in Reichweite ist und der passende Hammer 10€ kostet, im nächsten
> Baumarkt in 2h Entfernung.

Nur weil man mangelhaft vorbereitet ist, macht das einen 
zweckentfremdeten Gegenstand keineswegs zu einem besseren Werkzeug. Wenn 
du in einer Weltgegend wärst wo ein Hammer auch mit viel Aufwand einfach 
nicht zu beschaffen ist, z.B. in irgendeinem sozialistischen 
Dritte-Welt-Land, dann wäre das ein Argument.
Dann ist die Ausführung immer noch Stümperei, aber dann geht es halt 
nicht anders, im Gegenteil: Da würde ich für die Improvisation Respekt 
zollen.

So aber hast du zwar mit Stümperei um vernünftiges Werkzeug 
herumimprovisiert, aber was machst du beim nächsten Mal? Hoffen daß dann 
wieder ein Ziegelstein in der Nähe ist? Steckst du den Ziegel zum 
Werkzeug und arbeitest jetzt immer so?
Und Stümperei, die ich bei 10€ und einem 2h entfernten Baumarkt nicht 
akzeptieren würde, bleibt es ja immer noch.

von Nick M. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> mh schrieb:
>> Warum nen ganzen
>> Kern mit ner Software UART belegen, wenn ich auf einem anderen µC nen
>> Hardware UART haben kann (UART ist hier nur ein Beispiel)?
>
> Ich denke, dass die Entwickler des Chips Schnittstellen im Sinn hatten,
> die weniger weit verbreitet sind und deswegen oft in Software
> implementiert werden müssen.

@mh: Am Propeller kann ein Kern wimre 4 USART machen. Und das wohl bis 
115 kBaud.

@ Stefan:
Nein, Ziel ist möglichst viel der gebräuchlichen implementieren zu 
können. Und das hat ja auch geklappt. Hätte man z.B. USART per Hardware 
implementiert, wäre der Zgriff auf die Daten ein ziemlicher Bruch mit 
der Architektur geworden und damit irgendwie seltsam und zweifelhaft ob 
man dadurch eine CPU sparen kann.

XMOS ist zunächst den gleichen Weg gegangen, hat dann aber eine Familie 
um Ethernet und eine Andere um USB erweitert.

von Nick M. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Schnittstellen in Software zu implementieren, bringt zweifellos
> mehr Flexibilität, als HW Module vom Hersteller zu verwenden.Aber
> diese zu entwickeln kostet auch Zeit und bringt die Gefahr mit
> sich, unnötige Fehler zu machen.

Da hatte Parallax eine echt revolutionäre Idee:
Sie stellen den Code für die Schnittstellen zur Verfügung. Irre gell?!

von S. R. (svenska)


Lesenswert?

Egon D. schrieb:
> GraphikAUSgabe ist gut parallelisierbar; also ist das
> der Punkt, an dem massiv parallele Hardware den Weg
> in den Mainstream gefunden hat.

Das ist vor allem der Punkt, an dem man damit gutes Geld verdienen und 
eine Industrie (Spiele!) füttern konnte.

> Aber steht schon fest, dass es die EINZIGE gut
> parallelisierbare Aufgabe ist? Was ist z.B. mit
> Bewegtbildcodierung, oder mit Texterkennung?

Beides lässt sich sehr gut parallelisieren. Ich sehe jetzt kein Problem 
darin, eine Textseite in Streifen zu schneiden und diese mit etwas 
Überlappung parallel auszuwerten.

Die aktuell in Videocodecs (oder z.B. auch JPEG) verwendeten Verfahren 
arbeiten mit Blöcken, die ebenfalls parallel verarbeitet werden können. 
Ein relevanter Teil des Verfahrens ist damit parallelisierbar, auch wenn 
am Ende ein serialisierter Datenstrom rausfällt.

Zukünftige Algorithmen auf KI-Basis sind grundsätzlich auf 
Parallelisierbarkeit ausgelegt, man denke z.B. an neuronale Netze.

> Es gab immer wieder Versuche, Numerik auf Graphik-
> prozessoren zu betreiben. So, wie ich das verstehe,
> hängt es weniger an den Algorithmen oder der Hardware,
> sondern an geeigneten Werkzeugen.

Wenn man versucht, eine fixed function 3D-Pipeline, wie sie in frühen 
3D-Grafikkarten verbaut war, für Numerik zu benutzen, dann ist das 
naturgemäß schwierig.

Die größten Numerikprobleme, mit denen ich zu tun hatte (Fluidsimulation 
mit Lattice-Verfahren) werden real ausschließlich auf 
Grafikprozessoren gerechnet, weil die deutlich schneller sind und 
weniger Energie verbrauchen.

Dazu brauchte man natürlich Grafikprozessoren mit flexiblen Pipelines, 
wo die Verfahrensschritte nicht fest ins Silizium gegossen wurden. Die 
kamen aber so vir 10-15 Jahren auf den Markt.

Ich habe so ein bisschen das Gefühl, dass dein Wissen recht stark 
veraltet ist. Was du sagst, war einstmals wahr, ist es aber nicht mehr. 
Damit sind deine Schlüsse missweisend bis falsch.

Olaf schrieb:
> Ich kenne eine Anwendung wo I2C in Software drin ist weil das einfacher
> war als die Hardware im Chip komplett zu durchschauen.

Ich habe auch schon einige einfache Protokolle erst mit Bitbanging in 
Betrieb genommen. Einen GPIO kann man wesentlich einfacher in Betrieb 
nehmen, vor allem bei schlecht dokumentierter Hardware.

Witzigerweise reicht das oft genug auch aus.

von Nick M. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Ich habe leider die Erfahrung gemacht, dass Hardware-Hersteller sich mit
> Software eher schwer tun. Und das nicht nur im Mikrocontroller-Umfeld.

Es bleibt Parallax garnichts anderes übrig als alle 
Standardschnittstellen in Software zu implementieren und auch zu testen. 
Weil danach sofort geschrien wird. Und wenn die SW nicht funktioniert, 
dann wird der Fehler behoben. Die Quellen dafür sind offen und die user 
nützen das.

von mh (Gast)


Lesenswert?

Nick M. schrieb:
> @mh: Am Propeller kann ein Kern wimre 4 USART machen. Und das wohl bis
> 115 kBaud.
Wenn du so speziell werden willst ... bedeutet das, dass die 
Flexibilität am Ende ist, wenn ich 1M Baud brauche? Sind die 4 USART mit 
"Hardwareflussteuerung" RTS/CTS?

Wühlhase schrieb:
> mh schrieb:
>> Was genau habe ich übergeneralisiert? Was genau ist "so funktionieren"?
>
> Lies doch deinen eigenen Post noch einmal.
Ich habe das Argument nochmal von Anfang an gelesen und sehe nicht, wo 
ich etwas übergeneralisiert habe. Du musst also etwas genauer werden in 
deinen Vorwürfen.

Wühlhase schrieb:
> Und zum zweiten: Jedes
> (Sach)Argument geht allgemein von bestimmten Annahmen aus (hier: Man
> nehme eine Alternative, wenn es damit besser geht).
Exakt das habe ich doch geschrieben. Zur Erinnerung: du hattest 
geschrieben:
Wühlhase schrieb:
> Nun, das war EIN Beispiel - und sogar für ein reales Problem das hier
> kürzlich auftauchte. Der Propeller ist nicht interessant weil man damit
> besser einen SPI-Sklaven bauen kann, sondern weil man damit weitaus
> flexibler ist um z.B. einen SPI-Sklaven zu bauen.
Meine Antwort darauf war
mh schrieb:
> Das Argument funktioniert aber nur, wenn du etwas brauchst, das nicht
> genauso auf einem herkömmlichen µC funktioniert, ob in Hardware oder
> Software.
Das ist eine Einschränkgung deines Arguments. Was willst du also von 
mir?

Wühlhase schrieb:
> Und Stümperei, die ich bei 10€ und einem 2h entfernten Baumarkt nicht
> akzeptieren würde, bleibt es ja immer noch.
Wenn du weiter auf dieser unsinnigen Metapher rumreiten willst ... Ich 
benutze halt die Werkzeuge die ich habe und wenn der Nagel nach 10 
Sekunden in der Wand ist, hast du nichtmal die Schuhe angezogen auf dem 
Weg zum Baumarkt. Du kannst nach 2h gerne stolz sein, dass du einen 
Hammer hast.

von Nick M. (Gast)


Lesenswert?

mh schrieb:
> Wenn du so speziell werden willst ...

Wenn Du spezielle und klare Anforderungen hast, solltest du einfach 
nachschauen.

von Stefan F. (Gast)


Angehängte Dateien:

Lesenswert?

Achtung: Der Nick ist wieder da. Er verwickelt euch in sinnlose 
Endlos-Diskussionen. Gestern bin ich auf ihn herein gefallen.

von Nick M. (Gast)


Lesenswert?

Ja Stefan, auch wenn es dir nicht passt. Ich bin da.
Der Grund ist ganz einfach: Ich hab sowohl mit dem Propeller als auch 
mit xmos eigene Erfahrungen.
Aus deiner und der ersten Antwort 
(Beitrag "Re: Wofür Propeller von Parallax ?") schließe ich, 
dass du zu dem Thema leider nicht wirklich was beitragen kannst ausser 
irgendwas.
Das ist aber nicht meine Schuld.

Aber auch hier, danke für die erhellende Graphik. Jetzt ist klar wie der 
xmos funktioniert (aus deiner sicht).

Edit:
Ich hoffe dein Beitrag bleibt stehen. So können die Leute eigene 
Schlüsse ziehen.

von Stefan F. (Gast)


Lesenswert?

Nick M. schrieb:
> Ich hab sowohl mit dem Propeller als auch mit xmos eigene Erfahrungen.

Für die interessieren wir uns auch, aber nicht für deine persönlichen 
Angriffe auf einzelne Personen.

von Nick M. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Für die interessieren wir uns auch, aber nicht für deine persönlichen
> Angriffe auf einzelne Personen.

Ähhhhh ... verstehst du was du so schreibst?

von Lotta  . (mercedes)


Lesenswert?

Geiler Thread!

Dann heißt der Propeller also Propeller,
da er round robin in Hardware  macht,
hab ich das richtig vertanden?

mfg

von Nick M. (Gast)


Lesenswert?

~Mercedes~  . schrieb:
> da er round robin in Hardware  macht,
> hab ich das richtig vertanden?

Ja, das ist der Grund.
Im Hub (der Nabe) geht ein Zeiger rundrum von Prozessor zu Prozessor und 
gibt dem jeweilgen Proz den Zugriff auf das Hub-RAM. Die Drehrichtung 
ist auch definiert, weil man dadurch noch etwas Geschwindigkeit 
rauskitzeln kann.

von Lotta  . (mercedes)


Lesenswert?

Das ist ein Ding.
Ist da das Ram für alle Prozzis gemeinsam?
Kann jeder Prozzi im Ram für den nächsten was hinterlassen?

mfg

von chris_ (Gast)


Angehängte Dateien:

Lesenswert?

>da er round robin in Hardware  macht
Dies betrifft aber den "shared memory".

von Nick M. (Gast)


Lesenswert?

~Mercedes~  . schrieb:
> Kann jeder Prozzi im Ram für den nächsten was hinterlassen?

Ja. Das Bild vom chris_ zeigt das ganz gut.
Zusätzlich hat jeder Proz sein eigenes RAM für code oder Daten.
Hub ist gemeinsam, cog Proz-spezifisch.
Zugriffskollisionen sind per HW verriegelt.

von (prx) A. K. (prx)


Lesenswert?

~Mercedes~  . schrieb:
> Dann heißt der Propeller also Propeller,
> da er round robin in Hardware  macht,

Wobei die 8 Cores (COGs) des Propellers getrennt arbeiten, es werden 
also keine verschiedenen Kontexte durch die gleiche Ausführungseinheit 
rotiert. Rotieren tut der Zugriffs-Slot der 8 COGs auf den zentralen 
Speicher.

Demgegenüber gab es bei den Peripherieprozessoren der CDC 6600 eine 
einzelne Ausführungseinheit, die sich nacheinander 10 getrennten 
Kontexten aus Register+Speicher widmete. Dafür verwendete man den 
Begriff "Barrel", also Fass.

Das SMT (Hyperthreading) aktueller x86 Prozessoren und die Arbeitsweise 
von XMOS ähneln eher dem Verfahren der CDC als dem Propeller. 
Vereinfacht ausgedrückt kümmert sich eine gepipelinete 
Ausführungseinheit um mehrere Kontexte, bei gemeinsamem Speicher.

Bei XMOS bedeutet es, dass das in 4 Stufen erfolgende Pipelining der 
Ausführungseinheit dafür genutzt wird, 4 Threads in diesen 4 Stufen ohne 
Performanceverlust abzuarbeiten. Möglich sind bis zu 8 Threads, das 
bremst dann entsprechend aus.

Obwohl sowohl XMOS als auch die Transputer auf David May zurückgehen, 
ist die Arbeitsweise der Cores völlig verschieden. Deren Gemeinsamkeit 
ist die von Haus aus vorgesehene schnelle Verbindung vieler Knoten 
matrixartig untereinander, ohne gemeinsamem Speicher.

: Bearbeitet durch User
von Lotta  . (mercedes)


Lesenswert?

(prx) A. K. schrieb:
> ~Mercedes~  . schrieb:
>> Dann heißt der Propeller also Propeller,
>> da er round robin in Hardware  macht,
>
> Wobei die 8 Cores (COGs) des Propellers getrennt arbeiten, es werden
> also keine verschiedenen Kontexte durch die gleiche Ausführungseinheit
> rotiert. Rotieren tut der Zugriffs-Slot der 8 COGs auf den zentralen
> Speicher.
Also gibt es keine gemeinsame Instanz, man müßte also nen Core
zur Verwaltung abstellen?
Für nen Enigma-Cracker etwa, der ja praktich ein Vignere-
Cracker mit mod26 sein müßte ( das Alphabet hat ja 26 Buchstaben)
hätte man dann 7 Cracker und eine Verwaltung. :-P
>
> Demgegenüber gab es bei den Peripherieprozessoren der CDC 6600 eine
> einzelne Ausführungseinheit, die sich nacheinander 10 getrennten
> Kontexten aus Register+Speicher widmete. Dafür verwendete man den
> Begriff "Barrel", also Fass.
>
> Das SMT (Hyperthreading) aktueller x86 Prozessoren und die Arbeitsweise
> von XMOS ähneln eher dem Verfahren der CDC als dem Propeller.
> Vereinfacht ausgedrückt kümmert sich eine gepipelinete
> Ausführungseinheit um mehrere Kontexte, bei gemeinsamem Speicher.
Da wird ja auch Prioritäten-Multitasking gemacht, oder?
>
> Bei XMOS bedeutet es, dass das in 4 Stufen erfolgende Pipelining der
> Ausführungseinheit dafür genutzt wird, 4 Threads in diesen 4 Stufen ohne
> Performanceverlust abzuarbeiten. Möglich sind bis zu 8 Threads, das
> bremst dann entsprechend aus.
Hmmm.... :-P
>
> Obwohl sowohl XMOS als auch die Transputer auf David May zurückgehen,
> ist die Arbeitsweise der Cores völlig verschieden. Deren Gemeinsamkeit
> ist die von Haus aus vorgesehene schnelle Verbindung vieler Knoten
> matrixartig untereinander, ohne gemeinsamem Speicher.
Der Transputer, der oben auf den ISDN Karten erwähnt wurde,
was hat der gemacht? Das ISDN-Protokoll? Hast Du im Kopf, wie der Chip 
hieß?

von Stefan F. (Gast)


Lesenswert?

~Mercedes~  . schrieb:
> Der Transputer, der oben auf den ISDN Karten erwähnt wurde,
> was hat der gemacht? Das ISDN-Protokoll? Hast Du im Kopf, wie der Chip
> hieß?

Fritz ?  :-)

von Lotta  . (mercedes)


Lesenswert?

Stefan meinte:
> Fritz ?  :-)

Deshalb frag ich ja, die DSL-FPGA hatten ja
ne Butterfly-Aufschrift.

ich muß mich jetzt ausklinken, meine Zimmergenossin
und ich haben für 20 Leuts Käse-Erdbeertorten gebacken,
die tragen wir jetzt auf. :-P

mfg

von Rainer V. (a_zip)


Lesenswert?

Man muß vielleicht bedenken, dass es schon einen Unterschied macht, ob 
man von Parallelisierung oder von massiver Parallelisierung spricht. 
Sicher wird niemand mit einem Propeller einen Graphikprozessor aufbauen 
wollen oder ein neuronales Netz mit x Knoten. Die Frage ist dann 
einfach, was man mit dem Propeller besser machen könnte, als mit einem 
"einfachen" Controller. Unter den Stichworten zeitkritisch oder gar 
gleichzeitig sehe ich einen gewissen Verwaltungsaufwand im 
Hauptprogramm, der durch unabhängige Hardware entlastet werden kann, 
aber nicht muß. Und wie schon gesagt wurde, erst wenn ich mit f am 
Anschlag bin, denke ich über weitere Recheneinheiten nach. Ob das nun 
ein Symptom für die Unfähigkeit ist, über den sequentiellen Tellerrand 
zu schaun, kann ich auch nicht abschätzen. Also bleibt (für mich) die 
Suche nach dieser Community mit ihren Projekten...möglicherweise harren 
dort ja echte Schätze der Entdeckung...
Gruß Rainer

von (prx) A. K. (prx)


Lesenswert?

~Mercedes~  . schrieb:
> Also gibt es keine gemeinsame Instanz, man müßte also nen Core
> zur Verwaltung abstellen?

Verwaltung von was?

von (prx) A. K. (prx)


Lesenswert?

~Mercedes~  . schrieb:
> Der Transputer, der oben auf den ISDN Karten erwähnt wurde,
> was hat der gemacht? Das ISDN-Protokoll? Hast Du im Kopf, wie der Chip
> hieß?

https://www.ebay.de/itm/Transputer-Inmos-IMST400B-T400-AVM-B1-active-ISDN-ISA-/114079187728

von c-hater (Gast)


Lesenswert?

Arduino Fanboy D. schrieb:

> z.B. die 8 Bit AVR?
> Prächtig, als Master.
> Unangenehm als Slave.

Das trifft für die aktuellen Nachkommen (Tiny0..2, Mega0, DA ,DB series 
nicht mehr zu. Die SPI-Einheit ist bei denen "buffered". Ja, das war 
schon lange überfällig, ist aber nunmehr auch für die AVR8 geschehen. 
Abgehakt!

> das stört.
> Unangenehm.

Damit hinfällig. Genau das ist, was man bedenken sollte, bevor man sich 
auf sowas wie den Propeller einläßt: die Peripherie aller üblichen 
µC-Familien wird immer besser und immer vielfältiger anpassbar.

Genau damit schließt sich zunehmend die Lücke, die vor 1,5 Jahrzehnten 
mal der Ansatz für das Propeller-Konzept war. Damals berechtigt, heute 
einfach mal aus der Zeit gefallen. Höchstens noch für ganz exotische 
Probleme die optimale Lösung.

von Einer K. (Gast)


Lesenswert?

c-hater schrieb:
> Das trifft für die aktuellen Nachkommen (Tiny0..2, Mega0, DA ,DB series
> nicht mehr zu.
Das ist doch schön!

von MCUA (Gast)


Lesenswert?

> Im Hub (der Nabe) geht ein Zeiger rundrum von Prozessor zu Prozessor und
> gibt dem jeweilgen Proz den Zugriff auf das Hub-RAM.
Bloss das haben die nicht erfunden.
Multiprozessor-Systeme kann man mit MCUs/CPUs bauen, wie man sie 
braucht.


> ...Am Propeller kann ein Kern wimre 4 USART machen. Und das wohl bis
> 115 kBaud.
Das ist wirklich "atemberaubend".


>> Das trifft für die aktuellen Nachkommen (Tiny0..2, Mega0, DA ,DB series
>> nicht mehr zu.
> Das ist doch schön!
Und die FIFOs?

von Andi (Gast)


Lesenswert?

Das meiste, was da über den Propeller geschrieben wurde, bezieht sich 
auf den Propeller 1. Der Propeller 2 hat viele der Einschränkungen des 
P1 nicht mehr.
Beim P2 ist es nun nicht ein Zeiger der sich dreht, sondern es sind 8, 
die jeweils auf 8 separate RAM Blöcke zeigen, und bei jedem Takt auf den 
nächsten Block weitergeschaltet werden. Ein 8 flügliger Propeller also, 
statt einem 1 Flügler. Das bewirkt, dass jeder Prozessor nun den 
Speicher in jedem Takt lesen kann, solange die Adresse fortlaufend 
aufsteigend ist, was zu 99% der Fall ist. Das ermöglicht z.B. erst die 
schnelle Ausführung von Code direkt aus dem gemeinsamen Hauptspeicher.

Jeder Pin hat nun eine konfigurierbare Peripherie für UART und solche 
Sachen, man muss nicht mehr alles in Software machen. Ein Prozessor kann 
nun leicht viele UART Kanäle verwalten mit Baudraten bis 30 MHz 
(geschätzt), wenn es sein muss.

von Andi (Gast)


Lesenswert?

void schrieb:
> mh schrieb:
>> Der P2 kann also ~60 ADCs oder DACs haben? Das wäre praktisch, aber
>> irgendwie glaub ich das nicht.
>
> Stimmt auch nicht. Die Aussage von Andi war bewusst irreführend. Der P2
> hat 4 DACs, von denen sich jeder auf 1/4 aller IO Pins mappen lässt.
> Steht auch so im Datenblatt hust wenn man das Dokument in dem nicht
> Mal der Bereich der Versorgungsspannung beschrieben steht und in dem die
> volle DAC Funktionalität es auf genau 3 Sätze bringt so nennen darf.

Mit Glauben und Irreführung hab ich nichts am Hut.
Fakt ist, dass beim Propeller alle Pins grundsätzlich gleich aufgebaut 
sind, genauso wie die 8 Prozessoren. Das war dem Entwickler des Chips 
sehr wichtig.
Die Ansteuerung der Pins geschieht manchmal in Gruppen z.B. für USB oder 
HDMI. Auch die DACs können vom Prozessor, oder vom Streamer in 4er 
Gruppen beschrieben werden, zum Beispiel für VGA, um alle Farbkanäle 
gleichzeitig umzuschalten. Das bedeutet aber nicht, dass da nur 4 DACs 
vorhanden sind, die irgendwie den Pins zugeschaltet werden. Man kann den 
DAC jeden Pins einzeln mit einem 8 oder 16 Bit Wert beschreiben, wenn 
gewünscht.

Auch wenn es für manche unglaublich klingen mag, der Propeller 2 kann 
bis zu:
- 64 DACs
- 64 ADCs
- 32 USB Schnittstellen (Host oder Device)
- 64 UART Kanäle (RX oder TX)
- 64 PWM Ausgänge
- 64 Frequenzzähler
- und vieles mehr, alles natürlich nur einmal pro Pin/Pinpaar 
einsetzbar, aber in fast jeder Kombination.
Dazu all die Softwareperipherie die man selber programmiert.

Manches wird durch die Anzahl Prozessoren begrenzt, so lassen sich "nur" 
8 Video Ausgänge realisieren, diese aber als Component- oder Composite 
Video oder VGA oder HDMI, auch gemischt.

von blub (Gast)


Lesenswert?

Ab Minute 14 erklärt der Erfinder sein Zielpublikum

https://embedded.fm/episodes/2015/2/4/87-make-my-own-steel-foundry

von Olaf (Gast)


Lesenswert?

> Fakt ist, dass beim Propeller alle Pins grundsätzlich gleich aufgebaut
> sind, genauso wie die 8 Prozessoren. Das war dem Entwickler des Chips
> sehr wichtig.

Das finde ich grundsaetzlich sehr sympathisch. Ich denke sobald der Chip 
fertig ist, es also ein Datenblatt als PDF gibt welches einen kompletten 
Eindruck hinterlaesst schau ich mir das nochmal an.

> Auch die DACs können vom Prozessor, oder vom Streamer in 4er
> Gruppen beschrieben werden, zum Beispiel für VGA, um alle Farbkanäle
> gleichzeitig umzuschalten.

Das verwundert mich etwas an der Kiste. Ich meine ein DAC gut und 
schoen, ein schneller auch gut. Aber ich hab den Eindruck als wenn die 
mehr Aufwand und Liebe in DACs als in ADCs gesteckt haben. Wieso? Und 
VGA? Was soll der Quatsch? VGA ist Geschichte.

> Auch wenn es für manche unglaublich klingen mag, der Propeller 2 kann
> bis zu:
> - 64 DACs
> - 64 ADCs
> - 32 USB Schnittstellen (Host oder Device)
> - 64 UART Kanäle (RX oder TX)
> - 64 PWM Ausgänge
> - 64 Frequenzzähler

Fuer mich klingt das auch ueberraschend. Aber wie schon gesagt, das 
liegt am Mangel an Datenblatt. Ausserdem waeren vielleicht 
2-3Applikationen nicht schlecht. Aber 32USB-Schnittstellen ist ja 
schonmal super. Damit koennte man damit schonmal einen dicken USB-Hub 
bauen. Das koennen andere Prozessoren nicht. :-D

Was mich auch interessieren wuerde, Stromverbrauch? Sleepmodi?

Und was mich ganz besonders interessieren wuerde, wenn man alle 
Schnittstellen in Software nachbilden muss, koennte man damit einen 
paralleln Datenbus als Slave nachbilden? Also als Beispiel(!) mal einen 
kompletten 8255 simulieren?

Olaf

von MCUA (Gast)


Lesenswert?

> Das bewirkt, dass jeder Prozessor nun den
> Speicher in jedem Takt lesen kann, solange die Adresse fortlaufend
> aufsteigend ist,..
jeder Prozessor in jedem Takt ???
Bezweifele ich.
Schneller als das zentrale RAM es erlaubt wird RD/WR nicht möglich sein.
Und wie geschrieben, man kann das mit MCUs/CPUs bauen, wie man es haben 
will. (auch mit MB's an RAM)


> ... mal einen kompletten 8255 simulieren? ...
Klar geht das; die Frage ist, wie schnell der das hin bekommt?

von MCUA (Gast)


Lesenswert?

> Genau damit schließt sich zunehmend die Lücke, die vor 1,5 Jahrzehnten
> mal der Ansatz für das Propeller-Konzept war.
Umfangreiche Periph-Einheiten in MCUs gibt es schon seit den 90ern.

von chris_ (Gast)


Lesenswert?

Wie ist es eigentlich mit der Geschwindigkeit?
Die Cores werden wohl mit 180MHz getaktet.
180MHz x 8= 1440MHz

von Olaf (Gast)


Lesenswert?

> Klar geht das; die Frage ist, wie schnell der das hin bekommt?

Das ist ja im Prinzip die Frage. Der Controller muesste dann ja bei
Anfragen schnell genug Daten Bereitstellen oder abolen. Genau
das geht ja bei einem normalen Mikrcontroller nicht weil du dort
ja immer irgendeinen IRQ oder was anderes laufen hast das sowas 
verzoegert.
Fuer solche Spielchen koennte ein Multicore im Vorteil sein.

Olaf

von Nick M. (Gast)


Lesenswert?

Olaf schrieb:
> Genau
> das geht ja bei einem normalen Mikrcontroller nicht weil du dort
> ja immer irgendeinen IRQ oder was anderes laufen hast das sowas
> verzoegert.

Das lässt sich oft ganz schnell beantworten ob ein single-core schnell 
genug für eine Aufgabe ist:
Wie lange dauert ein Interrupt bis man überhaupt in der IRQ-Routine 
gelandet ist?

IRQ heißt ja auch Interupt request. Es kann sein, dass ein höherer IRQ 
aktiv ist, oder ein IRQ gesperrt wurde, weil im Moment nicht-atomare 
Daten bearbeitet werden.
Das IRQ-Problem entfällt beim xmos und Propeller komplett, weil es 
keinen IRQ gibt. D.h. es gibt keine Timing-Überaschungen. Beim xmos gibt 
es das nicht-atomar-Problem überhaupt nicht. Es gibt kein shared memory 
auf das man direkt zugreifen kann.

von (prx) A. K. (prx)


Lesenswert?

Nick M. schrieb:
> Beim xmos gibt
> es das nicht-atomar-Problem überhaupt nicht. Es gibt kein shared memory
> auf das man direkt zugreifen kann.

Die bis zu 8 Threads eines XMOS Cores haben gemeinsamen Speicher und 
können sich über entsprechende Hardware synchronisieren. Nur nicht die 
über Links kommunizierenden verschiedenem Cores.

von mh (Gast)


Lesenswert?

Andi schrieb:
> Auch wenn es für manche unglaublich klingen mag, der Propeller 2 kann
> bis zu:
> - 64 DACs
> - 64 ADCs
> - 32 USB Schnittstellen (Host oder Device)
> - 64 UART Kanäle (RX oder TX)
> - 64 PWM Ausgänge
> - 64 Frequenzzähler
> - und vieles mehr, alles natürlich nur einmal pro Pin/Pinpaar

Das hab ich beim überfliegen jetzt auch so verstanden. Wobei das eher 
"64 - Anzahl Versorgungspins" ist. Allerdings ist das Datenblatt so 
mies, dass ich nach ein paar Minuten aufhören musste und keine 
eindeutige Antwort gefunden habe. Wenn das Datenblatt irgendwann mal 
fertig ist, gucke ich mir das vielleicht nochmal an. Mal davon 
abgesehen, dass der Inhalt eher mau ist, die docs.google Idee ist eine 
Katasrophe. Ich konnte nichmal nach pdf exportieren, obwohl es die 
Option gibt, es ist einfach nichts passiert. Und ich kann nur das 
Chip-Datenblatt oder das Io-Zellen-Datenblatt öffnen, nicht beides 
gleichzeitig?
Die Pins, wenn es denn tatsächlich stimmt und so funktioniert, sind sehr 
interessant. Schön wäre es, wenn es die Pins mit einem ordentlichen Kern 
geben würde, dann wäre das Zielpublikum sicher deutlich größer. Bei dem 
Preis greif ich vermutlich eher zum FPGA, dann muss ich nix neues lernen 
und hab noch mehr "Flexibilität" ;-).

chris_ schrieb:
> Wie ist es eigentlich mit der Geschwindigkeit?
> Die Cores werden wohl mit 180MHz getaktet.
Keine Ahnung, auf der Webseite konnte ich nichts finden. Im Datenblatt 
wollte ich nicht suchen.

von (prx) A. K. (prx)


Lesenswert?

(prx) A. K. schrieb:
> Die bis zu 8 Threads eines XMOS Cores

PS: Das bezieht sich auf die erste Generation, die XS1, von 2008.

von Nick M. (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Die bis zu 8 Threads eines XMOS Cores haben gemeinsamen Speicher und
> können sich über entsprechende Hardware synchronisieren.

Es ändert aber nichts daran, dass man nicht auf den gemeinsamen Speicher 
direkt zugreifen kann.
Direkt im Sinne von: Ich greif direkt auf Daten eines anderen cores oder 
threads zu. Man muss immer über ein Interface gehen, es gibt keinen 
address-operator (&).

By reference geht in XC anders:
1
void swap(int &a, int &b) {
2
  int tmp = x;
3
  x = y;
4
  y = tmp;
5
}
6
7
swap(a, b);

Es kann auch nur eine Referenz auf ein und das selbe Objekt generiert 
werden.

von MCUA (Gast)


Lesenswert?

>> Genau
>> das geht ja bei einem normalen Mikrcontroller nicht weil du dort
>> ja immer irgendeinen IRQ oder was anderes laufen hast das sowas
>> verzoegert.
> Das lässt sich oft ganz schnell beantworten ob ein single-core schnell
> genug für eine Aufgabe ist:
> Wie lange dauert ein Interrupt bis man überhaupt in der IRQ-Routine
> gelandet ist?
Sofern diese Anfragen-Beantwortung nicht an der CPU vorbei (DMA, sep 
Hardware etc.) gehen könnte.
Je schneller es sein muss, desto eher ist sep. Hardware erforderlich.
(die CPU mit unendl. f gibt es nicht)



> Das IRQ-Problem entfällt beim xmos und Propeller komplett, weil es
> keinen IRQ gibt.
Und dadurch ist das doch vorhandene IRQ-Problem unlösbar (!), wenn man 
mehr als 8 äussere Anfragen (Threads) hat (die wegen Komplexität von 
einer CPU gemacht werden müssen).
(Einige CPUs haben bereits 16 oder mehr INT-Prioritäten)
> D.h. es gibt keine Timing-Überaschungen
Doch, Timing-Katastrophen.
Eine CPU(Kern), die nichtmal mit INTs umgehen kann, ist (meist) 
unbrauchbar.



> Die bis zu 8 Threads eines XMOS Cores haben gemeinsamen Speicher und
> können sich über entsprechende Hardware synchronisieren.
Auch diese Cores können m.W. nicht gleichzeitig auf den gemeinsamen 
Speicher zugreifen.

von mh (Gast)


Lesenswert?

MCUA schrieb:
> Eine CPU(Kern), die nichtmal mit INTs umgehen kann, ist (meist)
> unbrauchbar.

Es ist nur die Frage, ob der Propeller2 mit IRQs umgehen kann. Ich habe 
etwas von Eventsystem gelesen. Aber um mehr darüber herauszufinden, 
müsste ich in der miesen Doku lesen ...

von (prx) A. K. (prx)


Lesenswert?

MCUA schrieb:
> Und dadurch ist das doch vorhandene IRQ-Problem unlösbar (!), wenn man
> mehr als 8 äussere Anfragen (Threads) hat (die wegen Komplexität von
> einer CPU gemacht werden müssen).

Fehlende Interrupts bedeuten nicht unbedingt, dass man Ereignisse 
explizit abfragen muss. Beim Propeller mag das notwendig sein, aber das 
hängt mit deren fester Zuordnung von Threads zu Cores zusammen. Wenn ein 
Thread mit einem Core untrennbar verknüpft ist, kann man darin ebensogut 
pollen, warten spart höchstens Strom.

Wenn Threads jedoch freier zugeordnet werden können und inaktive Threads 
keine Cores belegen, sieht das anders aus. Bei Transputern war das nur 
anders abgebildet: Threads konnten auf Hardware-Ereignisse warten, und 
trat das Ereignis ein, hat der Hardware-Scheduler den Thread aktiviert. 
Wird bei XMOS vmtl ähnlich sein.

: Bearbeitet durch User
von Nick M. (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Threads konnten auf Hardware-Ereignisse warten, und
> trat das Ereignis ein, hat der Hardware-Scheduler den Thread aktiviert.
> Wird bei XMOS vmtl ähnlich sein.

Ja, das ist genau so. Man muss nicht mal pollen, es wartet Hardware auf 
ein Muster am Eingang. Sobald das da ist geht es los.
Man kann einen thread exklusiv einem core zuweisen, damit der nicht 
mehrere threads übernimmt. Umgekehrt kann man "unwichtiges" im 
Hintergrund laufen lassen.
xmos ist deterministisch, die Reaktionszeiten lassen sich berechnen. 
Dazu gibt es die Software XScope.

von Laie (Gast)


Lesenswert?

mh schrieb:
> MCUA schrieb:
>> Eine CPU(Kern), die nichtmal mit INTs umgehen kann, ist (meist)
>> unbrauchbar.
> Es ist nur die Frage, ob der Propeller2 mit IRQs umgehen kann. Ich habe
> etwas von Eventsystem gelesen.

"16 unique event trackers that can be polled and waited upon
3 prioritized interrupts that trigger on selectable events"
Von der Shopseite:
https://www.parallax.com/product/propeller-2-multicore-microcontroller-chip/

von Nick M. (Gast)


Lesenswert?

MCUA schrieb:
> Eine CPU(Kern), die nichtmal mit INTs umgehen kann, ist (meist)
> unbrauchbar.

Ein Programmierer der nicht ohne INTs auskommt ist unbrauchbar.

von mh (Gast)


Lesenswert?

Laie schrieb:
> "16 unique event trackers that can be polled and waited upon
> 3 prioritized interrupts that trigger on selectable events"
> Von der Shopseite:

Schön, das sagt nun wirklich nichts aus, außer dass es 16 von irgendwas 
und 3 von was anderem gibt und dass man irgendwas damit machen kann.

von Laie (Gast)


Lesenswert?

mh schrieb:
> Laie schrieb:
>> "16 unique event trackers that can be polled and waited upon
>> 3 prioritized interrupts that trigger on selectable events"
>> Von der Shopseite:
> Schön, das sagt nun wirklich nichts aus, außer dass es 16 von irgendwas
> und 3 von was anderem gibt und dass man irgendwas damit machen kann.
Ja, wollte deine Aussage nur in einen Zusammenhang bringen. Interrupts 
zu Pollen ("polled and waited upon 3 prioritized interrupts") scheint 
mir auch ein Widerspruch zu sein.

von void (Gast)


Lesenswert?

Andi schrieb:
> der Propeller 2 kann bis zu:
> - 64 DACs

Steht aber anders im Datenblatt.

mh schrieb:
> Allerdings ist das Datenblatt so mies,

Genau. Und ohne ordentliche Dokumente ist das Teil für die Tonne.

von Andi (Gast)


Lesenswert?

Laie schrieb:
> Ja, wollte deine Aussage nur in einen Zusammenhang bringen. Interrupts
> zu Pollen ("polled and waited upon 3 prioritized interrupts") scheint
> mir auch ein Widerspruch zu sein.

Man "polled" ja auch nicht die Interrupts, sondern die Events, steht da 
doch auch so. Die möglichen Events und was man damit machen kann wird im 
Dokument doch beschrieben, halt nicht in der Einleitung, sondern im 
entsprechenden Kapitel.

Wenn man als Event z.B. die negative Flanke eines Pins setzt, dann hat 
man 3 Möglichkeiten es (ihn?) zu nutzen:
1) Per Softwareloop den Status zu pollen - eher langsam, dafür kann man 
noch anderes im Loop machen.
2) Einen Interrupt auslösen zu lassen - Reaktionszeit hängt davon ab was 
der Prozessor gerade abarbeitet, manches kann nicht sofort unterbrochen 
werden.
3) Den Prozessor in einen Wartezustand zu versetzen, indem er nur auf 
das Ereignis wartet. Die Reaktionszeit ist dann ein einzelner Takt! Das 
ist nur mit wirklich parallel laufenden Cores, wie beim Propeller 
möglich.

Wenn man also den P2 als Peripherie Baustein an einen Bus hängen will, 
dabei auf die fallende Flanke des ChipSelect wartet, wird der nächste 
Befehl zum einlesen der Daten und/oder Adresse innerhalb von 2 
Taktzyklen ausgeführt. Das dauert also 10ns, wenn man den P2 mit 200 MHz 
taktet.

Die maximale Taktfrequenz des P2 liegt offiziell bei 180 MHz, das ist 
aber ein sehr vorsichtiger Wert von OnSemi, dem Chipfertiger. In der 
Praxis hat sich gezeigt das man bis etwas über 300 MHz gehen kann. Die 
meisten Befehle benötigen 2 Takte, also erreicht ein Prozessor etwa 
100..150 MIPs.

Olaf schrieb:
> Und
> VGA? Was soll der Quatsch? VGA ist Geschichte.

Ja, da wurde der Chip leider im laufe der langen Entwicklungszeit von 
der digitalen Realität überholt.
Immerhin hat man noch eine HDMI Schnittstelle eingebaut, als sich 
abzeichnete, dass der Chip auch mit 250 MHz läuft. Damit ist 
Digitalvideo mit 640 x 480 Pixel möglich. Für Computerverwöhnte 
vielleicht lächerlich, aber es handellt sich ja auch um einen 
Microcontroller. Und der Bildspeicher füllt bei 16bit Farben mit dieser 
Auflösung auch schon fast das ganze RAM.

von Stefan F. (Gast)


Lesenswert?

Andi schrieb:
> Damit ist Digitalvideo mit 640 x 480 Pixel möglich.
> Für Computerverwöhnte vielleicht lächerlich, aber es handelt
> sich ja auch um einen Microcontroller

Da der Hersteller in der Werbung gerade die Videoausgabe als 
Highlight/Anwendungsbeispiel hervor hebt sollte der Punkt auch 
überzeugen.

Wenn ich ein Auto bewerben würde, würde ich ja auch nicht schreiben: 
Erreicht bis zu 100 km/H in 30 Sekunden.

Da fehlt einfach die Begeisterungsfähigkeit mit 640x480 Punkten.

von Andi (Gast)


Lesenswert?

void schrieb:
> Andi schrieb:
>> der Propeller 2 kann bis zu:
>> - 64 DACs
>
> Steht aber anders im Datenblatt.
>
> mh schrieb:
>> Allerdings ist das Datenblatt so mies,
>
> Genau. Und ohne ordentliche Dokumente ist das Teil für die Tonne.

Hier der Mitschnitt des Zoom Meetings von heute Nacht. Da erklärt der 
Entwickler Aufbau und Funktion der DACs. Auch das Dithering von 8 auf 16 
Bits wird gezeigt.
https://www.youtube.com/watch?v=N1Yj9_Dq49E

Ich konnte das GoogleDoc Datenblatt als PDF runterladen, Online ist es 
in der Tat ungeniessbar. Datenblatt ist wahrscheinlich die falsche 
Bezeichnung, es ist mehr eine Beschreibung der Möglichkeiten und eine 
Referenz.

von Nick M. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Da fehlt einfach die Begeisterungsfähigkeit mit 640x480 Punkten.

Wird oft genug in kleinen Steuerungen als viel zu groß bewertet. Z.B. 
Kaffeemaschinen, WaMa, Telefon, ...
Wie viel kann denn der Arduino so an Pixeln?

von c-hater (Gast)


Lesenswert?

Nick M. schrieb:

> Ein Programmierer der nicht ohne INTs auskommt ist unbrauchbar.

Das würde ich doch stark in Frage stellen wollen. Ja klar, es gibt viele 
Interrupts, die vorhersehbar eintreten und somit bei optimaler 
Programmierung quasi überflüssig werden.

Aber: es gibt eben auch die unvorhersehrbare Interrupts aus externen 
Quellen. Und für diese ist nunmal die Nutzung des Interrupt-Mechanismus 
meist (aber auch nicht immer) die beste Lösung.

Unbrauchbar ist nur ein Programmierer, der nicht die optimale Wahl für 
das Target und das Problem treffen kann, also auf jeden Fall schonmal 
jeder, der nur "Hochsprachen" beherrscht, die das Timing abstrahieren 
(also diesbezüglich rein garnix garantieren).

Weil: er kann darauf dann schlicht keinen Einfluss mehr nehmen, das gibt 
sein Werkzeug nicht her...

von Andi (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Da der Hersteller in der Werbung gerade die Videoausgabe als
> Highlight/Anwendungsbeispiel hervor hebt sollte der Punkt auch
> überzeugen.

Werbung? Wo denn?

Über HDMI lassen sich immerhin die kleinen Monitore ansteuern, wie sie 
für den RasPi verkauft werden.
Per VGA oder Component Video gehen viel höhere Auflösungen, und das auch 
noch mit weniger Pins und Leitungen.
Digital hat nicht nur Vorteile...

von S. R. (svenska)


Lesenswert?

Andi schrieb:
> Olaf schrieb:
>> Und VGA? Was soll der Quatsch? VGA ist Geschichte.
> Ja, da wurde der Chip leider im laufe der langen Entwicklungszeit
> von der digitalen Realität überholt.

VGA gibt es seit 1987, taucht noch immer an vielen Stellen auf und ist 
erstaunlich kompatibel. Es wird wahrscheinlich länger gelebt haben als 
jede ihm nachfolgende Digitalschnittstelle.

> Immerhin hat man noch eine HDMI Schnittstelle eingebaut, als sich
> abzeichnete, dass der Chip auch mit 250 MHz läuft. Damit ist
> Digitalvideo mit 640 x 480 Pixel möglich.

Wenn ich sehe, dass die automatischen Tankstellen hier mit 640x480 
Auflösung und geschätzten 1fps laufen (fällt bei der PIN-Eingabe schon 
deutlich auf) und auf der Gegenseite sehe, wie die Kaffeemaschinen in 
der Firma bei gleicher Auflösung an Animationen scheitern...

: Bearbeitet durch User
von Nick M. (Gast)


Lesenswert?

c-hater schrieb:
> der nur "Hochsprachen" beherrscht, die das Timing abstrahieren
> (also diesbezüglich rein garnix garantieren).

Hochsprachen abstrahieren also das Timing.
Und eine ISR in Hochsprache garantiert überhaupt nichts. Das kann 
teilweise Stunden dauern.

Man lernt nie aus. Besonders hier.

von mh (Gast)


Lesenswert?

Andi schrieb:
> Hier der Mitschnitt des Zoom Meetings von heute Nacht.

Die können Videos machen solange sie wollen, bis es kein ordentliches 
Datenblatt als pdf gibt, werd ich mich damit nicht weiter beschäftigen.

von Nick M. (Gast)


Lesenswert?

mh schrieb:
> Die können Videos machen solange sie wollen, bis es kein ordentliches
> Datenblatt als pdf gibt, werd ich mich damit nicht weiter beschäftigen.

Ich vermute, dass das hier durchaus auf Gegenliebe stoßen würde.

von Stefan F. (Gast)


Lesenswert?

Andi schrieb:
> Werbung? Wo denn?

Siehe die Bilder auf https://www.parallax.com/propeller-2/

Beitrag #6530673 wurde von einem Moderator gelöscht.
Beitrag #6530769 wurde von einem Moderator gelöscht.
Beitrag #6530787 wurde von einem Moderator gelöscht.
von 900ss (900ss)


Lesenswert?

Stop! Bitte aufhören. Das Thema "ISR besser in Hochsprache oder nicht" 
ist nicht Thema dieses Threads. Schlagt euch bitte in einem anderen 
Thread den Kopf ein.

Beitrag #6530795 wurde von einem Moderator gelöscht.
Beitrag #6530800 wurde von einem Moderator gelöscht.
von void (Gast)


Lesenswert?

Andi schrieb:
> Hier der Mitschnitt des Zoom Meetings von heute Nacht. Da erklärt der
> Entwickler Aufbau und Funktion der DACs.

blub schrieb:
> Ab Minute 14 erklärt der Erfinder sein Zielpublikum
> https://embedded.fm/episodes/2015/2/4/87-make-my-own-steel-foundry

Verstehe. Als unter 50 Jähriger gehöre ich wohl nicht zur Zielgruppe, 
welche sich 2 Stunden per Zoom einen 8-bit R2R DAC vorlesen lässt und 
dann immer noch glaubt das es sich um eine PWM-Ausgabe handelt. 
Geräusch von Kopf auf Tischplatte

Nick M. schrieb:
> Ich vermute, dass das hier durchaus auf Gegenliebe stoßen würde.

Du meinst die Zielgruppe der unter 20 Jährigen nach Youtube-Video 
Schaltung Zusammenstecker? Ja, da könnte der P2 in der Tat gross 
einschlagen. Datenblatt wird da ja auch nicht benötigt für.

mh schrieb:
> bis es kein ordentliches Datenblatt als pdf gibt,
> werd ich mich damit nicht weiter beschäftigen.

Dem kann ich mich nur anschliessen.

Beitrag #6530808 wurde von einem Moderator gelöscht.
Beitrag #6530818 wurde von einem Moderator gelöscht.
Beitrag #6530821 wurde von einem Moderator gelöscht.
Beitrag #6530823 wurde von einem Moderator gelöscht.
Beitrag #6530831 wurde von einem Moderator gelöscht.
Beitrag #6530833 wurde von einem Moderator gelöscht.
Beitrag #6530834 wurde von einem Moderator gelöscht.
Beitrag #6530835 wurde von einem Moderator gelöscht.
Beitrag #6530837 wurde von einem Moderator gelöscht.
Beitrag #6530839 wurde von einem Moderator gelöscht.
Beitrag #6530854 wurde von einem Moderator gelöscht.
Beitrag #6530867 wurde von einem Moderator gelöscht.
Beitrag #6530868 wurde von einem Moderator gelöscht.
von (prx) A. K. (prx)


Lesenswert?

Nick M. schrieb im Beitrag #6530769:
> Der Aufruf einer ISR dauert immer gleich lang, egal ob die ISR in
> Assembler oder einer Hochsprache geschrieben ist.

Auf welche Plattform beziehst du dich dabei?

> Ausser du schreibst
> alles in Assembler und weißt, welche Register nicht gesichert werden
> müssen.

Denn das kann ein Compiler auch.

von Nick M. (Gast)


Lesenswert?

(prx) A. K. schrieb:
>> Ausser du schreibst
>> alles in Assembler und weißt, welche Register nicht gesichert werden
>> müssen.
>
> Denn das kann ein Compiler auch.

:-))
Natürlich, er kann nicht nur, er muss auch.
Ich meinte, dass er, wenn er alles in Asm schreibt, noch ein paar 
Register sparen könnte.

(prx) A. K. schrieb:
> Auf welche Plattform beziehst du dich dabei?

Auf welcher ist es nicht so? Ich sprech von µCs.

Beitrag #6530904 wurde von einem Moderator gelöscht.
Beitrag #6530912 wurde von einem Moderator gelöscht.
von (prx) A. K. (prx)


Lesenswert?

Nick M. schrieb:
> Auf welcher ist es nicht so? Ich sprech von µCs.

Ob es wohl bei jedem Compiler für Z80 vorgesehen ist, ggf den zweiten 
Registersatz in Interrupts zu nutzen?

Allerdings wollte ich damit nur absichern, dass konventionelle ISRs 
gemeint sind. Eventbasierte Aktivierung von Hardware-Threads hat mehr 
mit solchen alternativen Registersätzen gemein, weniger mit Stack-Push.

: Bearbeitet durch User
von Nick M. (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Eventbasierte Aktivierung von Hardware-Threads hat mehr
> mit solchen alternativen Registersätzen gemein, weniger mit Stack-Push.

Ah OK! Nein, die nicht.
"Ganz normale INTs", wenn das eine qualifizierte Beschreibung ist. :-/

von (prx) A. K. (prx)


Lesenswert?

Nick M. schrieb:
> Natürlich, er kann nicht nur, er muss auch.

Beim Interrupt von 6800&Co hat schon die Hardware alles gesichert (war 
ja nicht viel). Bei TIs 9995 waren Interrupts komplette Kontextwechsel, 
weil Register im RAM. Da muss er nicht, denn für einen Compiler gibts 
diesbezüglich nichts zu tun. ;-)

: Bearbeitet durch User
von Gerhard O. (gerhard_)


Lesenswert?

Junge, Junge! Ihr macht mir echt Sorgen;-)

Irgendwie kann ich mir trotz aller Nischenvorteile als eingefleischter 
Pragmatiker nicht wirklich vorstellen, daß die Propellerarchitektur groß 
Fuß fassen wird. Da müssen die Planeten wirklich zueinander richtig 
stehen um einen klaren Vorteil in einer spezifischen Situation zu haben. 
Ansonsten kommt man in der realen Welt wahrscheinlich mit herkömmlichen, 
bewährten Lösungen weiter. Sicherlich, die Konzepte der 
Propellerarchitektur sind teilweise "intriguing", aber die Industrie 
frisst doch lieber von dem das sie kennt. Wenn in der Firma erst gelernt 
werden muß um praktisch Produkte entwickeln zu können, kostet das Geld 
und hat schon deshalb einen Nachteil. Abgesehen davon gibt es viele 
Branchen wo SW aus sicherheitstechnischen Gründen schon einen Stammbaum 
haben muß um abgenommen werden zu können.

Ich bin der Meinung, daß Propellerarchitektur nicht besser oder 
schlechter ist, sondern grundsätzlich anderes konzeptionelles Denken im 
Ansatz bedarf und Grenzen in der Skalierbarkeit da sind, die die Größe 
der Anwendung limitieren. Das sind einfach verschiedene Welten die aber 
durchaus nebeneinander existieren können.

Da ich aber alt, lernfaul und gefrässig bin, werde ich 
höchstwahrscheinlich bis zum Ende meiner Tage beim althergebrachten 
bleiben; unintuitiv wie ich einfach bin, die bekannten Wege beschreiten 
bis man mich als altes Eisen dann aussondert. Bis dahin werde ich auf 
herkömmlichen uC mein Unwesen treiben;-)

Schönes Neues Jahr noch!

Gerhard

von (prx) A. K. (prx)


Lesenswert?

Gerhard O. schrieb:
> Irgendwie kann ich mir trotz aller Nischenvorteile als eingefleischter
> Pragmatiker nicht wirklich vorstellen, daß die Propellerarchitektur groß
> Fuß fassen wird.

Ich auch nicht, aber warum sollte man nicht über die Architektur 
diskutieren?

von Nick M. (Gast)


Lesenswert?

Groß Fuß wird weder der Propeller noch xmos fassen.
Propeller oder xmos sind auch nicht besser oder schlechter. Sie sind 
aber besser oder schlechter für einzelne Aufgaben geeignet. Und oft 
genug komplett ungeeignet.
Der Propeller ist überhaupt nicht skalierbar, xmos einigermaßen.


Gerhard O. schrieb:
> Da ich aber alt, lernfaul und gefrässig bin, werde ich
> höchstwahrscheinlich bis zum Ende meiner Tage beim althergebrachten
> bleiben;

Alt bin ich auch. Das ist genug. :-)

von Gerhard O. (gerhard_)


Lesenswert?

Nick M. schrieb:
> Alt bin ich auch. Das ist genug. :-)

Darauf sollte man was trinken!

von chris_ (Gast)


Lesenswert?

>Der Propeller ist überhaupt nicht skalierbar, xmos einigermaßen.

Hängt von der Software ab und wie gut einer der Prozessorkerne als 
Kommunikationsprozessor zum nächsten Propeller programmiert ist.

von Nick M. (Gast)


Lesenswert?

chris_ schrieb:
>>Der Propeller ist überhaupt nicht skalierbar, xmos einigermaßen.
>
> Hängt von der Software ab und wie gut einer der Prozessorkerne als
> Kommunikationsprozessor zum nächsten Propeller programmiert ist.

Unter skalierbar verstehe ich "Den gibts auch mit mehr RAM oder im 
16-poligen Gehäuse".

Wenn du die aber durch aneinanderhängen skalieren willst: Ja das ginge 
natürlich.
Mit handshake und allem schätze ich etwa 40 MByte / sec peak, dauerhaft 
5 MByte / s

von Marco H. (damarco)


Lesenswert?

Bei den Xmos nennt man das Channels die können 100Mbit/s. Das Konzept 
ist schon interessant, erfordert aber schon ein umdenken. Man gewöhnt 
sich an den XC den Rest kann man man mit C/C++ erledigen. XC umfasst nur 
das was sich auf C/C++ nicht abbilden lässt. Der Umfang ist nicht sehr 
groß und Hardware bezogen. Channels, I/Os,Takt, Prozess etc. VHDL 
ähnlich...

Nachteil ist das man alle Schnittstellen in der Software bauen muss. Es 
gibt zwar Bibliotheken aber die machen er einen ungepflegten Eindruck. 
Voll mit Fehlern...

Ich würde ehrlich heute nicht mehr mit Xmos eine Neuentwicklung starten, 
sondern mir einen ARM suchen...

von mh (Gast)


Lesenswert?

Ich hab nochmal ne Frage zum Hubmemory. So wie ich das verstanden habe, 
kann jeder Cog nur in jedem 8. Takt auf diesen Speicher zugreifen. Wie 
genau funktioniert das? Wenn man einen Zugriff zum falschen Zeitpunkt 
startet, dauert der Zugriff dann im schlimmsten Fall 8 Takte? Muss man 
dann in seinem Code die Takte zählen, um die maximale Geschwindigkeit zu 
erreichen? Wenn ja, übernimmt der Compiler das, wenn man in einer 
höheren Sprache arbeitet?

Die Frage geistert seit heut morgen in meinem Kopf rum, nachdem ich 
einen "bank conflict" in einem CUDA Kernel fixen musste. Ich konnte auf 
die schnelle keine zufriedenstellende Antwort finden.

von (prx) A. K. (prx)


Lesenswert?

mh schrieb:
> Wenn man einen Zugriff zum falschen Zeitpunkt
> startet, dauert der Zugriff dann im schlimmsten Fall 8 Takte?

Ja, keine Arbitrierung, sondern Rotation wie bei einem Propeller. 
Dadurch wird es deterministisch. Mit Arbitrierung käme ein faktisch 
unbestimmbarer Zeitfaktor hinein.

Das Konzept vom Propeller 1 sah die Programmierung zeitkritischer Module 
direkt in COG-Assembler vor. Die Hochsprache SPIN wird interpretiert, 
nicht compiliert.

: Bearbeitet durch User
von Nick M. (Gast)


Lesenswert?

mh schrieb:
> dauert der Zugriff dann im schlimmsten Fall 8 Takte? Muss man dann in
> seinem Code die Takte zählen, um die maximale Geschwindigkeit zu
> erreichen?

Beim P1 dauert das, ja
 Beim P2 scheint es anders zu sein.

Dadurch welchen Code man wo laufen lässt  kann man die Zugriffe 
optimieren (interleaving)
Man kann etwas Daten lokal halten, direkt von Proz zu Proz kann man 
keine Daten austauschen (P1).

von Nick M. (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Die Hochsprache SPIN wird interpretiert,

... ähnlich einer JVM oder P-code

von mh (Gast)


Lesenswert?

(prx) A. K. schrieb:
> mh schrieb:
>> Wenn man einen Zugriff zum falschen Zeitpunkt
>> startet, dauert der Zugriff dann im schlimmsten Fall 8 Takte?
>
> Ja, keine Arbitrierung, sondern Rotation wie bei einem Propeller.
> Dadurch wird es deterministisch. Mit Arbitrierung käme ein faktisch
> unbestimmbarer Zeitfaktor hinein.

Das bedeutet dann, man muss beim ersten Zugriff warten bis man dran ist 
und kann von da Takte zählen, wenn man schnell sein will?

von (prx) A. K. (prx)


Lesenswert?

mh schrieb:
> Das bedeutet dann, man muss beim ersten Zugriff warten bis man dran ist
> und kann von da Takte zählen, wenn man schnell sein will?

Üblicherweise wird man per Timer arbeiten. Aber wenn es auf jeden Takt 
ankommt, kann zählen angesagt sein.

von Andi (Gast)


Lesenswert?

Beim Propeller 1 kann ein Prozessor nur alle 16 Takte auf das HubRAM 
zugreifen, da jeder Zugriff 2 Takte dauert.
Takte zählen muss man nicht gross, man kann einfach 2 Befehle zwischen 
zwei Hub Zugriffen ausführen, ohne dass diese zusätzlich Zeit benötigen.

Da alle höheren Programmiersprachen des P1 den Code aus dem HubRAM lesen 
und ausführen, gibt es da leider nicht viel zu optimieren.

von Olaf (Gast)


Lesenswert?

> Takte zählen muss man nicht gross, man kann einfach 2 Befehle zwischen
> zwei Hub Zugriffen ausführen, ohne dass diese zusätzlich Zeit benötigen.

Ich wuerde sowas nicht ueberbewerten. Ich kenne sowas aehnliches vom 
SH2A. Also einem Microcontroller der Superscalar ist. (er kann mehrere 
Befehle gleichzeitig ausfuehren) Da ist es dann Aufgabe des Compilers 
seinen Code so anzuordnen das dies moeglichst gut klappt. Als 
Programmierer merkt man davon nichts solange man nicht im Debugger im 
Singlestep durch den Code wandert.

BTW: Ich hab mich noch nie auf dem Level mit ARM beschaeftigt. Sollten 
die nicht mittlerweile auch Superscalar sein?

Olaf

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.