BRT Community

Please login or register.

Login with username, password and session length
Advanced search  

News:

Welcome to the Bridgetek Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ Bridgetek Support

Please refer to our website for detailed information on all our products - Bridgetek - Bridging Technology

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 - AT38

Pages: [1]
1
Discussion - EVE / Fetch Graphics Context?
« on: June 15, 2021, 01:45:19 PM »
Hello.

I'm having a problem with the colour command not working under some circumstances, and I would like to read the colour stored in the graphics context to verify that it has changed to the requested colour.

Is there any way of reading out the current graphics context, or at least the current colour?

Cheers.

2
Discussion - EVE / Change polarity of Display Enable pin (DE)?
« on: July 23, 2020, 03:53:48 PM »
BT815's Display Enable (DE) output is active positive.

I am trying to use a display with an ILI9806E driver which requires Display Enable to be active low.

How do I change the polarity of DE so that it is compatible with this display driver?

Thanks

3
Discussion - EVE / REG_TRACKER N returns 0xDEADBEEF
« on: October 04, 2019, 04:25:03 PM »
I'm using an FT813.
I've enabled extended touch mode, and I can read out tags for each touch point.
However, when I try to read out the tracker registers, only the first works and the rest return 0xDeadBeef.

I have the register addresses as follows:

Code: [Select]
REG_TRACKER   0x309000
REG_TRACKER_1 0x307004
REG_TRACKER_2 0x307008
REG_TRACKER_3 0x30700c
REG_TRACKER_4 0x307010

Any ideas why?

4
Discussion - EVE / Filled Irregular Polygons - Mission Impractical
« on: July 01, 2019, 01:13:36 PM »
Hi,

I was hoping to be able to draw filled polygons using an FT813 so that I can replace some large icon bitmaps with a small list of vertices, saving me a whole load of flash memory space.

I looked at application note AN334 https://brtchip.com/wp-content/uploads/Support/Documentation/Application_Notes/ICs/EVE/AN_334-FT801_Polygon_Application.pdf and I saw filled polygons.
On closer inspection, it seems that the polygon is split up into smaller sections so that they have vertical and horizontal edges for the scissor command to trim to.
This makes diagonals impractical however, as they would have to be cut up into squares whose sides match the width of the diagonal section. A long thin diagonal would require many cuts.
Concave polygons also need to be chopped up into straight edged convex pieces, and would need some thinking about..


Firstly, is filled concave polygons something that is likely to be supported in the future? Are the existing range of chips field upgradable, or would this feature require rolling out a new product?


Secondly, what would be the best way of getting around this?

1) I could draw over the unwanted part of the polygon with another polygon set to the background colour, but this wouldn't preserve non uniform backgrounds.

2) Perhaps I could draw to the stencil channel instead, but the stencil is 1bit and wouldn't have nice smooth edges when I fill, so far as I can tell from the docs, haven't tried it yet. I suppose I could then draw the outline with with a LINE_STIP to get the anti-aliased edges.

3) Or I could break up the icons into smaller components and composite them, making use of completely blank rectangular bitmaps that can be generated with the MEMFILL command and using the bitmap transform to rotate them to get the diagonals. Rotating bitmaps is a bit iffy, though. I did try animating a rotating circle and it did not look good. Its size and position kept shifting about.

4) Or I could give up and just use bitmaps, take the hit on space, hope deflate does a good job.

I think option (1) would suit my immediate needs, but I'd like to know if other folk have encountered this limitation, how they've gotten around it, and why that method, so I can make an informed decision before making a commitment.

Cheers,
 AT38

5
Hi,

 I am attempting to run the touch screen calibration as per the documentation:

Code: [Select]
(Init screen here)

cmd(DLSTART)
cmd(CLEAR(1,1,1))
cmd(TEXT(80,30,27,OPT_CENTER, "Tap the dot")
cmd(CALIBRATE)
cmd(DISPLAY)
cmd(SWAP)

while(REG_CMD_READ != REG_CMD_WRITE);

This gives me a black screen with a small box of white hash near the top left. (I can post a picture if it would help)
Tapping the screen three times completes the operation, but the transform matrix is wrong because the dots aren't displayed and I've tapped in the wrong places.

The default matrix gives almost the right values, except that it's upside down, so I suppose I could invert param E and it would work,
but I'd like to have the calibration macro working correctly.

I've been having a hell of a time trying to get touch tracking working today, but I don't want to post about that until I've confirmed that the touch matrix is calibrated correctly.

Cheers

 AT38

6
Discussion - EVE / FT81x Backlight not working? [SOLVED]
« on: June 20, 2019, 11:08:47 AM »
Hi,

I'm currently developing on an ME813A-WH50C display module.

I've had several days of trouble free operation.

Last night I power cycled the board as part of a debugging process.

Since then the display has not worked.

I am able to communicate over SPI and read out the chip ID register as 0x7C.

On examination of the display, I noticed that the back light was not on (no light bleeding out at the edges).

I have measured the voltage on the backlight pin and it is zero.

I've read out the values of REG_PWM_DUTY and REG_PWM_HZ and verified that their values are correct, 0x80 and 250 respectively.

I've tried shorting out the backlight pin to 3V3. This enables the backlight, but also sinks 30mA into the FT813.

There was no contact with the module between working and non working states.

Only the power button of the bench top supply was touched. ESD seems unlikely.

The PSU outputs 5v and drops to 3.3v on the MCU board via a linear regulator, and on the display module via a buck converter. Surge damage seems unlikely.

Wiring between the boards looks ok, and would foul SPI comms if not.

Can anyone tell me:
1) Why this has happened,
2) How do I fix it (preferably without shorting the pin to 3V3)
3) How do I prevent this from happening again?

Cheers


EDIT:

I've loaded a display list and forced the backlight on, but it looks like nothing is being displayed.
Possibly all out pins at zero. I'm going to check PCLK and DISP next.

EDIT2:

PCLK is outputting at 1.13MHz, should be 30MHz

DISP, VSYNC, HSYNC and DE are all Zero.

7
Discussion - EVE / FT81x not rendering display lists? [SOLVED]
« on: June 03, 2019, 04:29:42 PM »
Hi folks.

I am in the process of moving my project from a back buffer based display to the FT81x

My target MCU is STM32F407 and I am using a Gameduino3 shield as a display dev board.

I have SPI comms up and running, reset the FT81x with the PWRDOWN and ACTIVE host commands,
wait for 7C in REG_ID, and enable the display by writing 0x80 to REG_GPIO and 5 to REG_PCLK.

I now have a black screen with a single red pixel in the top left corner. (could be the bottom right, but beside the point)

I have also written a simple display list to clear the screen to a distinct colour and finally written 1 to REG_DLSWAP to swap in the new list.

However, the display is still black with a single red pixel in the top left.

I've checked the display timings and verified that the default parameters are correct for this screen, and that also the gameduino library makes no changes to the timing registers.

Since I am able to reset, activate, read id and enable the display, I believe my SPI routines are working correctly.

I've also checked the Display List Command macros to make sure they're putting out the correct values.

I've had a jolly good look through the application notes, programmer's guide and data sheet, and I see nothing that I am missing.

I don't know why I have just a single red pixel in the corner of a black background.

My next step will be to start reading out registers and the display list, and verifying their values are correct.

But if anyone knows what causes this situation and how to fix it, I'd really appreciate it.

Cheers,

AT38


SOLVED:

Data is little-endian, address is big-endian. I was sending data as big-endian.

Pages: [1]