New feature, discussions. :-)

[RudolphRiedel]

Something is not quite working as expected or the somewhat deliberate lack of documentation around here left you with issues you feel you can not solve on your own?
Just ask. :-)

[theSwiftGuy]

Hi Rudolph,
I am using your library in a project that uses the XMC4700 and communicates using SPI at 750kHz. I'm having some issues with the refresh rate. I use the inflate method to load bitmaps from arrays of values, they are displayed, but often during refresh, some elements disappear or are distorted. If there is only text, which needs to be updated, it works for a while, after which the screen shows nothing. Also, I haven't found yet how I can refresh just a small area of a screen's content. I saw that you are very active on the Bridgetek forum, but I haven't been approved to post a question there yet, so I thought it would be a good idea to post it here as an introductory message.
I would like, if it is possible to discuss more about the subject, in private, maybe you can offer me some support, obviously paid.
Best regards!

[theSwiftGuy]

I went to : https://www.keil.com/demo/eval/arm.htm#/DOWNLOAD , complete the fields, and you get the .exe
Or what it is not working ?

[RudolphRrr]

I tried to follow the link on top "Keil MDK v6 Community Edition is now available".
Ignoring that and filling out that form will hopefully work then.

[theSwiftGuy]

The version I pointed I think is not a community one, but from what I know , you have a free license that could compile an amount of bytes, so you can try it. Also I guess is a free period of using

[RudolphRrr]

I'll try that and then I will also check what is here:
https://developer.arm.com/Tools%20and%20Software/Keil%20MDK#Editions
https://keil.arm.com/mdk-community

Yes, the version you linked looks like an evaluation version.

I kind of dislike Keil now before I even downloaded any package... :-)

[theSwiftGuy]

My opinion is that Keil is too much corporate. I am not a fan. And the price for a license is around 3k ,

[theSwiftGuy]

code - support.zip
I upload the files that are related with my GUI. In HMI_Riverdi, you will see the code that is creating the content and the methods used.
The XMC SPI is working in my case different in order to communicate with the display, clockPhase must be = PHASE1, the rest of modules are communicate using PHASE0, so that's the reason I change before call spiTransmit to PHASE1
In HMI_controller, there is an infinite loop, in which I call periodically method init_display_without_burst() which will update the display each second, increasing the value.

[theSwiftGuy]

In the attached images, when the last digit in the number is changed into 1 or 6, the text "S Circuit" is disappearing.(its the text above the 400 0c)
After a period, this wrong behavior disappeared. Now, is already on index 8601 and still working.
Perhaps this behavior could be related to an incorrect memory allocation and could lead us identifying where the problem is coming from.
After a while, it started to have a strange behavior.

[RudolphRiedel]

Hmm, you opened with "I am using your library in a project" and this is not my library.
It looks like it was derived from my library at some point, but it is something else entirely.
Sure, you can totally do this - but how am I supposed to support this?
There is no hardware abstraction anymore, everything is copied together, everything is renamed, modifications all over the place and the UI code is interleaved with the library code.
I can not even tell from which old version this was branched off.

I can't tell if your UI code is the issue or the library code itself.
This got a whole lot more complicated.

Can you at least separate the UI code from the library code?
And at this point, can you take a trace with a logic analyzer?

[RudolphRiedel]

While I am still waiting on the license key that Keil supposedly sent me twice already by email for the MDK community edition, I extracted the UI code from HMI_Riverdi.c, added it to my tft.c, converted it, made it compile and the next step will be to actually run it.
Not on the XMC7400 as the evalboard will take a couple more days to arrive, but on an ATSAME51.

One thing I did already notice though, you run your initStaticBackground() with every display refresh.
This is meant to be run once in the init function.

[RudolphRiedel]

Ok, I modified it further to actually display your UI.
tft.zip

This is adapted to the latest version of my llibrary, for example changing HMI_Riverdi_cmd_execute() to EVE_execute_cmd().

I left initStaticBackground() mostly unchanged, only removed the return value as I am using num_dl_static as global variable, this is not supposed to change and also could be converted to a constant.

I renamed HMI_Riverdi_TFT_init() to TFT_init() and removed the return value, just to match the original TFT_init() in tft.c.
I changed the backlight-pwm setting from 0x0 to 0x40 as I wanted to actually see something.
I added the call to initStaticBackground() as this needs to be run once.
I commented out the empty display list since EVE_init() already is providing this.

I modified my existing TFT_display() function that I call every 20ms in my main.c now to call init_display_without_burst() and provide the counter for it.

In init_display_without_burst() I removed the call to initStaticBackground().
I removed the osDelay(150) at the end as EVE_execute_cmd() already waits for the co-processor to complete the cmd-list.
I removed the write to REG_PWM_DUTY as there is no need to do this over and over again.

Then I ran into the issue that the c-library provided with Microchip Studio for the ATSAME51 does not provide a directly useable snprintf().
As the BT81x can embed numbers from variables into strings directly, I switched to using this feature.

So far this just works without a glitch although I am calling init_display_without_burst() much faster and using a much higher SPI clock.

Hmm, I need to switch to a different controller, I can not connect a logic-analyzer to the ATSAME51 board I am currently using.
I want to measure the time this needs with 750kHz SPI clock.

And in reference of "init_display_without_burst".
First off, this does not initialize the display.
And then you wrote "I am avoiding the burst mode, because I cannot keep SPI line occupied so much." - and this is a contradiction.
The "burst mode" removes some overhead from the commands so the overall transfer needs less time.

[theSwiftGuy]

Wow, that's impressive. There are so many things to be said. First, the mostly important one is a big THANK YOU!

Second, regarding your message about "you opened with "I am using your library in a project" and this is not my library."
I start to work on this task in December. It was a lot of research in the first place. I took that project, I took also riverdi-eve-examples.
I took even their "library". I guided using the project that thought it is using your library. I am sorry that I miss leaded you, but reading 3 different examples, that are looking pretty much the same, I got confused. And all I remember was that your library ft800 it is used.

After I found out about the Bridgetek forum, I saw your name everywhere and I start looking into your repository, and I start update my code using part of your code, mostly in EVE_busy and inflate methods.

Regarding the fact that the code is very messy, it is because I had some problems when I tried to add your library files into the projects. So, force by short amount of time, I decide to use only what I need for the moment, in order to start the communication with the display.
I am planning to do a refactoring, after I will succeed to make this screen work properly.

I have to try on my setup all you said previously, tomorrow on the office.
I am writing this message, and I already see that you written another one, Your passion is beyond the limit, I am amazed

[RudolphRiedel]

After short consideration I connected an Arduino UNO R3 clone as I have no idea how much time the SPI functions need to execute that you are using for the XMC4700 and you are not using the XMC4700 with DMA.
I am running the SPI with 1MHz clock.

The first result is this:

Now I added a EVE_start_cmd_burst() / EVE_end_cmd_burst():

So without changing anything, this is using less time on the SPI.
And note the "holes" in the SPI clock, these add up to about 300µs, whatever the 16MHz AVR needs to calculate during this time, it is very unlikely that the 144MHz 32bit XMC4700 needs the same time - so 0.3ms can be substracted from both runs which brings the result closer to what it is when using 750kHz SPI clock with the XMC4700.

[theSwiftGuy]

When I used burst mode, I kept the chip selector line too much time occupied, and in the project, we are using the same SPI line for other things, like buttons, motor, heating. ... so my colleague, told me that is not possible to keep so much time the SPI line, so I have to transmit the data in small block of messages, burst mode from what I saw, it transmits all the data, and using at 750kHz, like the project needs for the rest of the things, I measured that the time to transmit all the screen content takes around 300 ms , and after I transmitted without burst, the amount of time was about some uSeconds, but for each command individually.
Beside this, I didn't understand how can I use DMA mode, the library that is use for XMC, written by our colleagues, seems to complicated for my embedded level :)
If is possible to use DMA and get better results, I am open to do it, but I am not sure yet, how can I do that.

[RudolphRiedel]

Ah I see, as a hardware engineer I would call this a broken design and change the board.
What happens when you use that line for something else?
Pressing a button should be the worst, this is very likely to crash the display.

[theSwiftGuy]

Exactly. But they didn't see that coming. And the workaround for the moment is to do the trick with the semaphore. In the next design, they separate to use 2 SPI, because XMC support multiple SPIs, but for the moment I must work with what I have.

[theSwiftGuy]

They want to develop fast a new product, the team doesn't have so much experience, we are mostly juniors on this thing, and the management is pushing a lot, with short due times... almost impossible.
Personally, I am so stressed, I worked on this even in the holidays, and took the setup at home, to do extra work on my free time.
It's been a real pain in the ass.
So the help from your side, it means a lot for me.
I want to try later your changes, but I didn't took with me the logic analyzer. Maybe only tomorrow, it will be possible to measure the times.
Beside this, my HMI thread is calling for other function to get values from sensors, maybe this could also add some delays in the refreshing of the screen, the version that I send to you is without all this things.
Perhaps, next step is to understand how to use DMA, or maybe it is already used and I don't know.

[RudolphRiedel]

Ok. one step back, what you meant with "we are using the same SPI line for other things, like buttons, motor, heating" was not mis-using any of the SPI lines for anything else, you meant connecting to different SPI slaves on the same SPI?
Using one SPI for a couple of slaves would be ok.
Using the SPI lines for anything else than SPI would be bad, especially for uncontrollable things like buttons.

But then blocking the SPI less in one call of your display refresh function would be helpfull and functionally it would not matter if there is one big transfer or several small ones.

DMA would not help, at least not by much, it "only" would reduce the amount of time between bytes transferred and this is only really beneficial when used with a larger buffer.
What DMA does help with is to reduce the time a controller is spending in the update function but the SPI is blocked for a while after that function returned.

The first thing I would change is to speed up the SPI clock for the display update. If you can change the transfer mode, you can change the clock as well.
The next thing you could do is to call the display update function more often, but do less with every individual call.

Like this:

void init_display_without_burst(uint16_t dieTempTest)
{
    uint16_t readTemp = 23;
    uint16_t setTemp = dieTempTest;
    uint16_t readRPM = 750;
    uint16_t setRPM = 1300;
    uint16_t readSCircuitTemp = 400;
    uint16_t readVTrend = 95;
    uint32_t arguments[4];

    static uint8_t segment = 0;

    switch(segment)
    {
        case 0:
            EVE_cmd_dl(CMD_DLSTART);
            EVE_cmd_dl(DL_CLEAR_COLOR_RGB | BLACK);// 0xffffffUL); //
            EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
            break;

        case 1:
            EVE_cmd_append(MEM_DL_STATIC, num_dl_static); // append the static display content
            EVE_color_rgb(WHITE);
            break;

        case 2:
            arguments[0] = (uint32_t) readTemp;
            arguments[1] = (uint32_t) setTemp;
            EVE_cmd_text_var(80, 44, 31, EVE_OPT_FORMAT, "%d / %d oC", 2, arguments);
            break;

        case 3:
            arguments[0] = (uint32_t) readRPM;
            arguments[1] = (uint32_t) setRPM;
            EVE_cmd_text_var(57, 97, 31, EVE_OPT_FORMAT, "%d / %d RPM", 2, arguments);

        case 4:
            EVE_cmd_text(101, 150, 31, 0, "00 : 00 : 00");
            break;

        case 5:
            arguments[0] = (uint32_t) readSCircuitTemp;
            EVE_cmd_text_var(8, 246, 28, EVE_OPT_FORMAT, "%d oC", 1, arguments);
            break;

        case 6:
            arguments[0] = (uint32_t) readVTrend;
            EVE_cmd_text_var(111, 246, 28, EVE_OPT_FORMAT, "%d %%", 1, arguments);
            break;

        case 7:
            //EVE_cmd_text(204, 226, 22, 0, "pH");
            EVE_cmd_text(204, 246, 28, 0, "6.5");
            break;

        case 8:
            EVE_cmd_dl(DL_DISPLAY); /* instruct the graphics processor to show the list */
            EVE_cmd_dl(CMD_SWAP); /* make this list active */
            break;

        /* add a pause so we can identify the group in the logic-analyzer trace */
        case 9:
        case 10:
        case 11:
        case 12:
            break;

        default:
            segment = 0; /* we should not end up here */
            break;
    }

    segment++;
    if(segment > 12)
    {
        segment = 0;
    }
}

The result is this:

So instead of doing the full update once per second, stretch it out over a number of calls leaving all the time in between for other things on the same SPI.
I disabled the touch and still call TFT_display() every 20ms, the screen update is stretched over 260ms now.
It should be possible to make this much faster while still having the calls for other SPI slaves in between making the whole system more reactive.

I would like to see a trace of what your SPI looks like now with only the enable line for the display, no need to go into details what the other transfers are for.
Preferably as .sal file for Logic 2 from Saleae.

[theSwiftGuy]

Did you try to add also the bitmaps ? I commented the part where I am loading also a few bitmaps.
Updating the screen at 1 second , using also the icons, it made the screen crash faster than using only the text update.
I didn't mention, that the screen doesn't have touch feature, so we are using capacitive buttons.
From what my colleague told me, it will be necessary to run the UI thread under 1 second, because we must change values on the screen using the buttons, and the refresh rate must be even faster. The buttons are using the same SPI line, we are trying to switch polarities, using semaphores, so this is pretty much the reason behind all of this timing issues.

[RudolphRiedel]

I did not try to use the images.
But the CMD_INFLATE also should go in the init function, there is no need to do this over and over again.

[RudolphRiedel]

This is the project I am using, just as a reference:
EVE_Test_Arduino_PlatformIO.zip

I builds for a whole bunch of different Arduinos.

[theSwiftGuy]

Short update.
I kept the code as it is, and only changed to 20ms loop. It was working very well, after reload on the board with other value for refresh rate, it started to work very bad. I don't explain how or why it work very good at the first flash on device?
After I implemented your suggestions and it's not working anymore ... something is breaking everything. I must do some debugging .
I will come back with updates after I find what is the problem.

[RudolphRrr]

Well, keep in mind that I tried only a small fraction of it, I ran it with the current version of my library.

Yesterday I tried to compile the code for Arduino XMC4700 under PlatformIO - to find out that it does not compile, probably because the Arduino core used is years behind on the current version -> I put in a bug-ticket for this.
Hmm, and today I need to make another try to get a license for Keil ARM NDK, maybe this works better on a weekday...

[theSwiftGuy]

It's such a "pleasure" to work in embedded :)) and each time is a tiny thing that mess everything .. what I cannot explain, how ispossible to run better on 20 ms and worst under 1 second ? strange ..
btw, in function init_display_without_burst(), you added in your trial version, EVE_start_cmd_burst(); and end_cmd_burst(). I was not used them because I intended to use it without burst ? it is ok to use them?
As for library, I guess you are using your latest version 5 ?
I must start refactoring, maybe the big problem is coming from my interleaved code.

[RudolphRrr]

It's such a "pleasure" to work in embedded :))

I totally agree. :-)

btw, in function init_display_without_burst(), you added in your trial version, EVE_start_cmd_burst(); and end_cmd_burst()

That might not even been working with your variant, if I recall correctly your functions without _burst suffix do not have the code for it.

As for library, I guess you are using your latest version 5 ?

The latest release of V5, so 5.0.8 or current.

[theSwiftGuy]

Somehow, after I rebuild and flash the device, it happens that I get some content from the previous display. How can I ensure that the all memory of the old display content is cleared ? Because it seems that the display memory has old content, or I don't get it how is possible to see old content, like old number instead the current one

[theSwiftGuy]

No, I am not calling initStaticBackground(), and I commented the append call and is not working to good.
Regarding, RST_PULSE, I see that I use somehow the RST_PULSE, but in Riverdi example they use it after PDN calls, and in the manual it is used after ACTIVE command. I must check if RST_PULSE is available on BT815.
uint8_t HMI_Riverdi_init(void)
{
HMI_controller_setPDNPort(HAL_GPIO_OUTPUT_STATE_LOW);//set
osDelay(20); //6); /* minimum time for power-down is 5ms /
HMI_controller_setPDNPort(HAL_GPIO_OUTPUT_STATE_HIGH);//clear
osDelay(20); / minimum time to allow from rising PD_N to first access is 20ms /
HMI_Riverdi_cmdWrite(0x68,0);// RST_PULSE - cml
osDelay(300);
HMI_Riverdi_cmdWrite(EVE_CLKEXT,0); / setup EVE for external clock - EVE_CLKEXT = 0x44 /
HMI_Riverdi_cmdWrite(EVE_CLKSEL,0x46); / set clock to 72 MHz /
HMI_Riverdi_cmdWrite(EVE_ACTIVE,0); / start EVE */
osDelay(400);
HMI_Riverdi_memWrite32(REG_FREQUENCY, 72000000);
chipid = HMI_Riverdi_memRead8(REG_ID);

[theSwiftGuy]

I didn't used yet the CMD_LOADIMAGE, I didn't load the bitmaps yet, and if I am using I use setBitmaps

[RudolphRrr]

Yes, I have RST_PULSE directly after the reset by PD line, perhaps I need to do some tests with disconnected PD line again, it has been a while.

And the only things I see in your initStaticBackground() that have an impact on the rest of the display list are:
HMI_Riverdi_cmd_bgcolor(0xfbfafe);
HMI_Riverdi_cmd_dl(VERTEX_FORMAT(0));
HMI_Riverdi_cmd_dl(COLOR_RGB(0x6B, 0x6B, 0x6B));

[RudolphRrr]

Oh, btw, your logo_init[] is way longer than the 6547 bytes it says it has, more like 12000.
I was getting warnings when compiling at first but as none of the images is in active code I removed the arrays.

[theSwiftGuy]

I am not using logo_init[], I used it in the beginning, I have to clean my code. There are many trials in that code :)

[theSwiftGuy]

Today's result is not good. Everything I tried didn't work. I'm trying your suggestions and it doesn't seem to want to work. Somehow my version works fine for a while then fails.
I'm thinking of leaving the problem with the refresh for the moment and investigating the part with the loading of images, where if there are too many icons, distortions appear. Tomorrow is a new day of trials. I hope it will be more productive.

[theSwiftGuy]

Hi,
I ran again the old code, with initStaticBackground() run each time. I extracted the capture.
Maybe you can see something useful in it. When the increased value is equal to 7, 12 or 17 the screen had refresh issue.
In the excel file, I marked for each message what message is, (DLSTART, DLCLEAR, ... , SWAP)
I will try to obtain a short use case, to see clearly, what is the difference when something is wrong between repeated messages.
logic-pro.zip

[RudolphRiedel]

This reminds me that I started a high-level analyzer a while ago that I have not touched the last ten months.
It is barely usefull so far:

The last image however shows that your initialization is not working correctly.
0x30200c is REG_FREQUENCY, this is correct.
But when you look at MISO, the EVE chip is somehow not yet answering although there is a delay of 400ms between CMD_ACTIVE and writing to REG_FREQUENCY.
What I am missing in between is reading of REG_ID.
The first correct MISO sequence is quite a lot later, check for the sequence 0x00 0x4a 0x43 0x42.
Only at this point the communication actually starts, if anything else in between CMD_ACTIVE and this worked it would be quite surprising.

[theSwiftGuy]

Yes, I see that is getting the correct answer lately, I was having sometimes that problem. And I didn't understand why. Sometimes I get the correct id response "0x4a 0x43 0x42" immediately after ACTIVE command, but sometimes only after REG_GPIO, from what I remember, I will check tomorrow at work. Somehow after some new project buildings, that response is coming correct, now is not coming after ACTIVE.
But, I don't think that influence the display behaviour. Or?

[theSwiftGuy]

The display is working even if it is not respond correctly on MISO line, but at some point it starts to respond, how I said earlier, I encounter this problem some time ago, it is somehow related with the chip(I guess), I want to know what is happening but I didn't understand, but last time a merge with other branch and a new flash on board have fixed this issue. Very strange. I will try tomorrow somehow to fix this issue, I don't know how, but I will try.

[RudolphRrr]

Well, in my book it is not working properly if the EVE chip is not responding, regardless of anything being displayed or not.
You can not trust that any of the commands actually were executed properly, maybe some of it is just working because the default values in these registers are close enough.

[theSwiftGuy]

Hi again,
I caught a session where the display got a black screen, no more content is being displayed, but data is still being sent.
I have also attached a short session with some refreshes that are broken.
For the bad session, I cannot extract data as excel file. So the excel file is only for the good session.

short_session_plus_session_with_black_screen_no_content_error.zip

[RudolphRrr]

Yes and no, that memread32 does not work somehow in that the CS line goes low too late.
But before that there was an issue with the display list that made the co-processor stop executing commands.
So it looks like there was an issue and the code tried to recover from it but this went wrong as well.

[theSwiftGuy]

It is possible to be SPI transition, which is a little bit ambiguous, especially on the read side, I must invest more time to figure it out how it is really works, maybe that's the entire problem, you and I use different SPI code, and on your chip is working fine, so in the final, I guess that only the SPI is the problem..

[RudolphRiedel]

I analyzed the first part of the bad-session log and I do not actually believe that this is what is causing the issue.
bad_session_analysis.zip

Well, there is this bad read in between but what is leading up to it are countless reads of REG_CMDB_SPACE as the co-processor refuses to process the data.
But the commands are all fine down to the padded at the end of the CMD_TEXT commands.
I also decoded the three texts now and these are „S Circuit“, „V Trend“ and „pH“.

I am afraid things went off the rails before this.

[theSwiftGuy]

I created a simple use case, with a single line, that is changing 2 values, one is incremented by the thread,
and the other one is increased by 3, in order to see something different as value.
At some moments, there is a glitch on the screen, that I cached in some logs, but not on the camera.
When the glitch is catched, the message for CMD_TEXT usually has 4 bytes extra, but once I got a message with only 2 bytes extra.( I extracted already into the excel)
cmd_text_var.zip
the counter has reached 80k refreshes.

[theSwiftGuy]

In the previous example, I used the method show2lines, in which, for the line 2 , I create the string, but I think at some point, the created string was longer then the size allocated and I am guessing that maybe it could generate that fatal behavior , when the screen is going black forever. Now using your cmd_text_var, it seems that at least I don't get that black screen yet. Unfortunately, I cannot leave the device ON after I go home. Already reached 90k+ refreshes. The refresh rate is 100ms.

[theSwiftGuy]

Hi Rudolph,
I have good news. It seems that the problem was indeed the SPI. Somehow a module keeps passing some data and that thing randomly corrupted my display data. Now it seems to work ok.
Meanwhile, I started playing with a simple SPI project, but now I have to switch back to the regular project.
I want to thank you for all your support.
If I have other questions , can I write you here ?
Best regards!

[RudolphRrr]

If I have other questions , can I write you here ?

Sure, perhaps start a new discussion though. :-)
I also hope that I am not the only one answering here. :-)

And in regards of the XMC4700, I am still interested in adding proper support, this is on hold right now as getting a Community License for Keil µVision does not seem to be possible and I have another architecture I started work on earlier.
However, there is a "ARM Keil Studio Pack" for VSCode and I believe it uses the "Arm Compiler for Embedded 6.x", so µVision IDE or not, making it compile looks feasible.

[theSwiftGuy]

Hi again :)
I start refactoring, and I moved all the functions cmd_inflate() from the display_menu method. It is moving much faster right now.

bool HMI_TFT_init()
{
/// Initializes EVE (or checks if its already initialized). Only at first successful HMI_init() the tft is set active, backlight is set to medium brightness
uint8_t tft_active = false;
// Initialize EVE and initialize TFT if that is OK
if(HMI_init() != 0)
{
// Mark Display as active (TFT_display only does anything after his)
tft_active = true;

      HMI_Riverdi_cmd_inflate(0, sensor_icon, sizeof(sensor_icon));
      HMI_Riverdi_cmd_inflate(1152, volume_icon, sizeof(volume_icon));
      ....
      //must add initStaticBackground also
      // Initial Backlight strength
      HMI_Riverdi_memWrite8(REG_PWM_DUTY, 0x0);	// setup backlight, range is from 0 = off to 0x80 = max		
  }

return tft_active;

}