Kevéssé ismert, új technológiát jelent az XMOS cég xCore termékeiben lévő megoldás. Röviden:
Masszívan párhuzamos feladatokat lehet futtatni multicore környezetben. Ezt támogató XC nyelv a C kiegészítése, de verilog-hoz hasonló párhuzamos és szinkron, illetve időzítéstől függő leírásra is képes. Pár ns-es domainben reakció képes az eszköz. Igy nincs előre definiált funkció a lábakon, hanem szoftveresen alakítható ki minden. Jelenleg több profi audio készülékben használják.

A téma célja, hogy megosszuk tapasztalatainkat.

Az elmúlt 2 évben fejlesztgetek rá (korábban FPGA-ztam, PIC-eztem, ARM-eztem). Röviden leírok pár érdekességet.
A chip rendelkezik egy xLink/xConnect nevű busszal/protokollal, ami nem csak a tokozáson belüli magok, de kívül összekötött több ilyen chip között is kapcsolatot teremt. A fejlesztő környezetben az összekötött rendszert egyben látjuk. Pl esetemben 4 processzort, ami 4*8 darab független magot tartalmaz. Amikor a kódom forkol, a fordító olyan kódot készít, ami a párhuzamos feladatokat szétdobja külön magokra. Köztük ún. channel-en keresztül szálbiztosan kommunikálni lehet. Lényegében minden ki van elég jól találva, nem írom most le részletesen...

A fejlesztő panelekhez most egy csomó periféria kapcsolódik nálam. Színes lcd+touch panel, I2S hang, ADC-k, Ethernet, Wifi, keypad, midi port, rotary encoder. Ezek mind közvetlenül a cpu lábaira vannak kötve, ezen lábak mögötti funkciót pedig szoftveres IP blockok valósítják meg.
Mondjuk pl az lcd driver kódja XC nyelven van megírva, ami shifteli ki az RGB pixeleket szépen sorban (ez ugye elég nagy sebesség, mondjuk pl. pxa270-ben erre egy dedikált periféria van, dedikált lábakon). Mögötte lévő framebuffer, vagy karakter generátor is xc kód.
De ugyanígy a midi port uart blockja is le van programozva... A wifi modul spi-os, szóval van mögötte egy spi master block kód...

Ha valami még kell, és van szabad láb, akkor szoftveres feladat mögé tenni a perifériát... Ha elfogytak a lábak, akkor egy új xmos tokot lehet a designhoz tervezni, ezáltal újabb szabad lábakat és magokat adunk a rendszerhez... Ja igen, matematikai képesség terén: MUX acc 64 bit /core. XC-ből simán double-be, vagy longintbe lehet dolgozni vele, szóval ez kvázi egy DSP képesség. Elég durva...

A fejlesztési folyamat hasonlít egy olyan rendszerhez, ahol egy proci és fpga kombóval hozzák össze a speciális igényeket. De itt elég kiismerni egy fejlesztőkörnyezetet, az XC nyelvet.

Némi marketing bullshit van fenn : xmos application overview
Egy-két pro audio példa: Native Instrument - Traktor Kontrol S8 , és Focusrite - Scarlet 2i2 és 2i4.

Láttam nyomát, hogy a BME-n szóba került. Illetve itt is volt a fórumban 1 találat. Illetve pár ex kollégámmal beszélgettünk róla... Szóval nem egy tömeg termék, de hátha...

Örülök a topiknak, remélem felpörög. Én vagy fél éve vettem egy starter kitet + audio panelt, de még nem volt időm érdemben foglalkozni vele, csak a demókat próbáltam ki. Analog Devices DSP-kre szoktam fejleszteni, de a fejlesztőeszközeik irtó drágák és nem is túl jók, úgyhogy örülnék, ha legalább részben ki lehetne váltani ezzel...

Írtam valami szösszenetet az xmos architektúra és hagyományosabb mikrokontrolleres környezetek közötti különbségről:
xCore Architektúra

Illetve egy ideje van egy fb csoport is.
Magyar XMOS csoport

Szia
Köszönjük az információkat. Annyit kérdeznék hogy fizetős a c fordító,vagy a fejlesztő környezet?

xTIMEComposer Studio fantázia névre hallgató cuccból két verzió elérhető. Egy fejlesztői branch-be tartozó közösségi verzió, ami ingyenes, de nincs rá különösebb szupport, leszámítva a közösségi oldalt.
És van egy "céges verzió", ami pénzes, ahhoz fenntartanak Field application engineer-eket elvileg, valamennyi pénzes supporttal.

Lényegében egy gcc van mögötte, amihez készítettek xc nyelvet is fordító backendet. Plusz ez a csomag egy Eclipse IDE-t tartalmaz, pár olyan felülettel, frontenddel, ami a munkát segíti. Pl a statikus kód elemzőjuk XTA (timing analizer), xScope (ez kb egy analog scope, tracer cucc), illetve van egy signal tracer, ami kb egy wave view-erhez hasonlít. Debugger is, simulátor is.
xTIMEComposer Sutdio videó

Elvileg hw nélkül ugye szimulátorban lehet nézegeti a dolgot. Van egy 15usd körüli StartKit, és jópár developer kit, jtag/xlink adapter, stb..

Real time probe-ok bemutatása az xScope nevű eszközzel. Ehhez van egy lib, és az IDE oldali tool. jtag, soros port, vagy egyéb átviteli rétegen (pl ethernet) átküldött csomagokat tud megjeleníteni, tehát a kódot fel kell készíteni, probe-ok elhelyezésével, hogy mit szeretnénk látni. Lényegében mondjuk dsp szerű kód megfigyelésére hasznos, kb egy oscilloscope -hoz hasonló triggerelés, átméretezésre van lehetőség. Szimulátorral is megy.
xSCOPE videó
xScope másik videó
StartKit-en egy kicsi dsp kód, annak megnézésése xScope-on futás közben

Statikus kód analízis, XTA (x Time analizer) olyat tud, hogy az összes lehetséges futási útvonalat megjeleníti egy gráfon, pontos időzítéssel, avagy időzítési statisztikákat lehet kinyerni belőle.
XTA timing analyzer videó

Kihagytam az előbb, hogy vannak amolyan FPGA-s területről ismert Soft IP blockok, amire van egy kereső felület beépítve az Eclipse-be. Kicsi információ van a blockokról, pl port, szál, memória igény kapcsán. De ilyen blockokat le is lehet tölteni külön a közösségi oldalról, git repóból. Lényegében ezek lib-ek, vagy példa alkalmazások.
xSOFTip explorer videó

Angol előadás a Müncheni Electronica 2014 kiállításról. 50 perc alatt átfutják az architectúrát, tool-okat, xc nyelvet, startkit-et.
XMOS presentation at Electronica 2014 Munich

Elég hasznos, bár kicsit régi. Azóta említésre méltó még egy új család, az xCore-200, amiből szintén létezik általános, és speciális (usb2 phy, és gigabit ethernet rgmii-t tartalmazó) verzió. Ezek olyan kiegészítések, amik ki/be kapcsolhatóak, a kapcsolat jellemzően dedikált porton van megoldva. Illetve több sram memóriával rendelkező verzió is van, létezik belső flash-es blockot tartalmazó verzió is.

Sziasztok!

Épp most kaptam kézhez egy StarterKit-et. Nagy lendülettel le is ültem, hogy csináljak egy profi LED villogtatót, de sajnos megakadtam. Nem tudom feltölteni a FLASH-re a kódot...A JTAG emulátor drivere fel van telepítve, a win7 is korrekt működésről számol be, viszont az xTimeComposer-ben, a Run configuration menüben a programozó szekciónál nem látja a JTAG felületet. Tudtok erre megoldást ajánlani nekem? Eddig fórumokon csak annyit találtam, hogy másnál is volt már ilyen probléma

Az USB enumerációja körül akad valami baj. Egy környezeti változó hozzáadásával megjavult a dolog, sikerült a feltöltés:

XMOS JTAG probléma megoldás

Nem néztem utána alaposan, így egy kicsit megfoghatatlan kérdéseim lennének (ami késik nem múlik, csak gondoltam egy kérdést előbb megér). A chip-be integrált 1 megás SAR ADC-vel mik a tapasztalatok? Mennyire jó pl. az ENOB-ja vagy bármiféle jel/zaj viszony tapasztalatok, mennyire lehet kitekerni belőle az 1 megás mintavételi rátát (jó xmos oldali kóddal persze) , illetve mik a tapasztalatok a szinkronizált mérések esetén (valamiféle jitter)?

Szia, a starterkit-re anno lefordítottam egy projektemet és használtam az ADC-t. Abban az alkalmazásban nem volt kritikus a jel/zaj viszony. Egyéb okokból (sok csatorna) külső adc-t használok.
Az A8-as szériájú chipek datasheet-je: XS1-A8A-64-FB96
A 17.4 pontban van egy táblázat, a 33. oldalon:
Ez alapján a belső ADC karakterisztikája: csatornák száma: 4. Felbontás: 12 bit, ENOB: 10bit. Nem linearitások LSB értékben: DNL: -1..+1.5 INL: -4..+4. Egain: -10..+10 LSB.

Köszi a választ! Ez elég hasznos info volt így. Játékra, tanulgatni az XC nyelv lehetőségeit, teljesen jó lesz ez az ADC. Ha meg komoly dolgot kell csinálni, akkor úgyis majd egy külső konvertert kell mellé rakni.

Ahogy időm engedi, tanulgatom az XMOS-okat. A célom egy külső, párhuzamos ADC illesztése lenne a StartKit-hez, de kicsit megakadtam a strobed input értelmezésénél. A kód a következő:



Az adc_in egy bufferelt strobed input. Egy másik taszk birizgál egy kimeneti lábat, ami a kérdéses bemeneti port engedélyező lába. Az világos, hogy a port csak a strobe szignál magas értékénél olvassa a bemenetet, de a kérdésem az az lenne, hogy a "adc_in :> AdcDataBuffer[index++]" sor jól sejtem, hogy nem blokkoló típusú? Tehát nem rekedünk meg ott és várakozunk a port engedélyezettségére, hanem a folyamatos olvasással kiürítem a port FIFO-ját és utána 0-ákat olvasok, amíg nem jön egy engedélyezés a bemeneten?

Nem a kóddal volt a baj, hanem elnéztem a pin-eket és lebegni hagytam a strobe lábat. Viszont egy select-case default ággal szebb lenne a dolog, mert akkor nem blokkolná a while-t, mert mint utánanéztem a adc_in :> variable rész az bizony blokkoló típusú utasítás.

Egyre gyakrabban a képembe ugrik ez az Xmos és időm is volna rá. Volna valakinek javaslata, hogy miképpen is kezdjek el foglalkozni ezzel?
A programozás egyenlőre annyit jelent nálam, hogy 8 bites PIC-be írok mindenféle programokat, elég jók is, viszont ez már picit bonyolultabbank tűnik. Amúgy audio DSP lenne a cél, konkrétan saját aktív hangváltót készítenék vele, illetve nagyfelbontású kijelzőkre mennék még rá.

Hát a PIC után szemléletben lesz ugrás, az biztos, de pont ez benne a kihívás, meg az érdekesség szerintem.

Kezdésnek a StartKit-et ajánlanám, az olyan 4500 ft körül mozog. A többi panel már húzósabb azért, de lehet kapni kifejezetten audio-s dev. boardokat is, ha ez az igény.

Az XC nyelv lehetőségeit ez a doksi nagyjából összefogja. Nekem az a tapasztalatom, hogy azért igényel még google-t a dolog, de elindulni nagyon is jó:
XMOS Programming Guide

Illetve itt van egy rakat példa mindenféle dologra (debug, IDE dolgai, programozás):

Példák

Amúgy ha nincs board-od, akkor is érdemes lehet felrakni az XTime Composert szerintem, mert elég jó kis szimulátora van. Ha foglalkoztál már FPGA-kal, CPLD-kel vagy találkoztál már ilyesminek a fejlesztésével, akkor ismerős lesz a dolog.

Ez az, az FPGA is nagyon foglalkoztatott annó, de nincs ilyen irányú végzetségem, tapasztalatom és az nagy falatnak tűnt ahhoz, hogy a semmiből nekiugorjak. Időm van foglalkozni vele és a PIC után rájöttem, hogy azért érdemes lenne talán belekóstolnom, persze esélyes, hogy beletörik a bicskám...

Na mindegy, a start kitet amint tudom beszerzem, a többit pedig tanulmányozom aztán meglátom mi lesz, köszönöm a segítséget. Amúgy lehetséges, hogy "kapcsolatok" útján be tudok szerezni komolyabb board-okat is.

Már akkor fontam hajamat amikor kiderült, hogy java-ban írták, de akkor aztán pláne elment a kedvem az egésztől amikor a java telepítése után hibaüzenettel leáll... Saját architektúrájuk van és java-ban írják a szoftverüket, ki a frász ír bármit is Java-ra 2016-ban...

Szinte mindenki, aki platformfüggetlen fejlesztőkörnyezetet szeretne írni: Eclipse, NetBeans, Android Studio, Arduino IDE, Microchip MPLAB X, ...

Hiszed nem hiszed, igen komoly fejlesztések folynak Java területen. De ettől függetlenül én is utálom de nem kicsit.

Legjobb tudomásom szerint épp készülnek mindenhonnan kigyomlálni a java-t, mert egy bugos és könnyen támadható keret, akárcsak a flash.

Az lehet, de valamiért a programozó öcsém is java motort fejleszt a munkahelyén, és már oda jutottak az optimalizációval, hogy jobban fut egy java script, mint egy másik...

Sajnos nem efelé megy a világ, a "programozók" nagyon azt vallják, hogy mennyire jó a java, mert platformfüggetlen. Remélem egyszer benő a fejük lágya..

Érdekes, az internet közben attól harsog, hogy a korábban javat tanult programozókra nincs igény, mert már a kutya sem akarja használni és tanulhatnak új programnyelvet a programozók...

No mindegy is, kinek hogy sikerült működésre bírni az Xtime-ot? Ami java-t találtam felraktam, de mindegyiknél annyi történik, hogy kiírja mi nem stimmel, kezelhetetlen parancsot kap vagy micsodát és ennyi, egyszerűen nem indul el az xtime. Az MPLAB is java-s de benne van a futtatókörnyezet is legalább, így működik, persze bugos is rendesen.

Szia,
az xtime composer nem más mint egy eclipse. Csak egy IDE. Az összes parancssoros tooljuk native, amit Cdt-n keresztül hivogatnak. Lehet parancssorból is fordítani. Lényegében egy gcc (llvm) van kiegészítve. Szóval nem csináltak mást, mint a legelterjedtebb eszközöket használták fel.
Ha java runtime / telepítési anomáliák miatt nem megy a gépeden az xtime composer, akkor egy eclipse se megy.

Zárójelben: Utóbbi időben foglalkoztam ultimate++ környezettel is, ami eléggé minimalista c++ környezet (native, gyors). És van egy olyan közép-hosszú távú tervem, hogy abban a native cuccban (mivel a teljes forrása elérhető) ki kéne fejlesztgetni a szükséges képességeket, hogy az xmos -os toolokat jól kezelje. Momentán 0 időm van rá.

Több munkahelyemen, ahol beágyazott c, vagy rt linux környezet volt, a "szövegszerkesztésre" Eclipse volt a céges ajánlás. Nem szeretem a jávát én se, de hozzászoktam a felülethez. Nagyon sokat tud, csak pl visual studio után nagyon nem áll kézre semmi.

Ez a chip sokkal jobb, mint a Propeller chip? Nekem motorokat kellene vezérelni, léptetőmotorokat és szervomotorokat is többet egyszerre és közben tartani a kommunikációt több eszközzel is. Ezért kezdtem el nézegetni a párhuzamos végrehajtásra képes procikat. A Propellerben nem nagyon tetszik a SPIN nyelv és az interpreteres működés. Nagyon nem mélyedtem el még benne, de úgy látom, hogy az interpreter miatt lassú, ráadásul nekem kell gyors lebegő pontos számítás is, elég furcsán vannak ott ezek megoldva, jobban tetszene valami C alapú dolog, mivel abban más kontrollereket is szoktam programozni, PIC, Arduino, stb.

Nézegetem a gyári uart lib-et, azon belül is a uart_fast_rx.xc-t. A uart_rx_streaming(..)-ben találhatóak az alábbi sorok



A kérdésem az az lenne, hogy hogy kell értelmezni a pIn when... sort? Ha a pIn láb egyenlő 0-val, akkor? Elmentjük a port timer értékét a t-be? "int _ @ t" rész nem igazán áll nekem össze. Ha valaki elmagyarázná nekem, azt nagyon megköszönném.

xmos minden portja mögött egy szokatlanul bonyolult hw megoldás van, ami képes shift regiszterként láttatni a portot és/vagy időzített működésre is. A nyelv pedig a hw block felprogramozását, kezelését segíti.
Itt megnézhető ki tette hozzá az adott sort a git repo blame lekérdezésével, illetve egyben a file is olvasható:
github blame uart_fast_rx.xc

Ez a kód egy szálon fut, a kérdéses függvény a rész feladat főciklusa, ami egy while(1) -ben végtelenségig egy darab byte vételét valósítja meg. Csak a pIn bemeneti port hw közeli kezelése a feladata, tőle egy streaming channel segítségével lehet kiolvasni a vett byte-okat egy másik szálról (ahogy azok beérkeznek). A main loop startbitre való várakozással kezdődik, azaz a soron addig áll, amíg a láb nincs lehúzva gnd-re / nullára. Amikor ez teljesült a t lokális változóba elmenti a timestamp-et. (hw óra időalapja az adott core-on)
Később ez a t változó az idő mérésére szolgál, a következő mintavételünk időpontja lesz. A kód következő során 1.5 bit szélesség idejével növeli t + dt2. Feltételezésem szerint azért, hogy a mintavételezések ideje a stabil állapotokban legyen, ne a két élváltás időpontjában, hanem a kettő között.
Ezt követően egyébként egy 8 iterációjú ciklus van, ami a t-t mindig egy bitnyi szélesség idejével növeli. Ugye a startbit elejétől saját óránk szerint szinkronban mérve, ami azt jelenti hogy byte-onként rászinkronizálunk, de saját baudrátánk szerint mintavételezzük a lábat, elvileg a biteket reprezentáló időszeletek közepét mintavételezve. A ciklus végén a 32 bites data lokális változó tetején fentről lefelé sorakozik a 8 fogadott bit. Az MSB az utolsó minta, a 31-es biten, és 24-en a 0 bit, ami az időben első vett bit volt. A következő sor 24 bittel tovább shifteli, hogy az alsó 8 bitre kerüljön a vett byte. Majd beküldjük a cOut channelbe a vett byte-ot. Ezen a soron, ha nem volt korábban kiolvasva a túloldalon a korábbi itt kiküldött adat, leragad a futás, tehát fifo-zási képesség nincs a channelben, csak signaling a két szál között. Viszont ha szabad volt a channel, fut tovább. Ezután megint van egy @t -s port olvasás, tehát várunk a t időpont bekövetkezésére, de a port állapota nincs kiolvasva. data nullázása, majd loop eleje következik. Szóval a következő startbit low szintje előtt végigvárjuk az utolsó bit felét és egy fél bit (stop vagy start bit) idejét. A ciklus elején ha low-ban találnánk a lábat, akkor az már a startbitnek felel meg, amitől 1.5 bitre várjuk a következő bit0 közepét.

Apróbetűs rész az uart-ról: Ha jól sejtem a bit7 (nyolcadik data bit) után több mint fél bit szélességgel kell lennie egy magas állapotnak (stop bit), hogy a következő start bit elejére szinkronizálni tudjon, különben hosszútávon elcsúszhat a mintavételezések helye, ha a baud rátából adódó clock nem pontosan egyezik, stb... Kicsit egyszerű kód, ezért fast a neve. Csak 8N1 : 1 startbit, 8 databit, no parity bit, 1 stopbit beállítású küldő jelén működik jól. Gyakorlatban 9.5 bit-es ciklusidő a legrövidebb byte vételi idő. Valahol olvastam a neten erről egy ábrákkal tűzdelt leírást. A lényeg, hogy eltérő túloldali implementáció lehet, az ottani időalap is eltérő lehet. A hiba csökkentése érdekében egy jól megválasztott baud ráta szükséges. 9<(Ttxbitrata*9.5 / Trxbitrata)<10 amiből adott baudra számolható, hogy mondjuk például max +/- 5.2% eltérés tolerált.

Rövidebben a válasz:
a :> bal oldalán minden szükséges előfeltétel szerepel: mivel és mikor.
a :> jobb oldalán a tevékenységek: tároljuk a port értékét és timestampet (opcionális).

{port név} when {feltétel} :> {változó} @ {időpont változó}. Vár a feltételre, elmenti a port értékét, tárolja az időpontot is.
{port név}@{időpont feltétel} :> {változó}. Vár az időponton való áthaladásra, a port értékét tárolja a változóban.
Ha a változó helyén "int _" van, akkor a port értéke nem érdekel minket, nem mentjük sehova.
Ha a változónál >> shift operátor van, akkor shiftelve tárolja.

Köszi a kimerítő választ! Lehet, hogy túl egyszerűen fogalmaztam, de ennyire azért nem vagyok elveszve, csak az "int _" résszel nem találkoztam sosem még. Jól sejtem, hogy az alábbi sor jelentése ugyanaz?