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?
:
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.)
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
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.
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.
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.
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.
> 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
Vielleicht nur so ein obsoletes Ding wo die Energie-überschäumenden Jungspunde sich austoben können.
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.
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.
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
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.
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.
> 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
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.
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
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.
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
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.
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.
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.
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.
Bis jetzt fehlt hier noch der Link: https://www.parallax.com/propeller-2/ Die Seite braucht aber ewig zum laden.
(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 :)
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?
(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.
(prx) A. K. schrieb: > Problemlos zu finden: $14.95 Hast du zufällig auch ein "nicht docs.google" Datenblatt gefunden?
Stefan ⛄ F. schrieb: > Ist viel billiger als ich befürchtet hatte. Aber trotzdem immer noch viel teuerer als angemessen für die Leistung...
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 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.
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.
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.
(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.
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.
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.
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.
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
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?
Arduino Fanboy D. schrieb: > Es gibt ja noch mehr Ansätze, welche auf massive Parallelverarbeitung > setzen Interessant!
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.
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.
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.
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.
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.
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?
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.
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.
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.
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
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?
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.
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.
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
(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.
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
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.
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)?
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
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?
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)
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!
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).
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.
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.
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?
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
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
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. :)
...und rein interessenhalber...welcher Programmieralgorithmus ist mehr als eine Touringmaschine? Bin echt gespannt! Aber vielleicht auch nur zu doof... Gruß Rainer
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.
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.
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.
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
(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
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.
(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...
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.
Tim King hat ja auch nur das Amiga Betriebsystem entworfen. Und dann noch Transputer. Kinderkram
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
>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.
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.
>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.
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?
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.
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.
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.
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.
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.
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?
> 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
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.
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.
>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.
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.
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.
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?!
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.
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.
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.
mh schrieb: > Wenn du so speziell werden willst ... Wenn Du spezielle und klare Anforderungen hast, solltest du einfach nachschauen.
Angehängte Dateien:
Achtung: Der Nick ist wieder da. Er verwickelt euch in sinnlose Endlos-Diskussionen. Gestern bin ich auf ihn herein gefallen.
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.
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.
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?
Geiler Thread! Dann heißt der Propeller also Propeller, da er round robin in Hardware macht, hab ich das richtig vertanden? mfg
~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.
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
Angehängte Dateien:
-
parallaxPropeller.png
810 KB
>da er round robin in Hardware macht
Dies betrifft aber den "shared memory".
~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.
~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
(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ß?
~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 ? :-)
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
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
~Mercedes~ . schrieb: > Also gibt es keine gemeinsame Instanz, man müßte also nen Core > zur Verwaltung abstellen? Verwaltung von was?
~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
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.
c-hater schrieb: > Das trifft für die aktuellen Nachkommen (Tiny0..2, Mega0, DA ,DB series > nicht mehr zu. Das ist doch schön!
> 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?
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.
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.
Ab Minute 14 erklärt der Erfinder sein Zielpublikum https://embedded.fm/episodes/2015/2/4/87-make-my-own-steel-foundry
> 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
> 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?
> 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.
Wie ist es eigentlich mit der Geschwindigkeit? Die Cores werden wohl mit 180MHz getaktet. 180MHz x 8= 1440MHz
> 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
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.
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.
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.
(prx) A. K. schrieb: > Die bis zu 8 Threads eines XMOS Cores PS: Das bezieht sich auf die erste Generation, die XS1, von 2008.
(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.
>> 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.
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 ...
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
(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.
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/
MCUA schrieb: > Eine CPU(Kern), die nichtmal mit INTs umgehen kann, ist (meist) > unbrauchbar. Ein Programmierer der nicht ohne INTs auskommt ist unbrauchbar.
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.
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.
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.
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.
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.
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.
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?
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...
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...
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
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.
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.
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.
Beitrag #6530673 wurde von einem Moderator gelöscht.
Beitrag #6530769 wurde von einem Moderator gelöscht.
Beitrag #6530787 wurde von einem Moderator gelöscht.
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.
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.
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.
(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.
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
(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. :-/
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
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
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?
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. :-)
>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.
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
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...
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.
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
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).
(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?
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.
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.
> 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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.