Print

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

[Rudolph]

Hello,

why is this command named *GET*MATRIX?
This is not all what it does and it definately does not do the opposite of what SETMATRIX does.

GETMATRIX should be named SETMATRIX.
And the one that is now named SETMATRIX should be named ACTIVATEMATRIX.
And maybe a counter-part to what the current GETMATRIX does is missing.

That is if I am not completely wrong here.

[Rudolph]

Okay, since I am doing some heavy refactoring I stumbled over CMD_GETMATRIX again.

I have two sets of more recent example code from Bridgetek.
One implementation has a function EVE_CoCmd_getMatrix() that reads back these values from the cmd-FIFO after executing the command.
The other implementation has a function EVE_CMD_GETMATRIX() that writes the supplied parameters to the cmd-FIFO.

One of these two is implemented wrong - which one?

The documentation for this command is not clear.


---
5.51 CMD_GETMATRIX - Retrieves the Current Matrix Coefficient
Retrieves the current matrix within the context of the co-processor engine. Note the matrix within
the context of the co-processor engine will not apply to the bitmap transformation until it is passed
to the graphics engine through CMD_SETMATRIX.

Parameters
a
output parameter; written with matrix coefficient a. See the parameter of the command
BITMAP_TRANSFORM_A for formatting.
---

If this command really retrieves parameters from the co-processor engine, the additional note makes no sense.
The note implies that these parameters are written to the cmd-FIFO and that the command needs an additional
call to CMD_SETMATRIX to make to co-processor use the parameters.

[BRT Community]

Hi Rudolph,

Yes, this command will take the current matrix coefficients and put them in the co-processor FIFO for you to read. This works similarly to the CMD_GETPROPS for example where we write dummy values as part of the command and EVE then replaces those with the actual results. After the command completes, you can go back to the locations of the FIFO where you wrote the dummy values to read the result.

The main aim of this command is so that your MCU can read the current matrix values used internally within EVE and so to allow this it must take them and copy them to mapped memory which is in this case the CMD FIFO.

The reason for the note is that by loading the identify matrix, and by applying transforms, you are just changing the values of the current matrix inside the EVE device. But in order for them to have an effect, you must then set them as a bitmap transform so that they will affect your image etc.

Sorry, it was maybe not clear that in some code samples, although we call them by their a to f names, we would be writing the dummy value for all of these. And so you would call it with 0 for each parameter as the co-processor will then write over these. In BRT_AN_025 for example, we will add a comment to the code about this or provide an example in a future appnote to show the use of this. Also, some code examples may include the code to read the values within the same call to the function and others may need your application to read back the result.

Best Regards, BRT Community

[Rudolph]

Okay, the note makes more sense now.
While you can get the matrix coefficents from the co-processor using CMD_GETMATRIX, the values that you get might not yet affect the bitmap.

So, the implementation in BRT_AN_025 is wrong:

Code: [Select]

void EVE_CMD_GETMATRIX(int32_t a, int32_t b, int32_t c, int32_t d, int32_t e, int32_t f)
{
    HAL_Write32(EVE_ENC_CMD_GETMATRIX);
    HAL_Write32(a);
    HAL_Write32(b);
    HAL_Write32(c);
    HAL_Write32(d);
    HAL_Write32(e);
    HAL_Write32(f);
    HAL_IncCmdPointer(28);
}

Or at least it is pointless and misleading as writing all these parameters to the cmd-FIFO has no effect.

So I was wrong when I initially posted back in march.
And I also have to change my implementation of EVE_cmd_getmatrix(), again.

[BRT Community]

Hi Rudolph,

You can use this call and pass in 00s so that it writes six dummy values, or you can remove the parameters and just write six sets of 00s within the function automatically instead, as shown in this code below  - see resAddr = EVE_Cmd_moveWp(phost, 6 * 4) . But in any case, dummy values should be written as part of the function so that the co-processor can replace these with the results.

You can also include the code to do the actual reading of the results as also shown here:

Code: [Select]

EVE_HAL_EXPORT bool EVE_CoCmd_getMatrix(EVE_HalContext *phost, int32_t *m)
{
            uint16_t resAddr;
            int i;

            if (phost->CoCmdHook && phost->CoCmdHook(phost, CMD_GETMATRIX, 0))
                            return false;

            EVE_Cmd_startFunc(phost);
            EVE_Cmd_wr32(phost, CMD_GETMATRIX);
            resAddr = EVE_Cmd_moveWp(phost, 6 * 4);
            EVE_Cmd_endFunc(phost);

            /* Read result */
            if (m)
            {
                            if (!EVE_Cmd_waitFlush(phost))
                                            return false;
                            EVE_Hal_startTransfer(phost, EVE_TRANSFER_READ, RAM_CMD + resAddr);
                            for (i = 0; i < 6; ++i)
                                            m[i] = EVE_Hal_transfer32(phost, 0);
                            EVE_Hal_endTransfer(phost);
            }
            return true;
}
There are lots of ways to do it (so long as you end up writing the correct data) and so users creating their libraries can choose the best way for them.

You did make a good point though that the way shown in BRT_AN_025 is not the most intuitive or efficient and so we will make some updates to improve it and so appreciate your feedback,

Best Regards, BRT Community

[Rudolph]

Hello,

my implementation for my V5 library is this now:

Code: [Select]

void EVE_cmd_getmatrix(int32_t *get_a, int32_t *get_b, int32_t *get_c, int32_t *get_d, int32_t *get_e, int32_t *get_f)
{
if(!cmd_burst)
{
uint16_t cmdoffset;

EVE_start_command(CMD_GETMATRIX);

spi_transmit(0);
spi_transmit(0);
spi_transmit(0);
spi_transmit(0);

spi_transmit(0);
spi_transmit(0);
spi_transmit(0);
spi_transmit(0);

spi_transmit(0);
spi_transmit(0);
spi_transmit(0);
spi_transmit(0);

spi_transmit(0);
spi_transmit(0);
spi_transmit(0);
spi_transmit(0);

spi_transmit(0);
spi_transmit(0);
spi_transmit(0);
spi_transmit(0);

spi_transmit(0);
spi_transmit(0);
spi_transmit(0);
spi_transmit(0);

EVE_cs_clear();
while (EVE_busy());
cmdoffset = EVE_memRead16(REG_CMD_WRITE);  /* read the graphics processor write pointer */

if(get_f)
{
*get_f = EVE_memRead32(EVE_RAM_CMD + ((cmdoffset - 4) & 0xfff));
}
if(get_e)
{
*get_e = EVE_memRead32(EVE_RAM_CMD + ((cmdoffset - 8) & 0xfff));
}
if(get_d)
{
*get_d = EVE_memRead32(EVE_RAM_CMD + ((cmdoffset - 12) & 0xfff));
}
if(get_c)
{
*get_c = EVE_memRead32(EVE_RAM_CMD + ((cmdoffset - 16) & 0xfff));
}
if(get_b)
{
*get_b = EVE_memRead32(EVE_RAM_CMD + ((cmdoffset - 20) & 0xfff));
}
if(get_a)
{
*get_a = EVE_memRead32(EVE_RAM_CMD + ((cmdoffset - 24) & 0xfff));
}
}
}

I used to write the data to EVE_RAM_CMD + offset and REG_CMD_WRITE at the end of an command.
But now I have removed the support for FT80x entirely and only use REG_CMDB_WRITE.
This has two implications for this command.
The first is that the offset can not be stored anymore before writing the dummy bytes as there is no offset.
The second is that this function can not skip writing the dummy bytes anymore by just writing the correct offset value to REG_CMD_WRITE.

I went for providing individual pointers in order to to have it consistent with other functions that return two or more parameters like CMD_GETPROPS: void EVE_cmd_getprops(uint32_t *pointer, uint32_t *width, uint32_t *height)

Apart from consistency, this way parameters can be skipped: EVE_cmd_getprops(0, &width, &height);