XMOS xCORE

[mikikg]

Samo jos ovo oko displeja, vrtimo se dosta oko toga vec duze vreme, ono sto po meni za jedino vredi utrositi vreme i nesto novca je razvoj stand-alone TFT/LCD displej kontrolera na bazi XMOS sa externom memorijom (slicno Nextion ali bez FPGA) i to da displej na kraju bude klasican HMI, ima samo RS-232 ili SPI vezu i svoji internu logiku unutar kontrolera i API koji radi neke predefinisane operacije sa dugmicima i pokazivacima, mozda mozemo da se oslonimo na neke gotove frameworkove ali stvar je ta da jedan MCU mora da barata samo sa displejom i okolisom oko njega (uSD, Flash) i da se on proziva i osvezava totalno nezavisno od nekog tamo glavnog MCU koji radi kriticne real-time taskove.

Mada, sve napravili, treba samo da se izabere neki od 98 razlicitih dostupnih SoC modela : )
http://linuxgizmos.com/catalog-of-98-ope...ndly-sbcs/

[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.

[prasimix]

Samo jos ovo oko displeja, vrtimo se dosta oko toga vec duze vreme, ono sto po meni za jedino vredi utrositi vreme i nesto novca je razvoj stand-alone TFT/LCD displej kontrolera na bazi XMOS sa externom memorijom (slicno Nextion ali bez FPGA) i to da displej na kraju bude klasican HMI, ima samo RS-232 ili SPI vezu i svoji internu logiku unutar kontrolera i API koji radi neke predefinisane operacije sa dugmicima i pokazivacima, mozda mozemo da se oslonimo na neke gotove frameworkove ali stvar je ta da jedan MCU mora da barata samo sa displejom i okolisom oko njega (uSD, Flash) i da se on proziva i osvezava totalno nezavisno od nekog tamo glavnog MCU koji radi kriticne real-time taskove.

Ha, ha, da, meni se već odavna vrti u glavi od toga . Ne želim Nextion i slična (još skuplja) rješenja, a nikako da se skocka nešto što bi omogućilo da dosad napravljeno za generiranje HMI dobije adekvatnu platformu koja će također biti otvorena i za daljnje modifikacije. Evo mogu reći da ću bez obzira na zabrinutost/sumnju da bi se XMOS MCU mogao iskoristi kao master, a ne tek moćan koprocesor, probati složiti jedan eval. board (objavim specifikaciju uskoro).

Mada, sve napravili, treba samo da se izabere neki od 98 razlicitih dostupnih SoC modela : )
http://linuxgizmos.com/catalog-of-98-ope...ndly-sbcs/

Da, gledao sam slične liste, dajem glas za Orange Pi One, price/performance je vrlo atraktivan i za pretpostaviti je da neće uskoro nestati sa tržišta.

[gorankg]

Za tvoju aplikaciju a i za mnoge druge, Raspberry Pi i ostali derivati, su jako dobro rešenje jer ne brineš previše o interfejsima (USB, ethernet, WiFi, bluetooth...) a takođe ni o GUI. Na takav SBC dodaj neki MCU preko SPI za realtime i vozi. Sa druge strane imaćeš i veliko interesovanje široke RPI zajednice što je podstrek za tvoj proizvod. Cena jeste inicijalno viša ali zato će ti razvoj biti brži. Oslanjanje na XMOS, bez obzira na neke njegove dobre strane, je za tvoj slučaj stranputica.

[prasimix]

Za tvoju aplikaciju a i za mnoge druge, Raspberry Pi i ostali derivati, su jako dobro rešenje jer ne brineš previše o interfejsima (USB, ethernet, WiFi, bluetooth...) a takođe ni o GUI. Na takav SBC dodaj neki MCU preko SPI za realtime i vozi. Sa druge strane imaćeš i veliko interesovanje široke RPI zajednice što je podstrek za tvoj proizvod. Cena jeste inicijalno viša ali zato će ti razvoj biti brži. Oslanjanje na XMOS, bez obzira na neke njegove dobre strane, je za tvoj slučaj stranputica.

Hvala ti na mišljenju. Stvar je u tome što sam ja sam po sebi stranputica pa i to što pokušavam napraviti . RPi i slični neće uskoro bez FPGA moći raditi brzi A/D i D/A (jer nije ideja ostati na programabilnom PSU). U FPGA vode ne želim ići, zato mi XMOS otkako sam čuo za njega (hvala mikikg) izgleda zanimljivo. Ako naposljetku sve skupa i završi sa SBC + XMOS čini mi se da bi to još uvijek moglo biti dosta dobro. Ne želim napraviti drugi Red Pitaya, ali moguće bi se moglo dobiti nešto, generalno gledajući, usporedivo i upotrebljivo.

[gorankg]

Tvoja prošla kampanja je prošla dobro pa ne bih baš rekao da je bila stranputica . I tad sam ti predlagao, čini mi se, da ne ideš na arduino jer sam smatrao da će ti kad-tad zatrebati jača makina. Sa druge strane, to kad radiš sa nečim što je šire u primeni kod DIY zajednice, ti je i prednost jer mnogi bi da prave zato što im je stvar donekle poznata. Zato mislim da bi ti neki RPI pogurao stvar. 
Ako pak ideš na proizvod koji ćeš da prodaješ, onda raspali to sa jednim (ili dva - zavisno od koncepcije) STM32Fxx da ti troškovi budu niži. Ako još  Atollic da svoju PRO verziju TrueStudi-a za DŽ a ima najave da će se to desiti... Ekstra!
Mnogi beže od microchip PIC MCU (jbg. nije ARM pa nije dovoljno in) a on je i dalje u vrhu. Skoro sam video da su izbacili 32-bitni PIC sa GPU i RAM-om na čipu. Kad pogledaš ceo ekosistem oko PIC MCU to je i dalje vrlo dobar proizvod.
Red Pitaya je super ali je preskup. Bar po meni...

[prasimix]

Tvoja prošla kampanja je prošla dobro pa ne bih baš rekao da je bila stranputica . I tad sam ti predlagao, čini mi se, da ne ideš na arduino jer sam smatrao da će ti kad-tad zatrebati jača makina. Sa druge strane, to kad radiš sa nečim što je šire u primeni kod DIY zajednice, ti je i prednost jer mnogi bi da prave zato što im je stvar donekle poznata. Zato mislim da bi ti neki RPI pogurao stvar. 
Ako pak ideš na proizvod koji ćeš da prodaješ, onda raspali to sa jednim (ili dva - zavisno od koncepcije) STM32Fxx da ti troškovi budu niži. Ako još  Atollic da svoju PRO verziju TrueStudi-a za DŽ a ima najave da će se to desiti... Ekstra!
Mnogi beže od microchip PIC MCU (jbg. nije ARM pa nije dovoljno in) a on je i dalje u vrhu. Skoro sam video da su izbacili 32-bitni PIC sa GPU i RAM-om na čipu. Kad pogledaš ceo ekosistem oko PIC MCU to je i dalje vrlo dobar proizvod.

Tako je, i tada si to predlagao (link), ali ne samo to već i da pređem na touchscreen, što sam i poslušao i na tome ti još jednom hvala. Huh, čovječe, spasio si stvar!
Ta kampanja je bila stranputica, nije mi na početku bilo ni na kraj pameti da se napravi crowdfunding, ali eto u jednom trenutku je to postala realna opcija i dobro je prošlo. U stvari čini se da je u jednu ruku i bilo dobro što je tako jer nije bilo presinga komercijale već samo insistiranje na tomu da to mogu replicirati drugi ljudi s osnovnim vještinama i dovoljno volje i da je naravno sve open source.
Inače što se tiče kampanje i djela DIY zajednice koju je privukla kampanja mogu reći da u finalu uopće nije važno koliko su s nečim familijarni već koliko se to lako može sastaviti i staviti u pogon. Tako je ispalo da je više posla u podršci bilo razjasniti ljudima kako dignuti novi firmver kroz Arduino IDE negoli sve ostalo! To je dobra lekcija i ispada da bi najbolje bilo imati/napisati aplikaciju koja će se spojiti na GitHub, vidjeti ima li novi ".hex" firmvera i uploadati ga na uređaj. To do sad nismo uspjeli riješiti na tzv. "easy to use" Arduino platformi (nešto na tu temu ovdje).

Nedavna akvizicija Atollic-a je definitivno veliki plus za ST platformu. Ali, ako se ide prema zahtjevnijim stvarima (kako bogat HMI tako i jako brzi A/D, D/A transferi) čini se da će stvar na kraju zahtijevati neki SMC ili SoC. Ispravi me ako se varam, ne poznajem uopće ST, ne znam što stoji na raspolaganju za real-time intenzivne stvari, ali ako i postoji neki DMA i DSP čini mi se da to ne može parirati XMOS-u (FPGA ne uvodim u priču). Trebam još vidjeti s kolegom koliko će biti zahtjevan prelazak na XC programiranje, ali ovo malo što sam vidio kako se radi s portovima, steamingom, paketima, to izgleda izvrsno. Gotovo sa svakim pinom možeš raditi što te volja! Kako bi oni rekli, u softveru definiraš kakav je hardver, a ne izlaziš iz "komfora" C programiranja.

Ne radim ja ovo zato što me kopka novi proizvod, već to što bih htio na stolu u jednom trenutku imati još par instrumenata koji će biti open source i u podlozi imati spomenuti DIB .

Red Pitaya je super ali je preskup. Bar po meni...

Da i po meni bez obzira koliko ih košta glavni čip/čipovi jer su "newcomeri" i stvar nije open source, dapače na početku su čak zbunjivali ljude s time jesu li ili nisu, odnosno u kojoj mjeri su open. Osim toga 125Mbit/s, 14-bitno i nije neko čudo (tu bih uvijek prije mijenjao 14 bita u 10 ili 12 za 250 ili 500Mbit/s).

[prasimix]

Evo prvi pokušaj stavljanja na jedno mjesto XMOS MCU (XE216-512-TQ128) i sljedećih periferija:

• TFT 4.3" LCD sa touchscreen kontrolerom
  
• SDRAM
  
• Flash (koristi se samo na početku za učitavanje firmvera)
  
• USB host/device OTG
  
• 10/100 Mbit full/half duplex eternet (MCU može i gigabit, ali nisam koristio takav PHY)
  
• Audio izlaz (s malim pojačalom)
  
• EEPROM
  
• Micro SD Card
  
• RTC sa supercap kao pomoćnim napajanjem
  
• Programabilne LED x 3, 2 x otpoizolirani ulaz, 2 x optoizolirani izlaz
  
• Opcionalni konektor za jeftini W5500 Eternet modul
  
• Opcionalni konektor za Riverdi 20-pinski LCD
  

Prema novim saznanjima situacija sa slobodnim pinovima je bitno lošija nego li je to prikazano u postu #15. Ispada da USB i eternet libovi čine nefunkcionalnim dodatnih 16 pinova, što je ostavilo samo 3 slobodna pina za sve ostalo (u što se ne računa SDRAM i LCD kontrola). Kako bih dobio više slobodnih pinova, a da se ne gubi niti jedna od "native" funkcionalnosti (tj. USB i eternet) odlučio sam serijalizirati LCD. To bi moglo biti problematično iz razloga što se pikseli moraju slati brzinom koja je 24 puta veća od one potrebne za refresh ekrana. Dakle, ako je u paralelenom modu ta frekvencija 8 MHz, onda bi serijski clock trebao biti 192 MHz i trebao bi koristiti isto tako brze shift registre. Da bi se ovo svelo na nešto dohvatljivije, boje se mogu svesti na 16-bita pa time i serijski clock pada na 128 MHz, što se lako lovi sa AHC ili VHC logikom. Naravno ovo bi još uvijek mogao biti "račun bez krčmara", jer ne znam može li jedan MCU core serijalizirati takvom brzinom podatke i naravno da se sve to događa na 1-bitnom portu, a ne da moram trošiti 16-bitni jer onda sam opet na početku.

Sada mapa pinova izgleda ovako:



Šema prvog prijedloga bi izgledala ovako:



LCD se spaja preko 40-pinskog 0.5 mm FFC konektora, čiji je pinout manje-više standardan za 4.3" (480x282) displeje. Osnovna razlika koju sam pronašao je korištenje ili ne korištenje DE (Display Enable) signala (pin 34). Za touch kontroler sam izabrao jeftilen AR1021. Napajanje za WLED pozadinsko osvjetljenje je sa TPS61169 koji ima i PWM ulaz za dimming. Napajanja od 3.3 V i 1 V se dobivaju iz stabiliziranog napajanja od 5-16 V korištenjem dva TPS61208 koja su sekvencirana: prvo se pali 3.3 V i nakon toga 1 V. Sekvenciranje kontrolira TPS3808G33 koji prati stanje na 3.3 V. Serijalizacija LCD podataka radi se sa dva 74VHC595 shift registra. Boje su postavljene kao 5-6-5 (RGB) pa su nekorišteni LSB bitovi postavljeni na nulu.



Kontrola SDRAM-a je napravljena prema ref. dizajnu XMOS-a gdje su podaci i adrese multipleksirane, a njihov lib radi sav potreban "bit-banging" da stvar funkcionira. Ovdje imamo i reset generator korištenjem TPS3808G09 koji prati stanje na 1 V i koji se može i manuelno resetirati (SW1). Budući da XMOS mora učitati i firmver u interni RAM, korištenje modela sa ugrađenim flashom (XEF) nema puno prednosti. Zbog toga se koristi vanjski flash koji se prilikom reset-a spaja na QSPI bus koji je "hardcoded" (vidi u tablici gore: X0D01, X0D04-X0D07, X0D10) i kada se flash učita, korištenjem X0D00 linije se tih šest linija oslobađaju da bi se dalje koristile za SDRAM kontrolu. Za to se koriste dva brza quad 1-2 mux/demux (74CBTLV3257) i jedan D-latch (74AUP1G74) za pamćenje stanja.



Ovdje imamo USB koji bi trebao biti device i host prema OTG (on-the-go specifikaciji). Zbog toga sam dodao i napajanje od 5 V kada je USB host. Ovo mi nije skroz jasno, u DS MCU-a nema dodatnih informacija što napraviti za OTG. Zasad sam stavio umjesto obične USB utičnice, 5-pinsku AB mini i USB_ID pin nije spojen.
MCU napajanja su od 1 V i 3.3 V, PLL napajanje mora imati na ulazu RC. Kao glavni clock se koristi kristalni oscilator od 24 MHz, što je jedan od preduvjeta kada se koristi USB. Ovdje se također izvučeni signali za JTAG sa 2-wire xCONNECT za potrebe realtime debugging-a.



16 linija na Tile 1 zjapi prazno, to je danak USB i ethernet libova (valjda). Ostalo ide na spajanje eternet PHY koji može biti i gigabitni. Ovdje je korišten vremešan 10/100 PHY koji dolazi u ljudskom pakovanju (nije QFN ili BGA). Za audio će se koristiti PCM koji će se peglati i slati na malo pojačalo. PHY mora imati svoj clock, od 25 MHz. MCU i eternet clock bi se mogli dobiti iz jednog čipa, recimo Si5351, ali na nesreću isti se mora isprogramirati što komplicira prvi start (trebalo bi izvući sa strane I2C linije za programiranje) jer dok nije programiran nema na izlazima "default" clock. Ovo je izgleda rješeno kod CDCE913 koji je nažalost višestruko skuplji.



Zadnja slika sadrži ostale periferije. Tu se može vidjeti da se koriste dva SPI kanala (SPI1 i SPI2). Na prvom kanalu su sljedeće periferije: EEPROM, micro SD Card, RTC, I/O expander i opcionalni W5500 eternet (ako se neće koristiti glavni). Na SPI2 kanalu je postavljen opcionalni Riverdi LCD. Kako bi se uštedjelo na Chip select pinovima za svaku SPI periferiju, isti će se postavljati korištenje još jednog shift registra (IC24) koji je može postavljati maksimalnom brzinom pa u konačnici pristup pojedinoj periferiji ne bi trebao biti sporiji.

Ova eval. ploča bi trebala biti osnova za danji razvoj softvera, i ista bi se mogla kasnije pojednostavniti (svesti recimo samo na displej kontroler, sa ili bez periferija i ako treba i manjim/jeftinijim MCU).

Vaši komentari i kritike (i oči koje vide!) su više nego dobrodošli. U prilogu su i PDF-ovi.

[vojinilic]

Evo nekih mojih komentara za semu.
1. HC595 drugi ic5. Ja bih iskoristio i njegov izlaz i doveo ga na ulaz od MCU miso. Pored dva bajta saljes i treci (njega prvo saljes) koji je kontrolni, tj. ono sto posaljes, to i primis. Na ovaj nacin imas kontrolu spi lanca.
2. Razmisli da umesto D2 stavis p-kanalni mosfet. Pad napona i disipacija skoro nula.
3. Led1 je pogresno nacrtana, tj. zamenjeni su A i K.
4. Reset kolo ic6 ima open drain izlaz. Ic4 ne moze da se ukljuci posto nema stabilno stanje na ulazu. Vezati pull-up ili izabrati rst kolo sa totem-pole izlazom.
5. Na opto kaplerima ok2a i b bih zastitnu diodu postavio na red sa otpornicima, posto je ona manja snaga na otpornicima ako se zameni polaritet. Ne znam koji je ulazni napon.
6. Razmisli da za usd karticu koristis sdio inerface umesto spi. Brzi je 4x.
7. Obavezno povezi detekciju usd nartice na mcu


Pozdrav,
Vojin

[gorankg]

XMOS MCU, SDRAM i flash bih ja na jednu pločicu. Sve ostalo bi dolazilo kao modul na to.
USB i Ethernet, sam kažeš, ti uzimaju dosta pinova a možda neko i ne bi koristio to. DP838498 imaš i kao modul. Ja sam ga kupovao kod https://www.waveshare.com/
Rešenje za displej mi se ne sviđa kao i ovo sa expanderom. Sve to mogu da budu moduli, pa kome kako treba neka dodaje po potrebi.

[prasimix]

Evo nekih mojih komentara za semu.
1. HC595 drugi ic5. Ja bih iskoristio i njegov izlaz i doveo ga na ulaz od MCU miso. Pored dva bajta saljes i treci (njega prvo saljes) koji je kontrolni, tj. ono sto posaljes, to i primis. Na ovaj nacin imas kontrolu spi lanca.

Dobro, no što imamo od takve kontrole? Da smo sigurni da je na ekran stiglo to što je poslao? Da nešto nije u redu moralo bi odmah biti vidljivo na ekranu, ili?

2. Razmisli da umesto D2 stavis p-kanalni mosfet. Pad napona i disipacija skoro nula.

Evo maknuo sam mosfet iza ulaznog osigurača i zenerice, i gate direktno na gnd. Je li ovo ok ili da ipak stavim otpornik na gate (npr. 1K) i zenericu od 10 V između gate i source? Mosfet je od -20 V, cca -2 A.

3. Led1 je pogresno nacrtana, tj. zamenjeni su A i K.

Sređeno!

4. Reset kolo ic6 ima open drain izlaz. Ic4 ne moze da se ukljuci posto nema stabilno stanje na ulazu. Vezati pull-up ili izabrati rst kolo sa totem-pole izlazom.

Huh, hvala za ovo. Stavio sam pull-up na 3.3 V jer čini se da izlaz ne trpi više od 7 V. Budući da je EN prag 1.6 V onda bi to trebalo biti u redu.

5. Na opto kaplerima ok2a i b bih zastitnu diodu postavio na red sa otpornicima, posto je ona manja snaga na otpornicima ako se zameni polaritet. Ne znam koji je ulazni napon.

Mislio sam da ulazi budu 5 V, možda da još smanjim otpornike?

6. Razmisli da za usd karticu koristis sdio inerface umesto spi. Brzi je 4x.

Eh, da je slobodnih pinova, ali da, itekako ima smisla napasti SD card max. brzinom. Za to mi treba jedan 4-bitni slobodni port. Moram još razmisliti što učiti.

7. Obavezno povezi detekciju usd nartice na mcu

Dodam!

[prasimix]

XMOS MCU, SDRAM i flash bih ja na jednu pločicu. Sve ostalo bi dolazilo kao modul na to.
USB i Ethernet, sam kažeš, ti uzimaju dosta pinova a možda neko i ne bi koristio to. DP838498 imaš i kao modul. Ja sam ga kupovao kod https://www.waveshare.com/
Rešenje za displej mi se ne sviđa kao i ovo sa expanderom. Sve to mogu da budu moduli, pa kome kako treba neka dodaje po potrebi.

He, he, lako čovjeka povuče modularanost i onda je pitanje gdje je kraj, tj. koje sve module napraviti. Osnovna ideja mi je bila da napravim eval. pločicu za testiranje osnovnih funkcija, koje su u XMOS ponudi koje su usitnjene po više modula (sliceCARD) i da ista ne pređe magičnih 100 x 100 mm što min. košta u Kineza tako da se može ozbiljno razmisliti i o 4-slojnom PCB dizajnu. Ako ta prva profunkcionira, ne bi mi trebao biti preveliki problem izderivirati neke manje module. Ok, pitanje je i što je za nekoga osnovna funkcija, jer kada se spomene XMOS, kod dosta njih bi to u prvom redu značio opaki audio procesing, pa zašto onda ne dodati SPDIF, I2S, hi-end DAC, i slično.

Eternet zaista troši svo čudo pinova (gotovo čitav Tile 1), što se može možda opravdati potrebom za gigabitni transfer, a kojeg nisam stavio (!), pa bi možda sve skupa treba napraviti da se ti pinovi ili koriste za eternet ili ostale periferije koje sam nabio na Tile 0 pinove. U tom slučaju bi se na Tile 0 mogao ponovno raširiti bus za LCD na 16-bitni. U slučaju kada se ne želi koristiti ugrađeni eternet mogao bi se koristiti i XU216 model.

Što ti ne valja sa displejom i expanderom: to što su uopće na pločici ili kako je to izvedeno (displej sa serijalizacijom, korišteni čip u slučaju ekspandera, itd.)?

[prasimix]

Dobrodošli u realan svijet, gdje pravednici (udruženi u konzorcije) svoj težak rad štite tzv. patentima (mehanizmom koji su psihopate doveli do apsurda baš kao i sve druge ljudske ideje). Evo što sam našao u XCORE libu za SD Card:

Beware: 4bit SD protocol is subject to petents of the SD Association. When enabled on commercial products a license may be required. (see: https://www.sdcard.org/developers/howto/ )

Kada se ode tamo, može se doznati da već i za R&D traže 1000 USD godišnje + potpisivanje NDA (ako nisi učlanjen, cifra za članstvo vjerujem da te tjera suze na oči). Pa ti koristi 4-bitni transfer.

[gorankg]

Što ti ne valja sa displejom i expanderom: to što su uopće na pločici ili kako je to izvedeno (displej sa serijalizacijom, korišteni čip u slučaju ekspandera, itd.)?

Ne mislim da je nešto loše izvedeno već da je suvišno. Meni se XMOS baš sviđa i ako bi mi aplikacija zahtevala više pinova ja bih pre išao na drugi veći čip a izbegao dodavanje periferija.

[prasimix]

Što ti ne valja sa displejom i expanderom: to što su uopće na pločici ili kako je to izvedeno (displej sa serijalizacijom, korišteni čip u slučaju ekspandera, itd.)?

Ne mislim da je nešto loše izvedeno već da je suvišno. Meni se XMOS baš sviđa i ako bi mi aplikacija zahtevala više pinova ja bih pre išao na drugi veći čip a izbegao dodavanje periferija.

Da, nezgoda je (barem za mene) to što veći modeli dolaze samo u BGA pakovanju, iz tog razloga i sva ova kemija. Druga mogućnost je spajanje preko xCONNECT-a drugog MCU, ali i to košta 10 pinova (2 x 5-wire RX/TX), i da ne spominjem trošak MCU. Istina u tom slučaju se dobiva još dodatna sitnica od 2000 MIPS-a

[vojinilic]

Dobrodošli u realan svijet, gdje pravednici (udruženi u konzorcije) svoj težak rad štite tzv. patentima (mehanizmom koji su psihopate doveli do apsurda baš kao i sve druge ljudske ideje). Evo što sam našao u XCORE libu za SD Card:

Beware: 4bit SD protocol is subject to petents of the SD Association. When enabled on commercial products a license may be required. (see: https://www.sdcard.org/developers/howto/ )

Kada se ode tamo, može se doznati da već i za R&D traže 1000 USD godišnje + potpisivanje NDA (ako nisi učlanjen, cifra za članstvo vjerujem da te tjera suze na oči). Pa ti koristi 4-bitni transfer.

Za ovo stvarno nisam znao. Izuzetno bezobrazno. Jedan od razloga da ne radim sa njima. Ja koristim STM32F4 i normalno koristim 4 bit sdio + fatfs.
Ovo je izuzetno bezobrazno u 21. veku.

[prasimix]

Dobrodošli u realan svijet, gdje pravednici (udruženi u konzorcije) svoj težak rad štite tzv. patentima (mehanizmom koji su psihopate doveli do apsurda baš kao i sve druge ljudske ideje). Evo što sam našao u XCORE libu za SD Card:

Beware: 4bit SD protocol is subject to petents of the SD Association. When enabled on commercial products a license may be required. (see: https://www.sdcard.org/developers/howto/ )

Kada se ode tamo, može se doznati da već i za R&D traže 1000 USD godišnje + potpisivanje NDA (ako nisi učlanjen, cifra za članstvo vjerujem da te tjera suze na oči). Pa ti koristi 4-bitni transfer.

Za ovo stvarno nisam znao. Izuzetno bezobrazno. Jedan od razloga da ne radim sa njima. Ja koristim STM32F4 i normalno koristim 4 bit sdio + fatfs.
Ovo je izuzetno bezobrazno u 21. veku.

XMOS je dao lib koji tjera SPI i SDIO i dao to upozorenje, a SD konzorcij traži da im se plati. Nisam siguran da su ST korisnici izuzeti ovoga, jer "patent je patent". Možda i jesu ako je ST platio za svoje MCU, kao što je mislim slučaj sa CAN.

EDIT: Evo jedno mišljenje na ovu temu.

[gorankg]

Za ZigBee u komercijalnom proizvodu takođe se plaća.

[vojinilic]

Dobrodošli u realan svijet, gdje pravednici (udruženi u konzorcije) svoj težak rad štite tzv. patentima (mehanizmom koji su psihopate doveli do apsurda baš kao i sve druge ljudske ideje). Evo što sam našao u XCORE libu za SD Card:

Beware: 4bit SD protocol is subject to petents of the SD Association. When enabled on commercial products a license may be required. (see: https://www.sdcard.org/developers/howto/ )

Kada se ode tamo, može se doznati da već i za R&D traže 1000 USD godišnje + potpisivanje NDA (ako nisi učlanjen, cifra za članstvo vjerujem da te tjera suze na oči). Pa ti koristi 4-bitni transfer.

Za ovo stvarno nisam znao. Izuzetno bezobrazno. Jedan od razloga da ne radim sa njima. Ja koristim STM32F4 i normalno koristim 4 bit sdio + fatfs.
Ovo je izuzetno bezobrazno u 21. veku.

XMOS je dao lib koji tjera SPI i SDIO i dao to upozorenje, a SD konzorcij traži da im se plati. Nisam siguran da su ST korisnici izuzeti ovoga, jer "patent je patent". Možda i jesu ako je ST platio za svoje MCU, kao što je mislim slučaj sa CAN.

EDIT: Evo jedno mišljenje na ovu temu.

Mislim da je za ovo stvar malo drugacija. Ista je prica i za profibus. Ti mozes slobodno da koristis svaki od pomenutih drajvera/komunikacionih kanala, a na svom uredjaju ne smes da stavis znak, npr. Profibus ili CAN ili sl. dok ne platis clanstvo u odredjenoj organizaciji. Tada dobijas mogucnost da na svom uredjaju na slotu za usd karticu postavis znak usd organizacije. Ako karticu koristis interno u uredjaju, bez vadjenja, ne treba ti nikakva dozvola. Trenutno sam u istoj fazi pregovora sa PI organizacijom, pa zbog toga znam kako ide. Inace imam uredjaje koji koriste usd i imaju CE znak i prodaju se, ali nemam nalepnicu usd i nemam problema.

[prasimix]

Dobrodošli u realan svijet, gdje pravednici (udruženi u konzorcije) svoj težak rad štite tzv. patentima (mehanizmom koji su psihopate doveli do apsurda baš kao i sve druge ljudske ideje). Evo što sam našao u XCORE libu za SD Card:

Beware: 4bit SD protocol is subject to petents of the SD Association. When enabled on commercial products a license may be required. (see: https://www.sdcard.org/developers/howto/ )

Kada se ode tamo, može se doznati da već i za R&D traže 1000 USD godišnje + potpisivanje NDA (ako nisi učlanjen, cifra za članstvo vjerujem da te tjera suze na oči). Pa ti koristi 4-bitni transfer.

Za ovo stvarno nisam znao. Izuzetno bezobrazno. Jedan od razloga da ne radim sa njima. Ja koristim STM32F4 i normalno koristim 4 bit sdio + fatfs.
Ovo je izuzetno bezobrazno u 21. veku.

XMOS je dao lib koji tjera SPI i SDIO i dao to upozorenje, a SD konzorcij traži da im se plati. Nisam siguran da su ST korisnici izuzeti ovoga, jer "patent je patent". Možda i jesu ako je ST platio za svoje MCU, kao što je mislim slučaj sa CAN.

EDIT: Evo jedno mišljenje na ovu temu.

Mislim da je za ovo stvar malo drugacija. Ista je prica i za profibus. Ti mozes slobodno da koristis svaki od pomenutih drajvera/komunikacionih kanala, a na svom uredjaju ne smes da stavis znak, npr. Profibus ili CAN ili sl. dok ne platis clanstvo u odredjenoj organizaciji. Tada dobijas mogucnost da na svom uredjaju na slotu za usd karticu postavis znak usd organizacije. Ako karticu koristis interno u uredjaju, bez vadjenja, ne treba ti nikakva dozvola. Trenutno sam u istoj fazi pregovora sa PI organizacijom, pa zbog toga znam kako ide. Inace imam uredjaje koji koriste usd i imaju CE znak i prodaju se, ali nemam nalepnicu usd i nemam problema.

Pa nitko neće imati problema dok nije na radaru patent trollova, a kada oni krenu, e onda zavisi u kakvoj si "jurisdikciji", koliko si im dohvatljiv.