Forum Rule: Always post complete source code & details to reproduce any issue!
Page 10 of 10 FirstFirst ... 8 9 10
Results 226 to 229 of 229

Thread: Playing around with yet another version of ILI9341_t3 library (ILI9341_t3n)

  1. #226
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,538
    @kjn - Looks good, Also looks like I need a different version of SDFat .... I think mine is still going to his Beta project...

    One thing I see different which explains some of the speed differences. I was reading a raw BMP file, with 3 bytes per pixel and the overhead of the header.... Where yours is the previously processed one...

    As for Max Speed you could actually draw the screen, see if can sort of do the math again.

    Lets say in continuous mode, you are only outputting the pixels: so 320*240*16, but will say 17 instead of 16 for one SPI clock gap between pixel
    And if your SPI was running lets say at a maximum 30mhz, then 30000000/(320x240*17) = 22.977 so about 23 frames per second.

    Which is in line with what you observe.

    Now how to achieve that, with minimal tearing and the like?

    One thing I considered and have not done to ili9341_t3n is to have the DMA operation, give some more possible feedback as part of the operation.

    Suppose, that in order to output the ILI9341 frame buffer of 320x240x2= 153600 bytes you have to split this up into something like 3 or 4 DMASettings as each setting can only output 32767 words...
    Note: The actual mechanics are different for T3.6 versus T3.5 (especially SPI1/2) and T4...

    Currently in theory I may interrupt once per frame and update frame counter (or stop) depending on mode.

    What I thought about doing is to maybe interrupt more often, and maybe have some form of partial frame count or percentage of frame or ??? So suppose we have a 50% marker we detect.

    Then code could be written, that says, Ok top half of screen output, so read in the first half of next file, when it says frame is done, read in bottom half of the next file... Again this would assume that reading in is faster than display update...

  2. #227
    Quote Originally Posted by KurtE View Post
    @kjn - Looks good, Also looks like I need a different version of SDFat .... I think mine is still going to his Beta project...

    One thing I see different which explains some of the speed differences. I was reading a raw BMP file, with 3 bytes per pixel and the overhead of the header.... Where yours is the previously processed one...
    So the file I am using still is a full bitmap with header, but colour depth is 16bit (so not technically an "official" bitmap).
    I used some conversion utilities (and a few programming tricks) from the ILI9341_due library, which was forked from the ILI9341_t3 library many years ago: http://marekburiak.github.io/ILI9341_due/
    Check out the arcs function - pretty cool.

    I've actually been looking at if I add another 8bpp to add an alpha channel - but this is the next project.


    Quote Originally Posted by KurtE View Post

    As for Max Speed you could actually draw the screen, see if can sort of do the math again.

    Lets say in continuous mode, you are only outputting the pixels: so 320*240*16, but will say 17 instead of 16 for one SPI clock gap between pixel
    And if your SPI was running lets say at a maximum 30mhz, then 30000000/(320x240*17) = 22.977 so about 23 frames per second.

    Which is in line with what you observe.
    So the implementation is already running at max "stock" speed - is there scope to o/c the FBUS/SPI and see if we can get any higher? How do you do this on a 3.6?
    I just had a look Frank said he had overclocked to 60MHz bus speed, which using the above math would allow ~44FPS and 22ms refresh, this is still longer than an SD card read and would leave 6-8ms spare for "work".

    Now how to achieve that, with minimal tearing and the like?

    One thing I considered and have not done to ili9341_t3n is to have the DMA operation, give some more possible feedback as part of the operation.

    Suppose, that in order to output the ILI9341 frame buffer of 320x240x2= 153600 bytes you have to split this up into something like 3 or 4 DMASettings as each setting can only output 32767 words...
    Note: The actual mechanics are different for T3.6 versus T3.5 (especially SPI1/2) and T4...

    Currently in theory I may interrupt once per frame and update frame counter (or stop) depending on mode.

    What I thought about doing is to maybe interrupt more often, and maybe have some form of partial frame count or percentage of frame or ??? So suppose we have a 50% marker we detect.

    Then code could be written, that says, Ok top half of screen output, so read in the first half of next file, when it says frame is done, read in bottom half of the next file... Again this would assume that reading in is faster than display update...
    Breaking up the frame-buffer is a good idea - I'm not sure about execution in code.

    One option is the drawBMP routine, as it draws in line by line, after it fills the first line to the FB it could call the refreshAsync(0) routine. As the refresh flushes in the same direction as the draw routine fills the buffer. The fill routine would always be a few rows ahead of the refresh. It really only works when trying to draw frames as quick as possible but would get you towards a simultaneous operation of the two processes.

  3. #228
    Junior Member
    Join Date
    Sep 2019
    Posts
    11
    So I have been playing with t3n on T4 using the framebuffer with good results but I wondered if it would make sense to have two framebuffers - you could be composing to one while the other one was being sent via dma in the background. I'm trying to figure out if it would be worth it or really get you anything, does it make any sense to do this?

  4. #229
    Quote Originally Posted by 1of9 View Post
    So I have been playing with t3n on T4 using the framebuffer with good results but I wondered if it would make sense to have two framebuffers - you could be composing to one while the other one was being sent via dma in the background. I'm trying to figure out if it would be worth it or really get you anything, does it make any sense to do this?
    I think it would be really interesting to explore this idea but I don't know enough about the low level mechanics to know if it's feasible. I think though if you had two framebuffers both dedicated to one screen then you might be able to do a comparison of the two and only send pixel data for pixels that have changed since the last update? Can anyone who knows this better comment on if this is remotely feasible for the way we're interfacing with these screens?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •