Hi! Ich hab die XMOS-chips "entdeckt"! ;-) Zu dem chip gibts nur ein einziges Posting hier. Hat damit schon jemand gearbeitet und will einen Kommentar dazu loszulassen? Der µC lässt klar erkennen, dass er vom Transputer inspiriert wurde. Auch aus "Inmos" wurde "XMOS". Er hat eine eigene Programmiersprache "XC" die sich aus C ableitet und wohl das damalige "Occam" ersetzen soll. Entwicklungsumgebung ist kostenlos, incl. "XC", der kleineste Prozessor kostet humane $8. Board hab ich noch keines ... Gruß, Nick
Naja, XMOS scheint ja irgendwie aus Südengland zu kommen. 1988 war Inmos in Südwales beheimatet (ich bin da mal bei absolutem Sauwetter mit dem Rad vorbeigefahren), vielleicht besteht da ja tatsächlich eine Verwandtschaft. Bin auf Berichte gespannt.
> vielleicht besteht da ja tatsächlich eine Verwandtschaft.
Die Verwandschaft besteht tatsächlich. Hab mich wohl etwas orakelhaft
ausgdrückt.
Auf YouTube unter myXMOS gibts ein wenig zu sehen. Das übliche
Roboter-Zeug halt. ;-)
Der XMOS hat, wie der Transputer damals, recht flotte
Inter-Prozessor-Kommunikation. Und die auch in der Hochsprache
implementiert.
UART usw. ist änlich wie beim Propeller implementiert: Nämlich nicht.
Das muss alles ein Task (oder in Propeller-Sprech: Ein COG) erledigen.
Es scheint aber fertige Bibliotheken zu geben.
Wie gesagt, ich hab absolut keine Erfahrung. Finde den aber attraktiv,
mir gefällt ja auch der Propeller.
Gruß,
Nick
Gibts heute als ST20/ST40/ST... bei SGS Thomson. Und werkelt als Core in vielen Millionen DVB-S/T, DVD, GPS Wer hätte das gedacht :-) Schwierig wird es nur an Datenblätter, Tools etc. zu kommen. Jedes 2. Datenblatt wird von einem 'Confidential' verziert... Aber schon nett der Prozessor.
So, heute sind 2 verschiedene Dev-Kits gekommen: * XK-1 (single core) * XC-2 (quad-core mit Ethernet) Die LEDs blinken schon mal, ein "Hello world" geht auch. Kanns so schlimm nicht sein. :-) Interessant sind die Änderungen von XC ggü. C. Kein goto, keine pointer (geht als open arrays oder call-by-reference) und dass functions mehrere return-Werte haben können. Es geht aber dennoch C und gar C++ (wohl mit Randbedingungen, hab mich noch nicht genug eingelesen). Leider waren bei der Lieferung die Bücher nicht dabei, die sind erst ganz frisch vom Drucker gekommen und kommen wohl demnächst. Die brauch ich, um schlechter schlafen zu können. :-) Entwicklungsumgebung (Eclipse) läuft auf Win, Mac und Linux (bei mir Kubuntu 9.10). Hat bissl Zicken (Buttons in Dialogen werden tw. nur mit anklicken + Leertaste angenommen) aber scheint ansonsten stabil zu sein, übersichtlich und mächtig. Bestellt hab ich direkt bei XMOS. Da ich keine Silver-card und erst recht keine Gold-Card oder gar PayPal hab, hab ich um eine Proforma-Rechnung gebeten und vorab überwiesen. In US$ nach England. :-/ Wer die µP-Trampelpfade verlassen will oder mal über den Tellerrand schauen will, soll sich so einen Kit besorgen. Mit $99 nicht grad billig, aber ein schöner Abendteur-Spielplatz! Gruß, Nick
Bei Sparkfun gibts für 33 Euro ein X-Mos Board : http://www.sparkfun.com/commerce/product_info.php?products_id=9428 Bin mir aber nicht sicher ob man jeden beliebigen JTAG-Programmer nutzen kann.
Nick Müller schrieb:
> Der µC lässt klar erkennen, dass er vom Transputer inspiriert wurde.
Da dürfte mehr als Inspiration am Werk gewesen sein. Es erinnert nicht
nur die Architektur an Transputer, sondern auch der Stil des
Architecture Manuals. Das sieht nämlich in seiner "Bilderflut" so aus,
als wäre es ursprünglich auf der Schreibmaschine getippt worden ;-). Bei
den Transputern war's genauso.
He, da ist wirklich mal was neues drin. Es kommt ja nicht allzu oft vor, dass man für die Dekodierung von Befehlen, d.h. für's rausziehen der Registeroperanden, zweimal durch 3 dividiert.
> Bei Sparkfun gibts für 33 Euro ein X-Mos Board : Ja, soll auch funktionieren, inzwischen. Hier: http://www.xmoslinkers.org/forum/viewtopic.php?t=590 gibts einen thread dazu. Gruß, Nick
Das Packaging ist etwas ineffizient und nicht sehr bastelfreundlich. Von 64 Pins bleiben für I/O und Links nur 36 übrig, der Rest ist Strom oder fixiert auf Modus, JTAG usw. Das entspricht ungefähr der Konkurrenz im 48-Pin-Kleid. Und GND sitzt als Riesenpad unten drunter.
So, Ethernet geht auch (eigentümlicherweise nur über einen Switch; liegt wohl an mir). Ping-Zeit 0,12ms. Auch der Webserver läuft (incl. Bildern), sieht cool aus. Das alles aber auf dem Quad-core, und den gibts nur als BGA. Bekommt man das eigentlich (unter Auslassung etlicher pins, zusammen sinds 144) auf zweiseitig unter? Hab Null-BGA-Ahnung! Ein 4-lagiger Prototyp ist etwas ... ähem ... "unpreiswert". :-( Ich würde damit gerne versuchen (wenn's dann mit dem Proto-board klappt) ein Modbus-Interface über Ethernet zu machen. Über RS232 hab ich schon eines am Laufen (mit dem Propeller). Gruß, Nick
Weiterer Monolog ... :-) Der XMOS hat keinen UART o.ä., das ist eine der Gemeinsamkeiten mit den Propeller. Sowas muss also in Software nachgebildet werden. Das sieht dann so aus:
1 | // ----------------------------------------
|
2 | #define BIT_RATE 115200
|
3 | #define BIT_TIME XS1_TIMER_HZ / BIT_RATE
|
4 | |
5 | out port TXD = PORT_UART_TX; |
6 | |
7 | void txByte(out port TXD, int byte) { |
8 | unsigned time; |
9 | timer t; |
10 | |
11 | /* get initial time */
|
12 | t :> time; |
13 | |
14 | /* output start bit */
|
15 | TXD <: 0; |
16 | time += BIT_TIME; |
17 | t when timerafter(time) :> void; |
18 | |
19 | /* output data bits */
|
20 | for (int i=0; i<8; i++) { |
21 | TXD <: >> byte; |
22 | time += BIT_TIME; |
23 | t when timerafter(time) :> void; |
24 | }
|
25 | |
26 | /* output stop bit */
|
27 | TXD <: 1; |
28 | time += BIT_TIME; |
29 | t when timerafter(time) :> void; |
30 | |
31 | }
|
Das geht bis etwa 10MBit gut, dann ist der timer schon abgelaufen vor dem nächsten Statement. Sollte im Wesentlichen lesbar sein, trotz der Erweiterungen von C. Gruß, Nick
Nick Müller schrieb: > So, Ethernet geht auch (eigentümlicherweise nur über einen Switch; liegt > wohl an mir). Oder der arbeitet implizit half duplex, was den Switch nicht stört, wohl aber einen per Crossover-Kabel angeschlossenen PC irritieren könnte. > Das alles aber auf dem Quad-core, und den gibts nur als BGA. Wenn ich die Nummer mit dem Ethernet auf XMOS richtig verstehe, dann läuft das grad so wie bei UART, d.h. einzig der externe über MII/SMI angebundene PHY-Chip ist "echt", der interne MAC dagegen Software. Wobei das dann nicht unbedingt auf BGA-Versionen beschränkt wäre. > zweiseitig unter? Hab Null-BGA-Ahnung! Ein 4-lagiger Prototyp ist etwas > ... ähem ... "unpreiswert". :-( Vor allem ist BGA ziemlich besch....en zu löten.
Nick Müller schrieb: > Der XMOS hat keinen UART o.ä., das ist eine der Gemeinsamkeiten mit den > Propeller. Wobei der XMOS aber zumindest im mitgelieferten Code gleich zwei Threads dafür investiert. Ich meine dass Parallax das in einem Thread zustande brachte.
> Wobei das dann nicht unbedingt auf BGA-Versionen beschränkt wäre. So genau hab ich mir das noch nicht angesehen. Kann sein, dass das reichlich threads braucht und dann auf dem Single-core blöd wird. > Wobei der XMOS aber zumindest im mitgelieferten Code gleich zwei > Threads dafür investiert. Im PDF zu XC ist ein Beispiel das für Senden und Empfangen mit einem thread auskommt. Gleich zum Propeller. Nur wird das mit XC deutlich eleganter. In XC gibts nämlich ein Konstrukt das dem "case" sehr ähnelt und auf beliebige Events (timer abgelaufen, Signalwechsel auf einem Pin, ...) reagiert. Wie schnell das ist? Ich schätze, dass 1MBaud zu schaffen sind. Der Propeller ist schon in manchen Dingen ähnlich. Beim XMOS hat man sich aber auch Gedanken zur Sprache gemacht. Kein Wunder bei dem Hintergrund. Das SPIN vom Prop ist in meinen Augen halbwegs krank und primitiv (und ich hab mir desswegen auf dem Parallax-Forum schon meine Watschen abgeholt). Das Prop-C von Imagecraft ist natürlich und leider an parallele Prozesse überhaupt nicht angepasst. Und, das läuft nicht direkt in einem COG (ein Kern auf dem Prop), da der viel zu wenig RAM hat. Da muss op-code für op-code reingeladen werden. Machts nicht schneller! Ich hab den Eindruck (mit meinen paar Stunden "Erfahrung"), dass man mit XC nichts falsch machen kann. Möglicherweise könnte man mit selber denken und Semaphoren entspannter arbeiten. > Vor allem ist BGA ziemlich besch....en zu löten. Das vermute ich mal. :-) Hab im Forum schon bissl rumgelesen und es gibt ja Ansätze die scheinbar stabil sind. Gruß, Nick
Nick Müller schrieb: > In XC gibts nämlich ein Konstrukt das dem "case" sehr ähnelt > und auf beliebige Events (timer abgelaufen, Signalwechsel auf einem Pin, > ...) reagiert. Nix neu, nur schöner. Gab es auf Transputern auch schon. > Der Propeller ist schon in manchen Dingen ähnlich. Beim XMOS hat man > sich aber auch Gedanken zur Sprache gemacht. Yep. Synthese aus Occam und C. Occam war bis dicht an die Unverwendbarkeit kastriert worden. Nun hat er gemerkt, dass an C kein Weg vorbei führt, und hat seine Vorstellungen von besserer Programmierung mit C verknüpft. Sicherer wird die Programmierung damit schon sein, aber manchmal auch umständlicher. > Hintergrund. Das SPIN vom Prop ist in meinen Augen halbwegs krank und > primitiv Da stimme ich uneingeschränkt zu. > Ich hab den Eindruck (mit meinen paar Stunden "Erfahrung"), dass man mit > XC nichts falsch machen kann. Möglicherweise könnte man mit selber > denken und Semaphoren entspannter arbeiten. Das ist auch so ein Punkt, wo er vielleicht aus eigenen Fehlern gelernt hat. Die Transputer hatten exakt ein einziges Konzept zur Synchronisierung von Prozessen, und das war leider nicht die Semaphore. Das konnte scheusslich aufwendig werden, weil die dafür nötigen Software-Links dummerweise auch noch auf exakt zwei Prozesse beschränkt waren. Der Konstrukteur hat(te?) die Eigenheit, unbedingt der Welt beibringen zu müssen, wie man es besser macht - nicht ganz zu Unrecht, aber Gängelung wird selten widerspruchslos akzeptiert. Die Welt fand denn auch, es gäbe Besseres. Ich bin in das Link- und Synchronisierungs-Modell der XMOS aber noch nicht so tief eingestiegen, um festzustellen, ob's hier wirklich besser aussieht. > Das vermute ich mal. :-) Hab im Forum schon bissl rumgelesen und es gibt > ja Ansätze die scheinbar stabil sind. Hmm. Ofen oder so.
> Nix neu, nur schöner. Gab es auf Transputern auch schon.
Dass der Vater des XMOS auch der Vater des Transputer ist, ist (mir)
klar.
Ich muss mal nach meinem Occam-Buch suchen. Leider war die
Transputer-Karte von "mc"(?) damals für mich unbezahlbar.
Ich erfülle mir jetzt also einen Jugendtraum. :-)
Gruß,
Nick
Mein Fazit aus Querlesen der Doku: Gleiches Systemziel wie bei den Transputern. Sinnvoll vor allem dann, wenn man mehrere davon zusammenspannt und deren schnellen Verbindungen nutzen kann. Ein einzelner Transputer war wenig sinnvoll, ein Gespann von 16 oder so deutlich interessanter. Wenn man es hingegen mit einem einzigen Chip zu tun hat, dann sehe ich die Vorteile nur dann, wenn man mit sehr schneller I/O zu tun hat für die konventionell aufgebaute Controller keine fertigen Peripheriemodule haben. 64KB für Programm+Daten sind ziemlich schnell weg. Erweitert wird dann der Systemphilosophie entsprechend wohl durch Auslagern von Programmteilen in einen weiteren solchen Chip. Diese Vorgehensweise ist nicht unbedingt einfacher als konventionelle Programmierung. Aber immerhin, anders als beim Propeller geht das hier recht gut.
Nick Müller schrieb: > Ich muss mal nach meinem Occam-Buch suchen. Leider war die > Transputer-Karte von "mc"(?) damals für mich unbezahlbar. > Ich erfülle mir jetzt also einen Jugendtraum. :-) Bei mir war's andersrum. Das Konzept schien sehr interessant und der Zugang zu Transputern war gegeben (Uni). Aber die konkrete Beschäftigung damit offenbarte deren Probleme. Ein T212 als I/O-Controller (Ser/Par/Grafiksystem) resultierte in einem bizarr komplexen System. Und Befehlssatz wie Speicherstruktur waren derart auf Occam festgelegt worden, dass mein dafür gestrickter C Compiler ziemlich schräge und teils umständliche Techniken nutzte, um bei mehr als einem Thread effizient sein zu können.
> Wenn man es hingegen mit einem einzigen Chip zu tun hat, dann sehe ich > die Vorteile nur dann, wenn man mit sehr schneller I/O zu tun hat für > die konventionell aufgebaute Controller keine fertigen Peripheriemodule > haben. Sehe ich nicht ganz so. Die parallelen Prozesse gehen ja auch auf einem XMOS (oder Propeller). Der kleinste XMOS hat einen Kern mit 8 threads (wobei 4 threads sich gegenseitig nicht ausbremsen, darüber wirds langsamer wenn keiner der threads auf etwas wartet). Der größte hat 4 Kerne und somit 32 threads. Das mit den threads hat schon Vorteile, es gibt oft genug Aufgaben die im Hintergrund abgearbeitet werden können (z.B. Prüfsumme berechnen, Aufräumarbeiten, Vorbereiten auf das nächste Event, ...). Natürlich kann man sagen, der Chip XY hat SPI/I2C/UART in Hardware, aber hat er das genau in der Kombination wie mans braucht? Schau dir mal an wie viele Varianten es beim PIC oder Atmel gibt. Wie weit das RAM für "echte" Programme genügt weiß ich nicht, das wird von mir noch ausprobert. XMOS platziert den aber auch nicht als Prozessor, sondern näher zum FPGA (die dann soft-cores haben um näher zum Prozessor zu rücken). Gruß, Nick
Nick Müller schrieb: > Natürlich kann man sagen, der Chip XY hat SPI/I2C/UART in Hardware, aber > hat er das genau in der Kombination wie mans braucht? Schau dir mal an > wie viele Varianten es beim PIC oder Atmel gibt. Richtig, aber wenn's da einen passenden gibt und ich den CAN Controller nicht bis runter auf's Achtelbit selber programmieren muss, dann reicht mir das. Implementierte Features eines STM32 nicht zu nutzen stört mich kein bischen ;-). > Prozessor, sondern näher zum FPGA (die dann soft-cores haben um näher > zum Prozessor zu rücken). Ebendies wollte ich damit ja auch ausdrücken.
> Richtig, aber wenn's da einen passenden gibt und ich den CAN Controller > nicht bis runter auf's Achtelbit selber programmieren muss, ... :-) Mit der Verfügbarkeit fertiger Bibliotheken steht und fällt das Ganze natürlich. Ähnlich einem FPGA. Ich bin mal gespannt inwieweit sich die XMOS-Leute darum kümmern. Beim Propeller ist es leider so, dass es viel Wildwuchs gibt. Das fängt beim Original UART-Treiber in Assembler an der absolut Null Kommentar hat und mit zwei Startbits anfängt. Das ist denen bekannt, bleibt aber so. Einen offiziellen I2C-Treiber gibts auch nicht, der existierende eines Users hat ein falsches Timing (geht aber meistens). Abwarten und weiterspielen. Gruß, Nick
Nick, Es freut mich daß du der XMOS entdeckt hast ! (Ich weiß daß du in der Propeller Forum gesagt hast daß du eine Platine gekauft wolltest) Es ist ganz toll und wirklich schnell. Ich hab nicht viel mehr gemacht, andere Projekte. Vielleicht können wir ein Paar mehr Leute von Propeller nach XMOS schieben ;-) Ich sollte kaufen eine Platine wie die Platine Sparkfun hat weil meine XC-1 ist nicht für Standalone Projekte geeignet :-( Gruß Ale
> Vielleicht können wir ein Paar mehr Leute von Propeller nach > XMOS schieben ;-) Ach Gott! Darum gehts mir doch garnicht (trotz des ";-)"). Wie jeder Prozessor hat der Propeller auch sein Vor- und Nachteile. AVR-ist-besser-als-PIC oder ähnliches ist nicht mein Ding. Es gibt einfach für eine Aufgabe ungeeignete und geeignete. Und wenn jemand CP/M mit einer Z80-Emu auf dem Prop zum laufen bringt ist das zwar äusserst respektabel, aber trotzdem unsinnig. Ich hab gestern mindestens 1/2 Stunde gebraucht um ein Signal an einem bestimmten Pin des XMOS rauszubekommen. Zu jedem Prozessor braucht man eine Netlist (in XML). Die ist zwar dabei, aber nur mit den Einträgen für den Kit mit den tatsächlich belegten Pins (LEDs, Taster, Ethernet, ...). Und dann ist genau der Pin den ich wahllos rausgesucht habe nur auf dem Kern#1 verfügbar. Muss man beim source explizit angeben doch bitte den Kern zu verwenden. Also der Prozessor braucht mehr Einarbeitung. Aber das machts nur spannender. :-) Gruß, Nick
Ich hab gesehen daß ein Paar sachen (mit der Tools) anders als früher sind. Vorher gab kein XN Datei, alles könnte man in XC Datei rein machen... Ich "evangelisiere" auch nicht viel. Endlos "Prop ist besser als XMOS" usw. gehen nicht viel weiter...
1 | t :> time; |
2 | |
3 | TXD <: 0; |
wenn ich mal nachfragen darf, was bedeuten diese beiden Zeilen? :> und <: kenne ich nicht in C
>> Weil nicht C ist. Es ist XC. >> :> = lesen von port >> <: schreiben an port In C braucht man dafür nur ein Zeichen ;-) = Ich sehe da keine Notwendigkeit für zwei Zeichen ... Was bitte ist der Vorteil dieses Controllers gegenüber einem ATMEL Mikrocontroller? Die Architektur scheint anders zu sein, soweit habe ich das heraus gelesen, aber was sind die Vorteile? Ist er schneller? Einfacher zu programmieren? Effektiver? Bessere Möglichkeiten zur Speicherveraltung oder nebenläufigen Prozessen (Threads) oder eine gute Möglichkeit zur Interprozesskommunikation ? Danke !!!
Wesentliches Unterschiedungsmerkmal (ich sag absichtlich nicht Vorteil) ist, dass man pro Core bis zu acht parallel arbeitende threads haben kann. Bis 4 threads die gleichzeitig aktiv sind wirds nicht langsamer, darüber schon. Ausser ein thread wartet auf Eingabe, dann zählt er nicht zu den vieren dazu. Der große XMOS hat 4 cores also 4 * 8 threads. Threads können über ein eigenes thread-sicheres Protokoll kommunizieren (sieht pipe-artig aus). Das geht auch zwischen Chips. Weiter oben gabs mal eine Aussage von mir wg. Ethernet die vage war: MII geht auf einem thread mit 100MHz in Vollduplex. Der code dazu (ohne CRC) sieht beinahe lächerlich einfach aus (zumindest NUR Tx oder NUR Rx). Zum <: und :> Da steckt mehr dahinter als nur eine Zuweisung. Stell dir eher den streaming-operator aus C++ vor. Je nachdem wie der Port konfiguriert ist, wird dann ein Bit (oder andere Längen) seriell ausgegeben. Ports können 1 Bit, 4 Bit, 8 Bit (fehlt einer, weiß grad nicht) breit sein und entsprechend wird "zerhackt" und rausgeschoben. Puffer kann auch dahinter hängen, ebenso wie interner oder externer clock. Ist etwas komplex, ich hoffe nichts allzu falsches gesagt zu haben. Weil der Port immer links vom operator steht, brauchts die "Richtungsangabe" und daher die Syntax. Wohl wollte man das '>>' oder '<<' nicht misbrauchen. Speicher: 64kB pro Core. Ob das viel ist weiß ich nicht. Ich glaub der Compiler ist sehr effektiv. Am besten liest man sich das PDF zu CX durch. http://www.xmos.com/published/xc_en Mein Eindruck bis jetzt ist, dass man keine Veranlassung hat in Assembler zu programmieren. Konfigurationsregistergefummle (DIRA usw.) ist in weichen XC-Tüchern eingewickelt. :-) Nächste Woche werde ich hoffentlich Zeit finden eine Applikation auf den XMOS umzusetzen. Zumindest mal grob und im Wesentlichen. Gruß, Nick
Danke für die Info Nick! 4 parallele Threads klingt sehr interessant! Bei meinen bisherigen Erfahrungen mit Single Core Controllern war es immer so, dass man einen Zeitgeber hatte z.B. RTC Interrupt der zyklisch das Task Management triggert. Die Tasks selbst waren immer nicht priorisiert und nicht preemptiv... also alles sehr einfach gehalten und sehr statisch. Dafür aber mehr oder weniger deterministisch... wenn man von anderen Interrupts absieht.. ;-) Aber 4 Threads sind natürlich klasse. Ein Thread der z.B. permanent die Ethernetschnittstelle bedient (DLL - Data Link Layer, Puffer usw.) - damit lässt sich sicher viel schönes realisieren... Ist der Controller vergleichbar mit einer "modernen" Mehr-Kern Prozessor Architektur? Der Nachteil liegt aber da ganz klar auf der Hand: Standardisierung.. es gibt mich Sicherheit wenige RT OS oder sonstige Compiler, die auf diese sehr spezielle Architektur ausgelegt sind? Aber mit so einem Controller kann man "richtige" Software entwickeln.. ich denke da an Richtung C++, C# mit Entwurfsmusterm wie Observer usw. ... Event getriggerte Systeme mit einem hohen Abstraktionsgrad In der Praxis / Industrie hat es so eine Technologie immer schwer, weil es einfach erstmal was "neues", etwas nicht standardisiertes ist.. viele Kunden haben ja klare Vorstellungen, welche Controller und welche Standardsoftware einzusetzen ist... (ich denke da speziell an Automotive, aus der Ecke komme ich auch) Wie das in anderen Industriezweigen ist, weiß ich nicht... ich denke, aber dass da die Strukturen etwas flexibler und "innovativer" sind... Viele Grüße und ein schönes We :)
XMOS ? schrieb:
> 4 parallele Threads klingt sehr interessant!
Es sind bis 8 Threads pro Core, die ähnlich dem Hyperthreading diverser
Intel-Prozessoren arbeiten, wobei die sich dann schon ein bischen
gegenseitig bremsen werden. Die grösseren Versionen haben 4 Cores,
ergibt maximal 32 in Hardware verwaltete Threads.
> Ist der Controller vergleichbar mit einer "modernen" Mehr-Kern Prozessor > Architektur? Nein. Die Cores von PC-Prozessoren arbeiten in gemeinsamem Speicher. Die XMOS nicht. Die kleineren XMOS mit nur einen Core ähneln grob den älteren Pentium-4 Single-Core Prozessoren oder den Single-Core Atoms mit ihren 2 Threads, nur sind es eben 8 statt 2 und sie sind natürlich weit einfacher aufgebaut. Die Threads arbeiten im gemeinsamen 64KB Speicher. Die grösseren XMOS mit 4 Cores ähneln strukturell einem Aufbau aus 4 kleinen XMOS, die mit schnellen seriellen Kanälen untereinander verbunden sind. Die Cores haben also keinen gemeinsamen Speicher, ähneln damit eher einem Netzwerk von Prozessoren, grob vergleichbar zu den High-Performance Clustern aus hunderten und tausenden von einzelnen Prozessoren. Eine gewisse Skalierbarkeit ergibt sich dementsprechend, weil man mehrere solcher 4-Core XMOS hardwaremässig verbinden kann, und damit ein struktuell ähnliches aber grössere Geflecht aus Cores entsteht.
Zum RTOS: Das stammt aus der Zeit, als es noch Interrupts gab. :-) Du musst dich von der Idee lösen dass es eine Hauptschleife gibt die zyklisch irgendwelche Dinge erledigt. Denk mehr in Richtung Datenfluß. Quellen und Senken. Wenn du die Hardware skizzierst, hast du ja auch Daten-Quellen (ADC, Taster, usw.) und Daten-Senken (DAC, Display, ...). Und genau so kannst du das direkt umsetzen. Für jede Quelle ein thread, für jede Senke ein thread. Dazwischen hängt ein (oder mehrere "Master", auch ein thread) der die Daten empfängt, umwurschtelt & verknüpft und an die Senken weitergibt. Das ergibt mehrere kleine Progrämmchen die man getrennt betrachten kann. Dazwischen etwas Verarbeitungs-code. (leicht untertrieben) Denk in Richtung Datenfluß. Durchschieben. Das geht auch klassisch, nur gehts mit threads noch schöner, weil man man die Sachen getrennt(er) betrachten kann. Gibt genug Probleme wo der Ansatz übertrieben ist. Da ist auch der XMOS fehl am Platz da unterfordert. Mal ein Beispiel (Modbus-Interface): Ich hab das auf dem Propeller (halbherzig) gemacht, wills aber auf den XMOS umsetzen. Daten werden über RS232 empfangen, verarbeitet und Antworten zu Anfragen gegeben. Die empfangenen Daten müssen bestimmte Timing-Kriterien erfüllen, sonst ist das Paket ungültig. Das kann ein thread erledigen (und gleichzeitig die Pakete verwerfen die nicht an den Slave gehen). Es kümmert sich ein thread darum, die Daten zu lesen (Register, Coils). Die Abfrage der physikalischen Eingänge und setzen der Ausgänge kann ein (oder zwei) threads im Hintergrund machen und den aktuellen Status immer für die anderen threads bereithalten. Sobald eine gültige Anfrage gekommen ist, stehen alle Daten schon breit zur Antwort und mössen nicht erst eingesammelt werden. Das generierte Antworttelegramm wird an einen weiteren thread übergeben, der sich ums Verschicken kümmert. Manche Antworten erfordern ein Antworttelegramm UND Speichern von Daten im EEPROM. Das Speichern erledigt wieder ein anderer thread. So laufen die Daten tatsächlich irgendwo zusammen und werden tatsächlich verteilt. Ich hoffe, das war nicht zu wirr. :-) Gruß, Nick
Nachtrag: Zum automotive-Bereich passt der XMOS doch -rein philosopisch zumindest- recht gut. Da gibt es ja auch Busse über die Daten laufen. Hilfsprozessoren die nebenläufiges erledigen. Dem XMOS ist es egal ob sich der port physikalisch auf dem gleichen Chip befindet oder 1m weiter auf einem anderen. Übertragen wird immer über ports. Ich glaub der kann kein CAN-Protokoll. Könnte aber sein, dass es dafür Umsetzer-chips gibt, kenn mich damit nicht aus. Gruß, Nick
Verstehe ich das richtig, dass es bei der XMOS Architektur keine Interrupts mehr gibt? Das heißt doch im Grunde, dass jeder Thread wie eine main() Schleife auf einem einigen Controller funktioniert? Bestimmte Ereignisse werden dann gepollt und ein Signal gesetzt auf das wiederum ein anderer Thread pollt? So richtig? Z.b:
1 | void Thread_1_SPI() |
2 | {
|
3 | if (Data.Available() == true) |
4 | {
|
5 | SPI.Data.ready = true; |
6 | }
|
7 | }
|
8 | |
9 | void Thread_2_Display() |
10 | {
|
11 | if (SPI.Data.ready == true) |
12 | {
|
13 | Display.ShowData(SPI.Data.GetPtr(), SPI.Data.GetLength() ); |
14 | }
|
15 | }
|
16 | |
17 | // usw.
|
Hier enstehen doch klassische Probleme aus der Systemprogrammierung wie: - Deadlocks - Zugriffsregelungen (Semaphoren) - Synchronisationspunkte Durch viele nebenläufige Threads steigt natürlich der Aufwand an Synchronisierung bespielsweise, wenn eine Senke auf Daten aus mehreren Quellen warten muss ... Gibt es auch sowas wie "waitForEvent()" so, dass ein Thread aktiv warten muss ... für Synchronisationen und sonstiges... Ja, im Automotive Bereich ist das ziemlich ähnlich. Dort agieren je nach System 40 bis 80 Steuergeräte miteinander. Teilweise in Netze verteiles (HS-CAN, LS-CAN, MOST, Flex-Ray, LIN) und verbunden über Gateways, die Signale von einem Netz ins andere leiten... Manche Steuergerät sind nur Aktoren (beispielsweise Fensterhebermotoren) mit Feedbackleitungen. Ähnlich deinem Beispiel mit Datensenke und Datenquelle... nur hier pyhsikalisch verteilt über das ganze Fahrzeug... Aber irgendwie fasziniert mich die Idee, ohne Interrupts auf einem Mikrocontroller zu arbeiten. Bei der PC-Programmierung kommt man ja im Normalfall auch nicht mit Inerrupts (von Hardware usw.) in Berührung, dort werden beliebig viele Threads gestartet und kritische Daten per Sempahoren geschützt. Vielleicht die Zukunft... der modernen Mikrocontroller ... Gruß :)
> Bestimmte Ereignisse werden dann gepollt und ein Signal gesetzt auf das > wiederum ein anderer Thread pollt? So richtig? Doppelt falsch. :-) Das ist alles event-driven. Man kann sogar auf mehrere events gleichzeitig warten. Das ist einfach ähnlich einem switch-statement bei dem die cases events sind. *1) Tritt ein event auf, dann wird der code in dem case durchgeführt. Eben wie beim switch. Treten zwei events gleichzeitig auf, dann wir erst ein event gemacht, dann das andere. *2) Die Kommunikation zwischen threads passiert über ports (das entspricht recht gut "(named) pipes"). Wenn die Gegenseite nichts reinschiebt, kann auch nichts gelesen werden, der Empfänger steht. An einer pipe können nur zwei Teilnehmer hängen (an jedem Ende einer). Wenn du mehrere Konsumenten haben willst, dann musst du die Daten in eine neue pipe kopieren. Deadlock kann man über timeout machen. Wieder das "switch" (heißt aber anders) mit dem event "Daten kommen" oder "Timer abgelaufen". Blättere einfach mal schnell den PDF durch den ich weiter oben genannt habe und schau dir die Beispiele an. Die ersten 2/3 kann man sehr gut lesen ohne wirklich etwas kapiert zu haben oder überhaupt was zur Syntax gelesen zu haben (ist auch dann jeweils kurz und verständlich erklärt). *1): Wie das intern gemacht wird weiß ich nicht. *2): Das interessante dabei ist, dass wenn ein thread steht (wegen Wartens auf ein Event) dieser thread Prozessorleistung an die anderen abgibt. Wie gesagt, 4 threads laufen voll power, darüber (maximal 8) wirds langsamer. Stehende threads zählen NICHT dazu. Ich will hier nicht den Eindruck erwecken der XMOS-Guru zu sein! Ich beantworte auch paar Fragen bewusst nicht, weil ich mir nicht sicher bin. Ich wollte euch nur was zeigen, das ich interessant finde. Und für mich gibts da noch einiges zu entdecken und zu erarbeiten, mein Wissensvorsprung ist nur klein. Pferdefüße finden sich immer erst, wenns zu spät ist. ;-) > Vielleicht die Zukunft... der modernen Mikrocontroller ... Mag sein. Im Moment seh ich den Speicher als Problem (ab einer gewissen Größe). 64K pro core. Externes RAM kann man nicht so anstöpseln, dass es im Adressbereich erscheint. Geht nur über SPI o.ä. mit allen Nachteilen. Kann sein, dass da noch was nachkommt. Gruß, Nick
Servus Nick Ich hatte Deine Ausführungen mit Interesse verfolgt. Gedenkst Du über Deine Eindrücke und Erfahrungen weiter zu berichten? Ich würde mich sehr darüber freuen. MfG aus Istanbul
> Gedenkst Du über Deine Eindrücke und Erfahrungen weiter zu berichten?
Ja, werde ich! Das dauert aber noch etwas, es liegen dringende Sachen
auf dem Basteltisch. :-)
Dennoch hab ich schon mal einen Teil meines bestehenden
Modbus-Interfaces portiert. Es fehlen noch Nebenfunktionen
(Konfiguration im EEPROM speichern) und die Anbindung an die
Treiberplatinen.
Gruß,
Nick
auch räusper Ich sagte doch, das dauert. :-) Ich hab mir Urlaub von Projekten gegeben die dringend sind um mal was fertigzumachen was schon fast 1 Jahr Platz wegnimmt aber noch nicht funktioniert und komplett ist: Meine Myford MG-12 Rundschleifmaschine (findet man auf YouTube). Dann gehts mit der Steuerung meiner MAHO 700 C wieder weiter und ab dem Moment kann ich auch wieder programmieren. Dann muss ich mich mental nicht täglich von Mechanik auf Elektronik umstellen. :-) Gruß und Geduld, Nick
Wer setzt den XMOS eigentlich in Produkten ein? Wie finanziert sich so eine Firma? Insgesamt hört es sich interessant an, besonders die eigenschaft, dass es völlig egal ist, ob ein Thread auf dem selben µC oder auf einem andern läuft. erinnert mich an das Konzept der Linkports von AnalogDevices TigerSharc DSPs Gruß Tom
Es wird ein Amiga Nachfolger mit dem Mikrocontroller angekündigt. AmigaOne X1000! Da ich selber den Amiga nutze und auch ein wenig erfahrung mit dem Atmega8 habe, bin ich mal gespannt auf das Ergebnis.
Unglaublich, dass da wirklich jemand den Amiga wiederbeleben will. Für mich war es mein Start in das ernsthafte programmieren. Ich habe seinerzeits mit meinem Freund Ulrich Sigmund die Programmiersprache Cluster entwickelt, falls Du Dich daran erinnern kannst. Waren schöne Zeiten. Gruß Tom
Ahh, hier ist der XMOS auch angekommen. Bei uns wird auch mit XMOS grad gebastelt, mit Ethernet und relativ fixen (im Sinne von schnellen) weiteren IO-Sachen. Mal schauen
Zu meiner Freude habe ich festgestellt, dass Watterot die XMOS im Angebot hat: http://www.watterott.com/XMOS Jetzt fehlt nur noch etwas Freizeit .... na, mal weitertraeumen ....
Hallo, bin auch gerade dabei das Watterot-Kit zu bearbeiten. Es soll eine Ethernetschnittstelle LAN8710 erhalten. Die groesste Herausforderung ist wohl die Ethernet/TCPIP Software von 7 auf wenigstens 5 Threads einzudampfen, damit man mit den verbleibenden 3 noch was sinnvolles anfangen kann.
Hab mein XC-1 Development Kit bekommen. Vorweg: Ich bin ein Anfänger. Da mein Englisch sehr schlecht ist hab ich so meine Probleme mit der Dokumentation. Bin aber soweit das ich die Onboard Buttons und LEDs gezielt ansprechen kann. Hab jetzt versucht die Firmware zu aktuallisieren. Bekomme aber immer wieder eine Fehlermeldung.
Hier die Fehlermeldung beim "Brennversuche". Building flash images... platformxn_a05328:12 Error: XN11004 Node node contains unknown attribute "Number". Error: F03023 Failed to load a target platform definition from input archive. Wenn ich die Firmware als XCoreApplication "Brenne" läuft es. Zum Flashen geh ich wie beschrieben vor: 1. Boardtaste A solange drücken bis die A-LED 3 mal kurz blinkt. Dann über die Software und write to Flash Memory speichern.
@ Thomas Burkhart Ich nutze den Amiga mittels Emualtion (WINUAE) noch immer bzw. habe ich den nie vergessen. Es ist eine sehr liebevolle am leben gehaltene Community. Es ist natürlich nichts wo man Geld machen kann, aber vielleicht kommt es ja auch mal zu einer neuen Programmierung dort deinerseits? ;-) Ich denke viele erinnern sich sicher an dich...meines wissens schloss an Cluster später sogar Assembler an.
Hallo Zusammen Ich bin ein Schweizer Student und mache meine Masterthesis mit 4 XC-2 Boards. Dabei bediene ich 40 SPI Funkmodule und nutze praktisch alle 336 I/O's - XMOS vereint die Vorteile von FPGA's und ASICS wesshalb ich mich dafür entschieden habe. XMOS hat eine tolle community, wo sehr viele Projekte drin sind (möglicherweise meines auch bald) http://www.xcore.com/ Ich habe heute eine Deutsch sprechende Gruppe eröffnet: http://www.xcore.com/groups/xcore-auf-deutsch Registrier dich noch heute - die Leute im Forum helfen extrem schnell. Wenn wir uns vernetzen gelingen alle Projekte viel einfacher! Leuchtende Grüsse Remo / http://www.pfunzle.ch
Nick Müller schrieb: > Mal ein Beispiel (Modbus-Interface): > Ich hab das auf dem Propeller (halbherzig) gemacht, wills aber auf den > XMOS umsetzen. Kannst du mal kurz abreißen, wie du Propeller zu XMOS siehst? Meiner Meinung nach sind beide nur Nischenprodukte und werden es auch bleiben. Für Bastler ist das aber kein Problem. An einem Vergleich beider wäre ich interessiert! Gruß - Abdul
Hallo Abdul Also wir haben an unserer Schule viele Projekte mit Propeller gemacht. Und aufgrund des super organisierten Supports von XMOS kann ich sagen, dass die in einer anderen Liga spielen: XMOS Semiconductor, ein erst zwei Jahre alter fabless Halbleiterhersteller aus Bristol in England, hat die neue Prozesstechnik mit der Bezeichnung „programmierbares Silizium“ (Software- defined Silicon) erfunden. James Foster, President, CEO und Mitgründer von XMOS, war zuvor CEO von Oxford Semiconductor und arbeitete davor u.a. bei Lattice Semiconductor in führenden Positionen in der Entwicklung und im kommerziellen Bereich. David May, CTO und ebenfalls Mitbegründer von XMOS, hält als Pionier der Parallelverarbeitung bis heute 33 Patente, wobei weitere anhängig sind. Noel Hurley, bei XMOS für das Marketing verantwortlich, kommt von ARM, wo er als Direktor für CPU-Produktmarketing für Definition, Vermarktung und Management neuer Produkte verantwortlich war. Quelle: http://www.elektroniknet.de/home/bauelemente/fachwissen/uebersicht/aktive-bauelemente/programmierbare-logikasics/programmierbare-chips-sollen-asics-fpgas-und-assps-abloesen/ Ich denke, da kann mann bestimmt nicht mehr lange von Nieschenprodukt sprechen... Gruss, Remo
Hallo , Ich will wissen wie man CAN-Dateien(8 Bytes) in einem XMOS einlesen kann ? gibt es ein vorgefertigtes Programm ? wie muss ich sonst vorgehen ? Ich möchte auch dass, diese 8 Bytes in sequenz von 4 Bits geteilt werden und zu einem anderen Core übertragen werden. Vielen Dank
Nach der Benachrichtigung für diesen Thread würde mich mal interessieren, ob die ursprünglichen Enthusiasten es immer noch so sehen. Was ist aus den Projekten geworden?
Wir verwenden ein XMOS-basiertes AVB-Interface-Board (http://www.dsp4you.com/products/avb-oem-series/avb-dg). Der XCore macht da 100 MBit Ethernet und 16 Kanäle I2S in Software. Das kostenlose AVB-Referenzdesign war Gold wert; entsprechende IP-Cores für FPGA kann man wohl nur gegen NDA und tausende Euro bekommen, und muss dann mit VHDL UND Code auf der Soft-CPU hantieren; da ist es mir viel lieber, alles in Quasi-C machen zu können. Die nötigen Anpassungen an die Firmware hat ein Student inkl. Einarbeitung innerhalb einer Woche geschafft. IDE und Debugger scheinen ausgereift zu sein und laufen unter Linux problemlos.
:
Bearbeitet durch Admin
Ich dachte XMOS währen die ehemaligen Inmos-Leute? Parallax ist dagegen im Wesentlichen eine one-man-show. Die Architektur beider Devices ist auch unterschiedlich. Gemeinsam ist nur dass sie mehrere Prozessing-Elemente haben. Ich sehe wenig Sinn darin, beide zu vergleichen. Ich finde das XMOS-Design auf dem Mikroarchitekturlevel übrigens sehr elegant und clever. Der Propeller kommt mir im Momment eher wie ein Hack-Job vor, aber vielleicht ist das neue Design ja besser. Habe auf der EW14 auch einen sehr guten Eindruck gehabt. Es waren dort sehr kompetente Leute, die Ihr Produkt auch erklären und verkaufen konnten. Man hat mir sogar eines der weniger Startkits gegeben. Werde mir heute mal die Zeit nehmen, die Software zu installieren.
:
Bearbeitet durch User
Andreas Schwarz schrieb: > Wir verwenden ein XMOS-basiertes AVB-Interface-Board Danke für den Erfahrungsbericht. Der ist was wert. Wobei mir die Einarbeitungszeit + Anpassung in einer Woche super schnell erscheinen. Muß ein Überflieger gewesen sein der Student. ;)
(zwar schon paar Jahre her) >Es sind bis 8 Threads pro Core, die ähnlich dem Hyperthreading diverser >Intel-Prozessoren arbeiten, Mehrere Threads kann ein Core aber nur dann machen, wenn bei nur 1 Thread die Recheneinheiten nicht komplett ausgelastet wären, also wärten müssten. Sind die Einheiten jeweils komplett ausgelastet, bräuchte er für mehrere Threads auch entsprechend mehr Zeit (also von daher nicht mehr Performance vorhanden).
MCUA schrieb: > Sind die Einheiten jeweils komplett ausgelastet, bräuchte er für mehrere > Threads auch entsprechend mehr Zeit (also von daher nicht mehr > Performance vorhanden). Architekturen, die Threads mit einem Register-Set pro Thread unter die Arme greifen, haben beim Thread-Wechsel schon Vorteile gegenüber Architekturen, die alle Register der Threads irgendwo im Speicher ablegen müssen. Und je kürzer ein Thread läuft, desto größer ist der Vorteil.
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.