XMOS xCORE

[prasimix]

EDIT: postaviti ću ovdje vremenom linkove na informacije koje smatram da su korisne (app note, PDF knjige, diskusije na drugim forumima, itd.)

• Douglas Watt: Programming XC on XMOS Devices (PDF knjiga)
  
• XMOS programming guide
  
• XC specification (The layout of this manual and portions of its text are based upon the K&R definition of C. Commentary material highlighting differences between XC and C is indented and written in smaller type.)
  
• Xcore Open Source Repository Index
  
• Lista podržanih flash memorija u libflash
  
• XMOS startKIT: Introduction, Terminology/Architecture, Getting Started and Example Programs
  
• Opis strukture XN config file preko kojega su opisane XMOS eval. kartice za xTIMEcomposer IDE odnosno putem kojega se može definirati i vlastita. Tu se određuje i korišteni MCU, čiji je pinout definiran u .pkg fajlu. Npr. XS2-UEnA-512-FB236.pkg za xCORE-200 eXplorerKIT.
  

*****************

XMOS MCU-ovi su u više navrata spominjani u raznim temama na forumu. Možda je dosad najznačajnije ono što je mikikg startao od #187 u STM32 generic board temi. Vjerujem da će se o XMOSu još pisati, pa otvaram novu temu jer i sam imam pitanja čiji se broj naravno počeo povećavati kako sam krenuo pregledavati što XMOS nudi.
Inače trenutno tražim što uzeti kao sljedeći MCU jer korišteni Arduino Due je slijepa cesta, i u dilemi sam da li nastaviti s nekim jačim ST sa RGB grafičkim kontrolerom (npr. STM32F746 kao što postoji na STM32F746G-DISCO eval. ploči) ili krenuti put XMOS-a. Ovo govorim u ime dvojca, kolege koji bi se trebao prebaciti najvjerojatnije na novi IDE (xTIMEcomposer) i mene koji bi trebao skrpati neku prvu verziju eval. ploče.

XMOS nudi (preko distributera) svoje eval. ploče od kojih je najjeftinija XK-STK-A8DEV i koju ću nabaviti čim ponovno bude dobavljiva (ako se ne odlučim na nešto jače). Šema spomenute ploče se nalazi u ovom dokumentu (str 15 i 16). Na samom početku spomenuta dokumenta stoji da korišteni MCU dolazi samo s tom pločom i da zato nije posebno dokumentiran, ali se korisne informacije mogu dobiti u DS-ovima od XS1-U16A-128-FB217 (ima USB PHY) i XS1-A8A-64-FB96 (nema USB PHY).

Pretpostavio bih da XK-STK-A8DEV radi "out-of-box": spojiš se USB-om i uploadaš svoj firmver u eksterni SPI Flash (na ploči, nije u MCU). Da li je to stvarno tako? XK-STK-A8DEV ima mikro-USB na koji kaže da se spaja host debugger/JTAG. Upload firmvera moguće je napraviti iz komandne linije sa XRUN aplikacijom ili preko spomenuta xTIMEcomposer-a. U XRUN dokumentaciji kaže da je potrebno instalirati XMOS-ov ili FTDI USB-to-JTAG driver, pretpostavljam za neki hardverski debugger/JTAG adapter (recimo njihov xTAG v3.0). Prvo sam se upitao da li je mikro-USB konektor uopće za USB ili za debugger adapter. Ispada po šemi da je stvarno USB jer linije vode prema pinovima USB_DN, USB_DP.
Nadalje ploča ima i XSYS link na koji se može kačiti debugger preko 20-pin IDC konektora. Možda se primarno preko njega radi upload firmvera, što je indirektno preko USB-a jer se USB kabel kači na debugger/JTAG adapter, a onda on na XSYS link konektor. U dokumentaciji od xTAG v3.0 adaptera nalazim informaciju da isti dolazi sa svim eval. pločicama osim za XK-STK-A8DEV (xCORE startKIT). Ako je to tako, onda znači da je XK-STK-A8DEV sama po sebi nefunkcionalna.
Čitava ova priča se svodi na sljedeće: ako sutra XMOS-ov MCU bude u nekom uređaju i istom treba mjenjati firmvare, kako to napraviti? Uvođenje novog malog MCU koji će biti most između USB i flash memorije mi se ne čini praktičnim, jer i on ima neki firmver koji treba uploadati, itd. Postoji li neka druga opcija?

[prasimix]

Skinuo sam i pokrenuo zadnju verziju xTIMEcomposera na 64-bitnom Ubuntu 16.04. Umjesto slova dobio sam kvadratiće, kao da font nije podržan. Pronašao sam da i drugi ljudi imaju s time problema što je opisano ovdje. Tamo se spominju komentiranja ove i one linije. Najjednostavnije je otvoriti spomenuti bin/xtimecomposer i zakomentirati za korištenu linux distribuciju sljedeću komandu:

Code:

$ENV{LD_LIBRARY_PATH} = "$installpath/xtimecomposer_bin/swtbrowserlibs:$ENV{LD_LIBRARY_PATH}";

Za različite Ubuntu verzije to bi bile linije 131, 137 i 144.

[mikikg]

Ako je to tako, onda znači da je XK-STK-A8DEV sama po sebi nefunkcionalna.
Čitava ova priča se svodi na sljedeće: ako sutra XMOS-ov MCU bude u nekom uređaju i istom treba mjenjati firmvare, kako to napraviti? Uvođenje novog malog MCU koji će biti most između USB i flash memorije mi se ne čini praktičnim, jer i on ima neki firmver koji treba uploadati, itd. Postoji li neka druga opcija?

U sustini da, taj konkretan model procesora ne prodaju posebno, nemaju sem tog na toj plocici ni jedan drugi MCU sa A/D konverterom koji je iskreno delimicno upotrebljiv.

XMOS su malo specificni kontroleri, nema periferija kao kod STM i ostalih, ima samo GPIO modul koji je malkice bolje (zbog brzine) organizovan i sve ostalo je SOFTWARE, sve je bit-bang programski uradjeno, od USART do USB i ETH.
On ima 16 jezgra, pola od toga oni iskoriste i naprave JTAG USB adapter, ostane ti 8 za tvoju aplikaciju i sve moras da odradis sa njima preko programa sa raspolozivim I/O nozicama.
Takva postavka samo po sebi namece i upotrebu, XMOS je zgodno resenje kada nemamo puno "sharenih" prikljucenih periferija vec svega par gde svu ostalu procesorsku snagu mozemo da fokusiramo i skoncetrisemo na vrlo zahtevne zadatke koji trebaju da se odraduju brzo i sinhrono.

Sledece opcija je izbacivanje njihovog JTAG (SW) interfejsa i preuzimanje sad tih 8 jezgra pod nasom kontrolom ako nam to aplikacija dopusta.

Dakle jedna te ista MCU jezgra samo ih iskoriste u letu kako im treba, kombinuju debuger funkcije sa aplikativnim funkcijama i to je samo primer kako ta jezgra mogu da se upotrebe, ne trebaju nikakvi "medju" IC ili MCU da nesto sa njima pricaju, samo je stvar dobro postavljenog sistema i aplikacije, valjda sa 16 jezgra mozes da se izboris? : ) Malo je tu problemcic sa RAM memorijom jer svi moraju da dele isti prostor ali da se to sve organizovati.

Oko FLASH memorije za program, na spomenutoj StrartKit plocici je tako odradjeno jer taj model kontrolera nema FLASH u sebi, drugi modeli njihovih kontrolera imaju normalno interni Flash i RAM

[prasimix]

Dobro je što si spomenuo i debugging. Znači u slučaju startKIT/XK-STK-A8DEV ploče korišten je 16-core MCU od kojih je raspoloživo/vidljivo 8, jer se drugih 8 koristi za debugger. U slučaju XMOSa to je puno više od debuggera jer isti nudi XScope Logic Analyser za real-time neintruzivno monitoriranje stanja što je prezentirano u ovom videu:

https://www.youtube.com/watch?v=AOqdCBeukwE

Meni je 8 jezgri dovoljno (zasad ). Ali, ako sam dobro razumio ako se koristi taj xTAG (vanjski debugger adapter) i ako se izvede XSYS Link (20-pin IDC konektor, nema ga na StartKIT) radi istu stvar bez da troši MCU jezgre, dakle ako izaberemo MCU sa 16 jezgri sve stoje na raspolaganju, a kada se radi development/debugging onda se samo prikači xTAG. On na sebi ima 8-core MCU koji koristi XConnect link (koji je na spomenutom XSYS link konektoru) za brzu komunikaciju između više MCU.
Što se tiče ugrađene funkcionalnosti koja ne prati moćne MCUove, pa kao što kažeš sve to moraš u softveru da rješavaš, ne vidim problem. Libovi za najvažnije stvari već postoje: USB, brzi eternet, TFT RGB, LCD, GPIO, I2C, CAN, SPI, serial, itd. Ostaje ipak i dalje pitanje kako osigurati "user-friendly" in-field firmver upgrade bez da se korisnika tjera da nabavlja xTAG ili slična funkcionalnost dodaje u dizajn. Ovo vidim kao problem bez obzira ima li izabrani MCU flash ili se koristi eksterni. Prvi upload ("tvornički") nije problem, može se između ostaloga osigurati tako da se MCU gurne u RESET (kada je sve Hi-Z) i direktno pristupi flash čipu recimo sa SOIC8 test adapterom kakvih ima na eBayu (link) i napravi prvo programiranje. Ima i druga mogućnost, da se multipleksira SPI koji ide na flash i za potrebu uploada SPI bus dovede "izvana". Svakako bi htio izbjeći uvođenje dodatnog MCU-a koji mora imati svoj firmver da bi glumio SPI master za upload firmvera. Pada mi na pamet recimo USB-to-SPI bridge poput MCP2210. Za njega bi trebalo onda samo napraviti neku PC aplikaciju, ali u tome ne vidim veliki nezaobilazan problem.

[Macola]

Šteta što ne učismo Forth:

http://www.greenarraychips.com/home/products/

[mikikg]

Za bootloader i ostale stvari koje su vezane za in-field nadogradnju, u sustini opet ista prica, mozes da odvojis neko jezgro samo to da radi, izaberi interfejs, obcian seriski RX/TX (mozda zgodnije za WiFi/BTLE extenziju) ili USB/LAN, osmisi neki protokol ili mozda to sve vec ima gotovo kako se to sve moze odraditi.

Ja samo znam da kod ozbiljnih masina koje imaju te opcije da moze da se upgrejduje firmware obicno imaju dve posebne FLASH memorije, jedna radna i tu se sve snima i jedna za Backup koja moze da se vrati u slucaju da predhodni updejt nije bio dobar (kombinacijom nekih tastera/jumpera pri boot itd).
Ako se to "kolo" funkcionalno dobro osmisli i zatvori, onda mozes da se oslonis na SW procedure za upgrejd firmwera i korisniku nije potreban specialan programator da to odradi.

Povoljnije je da se stavi jos jedna FLASH memorija za Backup i da se osmisli robustan sistem za upgrejd sa zastitom od "brikovanja/zakljucavanja" sprave od strane korisnika nego komplikovati sa programatorima i cime vec. Ovo sa dve memorije nije nista novo, to se odavno koristi u PC svetu na maticnim plocama, setite se "Dual BIOS" maticnih ploca, to je bas to a vidjao sam i na industriskim Embeded resenjima nevezano za PC.

I naravno postoji kombinacija sa FLASH memorijom ali druga da bude FRAM jer ce vam on trebati pa trebati : ), i tu da se malo manipulise memoriskim prostorom, raspodeli se tamo-vamo sa sve Backup prostorom, "vecim" u Flash i "manjim" u FRAM i tu se cuvaju SVE adrese, vrednosti, firmware i najbitnije korisnicka podesavanja tj parametre koja su korisniku najbitnija, ovo ostalo ga u sustini ne interesuje, njega interesuje da mu ostanu sva podesavanja pre ili posle ili kad god nakon updejta firmwera i to da ima ceo set podesavanja backupovanih pod nekim imenom, MyConf1, MyConf2 i tako dalje.

Dakle potpuno isti princip se "mazne" sa PC platforme i maticne ploce, oni imaju SRAM sa baterijom i FLASH, ovde kod nas sa MCU imamo FRAM i FLASH i ne treba vam vise nista od toga, osim SRAM ako krenete u graficke vode, mada realno, u onaj PCI slot na XMOS StarterKit moze da se ubode i citava PC graficka kartica i to da biras od 20E do stotine Eur za graficke od 4-6-8-10GB DDR4/5 RAM memorije, imaju 2 DVI i 4 HDMI izlaza, imaju snage za "kalkulaciju" da se smrznes, kakav crni FFT, to moze da radi hiljade ili milione FFT-ova u realnom vremenu, to je tako surova procesorska snaga spakovana za graficke potrebe da je to nenormalno, i sto je je najludje to moze da se iskoristi za sve i svasta i koriste ljudi za sve i svasta!!!

---

Poenta je ako se dobro osmisli sistem i sastavi iz jedne ili vise "pametnih kockica" i sav ostali HW samo da se svede na buffere i opto izolatore, bez ikakve specificne externe logike sa expanderima, shift registrima ili slicno, i ako su sve te kockice spojene na red u recimo JTAG lanac onda je ceo sistem prakticno in-field programibilan i rekonfigurabilan do najsitnijeg detalje logike koja mozda sad postoji ili koja ce tek biti implementirana i sa XMOS resenjem to je skor rekonfugurabilno kao sa FPGA varijantom, naravno sa nekim ogranicenjima, ali generalno za taj nivo integracije trenutno nema bolje resenje a da nije CPLD ili FPGA.

[mikikg]

Dodatno moram da vam skrenem paznju na jos jedan zanimljiv detalj koji se tice XMOS i StarterKit plocice, PCI-E x1 slot/konektor!
Eh, sta sa njim?

Ako se malo samo zaokrene pogled na stvari, konkretno za 90* : ) dolazi se do jednog vrlo finog i povoljnog resenja a to je da niko nama ne brani da koristimo PCI-E konektore za bilo kakvu drugu elektroniku.
Sam konektor je odlican i prilicno robustan, povoljan, ima par puta gusci footprint na istom prostoru nego ICD-10 i slicni i sto je najlepse drugi deo konektora je sama plocica koja se ubada u slot i kada realno sagledamo stvari, uz nekoliko PCI-E slotova i nase "mother board" sa bilo kojim izabranim kontrolerom mozemo da napravimo vrlo vrlo zanimljivu i prosirivu platformu razlicitog HW-a, posle samo kockamo PCI kartice po potrebi, ulazi, izlaz, drajver itd, nikakva specialna nauka, cak moze vecim delom i da se zadrzi PCI-E specifikacija rasporeda nozica jer se tacno uklapa u to sto treba, napravljeno je za to : )

[prasimix]

Dodatno moram da vam skrenem paznju na jos jedan zanimljiv detalj koji se tice XMOS i StarterKit plocice, PCI-E x1 slot/konektor!
Eh, sta sa njim?

Ako se malo samo zaokrene pogled na stvari, konkretno za 90* : ) dolazi se do jednog vrlo finog i povoljnog resenja a to je da niko nama ne brani da koristimo PCI-E konektore za bilo kakvu drugu elektroniku.
Sam konektor je odlican i prilicno robustan, povoljan, ima par puta gusci footprint na istom prostoru nego ICD-10 i slicni i sto je najlepse drugi deo konektora je sama plocica koja se ubada u slot i kada realno sagledamo stvari, uz nekoliko PCI-E slotova i nase "mother board" sa bilo kojim izabranim kontrolerom mozemo da napravimo vrlo vrlo zanimljivu i prosirivu platformu razlicitog HW-a, posle samo kockamo PCI kartice po potrebi, ulazi, izlaz, drajver itd, nikakva specialna nauka, cak moze vecim delom i da se zadrzi PCI-E specifikacija rasporeda nozica jer se tacno uklapa u to sto treba, napravljeno je za to : )

Da, i tako dolazimo do teme koju sam u međuvremenu zanemario, ali ne i odustao, a to je DIY backplane (ili DIB od DIY Instrumentation Bus) . Tema mi se aktualizira upravo zahvaljujući tvojem dosadašnjem pisanju o XMOS-u. Čitava stvar bi se sada mogla organizirati kao "star" topologija između jednog xCORE MCU i brze serijske konekcije prema periferijama. No, o "pinoutu" budem nešto rekao u već započetoj temi s gore navedenog linka.
Kada smo kod pinouta ili toga što se koristi na fizičkom konektoru htio bih obratiti pažnju na to da PCIe X1 kojeg susrećemo unaokolo nema isti pinout kao XMOS, evo usporedne slike (izvor, wikipedia i XMOS StartKIT hardware manual):



Ne treba gledati dalje od prvih par pinova gdje se nalazi +12V na PCIe, dok XMOS uopće ne koristi taj napon. Isto tako, na osnovu moje dosadašnje informiranosti, mislim da ubacivanje standardnih PCIe kartica u priču traži neki hardverski i/ili softverski PCIe bridge što je zahtjev koji poziva na angažiranje elitnih snaga s ovog foruma!
Naravno, ako se apetiti u prvih par koraka smanje, onda bi se moglo nešto započeti na osnovu XMOS pinouta, ali i tu treba uzeti u obzir da oni imaju njih nekoliko, evo citata s ovog linka za njihove sliceCARD:

Star and Square sliceCARDs have 20 xCORE I/Os including four 1-bit ports.
Triangle sliceCARDs have 24 xCORE I/Os including twelve 1-bit ports.
Circle sliceCARDs have 20 xCORE I/Os including twelve 1-bit ports.
A double sliceCARD is a board with two sliceCARD finger connectors and connects to all of the I/Os on one Tile (e.g. to Star + Triangle or to Circle + Square.)

Moram tek doći do toga što im u stvari znače ti n-bitni portovi, jer vidim da se stalno spominju 1-, 4-, 8-, 16- i 32-bitni.
Kada se ne bi koristila PCIe komunikacija (kod koje ovisno od revizije govorimo o x1 brzinama transfera od 250MB/s do 3938 MB/s) XMOS predlaže u app noti 01024 korištenje xCONNECT linka za "lagani" bus pa kaže:

xCONNECT is a proprietary interconnect technology that facilitates data communication across different xCORE to create a fully scalable system. It is possible to achieve high bandwidth communication of up to 400 Mbits/sec for each xCONNECT link making it suitable for things like light weight industrial back-plane busses. No additional hardware is required for the xCONNECT communication.
Using xCONNECT over longer distances can introduce bit errors due to noise, xCONNECT is dependent on the application layer to recover from such communication errors. This application note demonstrates handling of transmit timeouts, receive timeouts and receive exceptions (e.g. unexpected control tokens) using software to ensure robustness of the communication.

Ovo je korektno rečeno jer 400 Mbits/s prema početnih 250MB/s PCIe x1 zaista izgleda lagano, ali to što ne zahtjeva dodatni hardver (bridge) zvuči zgodno, no trebalo bi razmisliti što bi to stvarno značilo u komunikaciji sa određenim periferijama (u prvom redu sa hi-speed ADC, DAC). Je li to dobar kanal za hi-speed SPI? Možda odgovor leži u app noti 01021 (trebam to pogledati). Opet, pitanje je kako bi se u slučaju našeg "mother boarda", kako kažeš, neke stvari mogle poslagati: možda po bus-u i ne bi trebalo ići ništa brže od 400 Mb/s, tj. da zahtjevne kartice imaju sve na sebi: xCORE, ADC, memoriju i DMA funkciju, a po bus-u ide samo "prezentacija" i master kontrola sa centralnog MCU koji je i spoj sa vanjskim svijetom (USB, eternet, wireless, itd.).

[mikikg]

Bas tako, po jedan kontroler na PCI-E konektor sa strane plocice i tu se lokalno sve resava u vezi jedne funkcionalnosti, na primer 8xIN kartica, 8 x OUT kartica sa kontrolom greske i raznim jos lokalnim stvarima, STEP/DIR ili PWM izlaz, Enkoder ulaz, ADC/DAC, pa onda pod serije tih kartica koje mesaju sve po malo i tako redom.

Takvu platvformu smo pravili u bivsoj firmi, taj model (kartica sa jednom funkcijom na vise kanala) je i dalje aktuelan i kao sto ti sad kazes aktuelizuje se sa pojavom ove XMOS price gde sad mozemo da biramo kako da se odradi sve ali jedno je bitno, ljudi su na ovom PCI-E izveli nekoliko bitnih stvari a to su, napajanja, zatim selekti za same kartice (zbog automatskog prepoznavanja tipa kartice, ima shirih PCI-E slotova x2,4,8,16), zatim je tu komplet nekoliko RESET linija, tu je dalje JTAG interface (prelepo!), zatim SMBUs koji tek "treba" da istrazimo ali i to je ozbiljan i koristan standard i na kraju 3 parice, LVDS nivo diferencialni i to jedna za TX, jedna za RX i jedna za CLOCK i to "napredni" jer se radi 10b/8b kodiranje ili za novije PCI standarde v3 120b/130b da bi smanjili efektivno EMI zracenje i jos dodali neku robustnost u smislu da se periferija "ne zagubi" u brojanju clocka nego ima patern za sinhronizaciju. Ozbiljne su to price ali i ne nedostizne jer je sam fizicki prenosni nivo totalno OK i prihvatljiv za upotrebu, LVDS tranceiveri mogu da se nasviraju na mnogo Gbit/s i to je odlicna platforma, sta je u samom protokolu e to je muka, mozemo da osmislimo nase ili da prihvatimo XMOS ili da se uhvatimo PCI standarda zasta mislim da trenutno nije prikladan u MCU domenu jer je previse zahtevan.

Dokle god imamo programibilne strane tih konektora i samih konekcija mozemo da se izborimo i mozemo da konfigurisemo celu platformu u letu, samo je bitno da se izbegnu digitalne IC komponente sa staticnom funkcijom.

Cak i sam koncept "mother board" nije moranje, ako se ide na varijantu rec kutije ili nesto slicno tome onda je procesor ustvari samo jedna od kartica dok je BUS back-plane unificiran i "prazan". Cim zafale "resursi" moze da se ide na sledeci veci PCI-E konektor x2, ili x4.

U "neka doba" ako zafali procesorske snage, heh, niko nam ne brani da spakujemo PC ili SoC platformu u tu nasu PCI-E karticu i da sve ostalo mozemo da zadrzimo i da budemo na nize kompatibilni.

[prasimix]

Da, "mother board" koncept je manje atraktivan/fleksibilan od praznog/glupog backplane. "Glavni" (ili u nekim varijantama možda i jedini) MCU trebao bi biti isto na kartici. Ako bi se koristila "automatika" xCONNECT linka (koji je bazno podržan od XMOSa) i sa druge strane se striktno pratila PCIe pinout specifikacija, onda bi trebalo napraviti neke konverzije jer na PCIe imamo diferencijalni CLK, Tx i RX (ukupno 6 linija) dok je to kod XMOSa 10 linija (po 5 za TX i Rx). To već samo po sebi komplicira stvar. Isto tako ako bi se želio pratiti PCIe standard onda i PCB konektor mora biti fiksiran na određenoj udaljenosti od kraja karice (to je manji problem).

Zaključno mislim da je trik upravo u programabilnosti konektora koju spominješ. Trebalo bi im fiksirati samo osnovne stvari (napajanje, backup/aux napajanje, sistemski reset i clk) a ovo ostalo bi trebalo biti "floating". Čini se da su recimo u VXI standardu (iz vremena paralelnih bus-ova) ovu fleksibilnost htjeli postići sa cross-point matrix čipovima (recimo 8 x 8) što ako su analogni ima smisla jer bi omogućilo miksanje i syncanje signala između više kartica (analognih i digitalnih). U slučaju jednog XMOS MCU po kartici ta bi se funkcionalnost mogla ostvariti softverski, sam "switch" (duduše samo digitalni) bio bi u MCU. Ako nam treba i analogni cross-point matrix doda se (recimo jedan Rx/Tx par po kartici). Naravno ovo su sve moja trabunjanja koja bi tek trebalo potvrditi.

[prasimix]

Evo još malo: zbog lakšeg praćenja, razumijevanja i fokusiranja pokušao sam široku ponudu raznih MCU-ova suziti na kandidate za hipotetički prvi prototip. Prvo malo o nazivima. Evidentno je XMOS pronašao jaku "nišu" u hi-end digital audio sklopovima u kojima je vjerujem po nekim stvarima i dalje vodeći, pa je onda i jasno da se audio gura u prvi plan. Na to mu se nadovezuje voice processing. No, za nas je više zanimljivo nešto generalnije, odnosno nešto što onda i uključuje podršku za isto tako generalnije komunikacijske kanale poput USB i eterneta. Dakle, zanemartiti ću u ovom postu sve audio/voice modele kod spadaju pod xCORE VocalFusion XVF3000, xCORE-VOICE XVSM-2000 i xCORE-AUDIO. U tom slučaju nam ostaju grupe xCORE-200 i XS-1. Potonji ima četiri podgrupe: xCORE-U, xCORE-E, xCORE-L i xCORE-XAU gdje je -XAU kombinacija sa Arm MCU. Ta je linija prva otpala, a isto će se uskoro dogoditi i za preostale iz XS-1 grupe.
xCORE-200 se bazira na XS-2 tehnologiji koja je nasljednica XS-1 i osnovna razlika se može svesti na sljedeće (za više detalja vidi XMOS XS2 Architecture Manual):

• Dual issue
  
• 64-bit load and store
  
• High priority threads
  

xCORE-200 ima tri podgrupe: Ethernet (Gigabitni!), USB i General Purpose, što kada dođemo do oznaka za narudžbu čini 6 grupa zato što MCU iz jedne grupe može doći u dvije varijante: sa i bez flash memorije. Oznaka MCU se sastoji od sljedećih elemenata:

X [U/E/L] - 2 - broj logičkih jezgri - memorija - vrsta pakovanja

U = USB PHY
E = Ethernet RGMII
L = General purpose
Broj logičkih jezgri može biti 8, 10, 12, 16 ili 32 (XS-1 je startao sa 4 logičke jezgre)
Memorija je 128, 256, 512 ili 1024 kB
Pakovanja ima raznih (TQ 128-pin, FB 236-pin, FB 374-pin)
Ukupna procesorska snaga ide od 1000 do 4000 MIPS.

Pretraga na DigiKey-u (koji je pored Farnell-a jedini veliki dobavljač) za xCORE-200 koji nisu u zastari (obsolete) vraća trenutno 162 tipa. No, po meni izbor je ipak manji, zato što se ne želim mučiti sa QFN i BGA izvedbama. U tom slučaju izbor pada na "samo" 83. Ali, i to se može dalje suziti ako se ne želi škrtariti na pinovima pa se izbace iz pretrage 48- i 64-pinske izvedbe. Tada ostaju 128-pinske kojih još uvijek ima 68 . Nažalost, u većini slučajeva minimalna količina je 90 komada, što zove na GB (ili crowdfunding!). Ipak, postoji i oni koji su dobavljivi komadno: njih čak 8. Nasreću, među njima su i dva ozbiljna: XE216-512-TQ128-C20 što će reći 16 logičkih jezgri, 512Kb memorije, bez flesha, odnosno varijanta sa flashom: XEF216-512-TQ128-C20. Treba znati da XE (eternet) varijanta ima i USB.

Zanimljivo je kako se troše portovi i alociraju fizički pinovi kod ovakva MCU kada se aktivira eternet, USB ili xCONNECT link-ovi. xCONNECT link troši po 10 linija (5 x Tx, 5 x Rx), kod najjačih modela njihov ukupan broj je 8, a kod izabranih efektivno bi se mogla, kako vidim, koristiti dva: link4 i link7. U prilogu stavljam editiranu tablicu koja je skinuta odavde, a iz koje sam izbacio sve što nije relevantno za izabrane MCU. Na softverskoj strani dosad sam pronašao da Ethernet MAC traži čak 8 logičkih jezgri za gigabitni link, dok su za 100Mbitni dovoljne dvije (odnosno 4 za real-time link). TCP/IP troši jednu, i ako se želi web server to je još jedna. USB lib također troši jednu logičku jezgru.

[prasimix]

Za bootloader i ostale stvari koje su vezane za in-field nadogradnju, u sustini opet ista prica, mozes da odvojis neko jezgro samo to da radi, izaberi interfejs, obcian seriski RX/TX (mozda zgodnije za WiFi/BTLE extenziju) ili USB/LAN, osmisi neki protokol ili mozda to sve vec ima gotovo kako se to sve moze odraditi.

Ja samo znam da kod ozbiljnih masina koje imaju te opcije da moze da se upgrejduje firmware obicno imaju dve posebne FLASH memorije, jedna radna i tu se sve snima i jedna za Backup koja moze da se vrati u slucaju da predhodni updejt nije bio dobar (kombinacijom nekih tastera/jumpera pri boot itd).
Ako se to "kolo" funkcionalno dobro osmisli i zatvori, onda mozes da se oslonis na SW procedure za upgrejd firmwera i korisniku nije potreban specialan programator da to odradi.

Povoljnije je da se stavi jos jedna FLASH memorija za Backup i da se osmisli robustan sistem za upgrejd sa zastitom od "brikovanja/zakljucavanja" sprave od strane korisnika nego komplikovati sa programatorima i cime vec. Ovo sa dve memorije nije nista novo, to se odavno koristi u PC svetu na maticnim plocama, setite se "Dual BIOS" maticnih ploca, to je bas to a vidjao sam i na industriskim Embeded resenjima nevezano za PC.

I naravno postoji kombinacija sa FLASH memorijom ali druga da bude FRAM jer ce vam on trebati pa trebati : ), i tu da se malo manipulise memoriskim prostorom, raspodeli se tamo-vamo sa sve Backup prostorom, "vecim" u Flash i "manjim" u FRAM i tu se cuvaju SVE adrese, vrednosti, firmware i najbitnije korisnicka podesavanja tj parametre koja su korisniku najbitnija, ovo ostalo ga u sustini ne interesuje, njega interesuje da mu ostanu sva podesavanja pre ili posle ili kad god nakon updejta firmwera i to da ima ceo set podesavanja backupovanih pod nekim imenom, MyConf1, MyConf2 i tako dalje.

Dakle potpuno isti princip se "mazne" sa PC platforme i maticne ploce, oni imaju SRAM sa baterijom i FLASH, ovde kod nas sa MCU imamo FRAM i FLASH i ne treba vam vise nista od toga, osim SRAM ako krenete u graficke vode, mada realno, u onaj PCI slot na XMOS StarterKit moze da se ubode i citava PC graficka kartica i to da biras od 20E do stotine Eur za graficke od 4-6-8-10GB DDR4/5 RAM memorije, imaju 2 DVI i 4 HDMI izlaza, imaju snage za "kalkulaciju" da se smrznes, kakav crni FFT, to moze da radi hiljade ili milione FFT-ova u realnom vremenu, to je tako surova procesorska snaga spakovana za graficke potrebe da je to nenormalno, i sto je je najludje to moze da se iskoristi za sve i svasta i koriste ljudi za sve i svasta!!!

---

Poenta je ako se dobro osmisli sistem i sastavi iz jedne ili vise "pametnih kockica" i sav ostali HW samo da se svede na buffere i opto izolatore, bez ikakve specificne externe logike sa expanderima, shift registrima ili slicno, i ako su sve te kockice spojene na red u recimo JTAG lanac onda je ceo sistem prakticno in-field programibilan i rekonfigurabilan do najsitnijeg detalje logike koja mozda sad postoji ili koja ce tek biti implementirana i sa XMOS resenjem to je skor rekonfugurabilno kao sa FPGA varijantom, naravno sa nekim ogranicenjima, ali generalno za taj nivo integracije trenutno nema bolje resenje a da nije CPLD ili FPGA.

Evo što sam do sada pronašao na temu uploada programa. Postoje dva alata koji dolaze u sklopu njihova xTIMEcomposer Studio IDE: xburn i xflash. Oba su komandno-linijska, a koristi ih i IDE. Mislim da su oni relevantni za upload, a ne xrun spomenut u postu #1 koji se koristi za load i pokretanje programa u radnoj memoriji (valjda ).
xburn se koristi za programiranje tzv. OTP (one-time-programming) memorije koje ima 8k po hardverskoj jezgri (tile) i gdje se stavljaju stvari poput serial no, kriptografskog ključa s kojim će se dekriptirati program prilikom učitavanja iz flasha, i slične IP (intellectual property) stvari.
xflash se koristi za uploade, kažem u množini, jer XMOS je to dosta dobro razradio. Prvo, flash se može podjeliti na boot i data particiju (vidi sliku dolje).



Početak boot particije sadrži Flash loader (tu je programski kôd koji selektira koji će se firmver pokrenuti) i tzv. Factory image koji ima id=0 i nakon kojeg može slijediti n drugih firmvera (na slici Upgrade image 1, 2, 3...). Data particija je po defaultu 0, tj. ako se drugačije ne kaže xflash-u onda će on sav prostor na flashu rezervirati za Factory image i n "upgrade" firmvera. Obratite pažnju na to da je Flash loader i Factory image hw zaključan (da se ne mogu pobrisati). Jako zgodno. Ako ima više firmvera loader će pokrenuti onaj s najvećim id (taj broj mora biti jedinstven/unique). Ovo bi sve trebalo vrijediti bez obzira da li se radi o internom (F verzija MCU) ili eksternom. Eksternih čipova može biti više, eto doznao sam da postoji i FRAM, hvala ti na informaciji. Izgleda kao bitno poboljšanje u usporedbi s flash i eeprom. Cijena mu nije mala, ali i to će vremenom doći na svoje.
Na tome priča ne završava. XMOS ima i flashlib koji omogućuje xflash funkcionalnost u run-time (što uključuje i pisanje u flash!). Navodim nekoliko povezanih stvari:

• Primjer korištenja flashlib (malo je vremešan, prije 6 godina)[/url]
  
• Primjer za custom flash bootloader
  
• qSPI flash lib
  
• Podrška custom memorije (PDF), odnosno noviji dokument o definiranju/dodavanju nove (nepodržane) flash memorije (PDF)
  
• Jedna od mogućnosti sada mislim da je i korištenje USB-diska/sticka na kojem se može snimiti firmver za upload. U tom slučaju dobro bi poslužila app nota 00125
  
• Design and manufacture systems with flash memory (web stranica i PDF nisu identični)
  

Mogućnosti izgleda da ima mnogo, ono što ne ohrabruje je dosta konfuznih ljudi na njihovom forumu koji su zapeli na priči o firmver uploadu i pokretanju.

XMOS dozvoljava pokretanje programa iz više izvora što se u slučaju izabranog MCU definira sa stanjima na pinovima X0D04, X0D05 i X0D06:


Može se koristiti QSPI master, običan SPI u master i slave režimu ili boot preko xCONNECT linka. Ako ovo dobro tumačim, prvo se pokreće Tile 0 (hardverska jezgra) i onda preko xlink0 Tile 1.

VAŽNO: pinovi za QSPI i SPI su "hardcoded" u ROMu i ako se žele koristiti drugi pinovi mora se ubaciti program u OTP memoriju u kojem će se definirati novi pinovi.
VAŽNO2: MCU očekuje da bitovi u byteu stižu od LSB prema MSB, pa u slučaju korištenja programera koji upisuje sekvencu od MSB prema LSB, bitove u ".hex" fajlu treba prvo obrnuti. To što vrijedi kod običnog SPI flasha za bitove, kod QSPI vrijedi za niblove (jer je QSPI 4-bitni).

Pored u prethodnoj tablici navedenih načina startanja programa (boot) moguće je to napraviti i iz OTP memorije. To će se dogoditi ako je bit 5 (security boot) tzv. security registra postavljen na 1.

[mikikg]

Ovo sto je Hardware Protected u slucaju sa externom SPI FLASH/FRAM memorijom je samo kontrola /WP pina, kada se povuce na GND onda ima zastitu za pisanje nad odredjenim blokovima memorije, vazi isto za oba tipa memorije samo su naravno adrese i velicine blokova razlicite dok se konfiguracijom kroz opcione registre moze detaljnije po blokovima konfigurise WP zastita, zavisi od upotrebljene memorije ali je kod svih isti princip.
Tako se u tom slucaju stite odredjeni blokovi da ne mogu da se prepisu, tu je smesten bootloaderi i originalni fabricki firmware.
Na PCB moze da se ostavi mali SMD pad za /WP koji se prespoji nakon sto se inicialno "prvi put" ucita firmware i popune potrebni podaci. Takodje u slucaju "krajnje nuzde" ako nesto nije u redu sa bootloader ili originalnim firmware, lako moze da se odspoji /WP pad i da se odradi ta procedura pa se posle opet prespoji.

[mikikg]

Kod PCI-E standarda se koriste seriske linije i masivna serializacija i deserializacija podataka i paketa, oko toga se vrti cela prica, da se tako izrazim to su SW expanderi.

XMOS ima zanimljiva resenja sa "klokovanim GPIO" i tu dolaze oni portovi za koje si pitao cemu sluze, 1bit port, 2, 4, 8, 16 i 32.
Da uprostim, recimo da je XMOS-ov 1bit port ekvivaletno funkciji kod STM-a GPIO->BSRR gde mozemo na nivou 1bit da upisemo informaciju, isto tako XMOS-ov 32bit port je isto sto i kod STM GPIOx = 0xABCD gde upisujemo 32bit WORD na port.
Ono sto STM nema je ovo izmedju, 2, 4, 8 i 16bit port gde mozemo isto tako "atomski" da upisemo "samo" 2 ili 4,8,16 bitova direktno na izlazni port a da "ne smetamo" ostalim nozicama i registrima i to bez "read-modify-write" operacija (|=) koja znaju da prave podosta problema posebno ako se umesa ISR koji barata na istom portu, bez obzira sto hocemo samo nekim nozicama da menjamo stanje, kod STM32 bezuslovno moramo da procitamo i ponovo upisemo stanje celog porta za sve situacije osim za 1bit ili 32bit, i tu stvarno ima problema, juce sam naleteo na to.
Takodje kod XMOS se GPIO nozica interno vezuje za CLOCK (ima ih nekoliko, programibilni su) i onda moze nozica da se proglasi da samo po sebi vec bude seriska i da radi automatsku serializaciju i desirializaciju podataka nase postavljene duzine i brzine i to sve da radi bez intervencije CPU, samo "stigne" ili "ode" gotov podatak u/iz predefinisanog registra.
Kod XMOS se moze tako "stvarno" nasvira 100Mbit/s po jednoj I/O nozici, ako to malo onda se ide na duplo brze tj 2bit port, malo i to na 4, na 8, 16, i na kraju 32bit port ; )
Na primer kod 7'' TFT/LCD sa touch sam iskoristio jedan 8bit port za data komunikaciju i iskoristio jedan 4bit port za kontrolne signale R, W, CS, RESET tako da sam mogao samo kroz jednu instrukciju da setujem zeljenu operaciju i jednu za podatak i dolazio sam do skoro prakticnog maksimuma od 100MByte/s (1Gbit/s) transfera podataka ka toj periferiji. Zato su zgodni ti portovi razlicite duzine a jos mogu da se klokuju i to je kljuc cele njihove price sa I/O!

Ono sto je za STM i ostale SPI, I2C i ostalo na fizickom nivou po broju nozica to je za XMOS 1bit, 2bit ... 32bit port jer su morali tako to da generalizuju da bi mogli da izguraju svoju pricu.

[prasimix]

Da, to sa portovima izgleda vrlo moćno. Portovi u određenoj mjeri nakon programiranja mogu nastaviti živjeti svoj život što omogućuje dramatične transfere. Nisam našao da se spominju 2-bitni portovi koje navodiš. Nisam gledao što nudi IDE i postoje li u XS-1 seriji. u xCORE-200 (XS-2) ih ne vidim.

Pokušao sam popuniti mapu pinova za XE216 u 128-pinskom pakovanju iz posta #11 sa onim signalima koje troše njihove slice kartice za touchscreen displej sa RGB interfejsom i SDRAM za display buffer. Dodatno, tu je vanjski QSPI flash, eternet transceiver, USB i debug/JTAG bus (za njihov 20-pinski XSYS konektor). Evo slika tablice iz PDF-a u prilogu:



Displej (kolona display slice u tablici) koristi pinout njihovog Triangle slice porta, a SDRAM Star slice porta. Ako se pogledaju šeme, može se vidjeti da je korišteni displej 16-bitni (5-6-5 RGB, što nije full color kako ga reklamiraju), a i pristup SDRAMu je multipleksiran (address/data). Pinout slice portova je prema šemi od xCORE-200 sliceKIT. Pinovi za QSPI su multipleksirani, dakle nakon boot-a sa vanjskog flasha pripadajućih 5 pinova koriste se za SDRAM.
Izgleda mi malo nezgodno preklapanje pinova za debugger i displej (X0D39, X0D40, X0D41 i X0D42). Ispada da se neće moći raditi debug displej funkcija.

Bez optimizacija ostaje nam 19 pinova slobodno od kojih se 3 mogu koristiti za 1-bitne portove, a ostalih 16 po želji organizirati u 16x1, 4x4, 2x8 ili 1x16-bitni port. U ovisnosti o tome za što će se MCU koristiti to bi moglo biti dovoljno, ali i više nego nedovoljno. U mom scenariju želim imati sve gore navedeno: touchscreen displej, SDRAM (za frame buffer, a moguće iz za neke druge stvari), debugger, eternet i USB. Dodatno ako bi MCU u backplane (DIB) varijanti bio na svojoj (master controller) kartici koja bi kontrolirala niz drugih nezahtjevnih periferija, npr. PSU, el. load, lo-speed I/O (opto-ulazi, relej/triac izlazi) i sl. onda bi prema svakoj kartici trebao povući barem SPI bus, što znači SCLK, MOSI, MISO i n CS/SS-ova, ili najmanje jedan SS koji će određivati kada će se poslati po SPI adresa periferije na određenoj kartici (to može biti neki shift registar). Ako bi želio ganjati barem 4 periferije to je već 16 linija. Nadalje na samoj "master controller" kartici može se očekivati neke periferije, recimo inkrementalni dekoder, SD Card, RTC, par LEDica, nekoliko I/O pinova za ext. triggering, sync i sl. To je glatko 5-10 linija pa ukupne potrebe prelaze 19 pinova bez da spominjem mogućnost da bi backplane mogao podržavati do recimo 8 perifernih kartica. Nadalje, ako bi neka od perifernih kartica dobila svoj XMOS MCU i željeli bi da se isti spoji sa "masterom" preko xCONNECT link-a vidimo da sa izabranim 128-pinskim pakovanjem i korištenjem linija prema XMOS slice pinoutima nemamo niti jedan slobodni link.
Ovdje se odmah postavlja pitanje, koja je logika pratiti XMOS slice slot pinoute? Zbog pretpostavke da bi postojeći programi i lib-ovi mogli biti direktno iskorišteni, što bi skratilo vrijeme implementacije. Naravno sve što već postoji bi se moglo adaptirati za neku drugu konfiguraciju pinova, no za to ću trebati uložiti nešto vremena s kolegom koji je zadužen za softver/firmver da se vidi koliko je postojeće upotrebljivo.

Uz pretpostavku da se postojeće može lako adaptirati i da će kolega brzo uspjeti uroniti u novi svijet XC (paralelnog) programiranja, valjalo bi se baciti na pametnu optimizaciju kako bi imali što više pinova na raspolaganju. Naravno, najjednostavniji način dolaska da više pinova jest izbor drugog pakovanja, ali sve preko 128-pinskog su BGA, što ne mogu rješiti lemilicom, a nemam peć (niti će se uskoro pojaviti).
Prvo što bi trebalo "kratiti" je broj displej pinova. Mikikg, već si pokazao da si nešto napravio sa kontrolom displeja. U prethodnom postu spominješ 8-bitni port za displej. Pretpostavljam da nisi koristio samo 256 boja, već da si isti raširio na 16 ili 24-bitni RGB. Ispravite me ako sam nešto krivo računao: ako bi uzeli 4.3" displej od 480x272 piksela i imali refresh od 30 Hz i 24-bitni RGB, za to nam treba 1-bitni stream od 7,8336 MHz. Ako 30 Hz nije dovoljno pa želimo 50 Hz tada je to 13,056 MHz. Čini mi se da bi to moglo biti skroz dohvatljivo sa 1-bitnim portom ovakvog MCU. Ako je to točno, to nam štedi 15 pinova s time što možemo podržati 16-, 18- ili 24-bitni RGB bez danjeg povećanja potrošnje pinova. Jasno, za to nam trebaju dva ili tri 8-bitna shift registra.
Ne znam može li se nešto napraviti sa SDRAM-om. Pristup istome bi trebao biti barem tri puta brži: write address i data i read displej data. XMOS spominje u svojim primjerima transfer podataka (16-bitnim portom) do 80 MB/s s clockom do 50 MHz. Za gornji slučaj 50 Hz frame buffer transfer je 2,488 MB/sec, odnosno ako se sve serijalizira (upis u SDRAM i čitanje za crtanje slike) ne treba nam više od 7,5 MB/s. Je li ova računica ima smisla? Ako jest, i na SDRAM komunikaciji bi se moglo uštedjeti daljnjih 15 pinova (ukupno 30!). Postoji i druga mogućnost za rješavanje displej/SDRAM priče, a to je da se uzme najjeftiniji MCU sa 8 logičkih jezgri i spoji sa xCONNECT na master. To diže ukupnu cijenu i ponešto bi zakompliciralo boot i update firmvera (jednog ili dva).

[mikikg]

Samo kratko oko TFT/LCD, ovaj model je imao samo izbor 8bit ii 16bit palete boja, nema 24bit paletu.
Dodatno tvoja racunica je korektna ali realne potrebe su vece jer mora da se prvo adresira memoriski prostor pa onda da se upise podatak i to svaki put ako nismo u block-transfer modu (automatski inkrement adrese pisanja) tako da se tu gubi dosta vremena po jednom pixelu.

[mikikg]

BTW: XMOS koliko god mocno izgledao za neke stvari nije savrsena zamena za MCU, evo samo jedan primer, PWM, XMOS isto PWM resava na SW nivou sa bit-banging ali tu iskace jedan nezgodan problem a to je sto je to limitirano na "samo" 100MHz clock-a, ako to uporedimo za nekim malo naprednijim MCU onda XMOS ispada "mala beba", recimo TI Piccolo "malecki MCU" ima PWM kome interni clock radi na 6GHz, kod TI Delfino serije im interni clock za HR-PWM radi na neverovatnih 13GHz tu interno u procesoru a inace procesor radi na 100-200MHz systemskog clock-a slicno kao kod XMOS dok ovi PWM-ovi nikako ne mogu da se porede, TI je prevazisao sve ostale proizvodjace po tom pitanju, otisli su svetlosnu godinu na tom polju od drugih!

Konkretan primer, STM32F1 moze da ima PWM rezoluciju od 16bit na samo 1kHz nosioca, XMOS je malkice bolji od toga sa SW resenjem, Texas Instruments Delfino ima 16bit na 200kHz PWM nosioca (ekvivaletno HQ CD-Audio po shumu i dinamici, heh preko 90dB dinamike na motor drajveru, jojjj, opasno), ili proporcionalno manje/vise zavisno od nosioca ali se krece negde oko 12bit na 3MHz PWM nosioca : )

Ko je "slusao" PWM od 12bit na recimo samo 100-ak kHz PWM nosioca (dsPIC) sve ce mu biti jasno, Rammstain na tako nekom "motor drajveru" sa zvucnikom zvuci isto kao na Class-AB analognom pojacavacu, a to je samo 100kHz nosica : )
Znas kako tek "peva" neki pravi Motor na takvom drajveru, "slusa k'o bela lala" i to u open-loop, kada se to na kraju stavi u closed-loop e to to su tek opasno dobre tehnike.
Na takvom drajveru bi obican STEP motor u opn-loop stvarno "pevao" a ne "drcao", radio bi skoro kao BLCD motor jer mozemo da ga pokrecemo cistim sinusnim signalom u dve faze, prakticno bi imali 65000x mikro-steping

[mikikg]

https://www.youtube.com/watch?v=hCdJK3GBdyM

https://www.youtube.com/watch?v=stoFZBN8KMU

[prasimix]

Ha, ha, hvala na ovom muzičkom intermecu. Pogon motora je tehnologija/problematika za sebe i eto kao što rekao, postoje značajno bolji kandidati za to specifično područje. Mene više brine jedan detalj kod XMOSa koji može biti generalno problem: patetično malo memorije.
Dakle, imamo sljedeću situaciju: kod XMOS-a se sve izvršava iz internog RAMa, to znači i da se firmver koji je u flashu/EEPROMu/F-RAMu kod pokretanja/boota učitava u taj RAM i isti se koristi i za radne podatke (varijable, konstante, itd.). Iz tog razloga možemo vidjeti zašto je na nekim njihovim eval. karticama QSPI bus (prema vanjskom flashu) multipleksiran: pinovi postaju slobodni za GPIO nakon što je firmver učitan (u RAM). Ovo samo po sebi nije problem: stvarni problem je 512KB RAMa (u najboljem slučaju 1024MB za modele u BGA pakovanju). To nije 512KB već je to samo 256KB po jednom tile-u (hardverskoj jezgri koja može opsluživati do 8 logičkih).
Moguće da ću sada krenuti uspoređivati kruške i jabuke: PSU projekt na Arduino Due (također 32-bita) glatko prelazi 256KB bez da spominjem koliko se internog RAMa koristi za varijable, konstante i druge programske podatke. I to je samo PSU koji doduše nije svakodnevni jer ima i USB i eternet (ali još uvijek bez Web servera za LXI), SCPI parser i opsluživanje LCD touchscreen displeja (koji ima kontroler, iako mizeran ali ipak ima) i praćenje rada dva kanala. Volio bih vjerovati da isti firmver prepisan u maniri XMOS-a može dovesti do dramatične uštede u veličini firmvera, ali kolika bi ona mogla biti: dvostruka ili tek 20-postotna?

XMOS i dalje nema odgovor na memorijsko ograničenje, u formi najave MCUa sa više memorije ili implementacije podrške za vanjski SRAM koji se može koristiti za izvršavanje programa, a ne samo kao brzi storage/buffer. Na njihovom sajtu možemo pronaći notu External SRAM memory Controller iz davne 2013.g. gdje kaže da je taj softver blok u feasibility stadiju (provjera isplativosti) da trenutno ne postoji programski kod za implementaciju tog bloka, ali da je u planovima (roadmap-u). Do sad se ništa nije dogodilo.
Smatram da više od 256KB (ukupne!) memorije nije nikakav luksuz, niti su drugi prozivođači u ponudu stavili 2MB ili 4MB flasha (kao programske memorije!) iz pukog nadmetanja. Ako se želi imati zaokruženu funkcionalnost uređaja koji je bitno kompleksniji od ekspreso aparata sa dva tastera i ledice onda za to treba napisati malo veći program i u nešto ga staviti: ne traže se stotine megabajta u tradiciji "dobrog" Windows i desktop programiranja, ali ni 256KB za C programiranje neće biti dovoljno.
Bez toga čini se da će XMOS ostati u domeni brzog/nevidljivog (bez korisničkog intefejsa) procesiranja ludih algoritama gdje može biti još bitno praktičniji od FPGA, ali će onda i zahtjevati svog "mastera": dobar MCU, SoC ili gotov SMC (bio on u klasi RasPi/Beaglebone ili nešto "profesionalnije").

EDIT: Evo ovdje jedna diskusija na XMOS forumu na temu memorije, citiram konstataciju jednog od članova (ne znam je li bio zaposlenik XMOSa ili ne):

By far the greatest benefit across the whole Xmos XS1 chip range would be an increase in internal Ram and replacing OTP with Flash.

To je rečeno za XS1 seriju, XS2 (xCORE-200) se pojavila u međuvremenu, no nažalost XMOS nije ništa učinio po ovom pitanju, radna memorija je povećana po tile-u do 256KB ali i dalje to je sve što se ima na raspolaganju za programski kod, podatke i firmver. Tužno.

[mikikg]

Njihov princip je generalno da memorija nije potrebna u tolikoj meri, cak preporucuju izbegavanje cache memorije ili medju-buffere jer podatke prosleduju direktno od tacke do tacke (end-point), funkcije su razlicite ali su tacke definisane sa I/O strukturom kao i metode koje ih prate tj event-i i callback funkcije.
Sto su manji bufferi ili ih nema u sistemu, kao ni cache memorije, sistem je agilniji i kako oni kazu sa manje problema.
Sta ako treba da se prenese nesto ogromnom brzinom, prikazivali su primere za 4K Video stream kroz Gbit LAN, tu nema sta da se bufferuje jer je potrebna sumanuto velika kolicina brze memorije, umesto toga su podelili to na manje pakete podataka i verovatno samo sa nekim minimalnim bufferom za nekoliko paketa dovoljnih da CPU moze brzo da odreaguju i da trazi re-send od mastera ili kako je vec osmisljen ceo protokol, ima ceo standard kako se pakuju i rutiraju ti podaci za Hi-Speed A/V/Data stream.

Problem "crtanja" po grafickom displeju je vezan iskljucivo za Aplikativni nivo i kolicinu "ikonica i slicica" sa kojim hocemo da baratamo, to negde mora da se smesti a usput ako imamo slozen GUI sa raznim "kliktajucim" stvarima, RAM-a nikad nece da bude dosta, i u startu interni RAM od MCU kontrolera moze da se zaboravi jer nije predvidjen za to.

Mozda treba opet rasclaniti pricu na najsitnije detalje i mozda iskoristiti XMOS sa svojim jezgrima tako da se iskoriste DINAMICNE memorije, DRAM, DDR1, 2, 3, 4, 5, neka valjda moze da se iskoristi? : ) Neka se potrose X jezgra samo za memoriski kontroler, Y samo za crtanje i API, i treba samo komunikacija i to je to, taj kontroler samo to treba (i moze) da radi.
A da li se to isplati raditi ili staviti Rpi/BBB ili slicne banane i vockice, to treba razmisliti, nisam pametan, zalazi se u "mnogo sitnu tehniku", memorije pocinju da rade na ispod 2V, treba konverteri nivoa, BGA i slicna kucista, treba nacrtati viseslojnu PCB za to, to je sve ogroman posao ...

BTW: Ne zaboravite da je Raspberry Pi kada se pojavio pa sve do danas "pobedio" je je resio problem sa memorijom i to kako, isto su imali ARM kontroler, falila memorija pa falila, gde da je sad izmisle, nozice, vodovi, terminacija muzka ziva, i setili se ljudi, ZALEPILI (zalemili) memoriju direktno preko kontrolera u sendvic, ne moze da bude idealnije i blize postavljena externa memorija, sa donje strane kontrolera se ide na PCB a sa gornje strane je MEMORIJA i sve lici kao jedan IC a u stvari su dva!