Hi Barracuda01,
I've done some similar thing with custom board, but I think you can do that thing.

Just keep in mind some advices:

- You have limited RAM and flash, so use external memory to keep datafiles (eg images).
- Keep strings (like html files) short, they are stored in your flash. Altering them with code does not solve, sorry. Maybe you can read them from file stored in SD card, but not sure of that.
- Be prepared using directly the code driving BT813 (not using EVE's code) or you'll have tons of code you'll not use. If not, you will end probably not be able tu use the web page part (no room for SSI pages)
- For web pages, use statically managed memory pools (expecially if you plan loading everything from the board) to keep under control memory usage. Doing so, UDP will be your best friend . Not doing so, will be your nightmare....

Array / grid managing will only be a question of math, think positions as variables (using constants makes lesser use of memory, but you can't have 110% of the pie...) depending from the previous one element.

Hi everybody,
I'm facing a strange, where not fancy, behaviour of the Eclipse-for-FT9xx.
And I spotted is caused by the position of libraries.
If you install your eclipse in program files (x86), you will likely have the libraries put in a path like
C:\Program Files (x86)\Bridgetek\FT9xx Toolchain\Toolchain\hardware\include

well, this is a administrative rights protected area (win 7 but every other newer) and you can be misleaded

I've imported a 2.5.0 library includes and source over a 2.3.2 library (and used git to keep the ability of switching back and forth)
But today I've stepped into the fact that what i thought it was a 2.5.0 library is "cached" somewhere and read as a 2.3.2 library.

I'm moving now the include path to see if anything changes.

Hi Vladi,
in fact there is not a main.c, you have to find the "main" function, that lies elewhere in the code (that is Ft_Esd_Framework/Ft_Esd_app.c)
But be aware, the "while" loop in ESD architecture is part of Ft_Esd_MainLoop() in Ft_Esd_Framework/Ft_Esd_MainLoop.c
So,to integrate, I suggest creating a "init" stage just before the  Ft_Esd_MainLoop() call in Ft_Esd_app.c file, and then use the already written while loop in the other file to insert your routine.

I had some struggle in that kind of integration at first sight, but if you work with EVE and some versioning tool (a git GUI , for example), you can:
-save yout eclipse project with git;
-export your interface into the eclipse project when needed;
-revert  to the previous ( or simply not commit the new ones ) Ft_Esd_MainLoop.c and Ft_Esd_app.c
-continue editing building and so on.

My two cents.

Hi, Minomano, I'm following the discussion.

A supercap is indeed a good energy storage, but how long would you like this storage to last?
I understand that you are asking this to know, instead, how much autonomy you will have given the supercap you are selecting.

Hi qwerty100,
I faced the very same problem, but I based all exporting the EVE project, not using freeRTOS.
I've posted into  http://www.ftdicommunity.com/index.php?topic=146.msg541#msg541 , it's a "hacked" way of doing this....
Hope this helps

I just wanted to sum up errors ( or, at least, not so clear statements ) in code examples.
By now, I found:

• CAN example 3: tx.data[] is a 8 byte array, so you can't access the tx.data[8] element. In other languages, you would get an OutOfBoundException, here you read/write spurious data. Not a big deal, however can lead to strange behaviour in other codes.
• DAC example 1: dac_start(0) with dac_mode_single starts the FIFO mechanism, thus leading to a delay in first output and a buffer delay when passing "realtime" data. DAC_write starts the dac itself, so there's no need (not to say, erroneous)  to explicitly start the DAC.

Hope you all can add your experience, thus helping refining documentation.

So, eventually we gained some light ! ADC is now a good boy that does its work!

There is a caveat that was not so easy to understand:

In the examples should be explicit this line of code:
ADCDAC->DAC_ADC_CONF |= MASK_DAC_ADC_CONF_ADC_EXT_VREF;this enables the rail-to-rail reference.

 If not enabled, you have a 0.33V -2.97 range which still corresponds to 0x000 - 0x3ff range ( 0d - 1024d ) and leads to a "bathtube" conversion: The center corresponds (1.65V set = 1.65 read), but has an error while going up and down.
Still, in rail-to-rail, you can see the very same phenomenon, but you can see it only near 0.1V or 3.2V, where the error is more explicit.

I STRONGLY suggest to make it explicit in datasheet.

Ok, so let's see the DAC....

Hi Everyone,
I'm developing a custom board based upon FT902 rev B, I'm facing a little problem using ADC's.

In fact, there is little or none documentation on ADC module... but also DAC is missing some important informations

I have a BIG difference between measured (with a calibrated multimeter) and translated from MCU.
I'm using the adc_example3 from the toolchain 2.5.0 installer to get samples.

While 0 is 0 (as channels connected are almost grounded) For instance,measured 0,85V are translated into a 185/1024, which shall mean 0,59V...

In case of DAC , it has a immense delay from setting data to obtaining a real output.

Are there any specific application notes or specific infos?
Everiyhing I found is AN-324, pages 39-41 & BRT_AN_020 pages 42-45 + 223 -224, TN159 where some errata address use of buffer, but nothing else.