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.

Messages - Rudolph

Pages: 1 ... 20 21 [22] 23 24 ... 27
316
Discussion - EVE / Re: Displays with EVE3
« on: January 14, 2020, 05:40:02 PM »
There may be one 5" from Glyn: ADAM50-LCP-WVGA-NEW-BT815
But I only have the name from a newspost on their website.
They are strictly B2B so actually getting one would not be that easy as using one from Riverdi or Matrix Orbital.

And there are a few from Panasys: http://www.panadisplay.com/ftdi-intelligent-display/
But they have no distributor, just like Glyn, and are located in Shenzen.
I was able to buy the 9" and the 7" as samples from them.
But so far I did only try out the 9" and had a couple of issues with it.
In my opinion their PCB needs a revision, functionally and to reduce the size.
But it has been a couple of months since I received the displays.


The last display manufacturer I know of that has EVE products is Newhaven Display.
But they have no BT81x displays and stated last May in their forum: "We currently have no plans for the BT81x series EVE products."

317
Discussion - EVE / Re: Products with EVE
« on: January 11, 2020, 07:55:54 PM »
No reply at all is a bit thin.

Okay, I have one for you: LulzBot TAZ Pro 3D Printer KT-PR0050NA
It has a 5" resistiv touch TFT which is driven by a FT810 on a custom board.
The software is part of Marlin for a while now.

Not the type of product I was hoping for as it would be pretty mad to get this printer just for the display. :-)
But it still is a commercial product with EVE that is beeing sold.

318
Discussion - EVE / Re: The Christmas list for BT82X
« on: January 10, 2020, 05:56:13 PM »
Quote from: FlorianG on January 10, 2020, 10:38:47 AM
"Well, in theory EVE already supports 2048x2048 pixels. :-)"
Thank you for this information, I was not aware. It must be said that Bridgetek is not very clear on this subject

That is because the refresh-rate starts to go down rapidly beyond 800x480.
As the base clock is a bit low and because of the way the pixel clock is derived from it.

Quote
"The clock frequency already is customizable."

Ok but when i say customizable it is with precision to 1Mhz.
So that everyone can do what they want with these needs, overclooking included.

And the rest of what I posted shows that I am agreeing with you. :)

A second PLL would be nice.
But not like the current one which only takes the 12MHz clock, allows a multiplier of 6 max so that
you scale this down again.

Instead it would be nice to have a Pixelclock-PLL which has a pre-scaler for the 12MHz
and a multiplier with a larger range and then the result is used as pixel-clock.

Example: 12MHz / 6x Prescaler * 23x Multiplier -> 55.2MHz Pixel-Clock.

Quote
"I agree, although even double the amount would be nice, so 16kB and 8kB."

I think that considering the fact that it is possible today to have 1 + 256M of video memory, we can have this parameter to have 64 - 128kb

I agree it would be very nice to have way more.
Embedded memory is driving up the costs though and I assume the FT81x/BT81x already have
around 2M integrated.
And do not forget that the display-list has to be processed, making it 8 times or 16 larger than it currently is may present a whole lot of additional challenges apart from "just" adding more memory.
So better a little more than no increase at all.

Also more GRAM would be handy at times, yes.

319
Discussion - EVE / Re: PowerTip PH800480T013-IHC12 with HY4635: touch problem
« on: January 09, 2020, 02:07:03 PM »
Dang, now I have to check if I can get myself a TFT with a HY4635 that connects to one of the BT815 modules I have. :)

And from the technical perspective, the interesting part for me is that this is a direct patch for BT81x unlike
the 811-cap-100 blob from AN_336 which is a packed binary to be send to the command copro to be executed to
have the included CMD_INFLATE write to 0x30b00.

Now give us a patch-sdk for the FT81x/BT81x, please.  ;D



Edit: trying to source a TFT for the BT815 boards I have only once again proved to me that I better stick
to complete display modules.

I have three different options for BT815, the EVE3 series from Matrix-Orbital, the RiTFT series from Riverdi and PA70/PA90 from Panays.
Much to my surprise all three do not only use a 40pol FFC for  the display itself, but the pinout is compatible.
For the touch interface however, Matrix-Orbital uses a 6 pin, Riverdi a 10 pin and Panasys a 12 pin.

I did not only fail to find a TFT with HY4635 that is compatible, I failed to find any compatible TFT for either of the three.
If the panel is using a 40 pin connector the pinout does not match.
If the 40pin connector pinout is a match it uses a different pinout for the touch connector.

And if I had found a TFT with matching pinouts it probably would have been mechanically impossible to fit both connectors the board.

And if I had found a perfect match I probably had no way to buy it.

Okay, I admit that I gave up after going over only 30+ TFT datasheets...

320
Discussion - EVE / Re: PowerTip PH800480T013-IHC12 with HY4635: touch problem
« on: January 09, 2020, 11:48:16 AM »
Sorry for causing confusion with this side-step to AN_336.
I was merely trying to point out that writing to 0x30b1ac in order to change the I2C speed will only
work on an unpatched FT811/FT813 and not on an FT811/FT813 with applied AN_336 Goodix patch or a BT815/BT817.

And actually a method to change the I2C speed for BT815/BT817 would be usefull for anyone trying to hook up a TFT with a HY4635.

321
Discussion - EVE / Re: PowerTip PH800480T013-IHC12 with HY4635: touch problem
« on: January 08, 2020, 03:31:47 PM »
This is not what I asked, but thanks. :)
So if the offset for the AN_336 version is 0x17c then the default value would be 0xb8 for 400kHz?

Do not mind me, I just like the "puzzle". :-)


322
Discussion - EVE / Re: PowerTip PH800480T013-IHC12 with HY4635: touch problem
« on: January 07, 2020, 04:46:35 PM »
Quote from: BRT Community on January 07, 2020, 01:34:03 PM
We have previously provided the following work around for the HY4614 touch controller, but this is not guaranteed to work with the HY4635.

Very interesting. :-)

As this directly patches the touch controllers memory like the Goodix patch does, this will only work with FT811/FT813?
So it will not work with a patched FT813 or a BT815/BT817?

Not to ask what offset to use in these case, but to prevent someone else from trying. :-)

323
Discussion - EVE / Re: PowerTip PH800480T013-IHC12 with HY4635: touch problem
« on: January 06, 2020, 05:13:19 PM »
I2C clock stretching is something else, a way to pause the bus essentially, not reducing the base clock.
There does not seem to be a way to change the I2C clock speed directly.

But even then the HY4635 is a bit odd.
The registers are more or less compatible with the FT5x06 series and not at all with the HY461x.

Even with reduced clock the EVE still might not be able to use the HY4635.
There has to be a mechanism in place to identify the different supported chips and while the
touch registers for the HY4635 seem to be compatible with the FT5x06 at least, the chip-ID registers are not.

So unless Bridgetek supplies a patch like the one for FT6xx6 and Goodix for FT811/FT813, I am afraid that touch with the HY4635 will only work in touch host mode.

324
Discussion - EVE / Re: EVE Screen Designer software support for EVE3-TFT series module
« on: December 20, 2019, 02:57:24 PM »
Regarding the porting of ugfx or LittlevGL, I also have to suggest that you play a bit with EVE Screen Editor.
EVE uses an approach that is a bit different to be highly efficent especially on small µC.

If you attach a basic CCS Project or send me one ( drone42(at)t-online.de ) for your target controller with a main.c that at least initialises one timer for a 5ms interrupt I can try to "port" my library to the MSP430.
Or rather make it support the MSP430 as there is nothing really to be ported.

I also need code to setup the SPI to mode 0 with a speed of less than 11MHz, code to set and release the I/Os for chip-select and power down as well as code to read and write data bus with the SPI.

To give you an example what the target portion of my library looks like, this is what I have for MSP432 now.
And I even consider the second block a bit misplaced as I normally use main.c for basic init.
Whats left is a crude delay function, five one-liners and three two-line functions.

Code: [Select]
    #if defined (__TI_ARM__)

        #if defined (__MSP432P401R__)

        #include <ti/devices/msp432p4xx/inc/msp.h>
        #include <ti/devices/msp432p4xx/driverlib/driverlib.h>
        #include <stdint.h>

        #define RIVERDI_PORT GPIO_PORT_P1
        #define RIVERDI_SIMO BIT6   // P1.6
        #define RIVERDI_SOMI BIT7   // P1.7
        #define RIVERDI_CLK BIT5    // P1.5
        #define EVE_CS_PORT         GPIO_PORT_P5
        #define EVE_CS              GPIO_PIN0           //P5.0
        #define EVE_PDN_PORT        GPIO_PORT_P5
        #define EVE_PDN             GPIO_PIN1           //P5.1

        void EVE_SPI_Init(void);

        static inline void DELAY_MS(uint16_t val)
        {
            uint16_t counter;

            while(val > 0)
            {
                for(counter=0; counter < 8000;counter++) // ~1ms at 48MHz Core-Clock
                {
                    __nop();
                }
                val--;
            }
        }

        static inline void EVE_pdn_set(void)
        {
            P5OUT &= ~EVE_PDN;   /* Power-Down low */
        }

        static inline void EVE_pdn_clear(void)
        {
            P5OUT |= EVE_PDN;    /* Power-Down high */
        }

        static inline void EVE_cs_set(void)
        {
            P5OUT &= ~EVE_CS;   /* CS low */
        }

        static inline void EVE_cs_clear(void)
        {
            P5OUT |= EVE_CS;    /* CS high */
        }

        static inline void spi_transmit_async(uint8_t data)
        {
            #if defined (EVE_DMA)

            #else
            UCB0TXBUF_SPI = data;
            while(!(UCB0IFG_SPI & UCTXIFG)); /* wait for transmission to complete */
            #endif
        }

        static inline void spi_transmit(uint8_t data)
        {
            UCB0TXBUF_SPI = data;
            while(!(UCB0IFG_SPI & UCTXIFG)); /* wait for transmission to complete */
        }

        static inline uint8_t spi_receive(uint8_t data)
        {
            UCB0TXBUF_SPI = data;
            while(!(UCB0IFG_SPI & UCTXIFG)); /* wait for transmission to complete */
            return UCB0RXBUF_SPI;
         }

        static inline uint8_t fetch_flash_byte(const uint8_t *data)
        {
            return *data;
        }

        #endif /* __MSP432P401R__ */

    #endif /* __TI_ARM */

Code: [Select]
    #if defined (__TI_ARM__)
        #if defined (__MSP432P401R__)

/* SPI Master Configuration Parameter */
const eUSCI_SPI_MasterConfig EVE_Config =
{
        EUSCI_B_SPI_CLOCKSOURCE_SMCLK,             // SMCLK Clock Source
        48000000,                                   // SMCLK  = 48MHZ
        500000,                                    // SPICLK = 1Mhz
        EUSCI_B_SPI_MSB_FIRST,                     // MSB First
        EUSCI_B_SPI_PHASE_DATA_CAPTURED_ONFIRST_CHANGED_ON_NEXT,    // Phase
        EUSCI_B_SPI_CLOCKPOLARITY_INACTIVITY_LOW, // High polarity
        EUSCI_B_SPI_3PIN                           // 3Wire SPI Mode
};

void EVE_SPI_Init(void)
{
    GPIO_setAsOutputPin(EVE_CS_PORT,EVE_CS);
    GPIO_setAsOutputPin(EVE_PDN_PORT,EVE_PDN);
    GPIO_setOutputHighOnPin(EVE_CS_PORT,EVE_CS);
    GPIO_setOutputHighOnPin(EVE_PDN_PORT,EVE_PDN);
    GPIO_setAsPeripheralModuleFunctionInputPin(RIVERDI_PORT, RIVERDI_SIMO | RIVERDI_SOMI | RIVERDI_CLK, GPIO_PRIMARY_MODULE_FUNCTION);
    SPI_initMaster(EUSCI_B0_BASE, &EVE_Config);
    SPI_enableModule(EUSCI_B0_BASE);
}

        #endif
#endif

I have Code Composer Studio installed and can turn a given project into a basic demo.
I never used MSP430 oder MSP432 though, or any other TI controller.

325
Discussion - EVE / Re: EVE Screen Designer software support for EVE3-TFT series module
« on: December 19, 2019, 12:02:18 PM »
I have to say, AN025 is looking a lot like my own code library: https://github.com/RudolphRiedel/FT800-FT813  8)

AN025 does support a different set of targets though and while I do have MSP432 code in place,
I did not add MSP430 code, yet.
But I have support for a whole buckload of display modules, including the EVE3-43G.

326
Discussion - EVE / Re: The Christmas list for BT82X
« on: December 19, 2019, 10:26:10 AM »
I forgot about CMD_GETPROPS which really does not work for random images.
While the first parameter, the address the image has been decoded to is rather useless since that parameter has been fed into CMD_LOADIMAGE anyways, what is missing from CMD_GETPROPS is the format of the resulting bitmap data.
Depending on the image it could be RGB565, L8, PALETTED565, PALETTED4444 or ARGB4.

This is an issue with user-provided images.

Now that I checked CMD_LOADIMAGE for the resulting formats I wonder why it is ARGB4 and not ARGB1555.


And to add a question are the COMPRESSED_RGBA_ASTC_* formats 32 bit?

327
Discussion - EVE / Re: Automotive qualified BT81x?
« on: December 17, 2019, 04:11:28 PM »
I planned to skip Embedded World 2020 but then I saw your newsletter and changed my plans. :-)

328
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.

329
Discussion - EVE / Re: FT810 @ AtSamE70 interrupt-driven GUI (ESD4.5)
« on: December 16, 2019, 02:21:40 PM »
The interrupt is only the signal that a touch event occured.
So yes, you still need to assign touch tag values in order to get events
and at least read the current value when an interrupt occors.

But since reading the touch tags over SPI takes time as well (8 bytes) I would only set a flag
to indicate that touch should be looked at in my main loop (and only if that flag is not set already).
At 12MHz SPI it takes about 5,5µs to read REG_TOUCH_TAG.
This could be shortened by only reading the low byte to around 3,5µs.
That is like forever in IRQ for a 300MHz controller.

I am not using interrupts though because of how much time it takes to read the tag value and because
of the unpredictable nature of these interrupts.
I am just polling the tag value(s) once every 5ms as reading the values is necessary either way.

Hmm, I should update my sample-code: https://github.com/RudolphRiedel/FT800-FT813

Right now I am looking at 26µs idle for a two-point "multi-touch" function (BT815) that also includes making sure that EVE ist not currently otherwise busy.

If a touch event is registered only global vars are changed by my function.
Like which screen is to be displayed or how a toggle-switch or button is to be displayed.

Every 20ms my display gets refreshed, regardless if there are changes or not.
Tracking all possible changes and only updating on change only works with a static display.
But I am displaying for example measurements as well and use the timed refresh for animations.

My current GUI is processed in <250µs and then send over SPI using DMA.

The result is a 354µs load for the display within a 20ms intervall when idle, that is less than 2%.
I set myself a "limit" of 1ms for processing the GUI, that would be an allowable load of ~5%.
And the reaction to touch events feels instant.

Well, that is at least what works for me.

330
Discussion - EVE / Re: Fonts and xxx.ttf files
« on: December 12, 2019, 08:49:42 AM »
>What else do I have to consider to display the xxx.ttf files correctly?

You have not told us if you are using EVE2 or EVE3.
If you are using EVE2 things are a lot more complicated.
If you are using EVE3 then just convert the font to extended format,
put the .glyph and the .xfont file in the external FLASH,
copy the .xfont file to G-RAM on start of your programm,
use cmd_setfont2() in your display list to assign a bitmap handle to your custom font
and last but not least make sure you are using UTF-8 encoding for your source-file in
order to have your cmd_text() commands behave like you expect them to.

Something to be considered is the size of the resulting .glyph file.
If you are using a font like NotoSans from Google it contains a lot of glyphs and it might be a good idea
to convert the font first in order to remove several languages that you do not want to support.

Pages: 1 ... 20 21 [22] 23 24 ... 27