BRT Community

Please login or register.

Login with username, password and session length
Advanced search  

News:

Welcome to the Bridgetek Community!

Please read our Welcome Note

Technical Support enquires
please contact the team @ Bridgetek Support

Please refer to our website for detailed information on all our products - Bridgetek - Bridging Technology

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - BRT Community

Pages: 1 ... 36 37 [38] 39 40 ... 50
556
Discussion - EVE / Re: Capacitive touch screen calibration
« on: June 16, 2020, 12:01:13 PM »
Hello,

the positioning of the three dots is as follows (X,Y) : (10%w,10%h), (90%w,50%h), (50%w, 90%h) w is the width of screen resolution, h is the height of screen resolution.


Best Regards,
BRT Community

557
Discussion - EVE / Re: Problem with my custom BT815 circuit
« on: June 15, 2020, 03:42:31 PM »
Hello,

What are the voltage supplies on the board sitting at? And is there a voltage on VOUT1V2?


Best Regards,
BRT Community

558
Discussion - EVE / Re: Capacitive touch screen calibration
« on: June 15, 2020, 03:31:53 PM »
Hello,

Thanks, I have pinged the dev team to see if they can provide the point positions.

Best Regards,
BRT Community

559
Discussion - EVE / Re: Capacitive touch screen calibration
« on: June 12, 2020, 01:10:56 PM »
Hello,

Quote from: avanti on June 11, 2020, 02:41:41 PM
Are REG_TOUCH_TRANSFORM_A-F stored persistently in the EVE? And, if the chip has non-volatile memory, what else is there that doesn't clear on a power-cycle or reset?

No, REG_TOUCH_TRANSFORM_A-F are not stored persistently in EVE, it is recommended to run the CMD_CALIBRATE command or write known good values to these registers on every start up.

Quote from: T.Pierret on June 12, 2020, 07:44:16 AM

The real solution would be a transformation matrix that is the result of many calibrations. For this, the coordinates of the points that are drawn on the calibration screen should be known. Is it possible to get such info ?

The point positioning varies depending on screen resolution. If you let me know what screen resolution you are using I can query the dev team for information on where the points would be located on the screen.


Best Regards,
BRT Community

560
Test and Review Area / Re: BRT_AN_025 Beta - Portable MCU library for EVE
« on: June 12, 2020, 01:04:10 PM »
Hello Epichfallen,

Can you let me know which version of the IDE you are using?

Best Regards,
BRT Community

561
Discussion - EVE / Re: Capacitive touch screen calibration
« on: June 11, 2020, 12:03:47 PM »
Hello,

It is recommended to run the calibration routine for every display.
When using CMD_CALIBRATE the co-processor engine overlays the touch targets on the
current display list, gathers the calibration input and updates REG_TOUCH_TRANSFORM_A-F.

One option for mass production would be to calibrate one given display and read back the values stored in REG_TOUCH_TRANSFORM_A-F, you can then use these known 'good values' in your production line by writing the values into REG_TOUCH_TRANSFORM_A-F for subsequent displays. This should allow your displays to be approximately calibrated, after which you can provide a calibration routine in your code for your customers to use to re-calibrate the display if desired.

Best Regards,
BRT Community

562
Discussion - EVE / Re: How to draw a colorful text with CMD_TEXT
« on: June 10, 2020, 11:11:40 AM »
Hello Qrenz,

Rudolph is above is correct.
But if you are still having issues, please provide your the display list you are using.

Best Regards,
BRT Community

563
Discussion - EVE / Re: Using Custom Font in RAM
« on: June 09, 2020, 05:27:31 PM »
Hello,

The raw data address is calculated as an offset which points to where the 0th character of the font
data would have been. The actual data loaded begins with the first printable character (i.e. the address for the data in RAM_G)but since this would be the 32nd character in an ASCII data set, the virtual value of the raw data address of
the 0th character would have been at, this is why the address is negative.

And yes, the character must be included in your converted font if you wish to use CMD_TEXT or CMD_NUMBER with the desired font handle. in your example the 'a/b/c' characters wouldn't display as they haven't been converted.

Best Regards,
BRT Community

564
Discussion - EVE / Re: Add code after exporting from Screen Designer
« on: June 09, 2020, 02:57:50 PM »
Hello

I was unable to open the project file previously attached.  However, I made a simple test project and it should work
as customer expected. Please give this a try and let me know how you get on.

Best Regards,
BRTCommunity

565
Discussion - EVE / Re: How to inflate large image
« on: June 08, 2020, 02:54:46 PM »
Hello,

Yes, Rudolph is correct, you would split the data into chucks smaller than the FIFO size.
Below is our implementation from our BRT_AN_014 for writing data to the FIFO.
Section 7.2 covers using the INFLATE command.

Code: [Select]
void API_LIB_WriteDataToCMD(const uint8_t *ImgData, uint32_t DataSize)
{
    uint32_t CurrentIndex = 0;
    uint32_t ChunkSize = 0;
    const uint32_t MaxChunkSize = 128;
    uint8_t IsLastChunk = 0;
    uint16_t Freespace = 0;

    // This code works by sending the data in a series of one or more bursts.
    // If the data is more than MaxChunkSize bytes, it is sent as a series of
    // one or more bursts and then the remainder. MaxChunkSize is a size which
    // is smaller than the command buffer on the EVE and small enough to gain
    // maximum buffering effect from the MCU SPI hardware.

    // Pad data length to multiple of 4.
    DataSize = (DataSize + 3) & (~3);

    // While not all data is sent
    while (CurrentIndex < DataSize)
    {
        // If more than ChunkSize bytes to send
        if ((DataSize - CurrentIndex) > MaxChunkSize)
        {
            // ... then add ChunkSize to the current target index to make new target
            ChunkSize = MaxChunkSize;
            // ... and this is not the last chunk
            IsLastChunk = 0;
        }
        // or if all remaining bytes can fit in one chunk
        else
        {
            // ... then add the amount of data to the current target
            ChunkSize = DataSize - CurrentIndex;
            // .. and this is the last chunk
            IsLastChunk = 1;
        }

        // Wait until there is space
        Freespace = 0;
        while (Freespace < MaxChunkSize)
        {
            Freespace = HAL_CheckCmdFreeSpace();
        }

        // Begin an SPI burst write
        HAL_ChipSelect(1);

        // to the next location in the FIFO
        HAL_SetWriteAddress(EVE_RAM_CMD + HAL_GetCmdPointer());
       
        HAL_Write(ImgData, ChunkSize);
        ImgData += ChunkSize;
        CurrentIndex += ChunkSize;

        // End the SPI burst
        HAL_ChipSelect(0);

        // Calculate where end of data lies
        HAL_IncCmdPointer(ChunkSize);
        HAL_WriteCmdPointer();

        // If this is the last chunk of the data,
        if (IsLastChunk)
        {
            break;
        }
    }
}
Best Regards,
BRT Community

566
Discussion - EVE / Re: How the Processor Know The End of Compressed Img For CMD_INFLATE?
« on: June 05, 2020, 05:59:39 PM »
Hello

If we take the following usage example:
Code: [Select]
API_LIB_BeginCoProList();
 API_CMD_INFLATE(0);
 API_LIB_EndCoProList();
 API_LIB_WriteDataToCMD(LeaveItToEVE, sizeof(LeaveItToEVE));
 API_LIB_AwaitCoProEmpty();

The data is written to the co-processor. The co-processor will then inflate the data into a format in RAM_G
on the user’s behalf which can be used directly by the GPU.
The library sends the CMD_INFLATE command to the co-processor as a separate command (using
the BeginCoProList and EndCoProList to do this). The parameter 0 indicates that the co-processor
will start outputting the resulting data to address 0 which is the beginning of RAM_G. The coprocessor now awaits the data to be inflated. The data follows immediately afterwards via the
WriteDataToCmd function which sends the array of data created above. This also takes care of
managing the co-processor read and write pointers and splitting the data into smaller chunks of
necessary. Finally, the code checks for completion by ensuring the buffer write and read pointers
are equal.

And yes the CMD_GETPTR will return the ending address of the data in RAM_G, you can load subsequent graphics assets in past this address.

Best Regards,
BRT Community

567
Discussion - EVE / Re: Updating basic text on screen while Erasing Flash
« on: June 05, 2020, 05:21:35 PM »
Hi Guys,

I can confirm that cmd_flashupdate works in both basic and full modes, the programmers guide will be updated to reflect this.

For an empty flash chip, it is recommend to write the blob to the first block so that flash can enter into full/fast mode, which is much faster than basic mode.

For cmd_flasherase, the speed depends on the nature of flash chip, since only several bytes commands are sent to flash chip by Eve and wait for its reply.

Best Regards,
BRT Community

568
Discussion - MCU / Re: Opportunities of implementing MQTT and their benefits
« on: June 05, 2020, 04:32:17 PM »
Hello,

Here's some feedback from the author of BRT_AN_041 FT90x-MQTT-Application:

You would still need networking support and some form of low level OS.

mbed and FreeRTOS are providing much the same support.

mbed has support for Ethernet and other stuff but you’d have to port it to FT900.

The advantage is that we have already implemented FreeRTOS, lwIP and mbedTLS in that example.

Maybe other users in the community have more input?

Best Regards,

BRT Community

569
Discussion - EVE / Re: Updating basic text on screen while Erasing Flash
« on: June 04, 2020, 04:12:07 PM »
Hi Guys,

I will try to clarify with the development team regarding which modes CMD_FLASHUPDATE works in:

Quote from: Rudolph on June 03, 2020, 06:38:57 PM
However, it is not clear if CMD_FLASHUPDATE even works in BASIC mode as this command is missing from the table on page 17 of the programming manual.
It should work at least in FULL mode but clearing the first sector with CMD_FLASHUPDATE should only be possible in BASIC mode.
I asked that before but have no answer to this so far.

Best Regards,
BRT Community

570
Discussion - EVE / Re: Updating basic text on screen while Erasing Flash
« on: June 03, 2020, 04:49:10 PM »
Hello,

A 1 min erase time for a 16MB flash does seem rather long.

Which EVE library are you using? and can I see the code you are using to call the erase?


Best Regards,
BRT Community

Pages: 1 ... 36 37 [38] 39 40 ... 50