FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  


Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support

New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - Rudolph

Pages: [1] 2 3
Discussion - Hardware / Re: FT813 power pin inssue
« on: October 31, 2020, 03:04:05 PM »
PD is to be connected to a GPIO output.
You could leave it open but issuing a core-reset command would be required for a proper warm-start then.

Check out my code library:

EVE_commands.c has EVE_init(), line 1177ff.

Discussion - Software / Re: Degree symbol
« on: October 26, 2020, 05:12:36 PM »
Well, or simply fake it as '°' is just a smaller 'o' at a different position.

EVE_cmd_text(GAUGE2_X, 60, 28, EVE_OPT_CENTERX, "[ C]");
EVE_cmd_text(GAUGE2_X-10, 57, 26, 0, "o");

And a 'µ' is just an 'u' plus an 'i'.

EVE_cmd_text(GAUGE1_X-29, 65, 28, 0, "i");
EVE_cmd_text(GAUGE1_X, 60, 28, EVE_OPT_CENTERX, "[um/m]");


Shared Projects / EVE code library
« on: May 19, 2020, 07:32:48 AM »
I have no idea why this forum is still up and why there is so much posted here.
I am more active over at:  http://www.brtcommunity.com/

That said, I have a code library for FT8xx/BT8xx that could answer a couple of questions that are posted here:

I have examples projects for Arduino, ATSAMC21 and ATSAME51.
My goal is to support all the EVE displays out there, at least these that I can actually get and that are documented.

And I went multi-plattform right from the start, I have support for a whole bunch of micros including AVR, ATSAM, STM32 and RISC-V.

Discussion - Software / Re: FT813 initialization
« on: May 19, 2020, 07:15:07 AM »
I have an Arduino example for my driver library: https://github.com/RudolphRiedel/FT800-FT813/tree/4.x/example_projects

The display is selected in EVE_config.h.
And the pins for CS and PD are configured at the end of EVE_target.h.

Yes, cmd_getprops returns the start-address and this is kind of useless since we already know the start-adress, we just fed it into cmd_loadimage.
And since the random image we just loaded could be either using 8 bit per pixel or 16 bit per pixel we can not really calculate the end-address from the size.
However, we do need to know the format to properly display the image, so it can not be all random.
And if the only allowed images are regular full color .jpg we can calculate the size as: width * height * 2
This is also at least safe in case a monochrome image is processed.

Discussion - Software / Re: EVE image loading problem
« on: September 09, 2019, 04:58:05 PM »
The chance of getting an answer from the community might be a little higer over in the BRT community forum. :-)

What am I doing wrong??

A couple of lines of code that demonstrate the issue might help with answering this. :-)

Other than that I can only assure you that it works as intended and you can use as much images as you can fit into the memory.

The chance of getting an answer from the community might be a little higer over in the BRT community forum. :-)

Annother solution would be to scale the images down untill they fit into the designated memory space.
With 200k available this would be 400x240.
And then let EVE scale the images to the desired size.
See cmd_scale

I just tried this in the EVE Screen Editor and the result looked okay.
And as a nice side-effect, the smaller images are loaded faster from SD, transfered faster to EVE and EVE needs less time to unpack these to RAM_G.

Discussion - Software / Re: FT813 (or BT815) few fonts at the same time.
« on: September 09, 2019, 04:17:17 PM »
The chance of getting an answer from the community might be a little higer over in the BRT community forum. :-)

The BT815 can use font.glyph flies directly from FLASH but it also needs the font.xfont file that is also generated
and the .xfont has to be copied to RAM_G.

I just put these both in FLASH, the .glyph first and then use cmd_flashread to to the .xfont into RAM_G.

Discussion - Software / Re: BT815 Image Issue
« on: December 12, 2018, 06:15:15 AM »
I wish I had a BT815 module yet. :-)

>Finally, in the startup, BT815 is slower than FT813, the difference is around 1-1,5 second.

Seconds? That would be awfull compared to the less than 200ms of a BT813.

General Discussion / Re: FT82x
« on: October 30, 2018, 06:16:35 AM »
I just learned that 2Gbit is rather unlikely since, at least by now, you will not find these in SOIC-8 or WDSON-8 packages but BGA packages.
Well, 64MBit already would be a huge step up, SOIC-8 would mean 256MBit max and WDSON-8 would mean 512MBit max.

General Discussion / Re: FT82x
« on: October 27, 2018, 01:48:09 PM »
I was aware of what you mean but I wanted to point out that I have an issue with the quality they deliver.
Sure, these are good value for the money, not bad products, but I want more value.

Now that the datasheet for the BT81x is released, these support up to 2GBit of QSPI NOR flash. :-)
And they can play animations and videos directly from external flash plus using fonts and images.

Some interesting features include UTF font support, printf style text output, using strings from memory.

I only have to get a BT815 module now.... :-)

Discussion - Software / Re: BT815 Car Dashboard
« on: October 26, 2018, 11:48:32 AM »
The Asset-Manager looks very interesting!
My virus-scanner at home puts a file named flash.exe or somthing like that under quarantine though.
I am certain that this is a false positive as the installation works without any issues on a different machine with a different virus scanner.

General Discussion / Re: FT82x
« on: October 25, 2018, 05:07:03 PM »
That is the problem for me Hotmcu's screens are much cheaper and not so much less expensive.

And the BT815/BT816 are in full release now. :-)

General Discussion / Re: FT82x
« on: October 02, 2018, 09:34:31 AM »
I do not know about Hotmcu and I am not sure if I really want to anymore.

But it looks like Matrix Orbital has plans for BT815/BT816 modules: https://www.matrixorbital.com/ftdi-eve/eve-bt815

>The BT81X should be available by the end of the year.

Hmm, not so nice.

Okay, what about updating the datasheet and perhaps the programming manual in advance, perhaps with a fat PRELIMINARY watermark across all pages?

General Discussion / Re: FT82x
« on: September 07, 2018, 12:13:16 PM »
>So you want to say that if we increase the memory for the display-list to 16K for example there would be 30 img / s instead of 60

No, I am saying that if the display-list would be increased the chip also would need to be made faster.
At least fast enough to handle 60 FPS for the max designated resolution which now is 800x600.

Only the first three lines of my post refer to the limited display-list, the rest has nothing to do with it. :-)

And maybe it even currently is fast enough to handle 16k for example, from a few observations I can only tell that it is pretty fast already,
but not how busy it really is from frame to frame.

I was merely pointing out that expanding the display-list memory looks like an easy thing to do from the outside, for example the gfx-memory could be reduced at the same time so the overall memory stays the same.
But it is more complicated then that and there is not much information around about how the FT8xx do function internally.

Thinking about it I wonder for example how the lists really work.
The display is written out line by line with no frame-buffer.
The objects however are all over the display-list. You can display a picture at the start of the list on top of the screen, lots of things in the next instructions and then a text to be printed across that picture at the end of the list.
So one way to do it would be to process the whole display-list for every single pixel - which I find a bit unlikely.

Pages: [1] 2 3