mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik XMOS jemand?


Autor: Nick Müller (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nick Müller (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: doofi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nick Müller (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Jakob (antibyte)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei Sparkfun gibts für 33 Euro ein X-Mos Board :

http://www.sparkfun.com/commerce/product_info.php?...

Bin mir aber nicht sicher ob man jeden beliebigen JTAG-Programmer nutzen 
kann.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nick Müller (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nick Müller (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Nick Müller (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nick Müller (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nick Müller (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nick Müller (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nick Müller (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Alejandro P. s. (ale500)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Nick Müller (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Alejandro P. s. (ale500)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Dummfrager (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
 t :> time;
   
  TXD <: 0;

wenn ich mal nachfragen darf, was bedeuten diese beiden Zeilen?

:> und <: kenne ich nicht in C

Autor: Alejandro P. s. (ale500)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weil nicht C ist. Es ist XC.

:> = lesen von port
<: schreiben an port

Autor: XMOS ?! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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 !!!

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1600 MipS, wenn ich mich nicht täusche. Da dürften die Atmels ein 
Problem haben...

Autor: Nick Müller (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: XMOS ? (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Nick Müller (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Nick Müller (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: XMOS ? (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
void Thread_1_SPI()
{
  if (Data.Available() == true)
  {
      SPI.Data.ready = true;
  }
}

void Thread_2_Display()
{
  if (SPI.Data.ready == true)
  {
      Display.ShowData(SPI.Data.GetPtr(), SPI.Data.GetLength() );
  }
}

// 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ß :)

Autor: Nick Müller (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Nick Müller (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
[räuspern]
hust
[/räuspern]

Autor: Nick Müller (muellernick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Berny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dave B. (gaston)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ....

Autor: ongaku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Berny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Berny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ted (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Remo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Remo Riztmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/fachw...

Ich denke, da kann mann bestimmt nicht mehr lange von Nieschenprodukt 
sprechen...

Gruss, Remo

Autor: IP0 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Tim    (cpldcpu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;)

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(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).

Autor: Konrad S. (maybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

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

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.