ILI9341_t3n Library basic question

C

clinker8

Well-known member
Not sure I understand fully the implications of using this library, so I have a couple of questions. @KurtE I'd appreciate your input, or anyone else who knows.

In non-DMA mode, is SPI running in a polled mode, or interrupt driven? I don't see any reference to a call to SPI using interrupts, in your code. If it is using interrupts, can you point me where it is set?

For DMA mode, I take it that one prepares a buffer, and perhaps a clip window ahead of time, and then one triggers the DMA? And once the trigger is pulled, the display routine returns and exits? And DMA uses SPI resources in the background until the clip window (or full window) is painted?

Which SPI peripheral is actually doing the work? A FlexSPI, or LPSPI instance? I am using "SPI0", the first SPI for my display. If it's LPSPI, isn't the clock limited to 30MHz, according to the chip spec? But I can change _SPI_CLOCK to 60 MHz?

Thanks. Appreciate any and all help on this.
 
Non- DMA mode - polled

DMA mode - lpspi, flexspi is used for things like memory chips.

I have posted, a more detailed pin chart several times, including the one Paul has linked to from the Teensy pin out page, including:
Other versions are up on github...

It is also easy to look up some of this information, for example: look at the SPI library:
look at SPI.cpp, search for IMXRT, which will get you down to the areas specific to Teensy 4.x
Then look for SPIClass: you will find a line like:

Code: 
SPIClass SPI(IMXRT_LPSPI4_ADDRESS, (uintptr_t)&SPIClass::spiclass_lpspi4_hardware);
Which lets you know that SPI object is using LPSPI4 ...
Ditto for SPI1:
Code: 
SPIClass SPI1(IMXRT_LPSPI3_ADDRESS, (uintptr_t)&SPIClass::spiclass_lpspi3_hardware);
and ...

For DMA mode, I may not have put in the code to clip the output, as you would have to setup to not output all
of the memory, but instead go so many bytes and skip so many... Plus if you turned on continuous mode, it would
potentially have to change on every frame...

But it has been a while since I played with it on Teensy... Well not 100% true. I have played some recently with a hacked up version,
that runs on a Teensy Micromod using zephyr... But that probably does not count... Also have not tried DMA on zephyr...

30Mhz is what they say is the maximum. Some have luck pushing it higher, some dont...
 
KurtE said:
Non- DMA mode - polled

DMA mode - lpspi, flexspi is used for things like memory chips.

I have posted, a more detailed pin chart several times, including the one Paul has linked to from the Teensy pin out page, including:
Other versions are up on github...

It is also easy to look up some of this information, for example: look at the SPI library:
look at SPI.cpp, search for IMXRT, which will get you down to the areas specific to Teensy 4.x
Then look for SPIClass: you will find a line like:

Code: 
SPIClass SPI(IMXRT_LPSPI4_ADDRESS, (uintptr_t)&SPIClass::spiclass_lpspi4_hardware);
Which lets you know that SPI object is using LPSPI4 ...
Ditto for SPI1:
Code: 
SPIClass SPI1(IMXRT_LPSPI3_ADDRESS, (uintptr_t)&SPIClass::spiclass_lpspi3_hardware);
and ...

For DMA mode, I may not have put in the code to clip the output, as you would have to setup to not output all
of the memory, but instead go so many bytes and skip so many... Plus if you turned on continuous mode, it would
potentially have to change on every frame...

But it has been a while since I played with it on Teensy... Well not 100% true. I have played some recently with a hacked up version,
that runs on a Teensy Micromod using zephyr... But that probably does not count... Also have not tried DMA on zephyr...

30Mhz is what they say is the maximum. Some have luck pushing it higher, some dont...
Click to expand...
Thanks for responding.

For SPI being polled, can I interrupt it? Can any level interrupt it? Even 128?

For the DMA mode, then, right now it's just refreshing the whole screen? Rather than computing a clip window and all that byte skipping?

But this whole screen refresh allows my program to go on it's merry business doing control? I only need to do a refresh every 150-160ms, can this be done with DMA, or would it take longer than that amount of time? I'm allegedly using 60 MHz for writing, seems to work. I made a PCB so I'm limited on what kind of changes I can make, or I have to do a respin.
 
clinker8 said:
For SPI being polled, can I interrupt it? Can any level interrupt it? Even 128?
Click to expand...
It is standard code, which does not turn off interrupts, so yes.

clinker8 said:
For the DMA mode, then, right now it's just refreshing the whole screen? Rather than computing a clip window and all that byte skipping?
Click to expand...
The released code always updates the full screen.

There is a branch (try_clipped_async), where I was experimenting with allowing it to be clipped. I was experimenting with it
two years ago. Don't remember how well it was working.

clinker8 said:
But this whole screen refresh allows my program to go on it's merry business doing control? I only need to do a refresh every 150-160ms, can this be done with DMA, or would it take longer than that amount of time? I'm allegedly using 60 MHz for writing, seems to work. I made a PCB so I'm limited on what kind of changes I can make, or I have to do a respin.
Click to expand...
Yes - there are some logical constraints, like best to not try to update the display buffer while it is still doing the updateScreenAsync...
yes, you should be able to do more than 7 updates per second. You can always measure how long it took, and/or find out if the update
has completed...
 
KurtE said:
It is standard code, which does not turn off interrupts, so yes.


The released code always updates the full screen.

There is a branch (try_clipped_async), where I was experimenting with allowing it to be clipped. I was experimenting with it
two years ago. Don't remember how well it was working.


Yes - there are some logical constraints, like best to not try to update the display buffer while it is still doing the updateScreenAsync...
yes, you should be able to do more than 7 updates per second. You can always measure how long it took, and/or find out if the update
has completed...
Click to expand...
Thanks. Hmm, I'm getting impacted in my control loop by even updating the RPM, which is several milliseconds. 10's of milliseconds corresponds to a huge phase error. Definitely need to look into DMA, as long loop times give the motor control system heartburn (loss of synchronization). SPI is for the display only, so if it can run "autonomously" with a quick call and return, it would be very helpful. Can't afford the pauses in the main loop, at least with the current SW architecture. I have 3 years experience with the current architecture running on my lathe, so I'd rather not make drastic changes, unless I have to.

Understood about not calling updateScreenAsync before it is done...
 
Solved my main issue by blocking display updates during a critical time, namely the synchronization period. I blank the updates for two revolutions of the spindle. Also elevated the priority of some interrupts. That helped a lot.
 
You must log in or register to reply here.
Back
Top