DIY evaluation board with XE216-512-TQ512
Posted: Sat Dec 30, 2017 12:32 pm
After few days of studying xCORE I decide to definitely give it a try as my next MCU platform that should goes way beyond currently used Arduino Due (32-bit), and give enough flexibility and performance that going into FPGA waters could not be just postponed, but completely unnecessary. My background in electronic is pretty basic, but I have a lots of time on disposal to invest in this adventure, and hopefully with your assistance it will be completed successfully.
As first step I tried to make a compilation of pins assigned to the following slice card and on-chip capability:
I made a table based on existing XMOS document and match LCD sliceCARD with Triangle slice slot pin mapping, and SDRAM with Star slice slot pin mapping. That also mean that LCD can address only 16-bit RGB color space (despite 24-pin bus available on display), use I2C for touchscreen controller, and that SDRAM address and data buses are multiplexed. Additionally, I presume that flash will be connected only during boot time (via QSPI). You can see columns that I've added on the right where far right column (Available) shows what is left when above mentioned hardware but also software libraries are in place:
The end result is not so encouraging, four pins that left barely could be used for one SPI channel. There is a slight chance that I misinterpret usage of USB library on this MCU and that X1D02 thru X1D09 (8 pins) are available (your input is welcome here). If not, that I have to rethink about such a "full Monty" approach and try to cut the corners or try to optimize pin usage. Regarding pin usage optimization I presume that only display addressing could be further shrink down if e.g. 16-bit parallel bus (5-6-5) is replaced with serial one using three 8-bit daisy chained shift registers. Clock frequency of 4.3" display that I'd like to use is not so high (typ 6.5 MHz) therefore clocking shift registers with three times higher frequency should be doable with xCORE. In case of serial communication, a full 24-bit RGB (8-8-8) can be deployed and pin count will drop down from 16 to 2 (clk + "strobe") and increasing total number of available pins to 20 for GPIO and few other peripherals, that I'd like to add on this evaluation board.
Thanks in advance for your comments and suggestions.
As first step I tried to make a compilation of pins assigned to the following slice card and on-chip capability:
- LCD sliceCARD
- SDRAM sliceCARD
- USB (XE216 on-chip)
- Ethernet (XE216 on-chip)
I made a table based on existing XMOS document and match LCD sliceCARD with Triangle slice slot pin mapping, and SDRAM with Star slice slot pin mapping. That also mean that LCD can address only 16-bit RGB color space (despite 24-pin bus available on display), use I2C for touchscreen controller, and that SDRAM address and data buses are multiplexed. Additionally, I presume that flash will be connected only during boot time (via QSPI). You can see columns that I've added on the right where far right column (Available) shows what is left when above mentioned hardware but also software libraries are in place:
The end result is not so encouraging, four pins that left barely could be used for one SPI channel. There is a slight chance that I misinterpret usage of USB library on this MCU and that X1D02 thru X1D09 (8 pins) are available (your input is welcome here). If not, that I have to rethink about such a "full Monty" approach and try to cut the corners or try to optimize pin usage. Regarding pin usage optimization I presume that only display addressing could be further shrink down if e.g. 16-bit parallel bus (5-6-5) is replaced with serial one using three 8-bit daisy chained shift registers. Clock frequency of 4.3" display that I'd like to use is not so high (typ 6.5 MHz) therefore clocking shift registers with three times higher frequency should be doable with xCORE. In case of serial communication, a full 24-bit RGB (8-8-8) can be deployed and pin count will drop down from 16 to 2 (clk + "strobe") and increasing total number of available pins to 20 for GPIO and few other peripherals, that I'd like to add on this evaluation board.
Thanks in advance for your comments and suggestions.