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.

Topics - Rudolph

Pages: 1 [2] 3

Discussion - EVE / cap-touch: configure / gesture ?

« on: March 25, 2021, 06:31:05 PM »

I have been asked how to configure the sensitivity for a cap-touch controller connected to EVE.
That would be for GT911 but would also be interesting to know if this is even possible for focaltech touch controllers.

I checked the datasheet and the programming guide and it looks like there is no way to configure anything for a cap-touch controller.

But what I found and what brings me to my second point, the datasheets have this:
"In extended mode a new set of readout registers are available, allowing gestures and up to five touches to be read."

As far as I can tell there is no gesture support and no way to activate an existing gesture mode in the touch-controller.
Is that correct or am I missing something?

Discussion - EVE / BT817 / BT818 new features

« on: October 29, 2020, 06:07:26 PM »

As the BT817 / BT818 are officially released now, let's talk about it. :-)
https://github.com/RudolphRiedel/FT800-FT813

These are the new registers:
#define REG_UNDERRUN 0x0030260c
#define REG_AH_CYCLE_MAX 0x00302610
#define REG_PCLK_FREQ 0x00302614
#define REG_PCLK_2X 0x00302618
#define REG_ANIM_ACTIVE 0x0030902C

This are the new commands:
#define CMD_ANIMFRAMERAM 0xFFFFFF6D
#define CMD_ANIMSTARTRAM 0xFFFFFF6E
#define CMD_APILEVEL 0xFFFFFF63
#define CMD_CALIBRATESUB 0xFFFFFF60
#define CMD_CALLLIST 0xFFFFFF67
#define CMD_ENDLIST 0xFFFFFF69
#define CMD_FLASHPROGRAM 0xFFFFFF70
#define CMD_FONTCACHE 0xFFFFFF6B
#define CMD_FONTCACHEQUERY 0xFFFFFF6C
#define CMD_GETIMAGE 0xFFFFFF64
#define CMD_HSF 0xFFFFFF62
#define CMD_LINETIME 0xFFFFFF5E
#define CMD_NEWLIST 0xFFFFFF68
#define CMD_PCLKFREQ 0xFFFFFF6A
#define CMD_RETURN 0xFFFFFF66
#define CMD_RUNANIM 0xFFFFFF6F
#define CMD_TESTCARD 0xFFFFFF61
#define CMD_WAIT 0xFFFFFF65

The first thing to note for me was that the BT817 / BT818 do have a second PLL now for the pixel clock.
The easiest way to setup the second PLL is using CMD_PCLKFREQ.

I have this in my code-library now:

Code: [Select]

#if EVE_GEN > 3
uint32_t frequency;


#if defined (EVE_PCLK_FREQ)
 frequency = EVE_cmd_pclkfreq(EVE_PCLK_FREQ, 0);
 if(frequency == 0) /* this failed for some reason so we return with an error */
 {
   return 0;
 }
#endif
#endif

EVE_memWrite8(REG_GPIO, 0x80); /* enable the DISP signal to the LCD panel */
EVE_memWrite8(REG_PCLK, EVE_PCLK); /* now start clocking data to the LCD panel */

Note, EVE_PCLK has to be defined to "1" to use PLL2.

With a define like this:
#define EVE_PCLK_FREQ (51000000L)

The resulting pixel-clock is 51MHz and the 1024x600 display I configured this for runs at 60Hz.:-)

What also got my attention is CMD_NEWLIST, CMD_ENDLIST, CMD_RETURN and CMD_CALLLIST.
Looks like we can expand display list now. :-)

And now I go on reading. :-)

Discussion - EVE / CoProcessor faults and REG_CMDB_SPACE

« on: August 30, 2020, 05:48:25 PM »

The programming guide states for REG_CMD_READ:
"In the case of an error, the co-processor engine writes 0xfff to this register."

As I was reading REG_CMD_READ for my EVE_busy() function anyways I put the reset-on-fault code
in EVE_busy() as well.

Now I changed my library from writing to RAM_CMD+offset to use REG_CMDB_WRITE.
And it seems obvious to use REG_CMDB_SPACE in EVE_busy().
When the FIFO is empty the value in REG_CMDB_SPACE is 0xffc.

Now my question is, does the coprocessor also write 0xfff to REG_CMDB_SPACE in the case of an error?
The documents do not say anything about this but it seems logical.

Discussion - EVE / Bug: invalid options in commands are handled badly

« on: August 22, 2020, 01:39:53 PM »

I am currently rewriting parts of my code library and as part of this I am trying out all the commands that I rewrite.
Oh yes, I am using a BT815 right now.

Currently at cmd_toggle I somehow had the idea to feed it unsupported parameter options.
Listed as having an effect on cmd_toggle are OPT_3D and OPT_FLAT.
And of course, these do work just fine.

OPT_MONO -> black screen
OPT_NODL -> black screen
OPT_CENTERX -> black screen
OPT_CENTERY -> black screen
OPT_RIGHTX -> black screen
OPT_NOBACK -> no effect
OPT_FILL -> black screen
OPT_FLASH -> black screen
OPT_NOTICKS -> black screen
OPT_NOHM -> black screen
OPT_NOSECS -> black screen
OPT_NOTEAR -> black screen
OPT_FULLSCREEN -> black screen
OPT_MEDIAFIFO -> black screen
OPT_SOUND -> black screen

The options I left out either are alias ones use the same values or combinations of those above.
I have no idea how OPT_NOBACK has no effect but any other options makes EVE fail.

Please make the command co-processor filter out invalid options in BT817 and beyond.
And for all commands that take options.

Discussion - EVE / EVE Asset Builder

« on: May 16, 2020, 07:36:35 PM »

I found more issues with EAB 1.4.0 beside the UTF-8 ones that are already under investigation.

The release notes state:
- Add the "Verify" function in flash utility

And yes, there is a checkmark-button for this in the EAB GUI.
However, when you activate the option and click "UPDATE", you only get the default output of "ProgFlash.exe"
in the Log window:
Welcome to BT81X Flash Programming Utility v1.0
Copyright(c) Bridgetek Pte Ltd All Rights Reserved

Usage: ProgFlash [command] [argument]

module Select Program Module [ FT4222 (default) | MPSSE ]
chip Select Program EVE Chip [ BT815 | BT816 | BT815A ]
erase Erase all of flash
newblob Install blob <file_name> in flash
write Write <file_name> to flash (assumes flash is already erased)
update Write <file_name> to flash, erasing if necessary
read Read all of flash into <filename>

As if the "ProgFlash.exe" is supposed to have a verify command but the version shipped with the EAB package does not.
The "ProgFlash.exe" from EAB 1.2 has the exact same output, the newer version is 512 bytes longer though.
And I have not found a verify command in the .exe but the list above is missing the "detect" command.

Regarding "detect", it does work as a command from the command-line but fails from the GUI.
And the GUI suggests that there is a parameter to avoid measuring the writing speed, I wonder if that is there and what is.

When I use ProgFlash to erase a chip this is what happens:
---
D:\Chip_Test>ProgFlash module MPSSE erase
Information on channel number 0:
Flags=0x2
Type=0x8
ID=0x4036014
LocId=0x422
SerialNumber=
Description=Single RS232-HS
ftHandle=0x0

handle=0x7197f0 status=0x0
VC1 register ID after wake up 7c

reg_touch_rz =0x7fff
reg_touch_rzthresh =0xffff
reg_touch_tag_xy=0x80008000
reg_touch_tag=0x0

Switch flash status to FULL. Result: SUCCESS
Erasing Flash...
Progress ERASE 1
Progress ERASE 90
Switch flash status to BASIC. Result: SUCCESS
Progress ERASE 100
Erase Flash successfully
---

Why does it switch the flash to FULL in order to erase it?
There is no need to this, the chip-erase command will not work any faster.
What it does however is making it impossible to erase chips with EAB that do not work with the "unified.blob".
For example AT25SF641-SUB-T and AT25QF128A-SHB-T from Adesto.

On a side-note, what is a BT815A?

And why does EAB come with a "unified.blob", a "BT815.blob" and a "BT816.blob" now?
Which really is the same file with three different names.

- Replace 'numpy' by 'tinynumpy' to reduce distribution package size

No numpy to be found anywhere in the EVE Asset Builder installation.

Discussion - EVE / BRT AN 033 BT81X Series Programming Guide

« on: March 31, 2020, 07:50:43 PM »

I noticed that version 1.2 has been released and when I checked the revision history I "only" lists clarifications for CMD_ANIMFRAME.
When I compared that to version 1.1 I found that the new document has fewer pages as well.
So I sent it thru a diff tool.

Some reformating, minor fixes, excellent.
The offset for REG_SPI_WIDTH is still wrong though.

Then I found this in chapter 2.4 on page 15:
3. Send Host command “ACTIVE” and wait for at least 300 milliseconds. Ensure that there is
no SPI access during this time.
4. Read REG_ID till it is 0x7C

This is from the version 1.1:
3. Send Host command “ACTIVE” and wait for at least 300 milliseconds.
4. Read REG_ID till it is 0x7C

And for comparision, this is from the FT81x guide 1.2:
2. Send Host command “ACTIVE” to enable the clock to the FT81X. FT81X starts its selfdiagnosis process and may take up to 300ms.
Alternatively, read REG_ID repeatedly until 0x7C is read.

Why has this changed to a fixed 300ms and why was this made stricter now and forbids SPI access during this time?

I am using this for years now:

Code: [Select]

while(chipid != 0x7C) /* if chipid is not 0x7c, continue to read it until it is, EVE needs a moment for it's power on self-test and configuration */
{
	DELAY_MS(1);
	chipid = EVE_memRead8(REG_ID);
	timeout++;
	if(timeout > 400)
	{
		return 0;
	}
}

And i works just fine with BT81x as well, I only increased the timeout to 400ms.

But for this post I went a step ahead and measured how long a couple of displays actually need:

EVE2-35G: 69
EVE3-35G: 42
EVE3-35G initialised as EVE2-35G: 75
EVE3-43G: 42
EVE3-43G initialised as EVE2-43G: 69
RiFT43: 42
EVE2-50G: 77
EVE3-50G: 42
EVE3-50G initialised as EVE2-50G: 72

No, these are not all my displays but the pattern is obvious.
FT81x need less than 80ms.
BT815 need less than 45ms since I set their clock to 72MHz.
And when I use a BT815 like a FT813 the startup delay becomes very similar.

Is there any compelling reason why I still should switch to a fixed delay of 300ms with no SPI access?

Discussion - EVE / CMD_GETMATRIX

« on: March 01, 2020, 09:24:13 PM »

Hello,

why is this command named *GET*MATRIX?
This is not all what it does and it definately does not do the opposite of what SETMATRIX does.

GETMATRIX should be named SETMATRIX.
And the one that is now named SETMATRIX should be named ACTIVATEMATRIX.
And maybe a counter-part to what the current GETMATRIX does is missing.

That is if I am not completely wrong here.

Discussion - EVE / issue with EVE Asset Builder 1.2.0

« on: January 20, 2020, 05:33:17 PM »

Edit: I am not sure where my head was yesterday evening.

Converting images with the EVE Asset Builder v1.2.0 to ARGB1555 with compression results in rather large files and I suspect this is due to dithering beeing turned on by default.

I attached an archive with two button images that I converted using the image convert tool and EAB.
The result from EAB is very similar to what "img_cvt.exe" produces when not switching dithering off.
And the result with dithering off is a lot smaller.

I am using .png images for GUI elements and logos in order to not get compression related noise
in my images, this is kind of pointless when the converter deliberately adds noise.

Can we please have a checkbox in EAB to disable the dithering?
Preferably so that dithering is off by default, please.

Does the converter use dithering for BT81x ASTC images as well? If so - why???

Discussion - EVE / Automotive qualified BT81x?

« on: December 17, 2019, 12:58:18 PM »

What I was meaning to ask since at least this years Embedded World, are there any plans to have AEC-Q100 qualified versions of any of the EVE chips?

I am partly asking because of this:
http://ftdi.newsweaver.co.uk/newsletter/177facpy9nf5j6u4jyypwd

But mostly as I am working in the automotive industrie.
And even while I am doing mostly prototyping, I prefer parts with AEC-Q qualification, or at least use parts for
which AEC-Q qualified versions are available.

Discussion - EVE / Products with EVE

« on: November 10, 2019, 05:21:38 PM »

EVE is around for some time now and yet I do know any product that has a FT8xx / BT81x inside.
There should be for example Coffee Makers with EVE inside.

Please name any product featuring a FT8xx/BT81x, regardless of what it is,
where are the Coffee Makers, Copiers, Glucose Monitors, Fish finders??

Discussion - EVE / List of QSPI FLASH Chips for BT81x

« on: October 05, 2019, 11:25:31 AM »

Maybe it is time to start a table of FLASH Chips that do or not do work with BT81x.

Detect: REG_FLASH_STATUS reports FLASH_STATUS_BASIC and REG_FLASH_SIZE is correct

Manufacturer	Chip	Size(MBit)	Detect	Erase	Read/Write	CMD_FLASHFAST
Adesto	AT25SF641-SUB-T	128	Yes	Yes	Yes	0xE004 - device/blob mismatch
Adesto	AT25QF128A-SHB-T	128	Yes	Yes	Yes	0xE004 - device/blob mismatch
Cypress	S25FL064LABMFI010	64	Yes	Yes	Yes	Yes
Cypress	S25FL128LAGMFV010	128	Yes	Yes	Yes	Yes
GigaDevice	GD25Q64CSIGR	64	Yes	Yes	Yes	Yes
GigaDevice	GD25Q127CSIGR	128	Yes	Yes	Yes	Yes
ISSI	IS25LP064A-JBLE	64	Yes	Yes	Yes	Yes
ISSI	IS25LP128F-JBLE	128	Yes	Yes	Yes	Yes
Macronix	MX25L6433FM2I-08G	64	Yes	Yes	Yes	Yes
Macronix	MX25L12833FM2I-10G	128	Yes	Yes	Yes	Yes
Macronix	MX25L12872FM2I-10G	128	Yes	Yes	Yes	Yes
Macronix	MX25L25645FM2I-08G	256	Yes	Yes	Yes	Yes
Macronix	MX25L25673FM2I-08G	256	Yes	Yes	Yes	Yes
Microchip	SST26VF064BA-104I/SM	64	Yes	Yes	Write fails	-
Micron	MT25QL128ABA1ESE-0SIT	128	Yes	Yes	Yes	Yes
Micron	MT25QL01GBBB	1024	Yes	Yes	Yes	Yes
Winbond	W25Q32JVSSIQ	32	Yes	Yes	Yes	Yes
Winbond	W25Q64JVSSIQ	64	Yes	Yes	Yes	Yes
Winbond	W25Q128JVSIQ	128	Yes	Yes	Yes	Yes
Winbond	W25Q256JV	256	Yes	Yes	Yes	Yes

Please report any other FLASH Chip that you found to be working or not and I will add it to the table.

Shared Projects / EVE code library

« on: August 06, 2019, 09:51:53 PM »

Looks like this is the place to put something like this, I have a code Library up on Github for a while now:
https://github.com/RudolphRiedel/FT800-FT813

Despite the name it supports BT81x as well.
I just finished a project for which I replaced a defective VM800B50A with a RVT50AQBNWC00.
This unit was driven by an Arduino mini-pro using the Arduino framework.
And in parallel I was testing the exact same display code on an EVE3-50G using an ATSAMC21E18A board with SPI by DMA.

Edit:
I just released the first interation of V5 of my code library:
https://github.com/RudolphRiedel/FT800-FT813/tree/5.x

Discussion - EVE / BT81x and Animation support

« on: August 02, 2019, 05:19:31 PM »

I played with the new animation support in the EVE Screen Editor.
And I wonder what this is supposed to be used for.

Splitting up the frames of an animation into tiles is nice to save space in the external FLASH I guess.
Although the converter doubles the amount of frames and all the odd frames look exactly the same than
the even ones, so I have to wonder if this really is saving memory.
Without more insight I call this a bug in the converter.

There is a huge issue however, due to the tiling of the frames the display list is getting filled rather fast.
Now the smallest off-the-shelve FLASH on a BT81x module is 32MBit and I can easily replace it.
But the size of the display list is still only 8kB or 2048 commands.
The 124x300 pixel animation I have up in the EVE Screen Editor fills up the RAM_DL to 28% with only four lines
of coprocessor commands.

Am I missing something important here?
Right now this looks like a feature I rather not use.
Just cyling thru images on my controller has zero impact on the display list and while this costs a couple
more lines of code I just got a lot of free space for moving the images into the external FLASH.

And I checked, there is no way to tell the animation converter to drop the tiling.

Discussion - EVE / implementing support for formated strings

« on: June 23, 2019, 05:29:25 PM »

Hi,

has anyone successfully implemented vararg functions for CMD_BUTTON, CMD_TEXT and CMD_TOGGLE?
I am looking into implementing it for CMD_TEXT and I am sort of stuck at the beginning.

The problem is, there is no way to tell how many arguments are supplied and of what type these are.
So if I understand this correctly you either have to work with a known set or arguments like numbers for which
you also provide the amount with which you are calling the function.

void EVE_cmd_text_numbers(int16_t x0, int16_t y0, int16_t font, uint16_t options, const char* text, num,...)

EVE_cmd_text_numbers(0,0,28,OPT_FORMAT,"foo bar %x.i",2,0xdeadbeef,8);

This approach seems lacking.

The other alternative would be to parse the string.
But then I could use snprintf() before using EVE_cmd_text() and be done.

A practical approach would be a function that adds a single uint32_t parameter that is transferred only if OPT_FORMAT is given.
Well, better than nothing, I am adding this for now.

Discussion - EVE / BT81x faster FLASH testing

« on: June 21, 2019, 04:45:14 PM »

Today I received two SST26VF064BA-101I/SM from Microchip which I bought from Mouser.
Instead of the industrie-standard 50...180 seconds for a chip-erase these do a chip-erase in 50ms max.
I soldered one onto my RVT43ULBNWC00 and tested it with the EVE Asset Builder.
The whole "Erase" action takes less than five seconds now which really is great for testing things.

Edit: after some tries and no help with this here I gave up on the SST26VF064BA-101I/SM now.
Yes, the chip-erase is very fast.
But as it turns out, EVE refuses to write to these.
The SST26VF064BA-101I/SM are detected correctly with the right size, but cmd_flashwrite does not write
anything to the chip.
And there is no output from the EVE Asset builder to indicate what could be wrong.

I removed the SST26VF064BA-101I/SM again and put back the 64Mbit flash that the RVT43ULBNWC00 was deliverded with.
And after a (painfully long) erasing of the chip with the EVE Asset Builder my test aplication used cmd_flashwrite just fine
for a small file containing the unified.blob and two images.