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 ... 35 36 [37] 38 39 ... 50
541
Test and Review Area / Re: BRT_AN_025 Beta - Portable MCU library for EVE
« on: July 01, 2020, 03:46:07 PM »
Hello korstiaan,

Thank you for your comments, we have passed these on to the developer to update the files according for release.

Best Regards,
BRT Community

542
Discussion - EVE / Re: FTDI Hardware Abstraction Layer (HAL) Library
« on: June 29, 2020, 02:34:47 PM »
Hello Amy,

Example Hardware Abstraction Layers (HAL) are included in all of our example projects, for example in our main SampleApp these are the Gpu_Hal.c files.

The following application note covers an example of how to develop a HAL for a given MCU, in this case a PIC:
BRT_AN_008 FT81x Creating a Simple Library For PIC MCU

Best Regards,
BRT Community

543
Discussion - EVE / Re: EVE Asset Builder
« on: June 23, 2020, 12:00:22 PM »
Hello Rudolph,

There is now a new version of EAB available (1.6.0) which should address the points in this post:
www.brtcommunity.com/index.php?topic=153.0

I would be grateful if you could give it a try.

Best Regards,
BRT Community

544
Test and Review Area / EVE Asset Builder 1.6.0
« on: June 23, 2020, 11:55:38 AM »
Hello,

We are pleased to announce the imminent release of EVE Asset Builder 1.6.0, this will be available on brtchip.com shortly but for now the installer can be downloaded from the following:
EVE-Asset-Builder-setup-1.6.0-rc1.zip

The release note below lists the updates since the last public release (1.4.0):

v1.6.0:
    - Fix bugs:
      + flash detection fails but program succeeds
    - Improve the session functionality in EAB
    - Add the keyboard shortcut for changing the order in flash image generator
    - Add shortcut key for deleting item in list widget
    - Add one "Clear" button for log panel
    - Add one warning window to prompt user for "Data Alignment" of EAB
    - Add a question mark to explain the hardware configuration of flash programmer
    - Show glyph information in different place


V1.5.0:
    - Fix bugs:
      + Some characters disappears from glyph if the code point mode is "utf-8"
      + Typo on code point mode drop-down box of font conversion utility
    - Add alignment option in flash image generation utility
    - Add a question mark to give the hint for code point mode of font conversion utility
    - Force 64-byte alignment for Flash address of Glyph file
    - Unknown freetype error when converting the symbola font file
    - Provide more information while previewing the input font file
    - Provide more information on the result panel of font conversion utility
    - Add bmp file support in Image conversion and Animation conversion
    - The compression for LUT file of paletted format in Image conversion utility shall be disabled
    - Add more information on compression mode in image conversion utility
    - Add the support of compression output in PNG2DXT1
    - Improve the flash utility in EAB
    - Improve the sample code for flash utility
    - Add some description about re-ordering assets in flash image generator
    - Add more information for "compressed" option of image conversion utility
    - Improvement on result window of image conversion utility: File size and full extension name
    - Add a bmp file under 'assets for test' folder of installation path
    - Add a section in user guide to list down the flash programmer modules

Best Regards,
BRT Community

545
Discussion - EVE / Re: Image corruption
« on: June 23, 2020, 09:22:18 AM »
Hi,

Your code 2 is missing a clear (1,1,1) which could cause issues.

In general, each new screen should begin with a clear (1,1,1)     (and in most cases you may wish to set clear_color_rgb first too)

And should end with a display and a swap.


Code: [Select]
cmdOffset = ft_wait4CoproReady()
ft_write32( RAM_CMD + cmdOffset, CMD_DLSTART );
ft_incCmdOffset( 4u );
ft_write32( RAM_CMD + cmdOffset, CLEAR_COLOR_RGB(10, 10, 60) );
ft_incCmdOffset( 4u );
ft_write32( RAM_CMD + cmdOffset, CLEAR(1 ,1 ,1) );
ft_incCmdOffset( 4u );
ft_write32( RAM_CMD + cmdOffset, CMD_DLSTART );
ft_incCmdOffset( 4u );
ft_write32( RAM_CMD + cmdOffset, SAVE_CONTEXT() );
ft_incCmdOffset( 4u );
ft_write32( RAM_CMD + cmdOffset, CMD_SETBITMAP );
.....


Also, bear in mind that large full screen images can be large and may take most of the RAM_G. However, after the application starts (and assuming you don't want the splash screen after that) you can load more things into the same area and overwrite it.

Best Regards, BRT Community

546
Discussion - EVE / Re: Capacitive touch screen calibration
« on: June 22, 2020, 12:26:58 PM »
Hello,

It seems like your other post regarding tags may be related to this.
http://www.brtcommunity.com/index.php?topic=147.0

The calibration on the screen should affect the tagging and track properties on the screen equally. Its possible that this behaviour could be related to the CTP as it might jitter between coordinates slightly and so eve might see coordinate inside tag and then outside, etc.

Would it be possible for you to create a simple example which exhibits the behaviour you are seeing?
e.g. can we see it by just drawing a rectangle and tracker on it and a small tag number printed beside?
This should help narrow down where the issue might lie.

I would appreciate if you could email this example into: support.emea@brtchip.com, along with a description of the symptoms you are seeing. We can then try this on some hardware here to further the investigation into this behaviour.
We can post the resolution here for any interested parties.


Best Regards,
BRT Community

547
Discussion - EVE / Re: EVE Asset Builder
« on: June 22, 2020, 12:10:41 PM »
Hello,

I will chase the development team up regarding this.
As for the 3 separate blob files, I believe this is for future proofing in-case different versions are required for different ICs, but yes currently they are all the same file.

Best Regards,
BRT Community

548
Discussion - EVE / Re: FT813 display show divided screen and strange "rainbow"
« on: June 22, 2020, 11:19:29 AM »
Hi,
It would be worth checking your defines for the display registers to ensure all are being written to correct addresses.
As Rudolph mentioned, this effect can appear if the values are wrong in the settings.
You can find an example header file in various libraries such as this zip file: https://brtchip.com/wp-content/uploads/EVE_Projects/SampleApp.zip
Best Regards, BRT Community

549
Discussion - EVE / Re: How to check status of TFT controller IC with FT813?
« on: June 18, 2020, 04:32:09 PM »
Hello,

As Ted mentioned, it is possible that the display controller inside the LCD itself has been affected and may need resetting.

For EVE itself, you may see an error condition indicated if the REG_CMD_READ and REG_CMD_WRITE never become equal (e.g. if the device is waiting on more data to complete a command and those bytes went missing due to noise on the SPI lines).   Or if REG_CMD_READ gives an error condition (0xFFF) where bad command values were encountered (e.g. if noise corrupts the address or some data in a burst write causing a non-4 byte aligned command). Or you may also see a swap fail to complete by reading the swap register.

Therefore, it is worth ensuring you check the read and write pointers with a software timeout in case they don't become equal and a way to jump out the loop if the error condition is flagged.

You can also read back or CRC data in the RAM as well if you suspect corruption.

However, as your application is still running well in this case, it is likely that EVE is running correctly and outputting the screen on its RGB lines and that the panel itself may be affected. As Ted mentioned, additional grounding and protection against the data being corrupted may be needed to prevent it happening,

Best Regards, BRT Community


550
Discussion - EVE / Re: Tag value of an area with content
« on: June 18, 2020, 04:09:53 PM »
Quote from: BRT Community on June 18, 2020, 04:01:59 PM
Hello,

The REG_TOUCH_TAGs default value is 0, however this normally indicates that no touch is detected. It may be that you are reading the register before the frame has fully scanned out.

Can you provide an example display list of how you are tagging the different objects on your screen?
I would like to investigate this behaviour further.

Best Regards,
BRT Community

551
Discussion - EVE / Re: Tag value of an area with content
« on: June 18, 2020, 04:01:59 PM »
Hello,

Can you provide an example display list of how you are tagging the different objects on your screen?
I would like to investigate this behaviour further.

Best Regards,
BRT Community

552
Discussion - EVE / Re: Using CALL and RETURN
« on: June 18, 2020, 03:53:47 PM »
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

553
Discussion - EVE / Re: Capacitive touch screen calibration
« on: June 18, 2020, 03:35:19 PM »
Hello,

Just to clarify, are these the values you're seeing whilst running the CMD_Calibrate routine?

Best Regards,
BRT Community

554
Discussion - MCU / Re: Opportunities of implementing MQTT and their benefits
« on: June 17, 2020, 04:45:52 PM »
Hello Vladi,

Quote
One question: Which lwIP-API do you use for your lwIP examples? Is it the Netconn API or the BSD Socket API?

It doesn't use either of them. The MQTT app for lwIP does it.

Best Regards,
BRT Community

555
Discussion - EVE / Re: Using CALL and RETURN
« on: June 17, 2020, 04:08:50 PM »
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

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