Why do I need this library?

[jacobbenlewis]

Hi, I'm new to display development in general, and to EVE specifically. Our EEs have decided to use the BT817 with a TBD display connected to our Infineon tc297 and I'm trying to learn about it.

So I found the EVE Screen Editor which ostensibly generates some code based on static screens I draw in their editor.

Does this library provide any new widgets or graphics not available in stock EVE Screen Editor? Or is it just about providing like a HAL to some pre-ported displays and MCUs?

Thanks! I also read through some existing discussions on trying to use this library with LVGL and have been convinced to leave it alone. The examples on LVGL's web site sure do look nicer than what I can do in EVE Screen Editor though.

[RudolphRrr]

use the BT817 with a TBD display connected to our Infineon tc297 and I'm trying to learn about it.

Interesting, the ECU I am currently working with has a TC297. :-)
And while there is a connector for a display as parts of the design are from me, I did not have the opportunity so far to actually connect a display to it.
Now I wonder how difficult it would be to integrate a display in our project. :-)

Does this library provide any new widgets or graphics not available in stock EVE Screen Editor?
Or is it just about providing like a HAL to some pre-ported displays and MCUs?

For the most part this library and the few others for EVE chips "merely" provide a HAL, yes.
So in essence this provides the API that translates commands and parameters for these commands into the stream of bytes that needs to be send over the SPI.

So this sits in between the application layer and the MCAL.

Yes, you do want something like this. :-)

There are a couple of functions like EVE_init() and EVE_init_flash() that go way beyond the plain EVE chip API but this is not adding any new widgets.

And in case of displays this is supporting at least all modules that I am aware of from FT810 to BT818.
In regards of MCUs, this library should be adaptable to almost anything.
I have not yet checked out the SPI functions of the Infineon MCAL we are using for the TC297 but I am confident that it can be made to work.

And using LVGL would mean to not actually use the EVE chips, this reduces EVE to a SPI connected framebuffer.
I am told that it works, yes, but I consider this kind of pointless and a better solution would be to use a different hardware with LVGL.

[jacobbenlewis]

Thanks for the great reply @RudolphRrr! If you do end up porting your library to the TC297 let me know as that would be very helpful.

Does your library work with the output of EVE Screen Editor at all? Should I not even bother with it?

[RudolphRiedel]

Well, now, at least I successfully integrated the library on friday into our Autosar project.
For the most part what needs to be adapted is one of the target files, in this case this one:
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_target/EVE_target_Tricore.h

This is not what I ended up using though as this was from an older project with a TC222.
I replaced the function calls with NOP lines to check if everything else compiles - and it did not right away,
but I fixed a couple of things.
And I stripped the library, EVE_commands.c is necessary, EVE_cpp_target.cpp, EVE_cpp_wrapper.cpp and EVE_target.c are not needed.

Plus a little tweak to the makefile and it compiled fine.

So HW_DIO_SetSync() for example needs to be replaced with whatever is actually used.
We are using the Infineon MCAL and I would actually need to configure two more I/O pins before I could use it.
And well, the SPI.

EVE_target.c would be where I would put support code in beyond of what is in EVE_target_Tricore.h now,
but at least for now I have none.

I have no hardware yet that I can actually attach a display to, that might cost me a couple of lunch breaks. :-)
If I can find an older board that I can modify for this, defininately can not use any of our current ECUs.

What the EVE Screen Editor shows in the Coprocessor window is rather close to what I have in my library.
CLEAR(1, 1, 1)
CMD_TEXT(143, 250, 28, 0, "Text")
CMD_BUTTON(246, 321, 120, 36, 27, 0, "Button")

EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
EVE_cmd_text(143, 250, 28, 0, "Text");
EVE_cmd_button(246, 321, 120, 36, 27, 0, "Button");

So the order of arguments and their types is the same, at least for most commands.

[dstulken]

So I found the EVE Screen Editor which ostensibly generates some code based on static screens I draw in their editor.
Does this library provide any new widgets or graphics not available in stock EVE Screen Editor?

The short answer is "Yes". People, particularly on the creative side, tend to be polarized in how they think. WYSIWYG layout editors are perfect for lots of situations... but in other cases, purely programmatic layouts are highly beneficial.

Personally, I rather enjoy the ability to have an entire UI that can be designed in nothing but a text editor, and that I can dynamically generate and position UI pages and display elements depending on runtime conditions.

Plus, Eve Screen Designer is yet another developer tool dependency that has to be installed and maintained. I'm sure it's great for those that use it - but it's Windows-only software in a cross-platform world, and that alone makes it a non-starter for many organizations.

[RudolphRiedel]

I am definately not doing enough UIs for my liking. :-)
And definately not in a product or consumer context.
So EVE Screen Designer is not for me.
And I am using EVE Screen Editor to quickly try out something or to provide working examples for things like drawing circles.

What a good UI is depends on who is using it.
A coffee maker would need more eye-candy than a tool for the test-bench that is used in a professional environment.
And yes, that tool needs some eye-candy as well, but this is where I am limited. :-)

Hmm, what I actually need to do now is to prepare and upload a bunch of minor fixes.
The version I did compile earlier was down to a single MISRA warning - advisory, at least in the context of the project I was compiling for.

[RudolphRiedel]

Here, this is what I added to our Autosar TC297 project:
EmbeddedVideoEngine_Tricore.zip

I am not actually sure what this is, perhaps a complex device driver.
Anyways, I put this into the folder with the base software modules.

I went one step further now, configured the chip-select and power-down pins in the MCAL, generated the DIO code and added the apropriate calls to EVE_target_Tricore.h.
This would probably toggle the pins if I would add EVE_init() to Ecum_init().

No SPI so far though, we do have two other devices on that SPI but these are not used in the project and one is not even populated.
But what I can share is limited and even when I get this to work for me you still need to adapt it since I am probably using a different MCAL/HAL than you have in your project.

[jacobbenlewis]

Hi @RudolphRiedel, more good info, thank you! And thank you to @dstulken for your input as well!

So it sounds like you are working to get the library working on your new tc297 ECU, and now I'm getting a little confused on just what you're doing for your project, versus what I will need to do to use the library for my project. Tasks that I've seen mentioned:

• adapt EVE_target_Tricore.h (but you didn’t end up using this?)
• strip the library (was this just for testing?)
• tweak a makefile
• replace HW_DIO_SetSync() with whatever is actually used (in MCAL to power up/down and set chip select I assume)
• configure 2 I/O pins (power up/down and chip select?) and SPI
• add more support code to EVE_target.c (what sort of support code?)
• prepare and upload a bunch of minor fixes
• add EmbeddedVideoEngine_Tricore.zip to the project (I don’t understand why you added this, especially when you don’t know what it is LOL)
• generate the DIO code and add the appropriate calls to EVE_targetTricore.h
• add EVE_init() to Ecum_init()
• adapt to my MCAL/HAL

Sounds like EVE Screen Editor (not Screen Designer) could be moderately helpful to get started, but I would need to port whatever commands it produced to use the commands from this library. Is that right?

I am maybe going to need more “eye candy”, is that achievable with this library? Am I going to be making my own eye candy by drawing lines and circles?

Thanks again! This is very helpful.

[RudolphRrr]

Ok, sorry, I tend to provide too much information. :-)

adapt EVE_target_Tricore.h (but you didn’t end up using this?)

I ended up not using the version I linked to and that is still current in this repository, I modified it.

strip the library (was this just for testing?)

Not necessary, but there are a number of files that are not needed, depending on the project context.
For example there are 34 header files in the EVE_target folder of the repository and you usually just need one.

tweak a makefile

Well, yes, I needed to do this, you might not, depends on the project.

replace HW_DIO_SetSync() with whatever is actually used (in MCAL to power up/down and set chip select I assume)
configure 2 I/O pins (power up/down and chip select?) and SPI

Yes, this is what you need to do in order to "port" this library to your target project.

add more support code to EVE_target.c (what sort of support code?)

This is something I am considering to do and this is either DMA support or at least blocking buffered transfers.
But for this I would need to have it up and running first.

prepare and upload a bunch of minor fixes

I did, compiling in the context of a TC297 Autosar project showed a couple of issues that I did not run into before.
And these are gone now.
Please report any issue you encounter.

add EmbeddedVideoEngine_Tricore.zip to the project (I don’t understand why you added this, especially when you don’t know what it is LOL)

This is just the exact folder with this library that I added to my TC297 project, stripped and with minor adaptions in regards to what is in this repository.

generate the DIO code and add the appropriate calls to EVE_targetTricore.h
add EVE_init() to Ecum_init()
adapt to my MCAL/HAL

This depends on your toolchain and your project.
The two IOs and the SPI need to be initialized before using the library.
Yes, the target code might need to be adapted,
Yes, EVE_init() needs to be called.

Oh, something else to consider as "Integration Requirement".
EVE_init() needs time to do it's job, how much exactly depends on the Eve chip used but at least about 75ms, usually more.
So as you are likely to use a watchdog it should be either not active yet or on longer timeout for the initialization.

Sounds like EVE Screen Editor (not Screen Designer) could be moderately helpful to get started,
but I would need to port whatever commands it produced to use the commands from this library. Is that right?

This is correct.

I am maybe going to need more “eye candy”, is that achievable with this library?
Am I going to be making my own eye candy by drawing lines and circles?

It sure is possible and you are not limited to lines and circles, everything can be used for touch events and so images could be used as buttons for example.

[jacobbenlewis]

Great! OK, I'm going to start setting up a project next week. I don't have devkit hardware yet, but that's hopefully coming soon, and I can at least get a project started with compiling code. I'll probably be writing with more questions...

[RudolphRrr]

I just remembered that we have Infineon Eval boards as well and checked and found a KIT_AURIX_TC297_TFT.
As this board is supported by the Aurix Development Studio, I can try to setup a project for it.
I still have no idea what you are actually using besides the TC297, not asking, stating. :-)

[jacobbenlewis]

Nice. I was looking at that dev kit as possibly the model for our hardware, but we decided we needed a bigger screen.

We're still nailing down our hardware, but for dev purposes I'm supposed to be getting a KIT_A2G_TC397_3V3_TFT soon (so we may actually end up with a tc397, supposed to be very similar to tc297), connected to this display which has the BT817 integrated:
https://www.matrixorbital.com/eve4x-70g-ips-1024600a

[RudolphRiedel]

I'll ask around for the KIT_A2G_TC397_3V3_TFT.
But yeah, even more cores and more memory and probably more of everything won't make a difference, at least not for me. :-)

The EVE4x modules from Matrix Orbital or on my want-to-buy list, especially the EVE4x-40G-IPS, but unfortunately these have not made it into distribution so far and shipping from Canada is a bit cost prohibitive for me given that I would "just" improve my collection. :-)
Well, I still hope these will become available from Mouser or Digikey.

[RudolphRiedel]

Damn, I have a TC297 and a TC234 kit here with me now and it looks like I won't be playing with either over the weekend.
Turned out that both boards are manipulated, probably to enable the hardware watchdog in the SBC.
I soldered one resitor to the default position but the boards keep going to power-down, I need to put these under a microscope and try to put everything back to default.

And no answer to my call for a TC397 board yet, but I posted it on an internal board not everyone is checking regulary and a large number of colleages are probably on vacation.

[jacobbenlewis]

Hey @RudolphRiedel, I got my test setup running as I described previously. It's using the Matrix Orbital EVE library from here which one of our EEs modified to work with the tc397 dev kit.

So I know I'll be asked why we should use your library instead of Matrix Orbital's since we already have it kind of working. Do you have an argument I can pass along?

Did you get your test setup working with the tc297?

[dstulken]

So I know I'll be asked why we should use your library instead of Matrix Orbital's since we already have it kind of working. Do you have an argument I can pass along?

@RudolphRrr already gave a good list of technical reasons... but if it is business folks you need to convince, the simple answer is that this library supports EVE-based displays from a wide variety of manufacturers, leaving your options open in the future if needed. ("Avoids vendor lock-in"). Granted, there are usually hardware differences to overcome as well, but letting the software side be prepared for anything (obsolescence, supply chain issues, or even just changes to your own products) is a significant benefit.

[RudolphRrr]

Hi,

So I know I'll be asked why we should use your library instead of Matrix Orbital's since we already have it kind of working.
Do you have an argument I can pass along?

I am certain that my library is faster, but this does not mean much with something like a TC397.
My library is prepared to do the display update with DMA.
The startup with my library is faster as I am not using a fixed 300ms delay after CMD_ACTIVE.
My library has the BT8xx running with the full 72MHz clock.
My library is feature-complete in regards of the EVE api, I am not sure if the Matrix Orbital library is.
My library is almost MISRA-C 2012 compliant.

Did you get your test setup working with the tc297?

No, not yet, we went thru two release-cycles in our project, not much time to tinker on the side.
And that reminds me that I wanted to ask a colleague directly if he has a TC297 or TC397 board.

[RudolphRiedel]

Oh, I am fairly certain that I can get back the TC387 dev kit and I still have TC297 ECUs.
So hardware is not the issue, I mostly ran out of time in the last weeks of the year at work and with a bunch of other projects I needed to resolve.
Hmm, I need to charge my work notebook anyways, maybe it is about time to take a closer looks at the TC297 and TC387 user manuals. :-)

[jacobbenlewis]

Hi Rudolph. I was able to get a blue dot to show up after modifying several functions in your library to look like the Matrix Orbital library. So like

void EVE_cmdWrite(uint8_t const command, uint8_t const parameter)
{
    HostCommand(command, parameter);
//    EVE_cs_set();
//    spi_transmit(command);
//    spi_transmit(parameter);
//    spi_transmit(0U);
//    EVE_cs_clear();
}

static inline void HostCommand(uint8_t HCMD, uint8_t param)
{
    //Ported TC397 code
    g_qspi.spiBuffers.spiMasterTxBuffer[0]=HCMD;
    g_qspi.spiBuffers.spiMasterTxBuffer[1]=param;
    g_qspi.spiBuffers.spiMasterTxBuffer[2]=0x00;
    IfxQspi_SpiMaster_exchange(&g_qspi.spiMasterChannel, &g_qspi.spiBuffers.spiMasterTxBuffer[0], &g_qspi.spiBuffers.spiMasterRxBuffer[0], 3);
    while(IfxQspi_SpiMaster_getStatus(&g_qspi.spiMasterChannel) == SpiIf_Status_busy) {}
}

That's about as far as I've gotten. I'm not sure if it makes more sense to keep going and convert all commands to use this style of SPI writes, or try to figure out why the tc397 doesn't seem to like 1 byte SPI writes. The above seems more efficient anyway, doesn't it? Similar to your burst mode?

[RudolphRrr]

While this should work, the ugly part of it is that this removes the hardware-abstraction from my library.
And it is not exactly like the burst mode since what the burst-mode does is to remove the need to send the 24 bit address for read/write commands with every command.

I checked what I actually have for the Tricore and found that I can not use it.
We are using a licensed MCAL from Infineon for our Autosar projects.
I hoped the MCAL would use the Ifx library so I would have this file for example:
https://github.com/Infineon/AURIX_code_examples/blob/master/code_examples/SPI_CPU_1_KIT_TC297_TFT/Libraries/iLLD/TC29B/Tricore/Qspi/SpiMaster/IfxQspi_SpiMaster.c

But no, the MCAL uses a completely different implementation, there is no IfxQspi_SpiMaster_exchange() function.

Doing this with the MCAL would mean that configuration with Tresos is required and this could only be used with MCAL.
Doing this with the Ifx library would mean that it could only be used with the Ifx library.

So I started to write this as complex device driver with direct register access.
At least there is a "IfxQspi_reg.h" in both implementations and I just checked, except for a note in the license information, these are identical.

And then I went off track again since what I am expected to work on is something else entirely. :-)

I have to further read in the user manual what the QSPI module actually can and can not do.

[jacobbenlewis]

Exploring some more I saw that your burst commands always send 32 bits using the spi_transmit_32 function, and that seemed like a good place to put the interface to the IfxQspi driver and then just avoid using spi_transmit().

But of course the IfxQspi driver is handling setting and clearing the chip select which each transmission so it messes up burst mode. With the stock IfxQspi driver it looks like you either use it's functions for setting/clearing cs, or you let the hardware handle it. Either way it happens with every call to IfxQspi_SpiMaster_Exchange(). So I modified IfxQspi_SpiMaster_activateSlso()/deactivateSlso() to do nothing and am controling them manually as you do with your commands. It seems to be working, at least with my first attempt at clearing the screen and then drawing a blue dot.

To summarize, in order to get your library to work with tc397 using Ifx driver, I:

• spiMasterChannelConfig.base.mode.autoCS = 0; // use manual chip select functions
• comment out calls in IfxQspi_SpiMaster_activateSlso()/deactivateSlso()
• change spi_transmit_32 to use IfxQspi_SpiMaster_exchange()
• change all the EVE_memReadXX()/WriteXX() functions to call functions using IfxQspi_SpiMaster_exchange()
• change EVE_cmdWrite() to call a function using IfxQspi_SpiMaster_exchange()
• use only burst commands for creating my display list

So now is it worth it? Think we can figure out a way to fit this into your abstraction? Or should I give up at this point and go to the Matrix Orbital library? Do you know of any other libraries that should be considered?

Some code examples:

uint8_t EVE_memRead8(uint32_t const ft_address)
{
    uint8_t data;
    EVE_cs_set();
    data = rd8(ft_address);
//    spi_transmit_32(((ft_address >> 16U) & 0x0000007fUL) + (ft_address & 0x0000ff00UL) + ((ft_address & 0x000000ffUL) << 16U));
//    data = spi_receive(0U); /* read data byte by sending another dummy byte */
    EVE_cs_clear();
    return (data);
}

static inline uint8_t rd8(uint32_t address)
{
    //Ported TC397 code
    uint8_t Data8;
    g_qspi.spiBuffers.spiMasterTxBuffer[0]=((address >> 16) & 0x3F);
    g_qspi.spiBuffers.spiMasterTxBuffer[1]=((address >> 8) & 0xff);
    g_qspi.spiBuffers.spiMasterTxBuffer[2]=(address & 0xff);
    g_qspi.spiBuffers.spiMasterTxBuffer[3]=0x00;
    g_qspi.spiBuffers.spiMasterTxBuffer[4]=0x00;
    IfxQspi_SpiMaster_exchange(&g_qspi.spiMasterChannel, &g_qspi.spiBuffers.spiMasterTxBuffer[0], &g_qspi.spiBuffers.spiMasterRxBuffer[0], 5);
    while(IfxQspi_SpiMaster_getStatus(&g_qspi.spiMasterChannel) == SpiIf_Status_busy) {}
    Data8 = g_qspi.spiBuffers.spiMasterRxBuffer[4];
    return (Data8);
}

void EVE_start_cmd_burst(void)
{
.
.
.
    EVE_cs_set();
    StartBurst();
//    spi_transmit((uint8_t) 0xB0U); /* high-byte of REG_CMDB_WRITE + MEM_WRITE */
//    spi_transmit((uint8_t) 0x25U); /* middle-byte of REG_CMDB_WRITE */
//    spi_transmit((uint8_t) 0x78U); /* low-byte of REG_CMDB_WRITE */
#endif
}

static inline void StartBurst()
{
    //Ported TC397 code
    g_qspi.spiBuffers.spiMasterTxBuffer[0]=0xB0U; /* high-byte of REG_CMDB_WRITE + MEM_WRITE */
    g_qspi.spiBuffers.spiMasterTxBuffer[1]=0x25U; /* middle-byte of REG_CMDB_WRITE */
    g_qspi.spiBuffers.spiMasterTxBuffer[2]=0x78U; /* low-byte of REG_CMDB_WRITE */
    IfxQspi_SpiMaster_exchange(&g_qspi.spiMasterChannel, &g_qspi.spiBuffers.spiMasterTxBuffer[0], &g_qspi.spiBuffers.spiMasterRxBuffer[0], 3);
    while(IfxQspi_SpiMaster_getStatus(&g_qspi.spiMasterChannel) == SpiIf_Status_busy) {}
}

[RudolphRiedel]

I brought an ECU home with me that has a TC297 and a debugger.
From what I read in the QSPI description so far it is possible to use the unit without hardware CS support and single transfers,
although it looks like a good idea would be to trigger the actual transfer with EVE_cs_clear().
I did not get that far though as the software I am modifying is using Register Access Protection and now runs into a Trap with the extra code I added to modify two GPIOs...

[RudolphRrr]

So I asked and it is not looking good in regards of TC397 boards.
We had KIT_A2G_TC387_5V_TFT boards, but not anymore.
And my suggestion to buy one was answered with the question why we would need one, as we currently are working on a TC3x7 ECU.
Hmm.

Adding the SPI code to our current TC297 ECU does likely not make any difference in regards of TC3xx.

[RudolphRrr]

Good news, I just received a KIT_A2G_TC387_5V_TFT to play with.
Now I only have to find the time to properly do so. :-)

It's using the Matrix Orbital EVE library from here
which one of our EEs modified to work with the tc397 dev kit.

I would like to take a peek at this modifications. :-)

[jacobbenlewis]

Hi @RudolphRiedel , I forked your library and created a branch here with the changes I had to make for it to work with Ifx QSPI driver. I am not sure if/what will have to be changed for MCAL which is what I will eventually be using. Let me know what you think.

[RudolphRiedel]

I'll have a look.
I have one our ECUs here with TC297 and a Lauterbach Debugger to flash it.
But that thing frustrated me in between so I put it on hold - for a couple of reasons.
At least I integrated my module into the software so that my _setup() and _main() functions are called and I can control the CS and PD lines.