Setting color for widgets.

[rascalito]

Hello!

I'm working on a display driver, and I got something working (I didn't work on it
for a while, but I posted images earlier).

The driver is basically working and I have tried all the existing widgets.
But I have some problems with setting colors. It somewhat works, but not always
and I'm trying to check what's wrong, so I'm back to a closer look at the documentation.

I have the following questions:

1. Page 14, there is a sample code which works fine. So I suppose it shows that
my implementation of the basic function wr8, wr16, wr32 and same for rd, work fine.
Now the next snippet, page 21 uses a "dl" function, without defining it anywhere
in the document. At least I didn't find it.
Is it right to assume that dl(val) means wr32(RAM_DL + offset, val);

2. I found some code on github, which is reported to work on many targets. And I had a look at
it to compare. As for changing colors, what I was doing is basically send the command
CMD_FGCOLOR, then send the color itself, so indeed there is something missing.
Looking at the code, it's like this:

Code: Select all

void EVE_cmd_bgcolor(uint32_t color)
{
	if(!cmd_burst)
	{
		EVE_start_command(CMD_BGCOLOR);
		spi_transmit((uint8_t)(color));
		spi_transmit((uint8_t)(color >> 8));
		spi_transmit((uint8_t)(color >> 16));
		spi_transmit(0x00);
		EVE_cs_clear();
	}
}

which calls this second function:

Code: Select all

void EVE_start_command(uint32_t command)
{
	uint32_t ftAddress;

	ftAddress = REG_CMDB_WRITE;
	EVE_cs_set();
	spi_transmit((uint8_t)(ftAddress >> 16) | MEM_WRITE); /* send Memory Write plus high address byte */
	spi_transmit((uint8_t)(ftAddress >> 8)); /* send middle address byte */
	spi_transmit((uint8_t)(ftAddress)); /* send low address byte */

	spi_transmit_32(command);
}

The second command sends first the REG_CMDB_WRITE's 3 bytes followed by the command itself.

In summary, it will send:
// The second function
1. REG_CMDB_WRITE // 3 bytes
2. CMD_BBGCOLOR // 4 bytes
// The first function, upon return of the second one.
3. The color itself // 4 bytes (color itself followed by a 0)

So all together 11 bytes.

I checked on the scope, and the byte sequence is like this: (bit sequence represented in hexa)

chip_select falling edge
302578 FFFFFF0A 00FF00 00
chip_select rising edge
The 2 first numbers are the REG_CMDB_WRITE and CMD_BGCOLOR. The third one is green, and
there is a trailing 0.

Then after that, I have a line of buttons.
The buttons are drawn with the CMD_BUTTON command, and it works fine.
Their size, position are fine, only the foreground color (for the text) doesn't work,
I get white characters.

Does anybody know what happens? Is the above sequence wrong?

Thanks

R

[rascalito]

Hello again!

Sorry for all that mess. I didn't work on the subject foe a while, but I got it.
I assumed that background would be the background of a button. But in fact, the background
of a button is defined by CMD_FGCOLOR. So the REG_CMDB_WRITE story is not needed.
That said, I wonder why it's reported to work, but it's another story.

As for writing the label, it's just a matter of writing to RAM_DL + current_pos the uint32
value of the color (0 to FFFFFF), to which you would OR the value 0x04000000 which is
basically COLOR_RGB, without the complicated #define stuff.

R

[Rudolph]

Hello,

I found some code on github, which is reported to work on many targets.

That one is mine and yes it does indeed work fine on several targets and for some time now. :-)

But in fact, the background
of a button is defined by CMD_FGCOLOR. So the REG_CMDB_WRITE story is not needed.
That said, I wonder why it's reported to work, but it's another story.

It is needed and correct, at least for the function you posted.
There are two ways to generate display lists and for both the first thing after the falling chip-select
is a command. And if it s a read or a write command the next 22 bits are the address data is written to or read from.
And the function is just doing that, issue a write command with REG_CMDB_WRITE as target address and then supply
all the data necessary for the command.

As for writing the label, it's just a matter of writing to RAM_DL + current_pos the uint32
value of the color (0 to FFFFFF), to which you would OR the value 0x04000000 which is
basically COLOR_RGB, without the complicated #define stuff.

What complicated #define stuff?
These are my current functions: EVE_color_rgb(WHITE); / EVE_color_rgb_burst(WHITE);
In the previous version this looked like this: EVE_cmd_dl(DL_COLOR_RGB | WHITE);

So you are writing directly into the display list which is the other way of doing things.
My code is using the command co-processor and therefore writes to RAM_CMD.
All the widgets like buttons and text output are provided thru commands that are processed by the command co-processor which in return writes the apropriate commands to the display list, writing directly to the display list means you can only use a small subset of features.
Why REG_CMDB_WRITE then?
Simple, with FT81x an optimisation was introduced to make writing to the command-FIFO, aka RAM_CMD, even simpler.
Writes to REG_CMDB_WRITE end up at the address of RAM_CMD+REG_CMD_WRITE and REG_CMD_WRITE is automatically increased.
With direct access to RAM_CMD it was necessary to keep track of an offset in this 4k FIFO and write to REG_CMD_WRITE after writing a command to make EVE execute this command.
For the latest versionI decided to cut out support for FT80x and one reason for that was to make use of this optimisation.

[rascalito]

Hello Rudolf!

Thanks for your reply.
I'm back to my own code...
>> What complicated #define stuff?

I mean the #define making a command from the r,g,b colors. Well, that's a matter of
style, but you will not convince me that writhing things like (b << 0) are useful,
neither that redefining new types like
#define xx_uint8_t uint8_t, as I have seen somewhere, help readability (I don't
remember what xx was).

>> These are my current functions: EVE_color_rgb(WHITE);

That's exactly what I was saying. You also use predefined colors, so do I.

Thanks for your explanation about REG_CMDB_WRITE! I was doing all the bookkeeping
by hand. And beside that, the fact that my code didtn't work was not related to
REG_CMDB_WRITE, but to the fact that I was using BGCOLOR for a button color instead
of FGCOLOR. Sorry.

R.

[Rudolph]

Ah, you mean the macros from FTDI that I still carry in my code, like this one:
#define COLOR_RGB(red,green,blue) ((4UL<<24)|(((red)&255UL)<<16)|(((green)&255UL)<<8)|(((blue)&255UL)<<0))

Yeah, I guess I could go over these and delete some.
But then these are kind of expected as FTDI put them in the programming manual.

The ones I use are defined in my application, like this:
#define RED 0xff0000UL
#define PURPLE 0x800080UL
#define WHITE 0xffffffUL
#define BLACK 0x000000UL

And when I use some other color I often enough do this:
EVE_color_rgb(0xc0c0c0);

>#define xx_uint8_t uint8_t, as I have seen somewhere, help readability (I don't
>remember what xx was).

No idea where this is from, I like clean C99 types.

>Thanks for your explanation about REG_CMDB_WRITE! I was doing all the bookkeeping by hand.

I used to do that as can be seen in V4 of my library, FT80x required this.
Only not like FTDI originally implemented it, I took a more lightweigth approach. :-)