BRT Community

Hi,
just joined recently, I've been using the EVE chip for a couple of years now but still need to lean things about what it can do.

glad to have found this forum

PhilipJ

Hi
thanks for this info.
I was unaware that I could let the EVE take care of the wraparound for the RAM_CMD buffer. Currently my library functions write to RAM_CMD + offset, and my code increments offset with Modulo 4096 to do the wrap-around.

     i.e. offset = (offset + 4) % 4096;

I had been trying to work out how I could build a Command List in memory and then use a DMA channel to transfer the buffer to the EVE via the SPI interface. I couldn't work out how the DMA would deal with the Modulo 4096 on the address it was writing to but with what you guys have described above, it isn't necessary. The DMA would just write to REG_CMDB_WRITE each time!!

Thanks
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

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

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

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.