Greetings all,

I've been looking to see if there are any details available on the font sets which are built into the Eve3 series of chips, but haven't found anything specific.

I'm interested in knowing what the different fonts are, and what licenses apply to their use.  It would also be helpful to know for each of the built in fonts, what the sizes are.  (Regarding size: is there a corresponding point size assuming a given dpi, or some other similar metric)

This information will be helpful to us both for updating our user-manual to reflect the new graphic layouts, and for the purposes of duplicating the appearance of our UI on other platforms.

Many thanks!

Hey all,

I've been over the doc and have been playing with both the current FG color, as well as the control color commands, but haven't found any way to change the appearance of the drop shadows used in 3D controls.

In particular, we're evaluating a black on white theme, however the drop shadow on text in 3D controls remains black causing black text to appear smeared along the shadow axis.  Is there any way to change the colors used for these effects without abandoning the 3D look or built in controls?

Cheers!

Greetings all!

Related to my other post on aborting a pending swap operation, I'm also seeking to clear the co-processor's command fifo.

Based on the "Coprocessor Faults" section of the programming guide, and my assumption that writing to REG_CMD_READ during co-processor execution would likely lead to state issues, I first attempted a reset similar to the recovery steps listed in the guide.  This however led to large portions of the screen not being displayed correctly.  Assuming that I was trying to feed the FIFO too early in the co-processor's initialization following reset, I had inserted delays following the reset as a test, but saw no change in observed behavior.

What appears to work reliably is simply copying the contents of REG_CMD_WRITE to REG_CMD_READ.  Upon doing this, I am seeing the INT_CMDEMPTY interrupt asserted, and correct 0xFFC reported by REG_CMDB_SPACE.  I'm skeptical that this is the safest way to proceed, but have otherwise been unable to use REG_CPURESET for this purpose.

My chief concern with clearing the fifo with the x_WRITE to x_READ copy, is what happens if the co-processor is part way through processing a multi-word command.  Would it still be expecting parameters to follow?  This smells like a race condition waiting to happen.

Any feedback on this approach, or suggestions on what to do instead?

** Side note regarding REG_COPRO_PATCH_PTR: I'm seeing conflicting info on properly using this register during the reset.  According to the register definition, this is a 16-bit read-only register, however the matrix orbital github code is using 32-bit operations on it.  During my tests, I've tried both sizes, and even omitting the patch pointer write from the reset.  All 3 of these cases gave me the same result.

Many thanks!

Hello all!

I'm in the process of evaluating and integrating the EVE3 into a commercial handheld remote for robotics and came up with some neat tricks for doing partial screen updates.  I'm here to share what I've come up with, and am curious to find out if anyone is doing anything similar.

In a nutshell, I'm using RAM_G to store blocks of DL commands, which are assembled into a display list using CMD_APPEND.  Nothing too fancy so far, however, wanting to still be able to take advantage of the coprocessor's widgets, these display list blocks are assembled in RAM_DL, and then transferred to RAM_G using CMD_MEMCPY.  This allows display lists in RAM_G to be updated, and by using segmented blocks which are assembled for display, can tolerate blocks changing in size without too much difficulty.

The CMD_APPENDs to assemble the final display list are built in RAM_G during the block construction described above.  Combined, these work out quite well as the coprocessor can feed it's own FIFO from RAM_G with some care.

Now the black magic that makes this method asynchronous.  There is no way to know ahead of time to know exactly how many commands will appear in each display list block, so ultimately, the block must be built and then the size retrieved from RAM_CMD_DL, and this has to happen before we can build the CMD_MEMCPY to move the DL block to RAM_G.  However, the coprocessor can also modify commands in it's FIFO, and this is essentially the trick:

• Tell coprocessor what to display in the DL block
• Tell coprocessor to copy the resulting block length, modifying the next instruction
• Tell coprocessor to copy that many bytes to a set destination in RAM_G

By having the coprocessor modify the contents of its own FIFO, this can all be set up in advance with the host MCU only busy while setting up the request.  Even if the coprocessor has to wait for a page-flip before it can build a new DL block, the only constraint in this case is available room in the FIFO.

I'd love to hear any thoughts, and am more than willing to share more specific detail to anyone interested.

Cheers!

Jesse