Hello,
Please refer to our watchdog example as part of AN_360 FT9xx Example Applications.
Full source code is provided to allow you to see the watchdog in operation.
This can be found at the following location as part of the FT9xx Toolchain.
C:\Users\Username\Documents\Bridgetek\FT9xx\2.5.0\Examples\Watchdog Example 1
You can also refer to AN_365 FT9xx API Programmers Manual for more information on the watchdog API functions.
Best Regards,
BRT Community
- July 10, 2020, 08:08:44 AM
- Welcome, Guest
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
|
1
on: July 08, 2020, 05:15:59 PM
|
||
| Started by harira - Last post by BRT Community | ||
|
2
on: July 07, 2020, 09:55:27 AM
|
||
| Started by harira - Last post by harira | ||
|
Hi,
i am trying to implement the watchdog on a ft900. It is correctly intialized with wdt_init (wdt_counter_1G_clocks); To test the function i am not resetting the timer with wdt_kick (); I would expect the controller to reset itself after 10 seconds. But nothing happens. The mainloop continues to run without reset. Did i miss something or is there something else to be initialized? Christian |
||
|
3
on: July 06, 2020, 02:47:49 PM
|
||
| Started by TSL - Last post by BRT Community | ||
|
Hello,
Question 1. Currently using an external PSRAM IC to extend RAM_G is not supported by EVE. We are looking into the possibility of adding this feature for future versions of EVE. Was this the only reason you were looking into using this PSRAM IC? Best Regards, BRT Community |
||
|
4
on: July 06, 2020, 02:43:27 PM
|
||
| Started by korstiaan - Last post by BRT Community | ||
|
Hello,
Yes this is to be expected, it is a function of how the bitmap is placed on the screen. The bitmap is positioned via the top left corner of the image when drawn. i.e. the x/y used by VERTEX2F represents the top left of the image. The VERTEX2F command updated via the macro register when using the screensaver command updates according to the screen parameters used, so it is possible that the bitmap may move off of the screen. It is possible to use some translate commands to centre the image on the VERTEX2F position used, however this may still result in section of the bitmap appearing to be off of the screen. Best Regards, BRT Community |
||
|
5
on: July 03, 2020, 05:04:54 PM
|
||
| Started by TSL - Last post by Rudolph | ||
|
I would apreciate a little information about these Blobs as well.
But mostly because I already found three SPI NOR FLASH chips that do not fully work with EVE. And sure, the more options the better, MRAM could be intersting as well. What would be the benefit of PSRAM though? You already can use the FLASH as extension of G-RAM by storing for example images and glyph files for fonts and directly use these from FLASH wthout moving them to G-RAM first. PSRAM is volatile, so you have to write your data after every power down. You would need to provide some other mass-storage device to load the data from. Then the size is rather limited with 64MBit at best while you can get 256MBit FLASH even in the simple SOIC-8 packages. Okay, there is one thing, you can write a lot faster to PSRAM than to FLASH. But there is a catch. First of all it is still rather slow at <20MB/s, more likely in the region of 10MB/s. Where I do get my numbers from? Reading from FLASH currently works at about 10MB/s according to tests with quite a number of chips and Progflash.exe. And then you only have one bus so writing to any external memory while at the same time displaying something should be in the best case a huge bottleneck for writing and in worst case almost impossible to implement for Bridgtek. If your application is to dynamically store full sized bitmaps and switch between these you probably would either be disappointed how slow writing is or that the display is glitching out every time data is written. Yes, the first 1280x800 displays are already anounced. And a single "full" color 16 bit image would need 2 megs of RAM_G. So the disparity between the size of RAM_G and the display resolution is getting worse. It would be nice to see RAM_G expanded to 0x1fffffh. But then we have ASTC now as well and displaying images in ASTC also works from RAM_G. I just converted a 560x560 image to ASTC 8x8. The uncompressed data in RAM_G has a size of only 78400 bytes. As raw data this would be 627200 Bytes. EVE quite happily displays that right now on an EVE3-50G here from RAM_G and also rotating it does work fine. For the heck of it I grabbed a random image from the internet, it has 1400x792 pixels. As ASTC 8x8 it needs 277200 bytes of RAM_G. So I could almost put four of these monstrosities into RAM_G. Edit: I also put the 1400x792 image into RAM_G now and EVE displays it at x = -300 and y = 65 while rotating it around its center. Zooming it by a factor of 1.456 at the same time while rotating it? No problem. |
||
|
6
on: July 03, 2020, 12:48:22 AM
|
||
| Started by TSL - Last post by TSL | ||
|
Hello.
I want to address my questions directly to the Bridgetek team. Question 1. Espressif has produced the SPI PSRAM recently. It is 64Mbit in size and could make a great option for RAM_G extension. Is it possible to use it with BRT81x? The PSRAM has a partly compatible to SPI Flash generic command set, it has QSPI mode, but the detect may be complicated because ID commands differ. I'm afraid that CMD_FLASHATTACH will simply fail with PSRAM. I would greatly appreciate the authoritative comment on this. Question 2. Is it possible to modify or recompile the blob to create an own version for custom purposes? E.g. the case above needs 8 dummy cycles for PSRAM to read in QSPI fast mode. What is blob format? Is it an executable code or a set of parameters? I couldn't find any info on this in the official documentation. Could you please clarify these aspects? Thank you in advance. |
||
|
7
on: July 02, 2020, 10:31:26 AM
|
||
| Started by korstiaan - Last post by korstiaan | ||
|
Hi,
Is it normal that if I use the screensaver functionality, the bitmap goes partly off screen on the right hand side? It bounces off the left, top and bottom but goes partly outside on the right hand side. This is my test list: Code: [Select] EVE_LIB_BeginCoProList();Is it meant to be like this or is there a way to keep the image inside the visible screen area? Korstiaan |
||
|
8
on: July 01, 2020, 03:46:07 PM
|
||
| Started by BRT Community - Last post by BRT Community | ||
|
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 |
||
|
9
on: July 01, 2020, 02:52:33 PM
|
||
| Started by BRT Community - Last post by korstiaan | ||
Hello there, Hi all, I've just tested this AN on my ESP32 and I had the same errors (ESP IDF 4.0.1) In order to get it compiled I changed the following in the code: - in file EVE_MCU_ESP32.c I added: Code: [Select] #include "driver/gpio.h"- in file edian.h I placed the following lines in remark in order to suppress the warnings about redefinition: Code: [Select] //#define __bswap16 __bswap_16After changing this I successfully compiled and flashed my ESP32 and the demo works fine. Luckily this AN exists because it would have been too much work to get started! Thanks for this! PS: I also had to change the EVE_config.h to add my 3.5 QVGA display. |
||
|
10
on: June 29, 2020, 02:34:47 PM
|
||
| Started by adouglas_ptl - Last post by BRT Community | ||
|
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 |
||