Hello,

Yes this is the correct approach.
We have a porting guide for the previous version of ESD which you can reference:
https://brtchip.com/wp-content/uploads/Support/Documentation/Application_Notes/Modules/EVE/BRT_AN_001-ESD-3.0-Exported-Project-Porting-Guide.pdf

Customers shall look into the function “Esd_Loop” in file “Ft_Esd_Core.c” to see which slots to be called periodically.

You can find the main function which is the entry to the application in the Ft_Esd_Support.c file.

In FreeRTOS, this main function shall be renamed and invoked by a RTOS thread, this should be scheduled to be higher priority to get fast response.

For App structure initialization, please see the attached picture. It is allocated statically in heap while the application is initialized.


Best Regards,
BRT Community

Hello,

It looks like the SPI master init is failing, which is causing the subsequent calls to return a FT4222_IS_NOT_SPI_MODE error.
Replacing the FT4222 Lib/DLL files in the project normally resolves this issue.

Are you by any chance using a USB 3.0 port on a windows 7 machine?

Best Regards,
BRT Community

Hello,

Please make sure to use the samples below which include BT81x support and to select the device in the platform.h file.
EVE_Samples_v1.1.0_RC_28062019.zip

We recommend to copy the LibFT4222H lib and dll files from our libFT4222H library into the same location as your exe in your EVE sample app directory to ensure that the sample app can find the library.
https://www.ftdichip.com/Support/SoftwareExamples/FT4222H.htm

Best Regards, BRT Community

Hello,

On CleO needles are in an built widget, if you wish to recreate a needle on a standard EVE module you can do so with bitmaps.
A base needle bitmap could be created (make sure to use a bitmap format which supports the alpha channel), this can then be coloured, rotated or scaled to suit your needs.

Best Regards,
BRT Community

Hi,

We tried your code and it was working on our board.

We would however recommend to do the full start-up until your screen is up and running and then play the sound. In your normal code which works with the display, you can set the bit 4 in the GPIOX and GPIOX_DIR at the same time as you write them to enable the display.

But for the code which plays the sound, try running it after displaying a screen for example as then you know the device is ready and running.

What hardware are you running with? it may be a connection issue or a define in your code for example. We tried with BRT_AN_025 code running on FT900 with VM816 and a CleO speaker connected to the socket on the VM816. We played the sound within the main program loop.

Best Regards,
BRT Community

Hello,

It is possible that REG_CPURESET may not be 0 if the chip has not fully initialised.

If you assert and then deassert the PD line before the start-up sequence, it should reset the chip. Any change in the clock (CLK commands) should be done before the active command as these pout the device to sleep and the active (and the following delay of 300ms) must come after the clock commands.

When it fails to start, how far do you get through the recommended start-up process from section 2.4 of the programmers guide. did the REG_ID read 7C and the REG_CPURESET read 0?

Also, do you have all the new definitions for the registers of the BT816?

Best Regards,
BRT Community

Hello

Here are details of which fonts are used. The fonts are in three groups:

•             Non-proportionate and non-anti-aliased - Fixed-width CP437 fonts are taken from the FreeBSD distribution's console driver. Please see CP437 8x8 and 8x16 (handles 16,17,18,19).
•             Proportionate non-anti-aliased - Variable width fonts are helvR08, etc. from X11 (handles 20 to 25)
•             Proportionate anti-aliased fonts were taken from the roboto regular file and converted into bitmap and into L4 format.

Best Regards,
BRT Community

Hello,

This is a known issue and will be fixed in the next version of the FT9xx Toolchain:

The following folder interferes with the build.
C:\Users\Username\AppData\Local\VirtualStore\Program Files (x86)\Bridgetek\FT9xx Toolchain\Toolchain\hardware\include

When Eclipse is not run in administrator mode, the library source files under system directory 'C:\Program Files (x86)' cannot be modified form eclipse editor. But if you actually try modifying them, the files gets discreetly saved in C:\Users\%Username%\AppData\Local\VirtualStore\Program Files (x86)\Bridgetek\FT9xx Toolchain\. Eclipse sees the files it changed in C:\Program Files (x86)\Bridgetek\FT9xx Toolchain, but other applications like the Explorer will see only the unchanged file.

Possible Workaround for v2.5.0 release:
Delete the C:\Users\%Username%\AppData\Local\VirtualStore\Program Files (x86)\Bridgetek upon installation of toolchain. But this will clear 'VirtualStore' folder only for that user username.

Please run Eclipse as an administrator to overcome any issues.

Also refer to BRT_TN_002 Modifying FT9xx API Functions when trying to override or modify local API code.

Best Regards,
BRT Community