XMOS xCORE

[prasimix]

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.

Da, ali ono što mene, a i puno drugih ljudi na njihovom forumu muči, jest programska memorija. XMOS po tile-u nudi 256KB ukupno za programski kod i podatke, što je SRAM i flash kod standardnih MCU. Na skromnom ARMu Arduino Due ploče to je bilo 512KB flash-a + 96KB SRAM.

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.

U dosadašnjem firmveru broj dekoracija na displeju je bio minimalan i po broju ikona i korištenih bitmap fontova koji nisu bili ni anti-aliasing. Naravno da bi to u XMOS priči sve bilo preseljeno na neku vanjsku memoriju i preko frame bufferinga pravovremeno transferirano na displej. To će smanjiti ukupnu potrošnju memorije, ali i dalje nisam siguran što će se moći strpati u 256KB. Neki ljudi sugeriraju kako bi se veliki programski kod trebao razbiti u blokove i učitavati u radnu memoriju po potrebi. Ne znam koliko je to praktično i koliko bi još nove discipline zahtjevalo prilikom pisanja koda.

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!

Vanjska memorija po dosad viđenom više "košta" u broju pinova nego jezgri. Broj pinova je 20, a dovoljna je jedna jezgra (za tzv. SDRAM server). SDRAM lib podržava rad sa do 256MB memorije, što bi trebalo biti i više nego dovoljno i za ozbiljna grafička iživljavanja. Ne znam čemu služi SRAM lib, tj. za što bi se vanjski SRAM u tom slučaju mogao kontrolirati.