Hi, den finde ich ja spontan sehr cool: http://de.wikipedia.org/wiki/Parallax_Propeller 8 Core, 32 Bit MCU. Hat jemand Erfahrungen damit gemacht? Wo kauft man den in DE am besten? Sieht mir so aus als müsste man nicht unbedingt ein Dev Board dafür haben, scheint so minimalistische Beschaltung zu brauchen wie ein AVR? Wie programmiert man den? Vg, Conny
Conny G. schrieb: > Hat jemand Erfahrungen damit gemacht? Ja, Beitrag "Re: CP/M auf ATmega88" Conny G. schrieb: > Wo kauft man den in DE am besten? z.B. hier: http://www.watterott.com/de/Parallax?x310b2=12ccc65956410d4eabe358945700025b Conny G. schrieb: > Wie programmiert man den? über USB Und hier noch ein guter Link: http://hive-project.de/
Hi
>Wo kauft man den in DE am besten?
CSD hat die auch im Sortiment.
MfG Spess
Hallo, netten und schnellen Service habe ich bei der Firma Sander Elektronik erhalten. Netter telefonischer Kontakt, Herr Sander gibt sich große Mühe und denkt mit. http://www.sander-electronic.de/be00066.html Gruß RomanK
Danke für die schnellen Antworten! Joe G. schrieb: > Conny G. schrieb: >> Hat jemand Erfahrungen damit gemacht? > > Ja, Beitrag "Re: CP/M auf ATmega88" Cooles Projekt! Ich habe das jetzt mal schnell quergelesen, leider ist es mir aber nicht gelungen da ein Resümee daraus zu extrahieren, ob und wie der Propeller tut. Es scheint als hätte er da funktioniert, da zumindest keine größeren Debuggingaktionen oder Frustrationen ersichtlich sind :-) Hast selber schon damit gearbeitet? Wie isser? Taugt, taugt nicht, macht Spass oder nicht? (Zu) komplex oder geht schon? Buggy, zickig oder völlig in Ordnung?
RomanK schrieb: > http://www.sander-electronic.de/be00066.html Die Architektur ist ja echt cool und genial.
Gibt's da eigentlich auch einen freien C-Compiler oder muss man den kaufen?
Conny G. schrieb: > Ich habe das jetzt mal schnell quergelesen, leider ist es mir aber nicht > gelungen da ein Resümee daraus zu extrahieren, ob und wie der Propeller > tut. Der Propeller werkelt in diesem Projekt als VT100 Terminal mit den Funktionen Tasttaturabfrage, VGA-Ausgabe und serielle Schnittstelle. Die Programmierung war relativ einfach (Spin und Assembler). Er macht genau das, was er soll. Conny G. schrieb: > Gibt's da eigentlich auch einen freien C-Compiler oder muss man den > kaufen? http://propeller.wikispaces.com/Software
Eumel schrieb: > http://www.parallaxsemiconductor.com/Products/propeller2specs > > Die legen nochmal nach ;) Ich nehme wegen des Smileys an, daß du weißt, wie STEINALT diese Ankündigung ist? Passiert ist in all den Jahren rein garnix, es ist bis heute bei dieser Ankündigung geblieben. Und ich glaube, ich lehne mich nicht allzu weit aus dem Fenster, wenn ich prophezeie, daß der Propeller2.0 entweder niemals kommt, oder zumindest nicht die Featureliste vollständig umsetzen wird, die da seit Jahr und Tag zu lesen ist... Sollte ich mich allerdings diesbezüglich irren, wäre das ein wirklich interessantes Teil, was man vom Propeller1 leider nicht behaupten kann. Die Schächen der Architektur sind unübersehbar, sobald man praktisch versucht, die Kerne (sinnvoll) wirklich voll auszulasten. Nur sehr spezielle Probleme lassen sich so umsetzen, daß wirklich alle Kerne fast ununterbrochen nutzbringend am Rechnen sind. Und es macht obendrein auch noch einen Haufen Arbeit, dagegen ist ein bissel Takte zählen beim AVR oder so ein Kinderspiel.
c-hater schrieb: > Die Schächen der Architektur sind unübersehbar, sobald man praktisch > versucht, die Kerne (sinnvoll) wirklich voll auszulasten. Nur sehr > spezielle Probleme lassen sich so umsetzen, daß wirklich alle Kerne fast > ununterbrochen nutzbringend am Rechnen sind. Und es macht obendrein auch > noch einen Haufen Arbeit, dagegen ist ein bissel Takte zählen beim AVR > oder so ein Kinderspiel. Woran hakt's bei der Architektur? Und was macht die Arbeit?
c-hater schrieb: > Eumel schrieb: > >> http://www.parallaxsemiconductor.com/Products/propeller2specs >> >> Die legen nochmal nach ;) > > Ich nehme wegen des Smileys an, daß du weißt, wie STEINALT diese > Ankündigung ist? Passiert ist in all den Jahren rein garnix, es ist bis > heute bei dieser Ankündigung geblieben. Sieht so aus als würde daran gearbeitet, wenn ich den Thread nicht komplett falsch verstanden habe: http://forums.parallax.com/showthread.php/144199-Propeller-II-Emulation-of-the-P2-on-DE0-NANO-amp-DE2-115-FPGA-boards Hört nur im März auf.
Geht glaub ich einfach nur im anderen Thread weiter: http://forums.parallax.com/showthread.php/125543-Propeller-II-update-BLOG/page146
Man bekommt aber keine Idee wie weit sie sind. Detaillevel zu hoch. Egal, ich kauf mir jetzt eh erstmal den Prop I, ich find' den cool.
Stichwort: XMOS (geht auch in ähnliche Richtung) -> http://www.xmos.com/ Und: Adaptiva - Parallella (derzeit aber ausverkauft und haben scheinbar auch noch Probleme mit ihren Boards) -> http://www.parallella.org/
Conny G. schrieb: > Woran hakt's bei der Architektur? Hauptsächlich daran, daß der zwischen den cogs gesharete Speicher zu klein ist. Darüber hinaus daran, daß die Synchronisation zwischen zwei cogs auch alle anderen zum pausieren zwingt, sobald sie was zu synchronisieren haben, selbst wenn diese Synchronisation garnix mit der aktuellen Sperre zu schaffen hat. Beide Schwächen befruchten sich also sozusagen gegenseitig. > Und was macht die Arbeit? Dafür zu sorgen, daß diese Blockade-Situationen möglichst selten eintreten. Das geht nur, indem man den Rechenzeitbedarf der Kerne bezüglich ihrer aktuellen Aufgaben sehr fein aufeinander abstimmt. Das geht überhaupt nur in Assembler und bei einem entsprechend ungeeigneten Problem (das ist leider die Mehrheit!) geht es fast garnicht. Das ist aber ein bekanntes Phänomen der Parallelprogrammierung, nur die Schwächen der Propeller-Architektur verschärfen es halt noch zusätzlich. Gedacht war die wohl primär dazu, die blödsinnigen Busy-Loops von unfähigen Hochsprache-Programmierern sozusagen "auszulagern". Das kann sie. Aber leider nicht viel mehr...
c-hater schrieb: > Gedacht war die wohl primär dazu, die blödsinnigen Busy-Loops von > unfähigen Hochsprache-Programmierern sozusagen "auszulagern". Das kann > sie. Aber leider nicht viel mehr... Ich stimme Dir prinzipell zu. Das Konzept ist aber für diejenigen tauglich, die mal drei UARTs, zwei I2C und VGA brauchen. Oder vier UART, zwei SPI und Sound. Oder eine beliebige andere Kombination, solange sie in die acht Cogs passt. Am hive sieht man auch schon die Grenzen des Chips. Dort sind sicher nicht umsonst drei Stück davon verbaut. Conny G. schrieb: > Wo kauft man den in DE am besten? Hier gibt es eine Übersicht: http://www.mikrocontroller.net/articles/Parallax_Propeller Viele Grüße Jens
Heisst also: Die Idee hinter dem Prop ist ein großer Schritt vorwärts, die Ausführung / Implementation beim Prop 1 eher nur ein kleiner...
Im Anhang die Eagle Datei aus einem alten Thread : Beitrag "Re: Neue Propeller Karte zu Fertigen" Kannst du dir bei seedstudio.com und anderen für inzwischen unter 20 Euro pro 10 Stück herstellen lassen.
:
Bearbeitet durch User
>Heisst also: Die Idee hinter dem Prop ist ein großer Schritt vorwärts, >die Ausführung / Implementation beim Prop 1 eher nur ein kleiner... Das finde ich nicht, die Idee hinter dem Prop ist genial und zu der Zeit, als der Prozessor entwickelt wurde, war er den anderen Prozessoren im Bezug auf Ausnutzung der Resourcen und der erzielten Rechenleistung weit voraus. Man darf nicht vergessen, das Parallax eine kleine Firma ist und nicht so viele Reourcen in den Chip stecken kann wie Intel oder irgend ein anderer großer MC-Hersteller. Für C-Compiler ist die Architektur nicht besonders geeignet. Es gibt allerdings 3 C-Compiler: Einen proprietären, Catalina ( http://forums.parallax.com/showthread.php/116370-Catalina-2.6-a-FREE-C-compiler-for-the-Propeller-The-Final-Frontier! ) und GCC. Für Hardwarenahe Echtzeitanwendungen ist der Chip mit seinen 8 unabhängigen "Cören" genial.
Die Reaktionszeit der Cores auf externe Ereignisse ist exzellent, ebenso die Präzision zeitgesteuerter Abläufe. Daher ist er besonders dort nützlich, wo keine Standardschnittstellen vorliegen, aber eine Reaktion im Nanosekundenbereich erwartet wird. Die Programmierung würde ich allerdings eher unter "schaurig" einordnen.
:
Bearbeitet durch User
A. K. schrieb: > Die Reaktionszeit der Cores auf externe Ereignisse ist exzellent, ebenso > die Präzision zeitgesteuerter Abläufe. Daher ist er besonders dort > nützlich, wo keine Standardschnittstellen vorliegen, aber eine Reaktion > im Nanosekundenbereich erwartet wird. So hätte ich mir das auf Basis der Architektur vorgestellt / gewünscht. > Die Programmierung würde ich allerdings eher unter "schaurig" einordnen. Weil?
Hi, so wie ich das bis jetzt im Propeller Forum gelesen habe wird der Propeller 2 vielleicht ende 2014 oder 2015 kommen. Er wird auch wesentlich mehr Funktionen und Rechenleistung haben. Mittlerweile wird wieder von 200 MHz geredet, wären dann 1600 MIPS mit allen 8 COGs Mehr und umfangreichere Befehle. Ich freue mich auf den Prop 2.
Conny G. schrieb: >> Die Programmierung würde ich allerdings eher unter "schaurig" einordnen. > > Weil? Mein Stand ist zugegebermassen der ursprüngliche. Die Methoden könnten sich verfeinert haben, so gibt ja wie erwähnt mittlerweile auch C, sowohl nativ auf dem Core als auch im zentralen RAM. Programmiert wird: (1) der kritische Code in Assembler, ~500 Worte für Code+Daten je Core, (2) per Interpreter in einem oder mehreren Cores, in 32KB zentralem RAM. Die Sprache dafür (SPIN) ist von eher schlichter Natur. Die vorhandenen sprachlichen Mittel für die Kommunikation zwischen (1) und (2) würde ich auch als eher schlicht ansehen. Im Vergleich würde ich XMOS vorziehen. Das ist hardware- wie softwareseitig das bessere Design.
:
Bearbeitet durch User
Soweit ich das mitbekommen habe, testen die derzeit das System (öffentlich?) mit einem FPGA. So könnte man die Sachen schon jetzt testen, ohne auf 2014/2015 zu warten... (unsichere Info, bitte selber im Propeller-Forum nach lesen) Eine Idee wäre auch, so etwas selbst mit einem FPGA zu entwickeln. Dann wäre man flexibler, braucht aber auch viel Aufwand und Zeit, vielleicht aber mit mehreren Leuten hier im uC Forum denkbar? (mein VHDL Wissen reicht dafür leider nicht aus)
Ingo P. schrieb: > Eine Idee wäre auch, so etwas selbst mit einem FPGA zu entwickeln. Natürlich. Propeller und XMOS sind angetreten, manche Probleme mit Prozessoren und deren Programmierung lösen zu können, für die man bisher ein FPGA benötigte. Wer sowieso schon FPGAs programmiert, der kann auch dabei bleiben.
A. K. schrieb: > Mein Stand ist zugegebermassen der ursprüngliche. Die Methoden könnten > sich verfeinert haben, so gibt ja wie erwähnt mittlerweile auch C, > sowohl nativ auf dem Core als auch im zentralen RAM. > > Programmiert wird: > (1) der kritische Code in Assembler, ~500 Worte für Code+Daten je Core, > (2) per Interpreter in einem oder mehreren Cores, in 32KB zentralem RAM. > Die Sprache dafür (SPIN) ist von eher schlichter Natur. > > Die vorhandenen sprachlichen Mittel für die Kommunikation zwischen (1) > und (2) würde ich auch als eher schlicht ansehen. Das ist allerdings schaurig und unhandlich. > Im Vergleich würde ich XMOS vorziehen. Das ist hardware- wie > softwareseitig das bessere Design. Mal ansehen.
:
Bearbeitet durch User
Zu einem Vergleich mit XMOS kann ich nichts sagen, aber der kam ja auch Jahre später und spielt schon in einer anderen Liga. Eher vergleichbar mit dem Propeller 2. Der Propeller 2 ist in den letzten Zügen und die Zusammenarbeit mit dem Chipfertiger hat begonnen. Bin auch gespannt, wann der dan endlich erhältlich ist. Der Chip hat in der Endphase seinen letzten Schliff auch mit Hilfe der über Jahre aktiven Forum-Mitglieder erhalten. Der Propeller 1 macht einfach Spaß! Die Kombi SPIN und PASM ist besser als ihr Ruf! Mit dem Prozessor und einem USB2Serial adapter kann man sofort loslegen. Die IDE bei Parallax. Für die gängigste Hardware gibt es kostenlose Treiber unter MIT Lizenz(object ). Man kann in ein paar Stunden alles mögliche ausprobieren und zusammenstellen ohne groß in den Manuals nach Registern und irgendwelchen Flags zu suchen oder sich Gedanken darüber machen zu müssen, ob code A dummerweise den gleichen IRQ braucht wie code B... Falsch ist auf jeden Fall, dass Kerne sich irgendwie blockieren! Die Kerne laufen völlig unabhängig voneinander. Wenn man LOCKs zum synchronisieren benutzt, dann betrifft das nur die Kerne, die eben über den LOCK synchronisiert werden sollen. Zudem gibt es recht gutes Lehrmaterial und das Forum ist das freundlichste, das ich kenne! Klar hat der Propeller seine Grenzen. Aber innerhalb derer ist er klar besser und durch den Verzicht auf Interrupts und Hardware interfaces in Verbindung mit dem object exchange einfacher als AVR&co.
Dito! Als Anfänger kommt man mit dem Propeller sehr schnell zu Ergebnissen. Und wenn ich mir die Hardware vom Prop 2 anschaue läuft mir scho das Wasser im Mund zusammen. Mehr Pins und alle mit ADC usw. Single Cycle Execution und multiply / divide in Hardware.
Ich finde den Propeller sehr interessant und befasse mich nun schon seit einigen Jahren damit. Gerade für Leute die bei (fast) Null anfangen ist der Einstieg recht einfach die Tutorials sehr umfangreich und das Forum, da kann ich mich meinen Vorgängern nur anschließen, leistet durch die vorhandene Community einen guten support, vor allem "vermisst" man da zum Glück die ganzen Spinner und Besserwisser die es in so manch anderen Foren gibt. Wahrscheinlich ist das auch der Grund warum ich da so lange hängen geblieben bin. Über die Vor- und Nachteile zu diskutieren erspare ich mir hier mal, man muss einfach mal ein paar Sachen mit dem Ding ausprobiert haben, um sich selber ein Urteil zu bilden. "Experten" díe den Prop zereissen gibt es einige. ich hab hier noch eine Adresse in UK wo ich mein letztes Board bestellt habe: http://www.spinvent.co.uk/ Versand pauschal nur 4 Pfund. Sehr netter Kontakt, parralax-like halt :-) Hab hier nochmal einen Link von meinem letzten Projekt: https://www.youtube.com/watch?v=jUx2i1AsTH4 Gruß Christian
Tharkun schrieb: > Hab hier nochmal einen Link von meinem letzten Projekt: > > https://www.youtube.com/watch?v=jUx2i1AsTH4 Cool, abgefahren :-)
Angehängte Dateien:
-
IMG_2323.jpg
230 KB
Mein Starter Kit kam heute an, freue mich schon darauf demnächst mal damit zu spielen. Muss allerdings erstmal noch eine andere Schaltung fertig routen und produzieren.
Erste Erfahrungen damit: erste Ergebnisse tatsächlich sehr einfach. Spin ist intuitiv und einfach zu lernen. Performance ist gut - gerade eine WS2812 Stripe angesteuert und das geht viel besser als mit einem Atmega328, der dabei an seine Grenzen kommt (bereits ein Millisekunden-Tick der ganz wenig tut bringt den Datentransfer aus dem Takt). Knifflig wird es allerdings, wenn man einen Datenstrom wie Audio-Samples von einem COG an einen zweiten weitergeben will, dann muss ich die Daten zum Global RAM schaufeln und das geht nur über den Hub und die Round Robin Sync, d.h. ich verliere viel Zeit. Das ist bei einer Sample Rate von 10/20 kHz noch nicht so kritisch, weil ich 4.000 CPU-Takte Zeit habe von einem Sample zum nächsten, aber hier sieht man schon eine Grenze, die aus der Architektur kommt. Was ich gerade machen will: mit einem COG Audio samplen, mit einem 2. COG FFTen, mit einem dritten COG darauf basierende Daten an den o.g. WS2812 Stripe schicken. Also im Grunde eine Aufgabe, die geradezu ideal für den Propeller ist. PASM ist soviel ich bis jetzt gesehen habe etwas ungewöhnlich und eigenwillig, da steht mir mehr Lernkurve bevor als mir lieb ist. Und wenig Material / Tutorials dazu, gar keins von Parallax. Also schon machbar, aber nicht schnell mal auf einen Abend. Die Community scheint nicht so gross zu sein. Die Zahl an "Objects" ist eher begrenzt, kein vernünftiges für RFM12 gefunden. Und nix für FFT. Wenn man nach Fragen googelt, wenig Ergebnisse. Meine Frage bzgl. des Datentransfers hat nach ein paar Tagen noch nicht viele und va. keine hilfreichen Antworten. Das ist hier bei mikrocontroller etwas anders. Oder bin ich verwöhnt? :-) Gerade dieser letzte Punkt ist etwas kritisch, gerade bei einem außergewöhnlichen Produkt, das die konventionellen Pfade verlässt. Denn wenn der Hersteller zu klein ist für viel Doku und Tutorial, dann müsste zumindest die Community genug hergeben. Summa summarum: sehr gute Idee, geniales Konzept und es macht Spass. Aber es ist ein mässig supportetes Nischenprodukt, wo man wissen muss auf was man sich einlässt. Wo einem einerseits die Architektur Türen öffnet, muss man an anderer Stelle mehr denken und mehr Hürden überwinden als anderswo. Ich habe aber weiterhin Spass am Propeller und bleibe dran. Das Konzept ist es mir wert, ein paar Hürden zu nehmen.
:
Bearbeitet durch User
Joe G. schrieb: > Conny G. schrieb: >> Und nix für FFT. > > http://propeller.wikispaces.com/FFT Das habe ich schon gesehen, aber das ist kein Object, sondern eher Beispielcode / Entwurfsqualität. Nix dagegen, aber ich hätte erwartet, dass es hierfür ein Object geben müsste, wenn genügend Drive hinter der Community ist.
Ich habe mir mal vor einiger Zeit einige Propeller in DIP (allein das ist schon ein großes Plus wie ich finde) bestellt und damit rumgespielt. Der Einstieg ist wirklich äußerst simple. Einfach den Prop und eine gute USB-UART Bridge und ein bisschen Hühnerfutter. Wenn er PC unabhängig starten soll noch ein I2C EEPROM dazu. Da ich weder Zeit noch Lust hatte das eher exotische Spin oder PASM zu lernen habe ich den propGCC verwendet der damals in einer frühen Beta war. Das ganze war mit der empfohlenen Code::Blocks(?) IDE schnell aufgesetzt und lief eigentlich weitgehend problemlos. Zu den Problemen die ich mit dem Propeller hatte: - Ich habe nie diese komische Fixierung auf Videoausgabe beim Propeller verstanden. M.E. hat der viel zu wenig RAM um das wirklich sinnvoll zu nutzen. - Richtiges on Chip Debugging ist m.E. nicht möglich. - Bei Programmieren habe ich viel Zeit- und Prozessorresourcen ver(s)wendet UART, I2C und SPI nachzubauen. Da ging jedes mal einer der tollen Cores für Aufgaben weg, die halt ein "normaler" uC schon eingebaut hat. Schön wenn man exotischerer Interfaces braucht, Verschwendung wenn nicht. - Zur fehlenden Perpherie kommt insbesondere der fehlende ADC. Natürlich kann wird groß beschrieben wie man einen Sigma-Delta ADC mit zwei Pins, etwas Hühnerfutter und einem Core nachbaut. Aber um den wirklich zu nutzen sollte man noch einen Analogmultiplexer (dessen Ansteuerung auch wieder Pins kostet) mit Referenzspannung dranhängen. Oder gleich einen "richtigen" ADC mit serieller Schnittstelle verwenden. - Am Ende hängt dann halt ziemlich viele Bausteine um den Propeller herum, angefangen vom EEPROM fürs Programm (gar nicht zu reden von den ganzen Konstruktionen mit (seriellen) SRAMs um den Speicher zu erweitern) die bei anderen uCs schon eingebaut sind. Damit sind die knappen GPIOs ganz schnell aufgebraucht. Besonders beim Preis von ~10 Euro bekommen schon ziemlich viel Cortex-M3/M4 mit viele eingebauter Perepherie und höherem Takt. Dank DMA kann da auch einiges Quasi-Parallel laufen. Vor kurzen hat XMOS ein Startkit verschenkt, das gibts auch für ~14 Euro zu kaufen. Dort ist die Sache mit der Parallelprogrammmierung meiner Ansicht nacht sehr viel eleganter gelöst. Da bin ich gerade am spielen. Leider sind die Chips eher schlecht zu bekommen, teuer und nicht in so schönen Packages.
:
Bearbeitet durch User
Ich habe mir die Beschreibugn des Chips jetzt mal nächer angesehen. Toll finde ich: - Dass der Chip mit Bootloader geliefert wird. - Dass er Prozesse parallel ausführen kann. - Dass der abwechselnde Zugriff auf's RAM schon hardwareseitig geregelt wird. - 32bit. Fragwürdig finde ich: - Den Nutzen des Video Generators. Analog TV/VGA ist veraltet. - Ebenso die PS/2 und RS232 Ports des Entwicklungs-Kits. - Diese komische interpretierte "Spin" Sprache. Ist performancemäßig vermutlich nicht der Hit, wenn man C und Assembler gewohnt ist. Nicht so gut finde ich: - Dass sämtliche I/O Pins nur simple GPIO Pins sind. Demzufolge muss man z.B. serielle Kommunikation in Software implementieren. - Offensichtlich kein ADC integriert ist - oder hab' ich was übersehen? - Die Stromaufnahme mit max 100mA scheint mir recht hoch. - keine klaren Angaben zum Timing der I/O Pins, insbesondere frage ich mich, wie sich die vielen verketteten Oder-Gatter auswirken. - Dass der Programmspeicher (Flash) extern angebunden werden muss. - Dass die I/O Pins nicht 5V tolerant sind. - Dass die Ausgänge nicht im Open-Drain Modus betrieben werden können. - Dass die Eingänge keine konfigurierbaren Pull-Up Widerstände haben. - Dass die Hub Operationen bis zu 22 Taktzyklen verbraten. Wenn ich mir die Nachteile anschaue... kann ich vermutlich mit einem ARM Controller oder Xmega ähnlich performante Programme schreiben - selbst wenn das Multi-Tasking dort nur über einen Kern läuft. Anscheinend soll die Spin Sprache den Einsteigern entgegen kommen. ich würde jedenfalls nicht freiwillig mit einer Sprache einsteigen, die nur ein einziger Mikrochip beherrscht. Da ist ja schon von Anfang klar, dass man sehr bald noch eine andere Programmiersprache dazu lernen muss. Die hätten mal lieber Java oder C# genommen.
Du kannst ja auch gcc nehmen, der wird mittlerweile vom Propeller unterstützt. Wobei man sagen muss, dass SPIN wirklich einfach ist.
Stefanus schrieb: > - Diese komische interpretierte "Spin" Sprache. Ist performancemäßig > vermutlich nicht der Hit, wenn man C und Assembler gewohnt ist. Stimmt. Aber man kann natürlich PASM (Assembler) benutzen! ;-) > - Dass die I/O Pins nicht 5V tolerant sind. Mit Serienwiderständen ist das Interface mit einem 5 V TTL oder CMOS System aufgrund (parasitärer) Schutzdioden kein Problem; siehe http://forums.parallax.com/showthread.php/85474-How-to-safely-interface-a-5v-signal-to-the-propeller-See-Post-Reply-104 > - Dass die Hub Operationen bis zu 22 Taktzyklen verbraten. Schlimmstenfalls 23 Zyklen, wobei die Typische Taktfrequenz 96 MHz beträgt und die meisten Instruktionen 4 Takte benötigen. Alternativer C-Compiler: http://propeller.wikispaces.com/Programming+in+C+-+Catalina
Conny G. schrieb: > Hi, > > den finde ich ja spontan sehr cool: > > http://de.wikipedia.org/wiki/Parallax_Propeller > > 8 Core, 32 Bit MCU. > > Hat jemand Erfahrungen damit gemacht? > Wo kauft man den in DE am besten? > > Sieht mir so aus als müsste man nicht unbedingt ein Dev Board dafür > haben, scheint so minimalistische Beschaltung zu brauchen wie ein AVR? > Wie programmiert man den? > > Vg, > Conny Die Firma Elektronikladen verkauft den Prozessor in DE. Es gibt ihn als DIP40, als Prop-Stick im DIP40 mit USB-Interface, Quartz, Ram und Eprom auf DIP40 und auf einer Vielzahl von Boards: http://www.parallax.com/catalog/microcontrollers/propeller/boards Die Firma Innovationsshop verkauft ihn mit einer Anwendung programmierbarer Rechteckgenerator mit Windows Bedieninterface in DE. Trial Version https://www.dropbox.com/s/tdj4tvq0ytftn58/PGen_demo_d.pdf Die Programmierung in Spin finde ich einfach und effizient. Das Software-Modulkonzept macht es leicht, fertige Funktionsmodule aus OBEX zu integrieren und das finde ich viel einfacher, als das Zusammenlinken von Funktionsmodulen in C oder C++: http://obex.parallax.com/ Die Assemblersprache ist effizient, alles Einwortbefehle mit optionalen Bedingungen und relozierbarer Code. Es gibt Beta-Versionen für Preprozessor (PreSpin) und Debugger (Pasd) bei http://www.insonix.ch/propeller
Benjamin B. schrieb: > Conny G. schrieb: >> Hi, >> >> den finde ich ja spontan sehr cool: >> >> http://de.wikipedia.org/wiki/Parallax_Propeller >> >> 8 Core, 32 Bit MCU. >> >> Hat jemand Erfahrungen damit gemacht? >> Wo kauft man den in DE am besten? >> >> Sieht mir so aus als müsste man nicht unbedingt ein Dev Board dafür >> haben, scheint so minimalistische Beschaltung zu brauchen wie ein AVR? >> Wie programmiert man den? >> >> Vg, >> Conny > > Die Firma Elektronikladen verkauft den Prozessor in DE. > > Es gibt ihn als DIP40, als Prop-Stick im DIP40 mit USB-Interface, > Quartz, Ram und Eprom auf DIP40 und auf einer Vielzahl von Boards: > http://www.parallax.com/catalog/microcontrollers/propeller/boards > > Die Firma Innovationsshop verkauft ihn mit einer Anwendung > programmierbarer Rechteckgenerator mit Windows Bedieninterface in DE. > Trial Version https://www.dropbox.com/s/tdj4tvq0ytftn58/PGen_demo_d.pdf > > Die Programmierung in Spin finde ich einfach und effizient. Das > Software-Modulkonzept macht es leicht, fertige Funktionsmodule aus OBEX > zu integrieren und das finde ich viel einfacher, als das Zusammenlinken > von Funktionsmodulen in C oder C++: http://obex.parallax.com/ > > Die Assemblersprache ist effizient, alles Einwortbefehle mit optionalen > Bedingungen und relozierbarer Code. > > Es gibt Beta-Versionen für Preprozessor (PreSpin) und Debugger (Pasd) > bei http://www.insonix.ch/propeller Habe ihn schon vor ein paar Monaten gekauft und schon eine Weile damit gespielt. Finde es auch ein nettes Konzept. Spin ist angenehm und schnell zu lernen, Asm habe ich angefangen, aber noch nicht viel Zeit investiert - macht aber sehr viel Sinn und ist auch eher leicht zu verstehen. Habe nur eine Hemmschwelle mich mit mehr meiner Zeit auf ein Nischenprodukt einzulassen, deshalb habe ich ihn noch nicht größer eingesetzt als für den einen oder anderen Test. Was mich stört ist "wait states" beim Verschieben von Daten zwischen den RAMs, denn das heisst ich kann nicht in Realtime Daten samplen und direkt in einen anderen COG schieben - ich muss immer auf den Zugriff warten und DMA gibt's keinen. Habe allerdings für die Anwendung die ich im Kopf habe (ein COG sampelt, ein zweiter macht FFT, ein Dritter produziert Ausgaben, z.B. auf einen WS2812 Stripe) festgestellt, dass die Sample-Frequenz so niedrig ist, dass die Zeit für die Waitstates problemlos drin ist.
Man kann den Durchsatz durch den Hub optimieren, indem man Daten en bloc sendet, dann kann man den round robin optimal nutzen. Positiv zu erwähnen sind die 2 Multifunktions-Zähler per Cog, die u.a. Messwerterfassung sehr erleichtern sowie das simple, aber mächtige Timer-Konzept i.V.m. den Einwort-Maschinencodes, die determinierte Zeitberechnungen für Routinen erleichtern. http://www.parallaxsemiconductor.com/sites/default/files/appnotes/AN001-P8X32ACounters-v2.0_2.pdf Im Gegensatz zu anderen Mikrocontrollern hat Propeller nur Ram im Chip und Eeprom ist extern. Rapid Prototyping kann damit im Ram stattfinden, geht schneller und schont die Schreibzyklen des Eeproms. Gespeichert wird erst, wenn die Routine läuft :-) Aso - meinte nicht relozierbar, sondern selbst modifizierender Maschinencode (Sprung- und Returnadressen, Quell-, Zielregister und Maschinenbefehl änderbar z.B. für indirekte Sprungadressen und Pointer auf Adressen).
:
Bearbeitet durch User
Der Prozi macht den Eindruck eher als "Spielerei" entwickelt worden zu sein anstatt mit einem "echten" Zweck in Aussicht. Die acht Kerne fressen ziemlich viel Strom (oben stand was von 100 mA) wovon die Hälfte schonmal dafür draufgeht Peripherie zu bauen. Die 160 MIPS macht ein ARM genausogut und an dem hat man noch massig Peripherie. Für richtig schnelle Schnittstellen reichen dann die 20 MIPS von einem Kern dann auch garnicht (USB-LowSpeed dürfte die Obergrenze sein; hat das eigtl mal wer auf dem gemacht ?). Ein SPI mit 5 MHz (was jeder Wald und Wiesen µC locker macht) dürfte schon eng werden (kriegt man in 4 Instruktionen die Daten irdendwo sicher hin ?). Wenn man dann seine Peripherie-Bedürfnisse befriedigt hat, dann bleiben noch 2-3 Kerne die die halbe Zeit auf die anderen warten weil es keine Interrupts gibt. Richtig interessant wird es dann wenn man Müll programmiert hat, dann darf man nämlich 8 Threads durchsuchen weil ein falsch eingelesener Wert durch die Anwendung hindurch geistert (das ist schon bei einem einzelnen Thread und mit JTAG ein Ärgernis). Und für "nicht-Standard"-Interfaces macht man entweder Bitbanging (wenns langsam ist) oder hängt per Peripherie (I²C ist da sehr schön) einen IC hin der das kann (ein Tiny10 z.b. kann eine WS2812 steuern und über USB reden, siehe hier: Beitrag "µ-wire - USB auf ATtiny10" und frisst dabei keine 5 mA). PS: Ich bin mir sicher es gibt ein paar Anwendungen bei denen der Propeller seine Stärken zeigt, aber die wird man an einer Hand abzählen können...
Was die FFT angeht. Hm, mir scheint der Artikel bezieht sich auf den Propeller 2, denn er geht auf Bugs von Befehlen ein. Welchen ARM bräuchte man denn für gleiche Leistungsdaten bei der FFT?
Beim Propeller war ich angenehm überrascht, wie genau sich damit Timing-Anwendungen erzeugen lassen. Durch die fehlenden Interrupts laufen die Programme auf den einzelnen Prozessoren absolut deterministisch, das ist bei anderen Konzepten nur mit Mühen erreichbar, beim Propeller hingegen inherent. >Richtig interessant wird es dann wenn man Müll programmiert hat, dann >darf man nämlich 8 Threads durchsuchen weil ein falsch eingelesener Wert >durch die Anwendung hindurch geistert Du hast vermutlich keine Erfahrung mit dem Propeller, deine Aussage ist eher eine pauschale Vermutung. Ich habe einiges mit dem Propeller gemacht, aber auf so ein Problem bin ich nicht gestoßen.
@Abdul: Da dürfte schon ein kleiner reichen (vielleicht so um die 70 MHz). Ein dickes Ding (STM32F4) kriegt ca. 800 Hz bei einer 32 Bit FFT hin (http://www.technologische-hilfe.de/fft-benchmark-auf-einem-stm32f4-microcontroller-beagle-bone-black-und-pc-support-266216632.html)
markus schrieb: > Beim Propeller war ich angenehm überrascht, wie genau sich damit > Timing-Anwendungen erzeugen lassen. Durch die fehlenden Interrupts > laufen die Programme auf den einzelnen Prozessoren absolut > deterministisch, das ist bei anderen Konzepten nur mit Mühen erreichbar, > beim Propeller hingegen inherent. So sehe ich das auch. Die komplexe Rechteck Generator Anwendung von Innovationsshop ist ein gutes Beispiel dafür. Erzeugung von komplexen, parametrierbaren Pulsfolgen mit Phasensynchronisation zwischen 4 Kanälen oder 3 Kanäle komplexe Pulsfolgen unabhängig voneinander mit individueller phase lock loop Feedback-Auswertung zur Frequenzanpassung kann ich mir realisiert auf einem single Core Controller mit Interrupts kaum vorstellen. Evtl. mit einer FPGA incl. Mikrocontroller Unterstützung (für den Benutzerdialog http://www.cypress.com/psoc4/?source=CY-ENG-HEADER), aber diese Anwendung schafft ein Propeller stand alone in Dip40. http://quelle-der-innovationen.com/pgen.htm Das Prop-Scope, ein 2 Kanal Oszilloskop, ist ein anderes Beispiel für schnelle Datenerfassung i.V.m. komplexem Benutzerdialog auf einem Single Chip http://elmicro.com/de/propscope.html http://www.parallax.com/product/32220
:
Bearbeitet durch User
Jan Berg schrieb: > @Abdul: Da dürfte schon ein kleiner reichen (vielleicht so um die 70 > MHz). Ein dickes Ding (STM32F4) kriegt ca. 800 Hz bei einer 32 Bit FFT > hin > (http://www.technologische-hilfe.de/fft-benchmark-auf-einem-stm32f4-microcontroller-beagle-bone-black-und-pc-support-266216632.html) Danke. Hm, klingt auch nicht so verlockend. Man bräuchte was wo jemand von der CPU und dem Problem FFT wirklich was versteht. Den Eindruck habe ich bei dem Link nicht wirklich. Ich denke dabei an ein Projekt mit sagen wir 1MHz ADC, FFT in einem MCU und dann das fertige Spektrum an den PC zur Darstellung schicken. So könnte man das Bandbreitenproblem zum PC hin elegant umgehen.
>So könnte man das Bandbreitenproblem zum PC hin elegant umgehen.
Wieso? Bei einer komplexen FFT kommen gleich viele Daten raus wie rein.
Hm. Ich bin nur an Real interessiert. Werde aber nochmal drüber nachdenken.
Angehängte Dateien:
-
schematic2.jpg
64 KB
Der Propeller zusammen mit gcc ist ein sehr schönes Spielzeug. siehe Anhang.
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.