BRT Community

Hi,

thanks for your effort!

greetings!

Hi,

I just wanted to ask, if theres some feedback regarding the qspi issue?

Thanks + greetings!

I took some more captures. I noticed that the delay between the addressing bytes is in single mode ~260ns besides ~1us in quad mode. Could this already cause trouble, that the chip isnt recognizing the addressing sequence at all?

Enclosed some more captures.

• QSPI Reg Id complete transfer sequence 32us
• SSPI REG_SPIWIDTH changing to QSPI and two dummy bytes
• SSPI delay between adressing bytes 260ns
• QSPI delay between adressing bytes 1us

Thanks for your help and best regards

Hi,

sorry for my late response!
Enclose you´ll find the QSPI caputre of reading REG_ID.

Unfortunately its not possible to put everything to one screen so I splitted it in the interessting parts.

• SS till 1st CLK 70ns
• Dummy sequence between falling edge of last 12,78us
• Clocking out GPU response 3,15us
• Last falling edge of GPU response Clks till SS unassert 12,5us
• complete QSPI RED_ID sequence 31,94us

Hi.
Thanks for your reply and the advise about the SampleApp, I checked it already but the involved routines are identicial the the ones I´m using. I forgot to mention that I´m using an Infineon XMC4500 MCU.

The reconfiguration of the REG_SPI_WIDTH is done twice during Eve_BootupConfig().

Enclosed the code of my boot sequence.

I can also provide some pictures from the logic analyzer, if this helps.
The LA shows, that the adressing is send out correct in QSPI and after some delay where the bus isnt driven from MCU or GPU the MCU sends 0xFF to provide the GPU with a clock to send out data.
For the REG_ID it performs Ft_Gpu_Hal_Rd8() where I read (host->spinumdummy + 1) from the GPU and om QSPI 2DUMMY my MCU sends 3 time 0xFF. The sequenz is SEND(0xFF) READ(QSPI) therefore I think the IOs are not blocked for the GPU and if the GPU would send data while the MCU sends 0xFF I could identify it trough missmatching signal levels on the IO lines.


Thanks for your help!



Ft_Gpu_Hal_Powercycle(s_Host, FT_TRUE);
Ft_Gpu_Hal_SetSPI(s_Host, FT_GPU_SPI_SINGLE_CHANNEL, FT_GPU_SPI_ONEDUMMY);

Ft_Gpu_HostCommand(s_Host, FT_GPU_EXTERNAL_OSC);
Ft_Gpu_Hal_Sleep(300);
Ft_Gpu_HostCommand(s_Host, FT_GPU_ACTIVE_M);
Ft_Gpu_Hal_Sleep(300);

ft_uint8_t chipid;
chipid = Ft_Gpu_Hal_Rd8(s_Host, REG_ID); //This REG_ID in Single SPI is read correct


/*Display Setup */
Ft_Gpu_Hal_Wr16(s_Host, REG_HCYCLE, FT_DispHCycle);
Ft_Gpu_Hal_Wr16(s_Host, REG_HOFFSET, FT_DispHOffset);
Ft_Gpu_Hal_Wr16(s_Host, REG_HSYNC0, FT_DispHSync0);
Ft_Gpu_Hal_Wr16(s_Host, REG_HSYNC1, FT_DispHSync1);
Ft_Gpu_Hal_Wr16(s_Host, REG_VCYCLE, FT_DispVCycle);
Ft_Gpu_Hal_Wr16(s_Host, REG_VOFFSET, FT_DispVOffset);
Ft_Gpu_Hal_Wr16(s_Host, REG_VSYNC0, FT_DispVSync0);
Ft_Gpu_Hal_Wr16(s_Host, REG_VSYNC1, FT_DispVSync1);
Ft_Gpu_Hal_Wr8(s_Host, REG_SWIZZLE, FT_DispSwizzle);
Ft_Gpu_Hal_Wr8(s_Host, REG_PCLK_POL, FT_DispPCLKPol);
Ft_Gpu_Hal_Wr16(s_Host, REG_HSIZE, FT_DispWidth);
Ft_Gpu_Hal_Wr16(s_Host, REG_VSIZE, FT_DispHeight);
Ft_Gpu_Hal_Wr16(s_Host, REG_CSPREAD, FT_DispCSpread);
Ft_Gpu_Hal_Wr16(s_Host, REG_DITHER, FT_DispDither);

/* Touch configuration */
Ft_Gpu_Hal_Wr16(s_Host, REG_TOUCH_RZTHRESH, RESISTANCE_THRESHOLD);


/*IO Setup*/
Ft_Gpu_Hal_Wr16(s_Host, REG_GPIOX_DIR, 0xffff);
Ft_Gpu_Hal_Wr16(s_Host, REG_GPIOX, 0xffff);

/*Init Screen*/
Ft_Gpu_Hal_WrMem(s_Host, RAM_DL, (ft_uint8_t *)FT_DLCODE_BOOTUP, sizeof(FT_DLCODE_BOOTUP));
Ft_Gpu_Hal_Wr8(s_Host, REG_DLSWAP, DLSWAP_FRAME);

Ft_Gpu_Hal_Wr8(s_Host, REG_PCLK, FT_DispPCLK);//after this display is visible on the LCD

Ft_Gpu_Hal_SetSPI(s_Host, FT_GPU_SPI_QUAD_CHANNEL, FT_GPU_SPI_TWODUMMY);
//Here I change my MCU to Quad SPI
ft_uint8_t u8ChipidQSPI
ft_uint8_t u32ChipidQSPI
u8ChipidQSPI = Ft_Gpu_Hal_Rd8(s_Host, REG_ID); //This REG_ID in QSPI only read
u8ChipidQSPI = Ft_Gpu_Hal_Rd32(s_Host, REG_ID); //This REG_ID in QSPI only read



Hi everyone,

I can´t get my FT810 in QSPI Mode running. In single mode it´s perfectly working but as soon as I change to qspi nothing works.
I checked the entire data stream with an logic analyzer. For me it seams, that in quad, the ft810 never starts to send any data back.
The SPI_WIDTH register is correct addressed with the needed paramter (0x2 for qspi 1 dummy, 0x6 for qspi 2 dummy), thats what I still can see with the LA becuase it´s in single mode.

The register I´m trying to read it REG_ID because for my unterstandig this should be a good reference to verify  if qspi reads proper results.

It´s  approx 7us from the last address byte to the receive procedure of my MCU, but I can´t see any usefull data comming form the ft810.

Does some have have FT810 or BT816 running in QSPI?

Im using a EVE4.5 GUI with the corresponding EVE Framework.

Thanks for any help you guys can provide!

Cheers!

Hi Rudolph,

thanks for your feedback and the good summary about interrupt handling and its pitfalls/design consideration.
I will check your library and see if I can gain more insight for my project.

I forgot to mention, that my system runs an OS and the Gui has the lower priority for the scheduling. Thats actually why I considered an interrupts approach first because I think it´s better to implement than adapting the entire timing for the scheduling. But I´m at the very beginning of the interrupt implementation.

I´ll keep this thread updated with my progress maybe some might be interested in it too and also leave some lessons learned to posterity

Cheers!

Hi all,

I searched quite a lot,  checked the datasheet and tried to analyze the code but can´t find a good starting point how to run my GUI interrupt-driven.

I want to reduced the system load and therefore only communicate with the gpu when there is a touch input by the user.

But I can´t get a grip of what to trigger by the interrupt handler of the mcu once a touch occurs. I guess it have to assign touch tags of my elements and then handle the ESD_Slot (idle, render, update) within the ISR?
I´m using an AtsamE70 with Ft810. The system works completely fine, I ported the necessary spi routines to the atmel mcu.

Maybe someone can give me a hint or point out where my view of the interrupt-driven approach is faulty.

Thanks + greetings