Hallo, Ich arbeite bislang immer noch ausschließlich mit AVRs. Nun möchte ich mich aber auch mit etwas leistungsfähigeren uC beschäftigen. Daher hab ich mich entschlossen mich mit der STM32-Familie zu beschäftigen. Bei der Suche nach einem geeigneten Eval-Board bin ich auf den Parallax Propeller gestoßen und fand ihn auf den ersten Blick sehr interessant. Es handelt sich dabei ja um ein ganz anderes Konzept als bei den meisten anderen uC. Nun würde mich interessieren ob jene die mit dem Propeller schon gearbeitet haben dies im nachhinein bereut haben oder ob man mit dem Ding wirklich etwas anfangen kann. Konkret schwirtt mir schon ein Projekt im Kopf herum das man mit dem Propeller eigentlich gut lösen können müsste. Ich hab noch ein LCD Display ohne Graphiktreiber rumliegen. Dafür möchte ich einen Treiber schreiben. Zusätzlich noch ein Keyboard-Anschluss... . Halten diejenigen die Propeller kennen dies für machbar? Nach dem durchstöbern des Datenblattes (33 Seiten?) schaut die Einarbeitung gar nicht mal so aufwendig aus. Irre ich mich da oder kann man sich tatsächlich relativ schnell in den uC einarbeiten? lg much PS: Bevor die Ersten jetzt posten, dass der Propeller kein Ersatz für einen STM32 ist möcht ich noch mal klarstellen das mir das schon bewusst ist. Der STM32 kommt auf jeden Fall ins Haus. Der Propeller wäre nur zusätzlich als kleine Spielerei gedacht weil ich das Konzept interessant finde.
Das Problem am Propeller ist die duale Programmierung, jedenfalls so wie Parallax sich es vorstellte. Also Assembler-Programmierung für die I/O-Module und ein recht frugaler Interpreter darüber. Zudem stösst man schnell an Speichergrenzen und dann ist Ende Gelände. Die Konkurrenz von XMOS gefällt mir besser. Ebenfalls Hardware-Multithreading mit schnellen Cores. Aber schneller, in C oder C-artig programmierbar, und die Low/High-Trennung entfällt. Es ist auch etwas mehr Grips in die Pin-I/O gelegt worden.
Ja, nur dass Doku und Support für XMOS Shice sind!
Yep, der Stil der Doku von XMOS erinnert stark an den Stil von Inmos bei den Transputern - was natürlich nicht weiter erstaunt, wenn man sich das Personal ansieht. Aber andererseits sieht man XMOS auch an, dass sie schon einmal auf den Bauch gefallen sind und daraus gelernt haben.
Der Propeller kann schon was, keine Frage, dafür sieht es mau aus mit Peripherie, keine SPI, TWI etc. Die muss man dann emulieren und dann nehmen die freien Cogs schnell ab. ist aber ne nette Spielerei
Fhutdhb Ufzjjuz schrieb: > dafür sieht es mau aus mit Peripherie, keine SPI, TWI etc. > Die muss man dann emulieren und dann nehmen die freien > Cogs schnell ab. Im "Typical Connection Diagram" Ist ja der UART zur Programmierung und das SPI für den EEPROM dargestellt. Dafür brauche ich aber keine Cog opfern nehme ich mal an, oder? Verstehe ich das Richtig, dass diese schon in Hardware implementiert sind, ich allerdings nicht via Software darauf zugreifen kann? A. K. schrieb: > Die Konkurrenz von XMOS gefällt mir besser. Sieht auf den ersten Blick auch sehr interessant aus (werd ich mir noch mal etwas genauer anschauen müssen). Was mich noch interessieren würde, wie schnell man sich in die Controller (sowohl Propeller als auch XMOS) einarbeiten kann. Kriegt mann sagen wir mal an einem Nachmittag bereits ein kleines Lauflicht hin, oder muss mann sich tiefer mit der Materie beschäftigen um etwas mit den Controllern anfangen zu können? lg much
Michael N. schrieb: > Der Propeller wäre > nur zusätzlich als kleine Spielerei gedacht weil ich das Konzept > interessant finde. Ist es nicht sinnvoller Zeit in FPGA/VHDL zu investieren? Konzeptionell halte ich das für ertragreicher und z.B. eine STM/FPGA Kombination hat auch mehr Möglichkeiten.
Das Hive-Projekt ist eine gute Anlaufstelle für Fragen zum Propeller. Der Hive ist ein Retro-Computer mit drei Props und externem RAM. Im Forum werden weitere Projekte um den Propeller vorgestellt und diskutiert. Der "Gam_Bo_Prop" entspricht vielleicht in etwa dem, was Du vorhast. Homepage http://hive-project.de/ Forum http://hive-project.de/board/ Gam_Bo_Prop http://hive-project.de/board/viewtopic.php?f=24&t=451
Michael N. schrieb: > Dafür brauche ich aber keine Cog > opfern nehme ich mal an, oder? Verstehe ich das Richtig, dass diese > schon in Hardware implementiert sind, ich allerdings nicht via Software > darauf zugreifen kann? The pins shown below have a special purpose upon power-up/reset but are general purpose I/O afterwards. P28 - I2C SCL connection to optional, external EEPROM. P29 - I2C SDA connection to optional, external EEPROM. P30 - Serial Tx to host. P31 - Serial Rx from host. Das "Propeller Manual" gibt dir alle nötigen Informationen. http://www.parallax.com/tabid/442/Default.aspx#Manuals Michael N. schrieb: > Kriegt > mann sagen wir mal an einem Nachmittag bereits ein kleines Lauflicht > hin, oder muss mann sich tiefer mit der Materie beschäftigen um etwas > mit den Controllern anfangen zu können? Wenn du dich etwas beeilst, bekommst du an dem Nachmittag auch noch ein kleines Protoboard für den Propeller hin. ;)
Michael N. schrieb: > Im "Typical Connection Diagram" Ist ja der UART zur Programmierung und > das SPI für den EEPROM dargestellt. Dafür brauche ich aber keine Cog > opfern nehme ich mal an, oder? Merkregel: Von wenigen Ausnahmen abgesehen haben diese Konzepte keine I/O-Module wie UART, SPI, I2C, ... sondern alles wird per Software realisiert. Für eine gewünschte UART kannst du also schon einmal einen COG abziehen. Das I2C für das Boot-EPROM funktioniert ebenso. Aber das macht der interne Bootloder und danach sind die Pins frei.
oog schrieb: > Das Hive-Projekt ist eine gute Anlaufstelle für Fragen zum Propeller. > Der Hive ist ein Retro-Computer mit drei Props und externem RAM. Im > Forum werden weitere Projekte um den Propeller vorgestellt und > diskutiert. > > Der "Gam_Bo_Prop" entspricht vielleicht in etwa dem, was Du vorhast. > > Homepage > http://hive-project.de/ > > Forum > http://hive-project.de/board/ > > Gam_Bo_Prop > http://hive-project.de/board/viewtopic.php?f=24&t=451 Auf das Hive-Projekt bin ich bei meiner Recherche auch schon durch das Embedded Jornal gestoßen. Derart komplex soll mein Porjekt aber nicht werden. Der Gam_Bo_Prop entspricht so in etwa dem was ich vor hab. was? schrieb: > Das "Propeller Manual" gibt dir alle nötigen Informationen. > http://www.parallax.com/tabid/442/Default.aspx#Manuals Danke für den Link, dieses Manual hab ich gesucht. Ich hab vorhin nur eine stark abgespeckte Version dieses Manuals gefunden. Ich werd mir mal ein paar von den Propellern (der XMOS ist einfach nicht so bastlerfreundlich/steckbretttauglich) besorgen. Mittlerweile bin ich neugieriger auf die Dinger als zuvor. Danke für die vielen konstruktiven Inputs lg much
Michael N. schrieb: > Ich werd mir mal ein paar von den Propellern (der XMOS ist einfach nicht > so bastlerfreundlich/steckbretttauglich) besorgen. Mittlerweile bin ich > neugieriger auf die Dinger als zuvor. Noch ein Tipp: Auf den Parallax USB Seriell Wandler "Propeller Clip" oder "Propeller Plug" kannst du getrost verzichten. Das ist einfach nur ein "USB to UART" Adapter und dafür ziemlich überteuert.
Ich sag mal platt "nein", die Vorteile der Architektur werden durch Spin wieder negiert und es gibt keine Typenvielfalt. Die SW is auch mehr als bescheiden. Aber man sollte bedenken dass das gesamte Projekt inklusive der Entwicklungsumgebung nur von ein paar wenigen Entwickeln getragen wurde...
Aber du hattest mit dem Teil doch auch deinen Spaß und als "kleine Spielerei" taugt das Teil allemal.
Michael N. schrieb: > Ich werd mir mal ein paar von den Propellern (der XMOS ist einfach nicht > so bastlerfreundlich/steckbretttauglich) besorgen. Mittlerweile bin ich > neugieriger auf die Dinger als zuvor. Was ist draus geworden?
max schrieb: > Was ist draus geworden? Ich hab mir drei Chips bestellt, die nun schon seit einiger Zeit in der Grabbelkiste liegen. Leider hatte ich bislang noch keine Zeit mich damit zu beschäftigen. Habe aber vor demnächst mit ein paar einfachen Übungen zu beginnen. Ein etwas Aufwendigeres Projekt, das den Prozessor auch mal an seine Grenzen bringt wird sich allerdings auch in nächster Zeit nicht ausgehen. Darf man fragen woher das Interesse an diesem Thread stammt? Beschäftigst du dich selbst auch mit dem Chip? lg much
> Nun würde mich interessieren ob jene die mit dem Propeller schon > gearbeitet haben dies im nachhinein bereut haben oder ob man mit dem > Ding wirklich etwas anfangen kann. Einfach und unkompliziert für Prototypen zu verarbeiten, gute Software, viele fertige Objekte der Community, die man nur wie in einem Bausteinsystem einbinden braucht. Spin ist eigen, aber in meinen AUgen gut geeignet für einen Multicoremikrocontroller. Kurz, ich habe es nicht bereut. > Konkret schwirtt mir schon ein > Projekt im Kopf herum das man mit dem Propeller eigentlich gut lösen > können müsste. Ich hab noch ein LCD Display ohne Graphiktreiber > rumliegen. Dafür möchte ich einen Treiber schreiben. Zusätzlich noch ein > Keyboard-Anschluss... . Halten diejenigen die Propeller kennen dies für > machbar? Für diverse Display gibt es fertige Objekte, ebenso natürlich für VGA oder Composit Video. Per Video bekommst du jeden popligen Rückfahrmonitor für lau aus der Bucht an den Chip zur Visualisierung angeklemmt. Objekte um Text oder Grafik darzustellen sind auch verfügbar, halt nur nicht in gigantischen Auflösungen. ABer für eine Textanzeige oder Diagramme zum Beispiel von Sensordaten ideal. > Nach dem durchstöbern des Datenblattes (33 Seiten?) schaut die > Einarbeitung gar nicht mal so aufwendig aus. Irre ich mich da oder kann > man sich tatsächlich relativ schnell in den uC einarbeiten? Geht fix, Spin ist eine sehr zugängliche Sprache. > Das Problem am Propeller ist die duale Programmierung, jedenfalls so wie > Parallax sich es vorstellte. Also Assembler-Programmierung für die > I/O-Module und ein recht frugaler Interpreter darüber. Ich für meinen Teil kann aus Erfahrung bestätigen, das dieses Konzept voll aufgeht. Habe lange nicht so entspannt kleine Projekte vom "Scratch" realisiert wie mit diesem Chip. > Zudem stösst man > schnell an Speichergrenzen und dann ist Ende Gelände. Naja, 32 KByte Hubram plus 16 KByte COG-RAM sind doch eine Menge Holz für einen Mikrocontroller im lötfreudigen DIP-Gehäuse für das Experiment "zwischendurch". > Die Konkurrenz von XMOS gefällt mir besser. Ist interessant, aber nichts für ein Steckbrett oder eine Lochrasterplatine. Außerdem ist die Community beim Propellerchip deutlich reger. > Der Propeller kann schon was, keine Frage, > dafür sieht es mau aus mit Peripherie, keine SPI, TWI etc. Das ist aber das Konzept: Hardware durch Software ersetzen. Wozu sonst sind denn die acht COGs da? Wenn kein SPI nötig ist, dann werden halt auch keine Ressourcen dafür verschwendet. Aber wenn man zum Beispiel sechs SPI-Schnittstellen benötigt, dann sind diese halt auch möglich.
frichter schrieb: > Geht fix, Spin ist eine sehr zugängliche Sprache. Yep, aber auf dem Stand der 70er Jahre, an BASIC Interpreter dieser Zeit erinnernd. Eine Sprache, in der man Daten nicht strukturieren kann, ist natürlich sehr einfach und zugänglich, aber eben auch reichlich antiquiert. Eigentlich wäre es sinnvoll, für beide Teile die gleiche Sprache zu verwenden. Per Compiler. Also ein ein Compiler für das COG-Programm. Und es fehlt auch eine saubere Interface-Definition zwischen Hub- und COG-Programm. > Naja, 32 KByte Hubram plus 16 KByte COG-RAM sind doch eine Menge Holz > für einen Mikrocontroller im lötfreudigen DIP-Gehäuse für das Experiment > "zwischendurch". Und dann? Ein nicht einsparbares Byte zu viel, egal lokal im COG oder global im Hub, und das ganze Lösungskonzept geht in Rauch auf. Geht so sehr in Rauch auf, dass man nicht nur das Programm, sondern auch das ganze Konzept dahinter verbrennen kann. Ich bin kein Gegner der Propeller. Sie sind für ein gewisses Aufgabenspektrum geeignet. Aber das Teil ist eben ein Einzelstück, einzig in seiner ganzen Art. Zum "rumspielen".
> Yep, aber auf dem Stand der 70er Jahre, an BASIC Interpreter dieser Zeit > erinnernd. Eine Sprache, in der man Daten nicht strukturieren kann, ist > natürlich sehr einfach und zugänglich, aber eben auch reichlich > antiquiert. ...und wahrscheinlich für die meisten Projekte auf dem Propeller ausreichend. Warum also alles unnötig komplex machen, wenn es auch einfach geht. Und wem Spin nicht reicht, der nimmt einfach C oder C++: https://sites.google.com/site/propellergcc/ > Und dann? Ein nicht einsparbares Byte zu viel, egal lokal im COG oder > global im Hub, und das ganze Lösungskonzept geht in Rauch auf. Geht so > sehr in Rauch auf, dass man nicht nur das Programm, sondern auch das > ganze Konzept dahinter verbrennen kann. Das ist jetzt aber genau betrachtet nicht unbedingt ein Argument gegen den Propeller, sondern mehr ein Argument dafür, dass Problem genauer zu durchdenken und halt einen passenden Chip zu verwenden. Oder den Hub-RAM zu erweitern: bietet es sich vielleicht an einen externen RAM per I2C oder SPI zu verwenden oder auf SD-Card auszulagern? Nicht alle Daten müssen in der gleichen Geschwindigkeit verfügbar sein, Programmcode kann in Module aufgeteilt und ausgelagert werden usw. Gibt doch oft tausend Möglichkeiten um so ein Problem zu lösen.
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.