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
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.
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:
// ----------------------------------------#define BIT_RATE 115200#define BIT_TIME XS1_TIMER_HZ / BIT_RATE
out port TXD = PORT_UART_TX;
void txByte(out port TXD, int byte) {
unsigned time;
timer t;
/* get initial time */
t :> time;
/* output start bit */
TXD <: 0;
time += BIT_TIME;
t when timerafter(time) :> void;
/* output data bits */for (int i=0; i<8; i++) {
TXD <: >> byte;
time += BIT_TIME;
t when timerafter(time) :> void;
}
/* output stop bit */
TXD <: 1;
time += BIT_TIME;
t when timerafter(time) :> void;
}
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...
>> 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:
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.
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.
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.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten