BRT Community

I am re-visiting my circle function:
void EVE_widget_circle(const int16_t xc0, const int16_t yc0, const uint16_t radius, const uint16_t border, const uint32_t bgcolor)
{
    EVE_save_context();
    EVE_begin(EVE_POINTS);
    EVE_point_size(radius);
    EVE_vertex2f(xc0, yc0);
    EVE_color_rgb(bgcolor);
    EVE_point_size((uint16_t) (radius - border));
    EVE_vertex2f(xc0, yc0);
    EVE_end();
    EVE_restore_context();
}

While that is short and simple, it is a bit odd to use.
The inner area is not transparent, but filled with the provided color.
This is using 9 commands, so 36 bytes in the command-list.

Now I have this:
void EVE_widget_circle(const int16_t xc0, const int16_t yc0, const uint16_t radius, const uint16_t border)
{
    EVE_save_context();
    EVE_color_mask(0, 0, 0, 0);
    EVE_stencil_func(EVE_ALWAYS, 0x01, 0x01);
    EVE_stencil_op(EVE_REPLACE, EVE_REPLACE);
    EVE_point_size((uint16_t) (radius - border));
    EVE_begin(EVE_POINTS);
    EVE_vertex2f(xc0, yc0);
//    EVE_end();
    EVE_color_mask(1, 1, 1, 1);
    EVE_stencil_func(EVE_NOTEQUAL, 0x01, 0x01);
    EVE_stencil_op(EVE_KEEP, EVE_KEEP);
    EVE_point_size(radius);
//    EVE_begin(EVE_POINTS);
    EVE_vertex2f(xc0, yc0);
//    EVE_end();
    EVE_color_mask(0, 0, 0, 0);
    EVE_stencil_func(EVE_ALWAYS, 0x00, 0x01);
    EVE_stencil_op(EVE_REPLACE, EVE_REPLACE);
//    EVE_begin(EVE_POINTS);
    EVE_vertex2f(xc0, yc0);
    EVE_end();
    EVE_restore_context();
}

And this works fine, 18 commands, 72 bytes in the command-list.

At least in the EVE Emulator library I can do this:
EVE_color_rgb(BLACK);
EVE_cmd_text(40, 350, 31, 0, "The quick brown fox jumps...");

EVE_color_rgb(GREEN);
EVE_widget_circle(100,400, 50*16, 8*16);

EVE_color_rgb(RED);
EVE_widget_circle(150,400, 50*16, 8*16);

EVE_color_rgb(MAGENTA);
EVE_widget_circle(220,400, 50*16, 8*16);

I get three overlapping circles and the text underneath.

Hmm, yes, I am also using:
EVE_vertex_format(0);
But neither POINT_SIZE or LINE_WIDTH care about that.

What I am wondering now is, is there a way to do this more efficient?

For rectangles with transparent background I played with this in EVE Screen Editor:
SAVE_CONTEXT();
COLOR_MASK(0, 0, 0, 0);
STENCIL_FUNC(ALWAYS, 0x01, 0x01);
STENCIL_OP(REPLACE, REPLACE);
BEGIN(RECTS)
VERTEX2F(4100, 2100);
VERTEX2F(5900, 3900);
//END();
COLOR_MASK(1, 1, 1, 1);
STENCIL_FUNC(NOTEQUAL, 0x01, 0x01);
STENCIL_OP(KEEP, KEEP);
//BEGIN(RECTS)
VERTEX2F(4000, 2000);
VERTEX2F(6000, 4000);
//END();
COLOR_MASK(0, 0, 0, 0);
STENCIL_FUNC(ALWAYS, 0x00, 0x01);
STENCIL_OP(REPLACE, REPLACE);
//BEGIN(RECTS)
VERTEX2F(4000, 2000);
VERTEX2F(6000, 4000);
END();
RESTORE_CONTEXT();

Same principle, only not put into the final form.
The setting of color and line-width is deliberately left out, so you can have multiple
rectangles with only setting the color and line-width as needed.

Hi,

yes I know, I am not answering the question directly, but I never used interrupts with the EVE chips and never found out what the benefit of using interrupts is supposed to be.

When you use an interrupt, you have to make sure to not disrupt any other on going SPI transfer before reading the touch information.
If you are using DMA to update the display you certainly can not wait in the interrupt function for the DMA transfer to finish.
So the sane option is to set a flag in the interrupt to check in the main loop and read the data when EVE is not busy otherwise.
First you need to find out what the interrupt was about, then read the touch data.

I am just polling REG_TOUCH_TAG every 5ms between display updates, this is fast enough to not lose events and if any change is necessary in the display as a reaction, the display can not be updated immediately anyways, you have to wait for the next update cycle.

Totally forgot about this one, untill the project I was struggling with back in march landed back on my desk today with one of tasks beeing to increase the font size.

I just converted the font in EAB 4.5.0 for BT817 again, using the same size as a first stept but ASTC 8x8.
It looks fine now and the size of the binary is much smaller.

    

I just remembered this issue while playing with the VM820B10A.

The issue with the RVT101HVBNWC00-B is still there.

The VM820B10A however does not have this issue, I just tried all values from 0 to 7 and the output is fine regardless of the orientation.

Yeah, the VM820B10A arrived today, about a week earlier as expected. 
Unfortunately, my PCBs for it have not arrived, maybe tomorrow.

The first thing I noticed, the cover glas of the VM820B10A is significantly smaller than the one on the RVT101H - yes, I did not bother to check the measurements. 
I guess I need to ask for a re-design of the case instead of modifying it myself then.

Edit: the MCU boards arrived yesterday, I had to assemble a couple of missing parts, did some basic tests and combined the PCB withthe VM820B10A today.

Came out pretty much as planned. 

You cannot view this attachment.

The extra cables?
Debugger and Logic Analyzer.

I have a CAN-FD XCP bootloader for the ATSAME51, but I have not populated the CAN transceiver and the common mode choke, I rather use the microscope in my lab at work for that.   

Ah, why not, have a few more images.
Today I finally got around to complete another RVT101 based "tablett" (so BT817) at work.

You cannot view this attachment.
You cannot view this attachment.
You cannot view this attachment.

Unfortunately, the shot from the side was not showing anything usefull.
And I would like to show you what the mcu does, but I really can not.

Again, I specifically designed this PCB for the RVT101, it has two switching regulators, one for the backlight, one for the logic including the mcu.

Hello,

and yes, the plan is to add my MCU board to the back.
Usually I would use a FFC connector, but I opted to connect to CN17.
And I might remove CN1 and CN3 as these are very tall.
My design for the BT817 10" uses a case that is almost 20mm thick.
And with the VM820B101A it might be required to go beyond that without
removing components - and 20mm already is a fat "tablet".

You cannot view this attachment.

I ordered a VM820B10A and I hope to receive it by the end of the month.

And to share something that I did not share before, attached is an image of the target controller board I designed specifically for the VM820B10A.
Top Left is a P-FET for reverse polarity protection, under it a 5V LDO for the two CAN-FD transceivers.
The SOT-223 is for the 3.3V controller and logic supply, yes, the size is overkill for the expected <20mA drawn, but I happen to have about 400 of these.
The two SOIC-8 are LIN transceivers.
Almost done, I need to finalize and order it soon.

You cannot view this attachment.

Interesting, somehow I was logged out.
Anyways, any news on the topic?

And another thing, this is from the BT81x programming manual:

/* Enable backlight of display panel */
#if defined(FT81X_ENABLE)
wr16(REG_GPIOX_DIR, 0xffff);
wr16(REG_GPIOX, 0xffff);
#else
wr8(REG_GPIO_DIR,0xff);
wr8(REG_GPIO,0xff);
#endif
wr8(REG_PCLK,2); //Configure the PCLK divisor to 2, i.e. PCLK = System CLK/2

This does not enable the backlight and it would not be a good idea to enable the backlight at this point since generally the signals need to go out before the backlight is activated.

This is supposed to set the DISP output to HIGH, and it also does.
But why is this setting all the bits in the registers?
DISP is set to output by reset-default in both REG_GPIO_DIR and REG_GPIOX_DIR, so neither of these need to be written to.
And setting all the bits in REG_GPIO or REG_GPIOX does not only set the GPIOx pins to high, it also changes the drive-strength for a couple of pins.

Sure, this might work.
Or it causes problems by for example setting INT_N from Open Drain to Push-pull.

Also, FT81X_ENABLE is not explained.
As the programming guide is for BT81x this might suggest that REG_GPIO_DIR and REG_GPIO are used.
Which would be fine since these are also available in BT81x.

Just keep it simple?

/* Enable DISP signal of display panel */
wr8(REG_GPIO,0x80);

Hello,
I believe I posted this before, but your documentation is inconsistent and I believe it is wrong.

DS_FT800 states:
"Wake up from POWERDOWN state requires the host to pull the PD_N pin down and
release, a low to high transition enables the 1.2V regulator. POR generated when 1.2V
is stable and FT800 will switch to STANDBY mode after internal oscillator and PLL are up
(maximum 20ms from PD_N rising edge). The clock enable sequence mentioned in
section 4.2.3 shall be executed to proper enable the system clock."

That is a clear and concise statement that the 20ms delay after raising PD_N is required and why.

In the FT81x datasheet this was changed to:
"When in the POWER DOWN state, if the device enters this state via an SPI command, then only the SPI
ACTIVE command will bring the device back to the ACTIVE state, provided PD_N pin is also high.
However, if PD_N is used instead, then making PD_N high followed by a SPI ACTIVE command will wake
up the device."

and
"From the SLEEP state, the host MPU sends an SPI ACTIVE command to wake the FT81x into the ACTIVE
state. The host needs to wait for at least 20ms before accessing any registers or commands. This is to
guarantee the clock oscillator and PLL are up and stable."

This contradicts the FT800 datasheet.
This is also found now in the BT88x, BT817/8, BT815/6 - and I believe it is wrong.

It also contradicts this statement in the BT8178 datasheet:
"After reset the BT817/8 will be in the SLEEP state. Upon receiving the SPI ACTIVE command (or
CLKEXT followed by SPI ACTIVE command if external clock source is used), the clock oscillator and
PLL will start up. Once the clock is stable, the chip will check and repair its internal RAM, running the
configuration and then entering into normal operations. The boot-up may take up to 300ms to
complete. During boot up process, software should not access BT817/8 register or RAM except reading
REG_ID and REG_CPURESET."

So one paragraph states that the host must not read any register directly after ACTIVE,
the other states reading REG_ID is fine.

The BT817/8 programming guide has this:
host_command(ACTIVE);//send host command "ACTIVE" to wake up
delay(300ms);
while (0x7C != rd8(REG_ID));

This is at least consistent with the description as it has a delay() between ACTIVE and reading REG_ID.

Now checking what Bridgetek is using in their own code I found this:

    // Reset the display
    MCU_Delay_20ms();
    HAL_PowerDown(1);
    MCU_Delay_20ms();
    HAL_PowerDown(0);
    MCU_Delay_20ms();
...
    // Set active
    HAL_HostCmdWrite(0, 0x00);

    // Read REG_ID register (0x302000) until reads 0x7C
    uint8_t val;
    while ((val = HAL_MemRead8(EVE_REG_ID)) != 0x7C)
    {
        MCU_Delay_20ms();
        (void)val;
    }


So what is does is adding a delay after setting PD_N to high and it has no delay whatsoever between ACTIVE and the first reading of REG_ID.

To my experience and in accordance with the FT800 datasheet, this is correct.
The delay after setting PD_N is for the EVE chip to go from POWERDOWN to STANDBY.
And reading REG_ID directly after ACTIVE is not a problem, the EVE chip does not answer though untill the internal startup is done which I just measured for a BT817 to happen 43ms after ACTIVE.


The next thing is, why are you using:
host_command(CLKEXT);
host_command(CLKSEL);
host_command(RST_PULSE);
host_command(ACTIVE);

And not:
host_command(RST_PULSE);
host_command(CLKEXT);
host_command(CLKSEL);

host_command(ACTIVE);

From the BT817/8 datasheet:
RST_PULSE

Send reset pulse to BT817/8 core. The behaviour is the same as POR except those settings done through SPI commands will not be affected

So what this meant to say is "host commands"?
Ok, if that is the case, the order should not matter as long as RST_PULSE comes before ACTIVE.

Yes, using zlib compressed files is not about RAM-G usage.
But it would reduce the transfers from the SD card and the SPI traffic to the EVE chip.

I do have Teensy 4.0 and 4.1, but I never really found a use for them apart from implementing the library code. Total overkill.

There are a couple of options that I have not explored myself as my hardware usually does not have an SD card socket.

- CMD_LOADIMAGE with a MEDIA-FIO and scaling - but this probably does not look good.
- CMD_INFLATE2 with a MEDIA-FIFO for zlib compressed ASTC.
- CMD_INFLATE with some modifications.
void EVE_cmd_inflate(const uint32_t ptr, const uint8_t * const p_data, const uint32_t len)
void block_transfer(const uint8_t * const p_data, const uint32_t len)

block_transfer already cuts larger transfers into chunks of 3840 bytes as the transfer goes through the FIFO

- Write directly to RAM-G.
void EVE_memWrite_sram_buffer(uint32_t const ft_address, const uint8_t *p_data, uint32_t const len)

You would only need a wrapper around this to count up from the base address for whatever block you are transferring.
This might be the easiest to implement, but this would be for unpacked data, so 1024x600 in ASTC 8x8 would require to write 150kiB.

Edit: personal point of curiosity - which MCU are you using?

Check this:This device is using an EVE3-50G from Matrix Orbital which has a BT815.

And a little over a week ago I found that the Polyend Tracker is using a FT812 soldered to the board.

Very nice to finally have some more products confirmed, unfortunately these are way to expensive to buy them for just the heck of it. 

Hi, I am still having this issue and it just made me publish my first youtube video ever.


Fortunately, while I had to rotate the display for my last project to landscape (EVE_cmd_setrotate(2) ), this was fine while EVE_cmd_setrotate(3; shows the same distortion.
Since the panel is IPS the viewing angle is the same from all sides anyways.