Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[PhilipJ]

Hi,
has anyone successfully used the CALL and RETURN features of the FT81x display driver chips?
I am specifically using the FT813 to drive a 5" 800x480 TFT screen, All my current programming works by building a Co-Processor command list and ending it with CMD_SWAP.
Recently I have found that my lists are getting pretty close to maximum size, I've been looking for ways to either shrink the list or get more space and I've seen that the RAM_DL is actually twice the size of the RAM_CMD so my thought was to write a CoPro list that builds a DisplayList somewhere high up in the RAM_DL _BUT_ doesn't execute it; then build another CoPro list that amonst other stuff, includes a CALL to the first DL and that's the one that has the CMD_SWAP in it.

Any advice would be gratefully received
PhilipJ
PS: I know about APPEND, but I wanted to know if my method above would work.

[Rudolph]

No, I have not even tried to use CALL and RETURN since I only use the co-processor to build the display list.

But, have you checked the size of the resulting display list?
That RAM_DL is twice the size of RAM_CMD does not help when you run out of space in RAM_CMD since the resulting display-list
in RAM_DL that is generated from RAM_CMD is a lot larger as commands like CMD_BUTTON are generated with several display list commands.

Just mem-read-16 REG_CMD_DL before building a new list, that is the size in bytes of the previous list.

Or check what the EVE Screen Editor does.
Just putting 10 buttons on the screen fills up RAM_DL by 24%.
And when you click on the "Inspector" tab you see that 11 lines of Coprocessor commands get translated to 550 entries in the display list.
36 buttons and the display list is full.

So no, the RAM_CMD size usually is not the limiting factor.
At least not if you use widgets.

My debug output always lists both the RAM_CMD size and the RAM_DL size.
Well, okay, I also use CMD_APPEND but even without it you could fill up RAM_DL without filling RAM_CMD.

[BRT Community]

Hello,

Yes it is important to note RAM_DL usage when constructing co-processor lists as this is ultimately the limiting factor when creating a given screen.

Section 2 of the following application note covers co-processor usage:
BRT-AN-006 FT81x Simple PIC Example

With your co-processor lists, how much of RAM_DL is being utilized?

Best Regards,
BRT Community

[PhilipJ]

Hi,
thanks for the replies.

I have been checking the RAM_DL size and understand that I have to be wary that a CMD list may produce a DL list that is bigger than itself. At the moment I am just experimenting to see exactly what I can get out of the chip. I don't use any of the built-in widgets so I think the only thing that grows bigger when transfered to the DL is text, please correct me if I'm wrong.

I have the EVE Screen Editor program (v3.3.0) and I was trying experiments with it at first and I did successfully build a CMD_LIST that used subroutines to draw a repeating graphic (bitmap) and use less RAM but it is a bit tricky knowing where the subroutine will be hence my interest in whether I could load a DL into a fixed location in RAM_DL (as a subroutine at a high address) and then put another DL in starting at address 0, that calls it.

Since I posted, I have successfully loaded the CMD list, designed in EVE Screen Designer, into my specific hardware and it came out as expected EXCEPT the bitmap image that has those small 'speaker' icons in coloured GREY appeared BLUE on the real hardware ?? I have attached a JPG of the screen as it is displayed in EVE Screen EDitor, and the relevant CoProcessor CMD List.

If you can see why the bitmap colours are "turning blue" I would be most grateful for the advice...

Regards
PhilipJ

[PhilipJ]

Hi again,

please ignore my comments about the bitmap "going blue".
Something went wrong in the conversion process that I use to build the tables for loading the bitmaps into GMEM.
Previously I have been using the command line program ImageConvert. I tried this time with Asset Builder and the colours are now correct.

Still looking for advice on how to reference the start address of a subroutine for CALL and RETURN ??

regards
PhilipJ

[darkjezter]

How to reference the subroutine?  I haven't played with this yet, but I'll try to address your question.

The doc for the 815 (which I'm using) shows this:
 - dest
The offset of the destination address from RAM_DL which the display command is to be
switched to. BT815/6 has the stack to store the return address. To come back to the next
command of source address, the RETURN command can help.
The valid range is from 0 to 8191.

So, when you make the call you need to include the offset from RAM_DL to the beginning of the routine in the command.  As for what that offset will be, that depends on where you place it when building the display list.  My only observation here, is you might need to be careful placing the routine at the end of your list.  From my own testing, it seems as though RAM_DL is a window into one of two independant display lists, and the swap might just be alternating the roles of those lists.  One which is being constructed, and the other which is actively being displayed.

If that's true, then your routine should be fine anywhere in RAM_DL, maybe even if it appears after the DISPLAY command.  If it isn't, then you might need your routine to appear before DISPLAY.  In that case, you may be better off placing the routines near the beginning of RAM_DL, and skipping over them using the JUMP command.  Then you can easily know ahead of time where the routine was placed.  If using the coprocessor to build the display list, you can use REG_CMD_DL to determine where the next location in RAM_DL is that will be written to.

The only other note I'd add, is you will need to place these routines in RAM_DL for each time you build a new display list.  A common method used with these screens is to have a fixed portion of the screen content (say background and state setup) at the beginning of the list, followed by dynamic content which may change from frame to frame.  The routines would naturally fit into that fixed portion, you just need to be sure to JUMP past them until you intend to call them.

I'm not sure if this helps, but I am interested myself in exploring the subroutines in the display list (eventually).  Just keep in mind, that the available DL memory is just one aspect of the limits of what you can get this chip to do.  Every scanline drawn to the display has to execute the entire display list, and how long that takes will be a function of both the clock speed and the complexity of the display list.  At best, complex lists will slow down the frame rate while at worst you may wind up with hard to diagnose graphic glitches.

Keep us posted! 

[BRT Community]

Hello,

Our main SampleApp includes a couple of examples of using the CALL and RETURN functions. You can see these in the SAMAPP_GPU_Vertex_Translate() and SAMAPP_GPU_StreetMap() functions.

Just a quick note on frame rate, the display list complexity does not affect this, but it may result in performance issues for a particularly complex list. The EVE series of ICs do not include a frame buffer, they dynamically clock out each computed pixel on the screen. A displays size and what the Pixel Clock is running at will determine the achievable performance.  As each pixel is clocked out EVE must calculate what to draw for this given pixel, if the refresh rate is too high and the number of intersecting graphics commands for a given pixel is too high then you may run into a case where some pixels aren’t drawn.

If you’re curious the refresh rate of the screen can be worked out in the following manner:
                Fps = (System Clock/REG_PCLK) / (VCYCL * HCYCLE)

If we take the example from the following WQVGA settings:

Code: [Select]

     // WQVGA display parameters
    lcdWidth   = 800;                                                           // Active width of LCD display
    lcdHeight  = 480;                                                           // Active height of LCD display
    lcdHcycle  = 928;                                                           // Total number of clocks per line
    lcdHoffset = 88;                                                            // Start of active line
    lcdHsync0  = 0;                                                             // Start of horizontal sync pulse
    lcdHsync1  = 48;                                                            // End of horizontal sync pulse
    lcdVcycle  = 525;                                                           // Total number of lines per screen
    lcdVoffset = 32;                                                            // Start of active screen
    lcdVsync0  = 0;                                                             // Start of vertical sync pulse
    lcdVsync1  = 3;                                                             // End of vertical sync pulse
    lcdPclk    = 2;                                                                // Pixel Clock
    lcdSwizzle = 0;                                                             // Define RGB output pins
    lcdPclkpol = 1;                                                             // Define active edge of PCLK
                 

HCYCLE = 928
VCYCLE = 525
VCYCLE * HCYCLE  = 487,200

Note: REG_PCLK is using the value 2 which will divide the clock down to 30Mhz (FT81x).

Fps = 30,000,000/487,200 = ~ 61


Best Regards,
BRT Community

[darkjezter]

I took the time to look at the example, which includes the routines after the DISPLAY command.  Though, I see that including DISPLAY, there are 10 commands preceeding the routine start.  The calls use 10 as the offset, which is fine.  But wouldn't that make the documentation incorrect, as the offset is in 32-bit words and not bytes?  According to the doc, the valid range for call is 0-8191, but shouldn't that range actually be 0-2047 for an 8KB display list?

Edit:
"Just a quick note on frame rate, the display list complexity does not affect this"
Is this true even given REG_ADAPTIVE_FRAMERATE which by default is set?

[PhilipJ]

Hi,
and once again thanks for the replies.

Darkjezter: you make a very good point about the display list swap process. My idea would work if the chip has 2 internal areas of memory and a pointer is deciding which area I can write into while the other area is being displayed, but, if I failed to write my subroutine into high memory each time I wanted to swap then the display process would go wrong!!

BRT Community: thanks for the link to SampleApp, I will check through it for further inspiration. Also thanks for the details about the rame rates etc. Is there a simple way to know how long it takes to process a Display List when it is being displayed to be sure that it is not overrunning ? Perhaps in any new chips we could have a STATUS register that could include a Display Overrun flag ? Perhaps there already is one and I've just never found it...

I have changed my CPU process a little so that I now build a "table" of CoProcessor commands in memory and so now the problem of how to determine the offset address to the subroutine becomes a 'C' coding problem. It would be nice to be able to create a "label" at the point in the table where the subroutine is and refer to it by name as the address for the CALL. Sadly 'C' does not allow you to put lables in arrays, only in code functions.

Anyway. I have learned a great deal more about the EVE chip through this, can't wait for the next, bigger version to become available!!

PhilipJ

[BRT Community]

Hello,

I will clarify with the dev team on the CALL API documentation.

In the case of using REG_ADAPTIVE_FRAMERATE EVE will adjust the frame rate accordingly to allow for more time where pixels have many intersecting graphics commands to be calculated.

Currently there isn't there isn't a such a register available, but this is a feature  we are looking into adding for future revisions of EVE.

Best Regards,
BRT Community

[darkjezter]

"Currently there isn't there isn't a such a register available"

This is good to know, I got the information for that register from the chip datasheet.  Document No.: BRT_000220 Version 1.0