12-26-2017, 11:47 AM
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:
![[Image: atPhwZV.png]](https://i.imgur.com/atPhwZV.png)
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).
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).