Page 2 of 2

Re: I2C Read with GTT43

Posted: Tue Sep 11, 2018 4:57 pm
by Daniel Divino
Hi Haz,

The Set_Communication_Channel command would be included in the post load script on the GTT. That way you wouldn't have to continuously attempt to open communication with the display, and instead the GTT would open communication once the first screen has been loaded. Once the GTT opens communication, it would return the backlight brightness to the host. All the host would have to do is continuously read the GTT's I2C port, until it receives a value from the GTT. At that point, the host will know that the GTT has finished loading its first screen, communication has been re-opened, and you are now in sync with the display.

After further discussing with my team here, they believe it would be safer to set the default communication channel to I2C in the GTT Designer, and on the host's end, send a gtt_get_backlight command. When configured this way, the GTT will report all data to the host during startup, during which the host will send the gtt_get_backlight command to the GTT. The gtt_get_backlight will act like a blocking function, and parse through all of the reported values until the backlight value is returned. Once the backlight value is returned, the code will continue on.

Cheers,
Daniel Divino

Re: I2C Read with GTT43

Posted: Tue Sep 11, 2018 5:34 pm
by Haz
ok, I made the changes, and now I am able to synchronize as you mentioned.

I will be using the get_backlight command to synchronize every time I load a new screen. Is there any downside to this? or a better way of doing it?

I am also running a poll for the gtt_parser_process, is there a minimum time i need to put between reads to make sure it processes them internally?

Re: I2C Read with GTT43

Posted: Wed Sep 12, 2018 8:19 am
by Haz
ok, so I implemented the code:

Code: Select all

/* Synchronize with the LCD */
 uint8_t backlight = gtt_get_backlight(&gtt1);
Log_MessageVariadic(info, "Backlight = %d\r\n", backlight);
/* Setup the first screen */
gtt_run_script(&gtt1, "MustangElectronicDisplay_SystemManagement\\Screen_Login\\Screen_Login.bin");
uiParameters.screenId = SCREEN_LOGIN;
backlight = gtt_get_backlight(&gtt1);
Log_MessageVariadic(info, "Backlight = %d\r\n", backlight);
//TODO: EHK - Need to fix this delay. The system locks up if there is no delay
 vTaskDelay(pdMS_TO_TICKS(3000));
The Screen_Login loads fine, but the code throws a fatal error due to I2C commands out of range. So the data coming from the LCD when i send the second command for backlight is out of sync (the command code is where the length should be) so out of bound.

If I comment the second gtt_get_backlight after running the script, it works only with the vTaskDelay, giving the script enough time to load properly. If I remove the delay, the error happens.

So something in the LCD is out of sync when I have fast repeated commands while a script is being executed. I am using the same project I sent you. So the only post load is the make the communication as I2C and the rest is in my host.

I am really stuck. Without getting the screen to work with screen navigation, etc... I cannot do anything on the rest of the project.

Any help is really appreciated.

Thanks,
H-

Re: I2C Read with GTT43

Posted: Wed Sep 12, 2018 8:48 am
by Haz
Some more debugging:
The code works completely if i add a 1 second delay after every screen load.

And I have to call the gtt_set_default_channel(&gtt1, eChannel_I2C); after every screen load. Even if it is setup in GTT designer, I will probably have to add this to the Post load of each screen in GTT designer for some reason.

I hope this helps narrow down the problem for you

Re: I2C Read with GTT43

Posted: Thu Sep 13, 2018 10:48 pm
by Daniel Divino
Hi Haz,

What is the get_backlight command returning to your host? Also, are the returns consistent?

You mentioned that if you remove the get_backlight command and the vTaskDelay, you get an error. I assume this is the I2C lock up you mentioned previously?

Also, the gtt_default_communication_channel only needs to be sent once, so there shouldn't be any need to send it after every screen. My assumption would be that after every screen transition, the display and host become out of sync one way or another, and setting the communication channel syncs the display. I'll see if I can replicate your setup to see exactly what might be getting returned from the display, and where the communication might get out of sync.

Cheers,
Daniel

Re: I2C Read with GTT43

Posted: Fri Sep 14, 2018 10:24 am
by Haz
Thank you Daniel,
The get backlight is returning the right command, and the value expected.
I do however need to send the set communication command after every screen, otherwise, my new loaded screen is not sending any of the button presses. If i add the command, then i start seeing the data coming. Not sure why that is different than what you expect. I have not tried to make the change in the project though and removing all of them. But I recall before that this works. Having the communication set in the project setting is the only global setting which worked for me.

On the LCD out of sync topic:
The LCD gets out of sync in a way that it mixes up the bytes sent, and my code catches it and throws an assert. What i mean in the lockup is that the data returns for example will have 252 in the length byte, but in fact, that byte should be the command.

My workaround now which is the reason i say it is an out of sync problem is to to add a delay after every screen load. The delay is about 1s, and the more objects i have on the screen, I have a few which go to 1.5seconds. With those delays in it does not lock up. I also find myself having to add 10-100ms after every command which involves buttons, like changing the button image or button state. Otherwise, the same issue happens.

My project now is running, meaning i am able to develop the rest of it but the delays i implemented to do that are just making the LCD seem unresponsive.

Let me know if you are able to get any leads on what it might be, and from my end, I will try to work with iotexpert to see if we can get some I2C traces on a logic analyzer to see what is going on on the bus or anything else which can help us.

Thanks,
H-

Re: I2C Read with GTT43

Posted: Mon Sep 17, 2018 1:06 pm
by Daniel Divino
Hi Haz,

I've built an environment that will continuously cycle through each of your screens and I have found something rather odd.

My program will run one of your screen scripts, get the back light value, then transition to the next screen and repeat the process. I found my code was able to properly transition and grab the back light of each of your screens except for your Screen_Login screen.

To summarize, I am seeing the exact same issue you are seeing, where I run the Screen Login script, attempt to get the backlight value, and find that the I2C protocol has been locked up. AFAIK this issue only occurs on your Screen Login. All other screens seem to operate perfectly fine. I was even able to forego adding delays to the screen cycling program, and there didn't seem to be any issues, as the get_backlight command would block the program from continuing until the GTT was ready.

I'll continue my testing to see what is so special about the Screen Login script. I'll let you know what I find.

Cheers,
Daniel

Re: I2C Read with GTT43

Posted: Mon Sep 17, 2018 1:53 pm
by Haz
That's great that you were able to reproduce it.
Let me know how this progresses and i will duplicate any fix on my end.

Thanks,
H-

Re: I2C Read with GTT43

Posted: Sun Sep 23, 2018 3:44 pm
by Haz
Daniel,

Just wanted to follow-up and see if you have made any progress. This is in my critical path for the project and I need to get it resolved, or at least a root cause so i can work around the specific case, and now jeopardize project functionality. It keeps locking up my whole project randomly, and i can't keep adding delays throughout.

Let me know,
thanks,
H

Re: I2C Read with GTT43

Posted: Mon Sep 24, 2018 4:39 pm
by Daniel Divino
Hi Haz,

My colleague and I have been testing your project to determine a solution, but our findings have been inconsistent based on the platform. When testing on a LPC microcontroller, there were no issues to be found. But when using an Arduino, we found that the program would hang after running the Screen_login script.

We have found that using the gtt_get_backlight command immediately after running the Screen_Login script causes the program to hang. But unlike in your case, the GTT is still fully responsive, and it seems as if the host is waiting for data to be returned, rather than the I2C lines being locked up. This was confirmed when we sent a reset display command from the Arduino to the display, and the GTT reset.

We did find that if we built and used our own get_backlight function, there would be no hang ups in the code, and the program would run properly. Once we started using the gtt_get_backlight command, the issues would return. We're taking a deeper look into our GTT library to see what could be the issue. Ultimately, the get_backlight function we substituted isn't any different from the gtt_get_backlight command available in the GTT library, so we're perplexed as to what might be causing the issue.

Nonetheless, I suggest you use the function below in place of the gtt_get_backlight command available in the GTT library. Let me know how your program fares after implementing this function. Of course, you will have to use your own read and write functions in the code block

Code: Select all

int get_backlight()
{  
  char command[] = { 254, 154 };
  int backlight[5] = {0};
  Write( command, sizeof(command));  
  do{    
    backlight[0] = i2cRead();
    if(backlight[0] == 252) //If the data read from the GTT is a return message, continue parsing
    { 
      backlight[1] = i2cRead();          
      if(backlight[1] == 154)//if the data read is backlight data, continue parsing
      {             
        backlight[2] = i2cRead();       
        backlight[3] = i2cRead();
        short return_length = backlight[2] << 16 | backlight[3]; //Read the length of the return message                    
        for(int i = 0; i<return_length; i++)
        {
          backlight[4+ i] = i2cRead();//Read the return message
        }       
      }      
    }    
  }while (backlight[1] != 154);//Do this loop until backlight data is returned.  
  return backlight[4];//Return the backlight data
}
Also, if possible, could you send us your read and write functions, as well as the GTT initialization code if you have any?

Cheers,
Daniel