the lcd is hogged? (robotc)

I have recently tried to use the LCD to display certain text during the disabled period. Currently… it has not been very successful. I am wondering if anyone has actually done this before. If so, then what I am doing wrong? Currently using RobotC 3.04.

My goal: To use the LCD to display and constantly update from a sensor input.

When I look at the competition includes, I see the LCD being used by the main task. Is there anyway to get around this?

while (true)
			{
				displayStatusAndTime();
				if (!bIfiRobotDisabled)
				  break;
				wait1Msec(25);

				displayStatusAndTime();
				if (!bIfiRobotDisabled)
				  break;
				wait1Msec(25);

				displayStatusAndTime();
				if (!bIfiRobotDisabled)
				  break;
				wait1Msec(25);

				displayStatusAndTime();
				if (!bIfiRobotDisabled)
				  break;
				wait1Msec(25);
				++nTimeXX;
			}

I have heard a little mention of semaphores. If I have heard correctly, I am able to use these to gain control of the LCD through another task and gain exclusive access to it? What I still don’t get is this “time-out” thing mentioned in the function library. “Wait up to ‘waitTime’ milliseconds to lock (i.e. gain exclusive access) to semaphore”

I was able to get around it half the time during league play. I simply started my task and updated more frequently than 25 milliseconds. It displayed what I wanted to sometimes, and sometimes it didn’t. This task was started before the disabled period (before the main task starts to use the LCD) using the pre_auton function. Here is my league play code:

task p_intialize(){
  bLCDBacklight = true; // turn on backlight

  while(true){

    p_choice = SensorValue[auto_pot]/800; // set program variable from potentiometer

    if(SensorValue[a_jump] == 0){ // set match type to skills if jumper is in
      p_choice = 5; 
    }
    else{ // otherwise set p_choice to normal
      p_choice = p_choice;
    }

    if(p_choice == 0){ // display programs to be run...
      displayLCDCenteredString(0, "Red_Iso");
      displayLCDCenteredString(1, "Program");
    }
    else if(p_choice == 1){
      displayLCDCenteredString(0, "Blue_Iso");
      displayLCDCenteredString(1, "Program");
    }
    else if(p_choice == 2){
      displayLCDCenteredString(0, "Red_Int");
      displayLCDCenteredString(1, "Program");
    }
    else if(p_choice == 3){
      displayLCDCenteredString(0, "Blue_Int");
      displayLCDCenteredString(1, "Program");
    }
    else if(p_choice == 4){
      displayLCDCenteredString(0, "Driver");
      displayLCDCenteredString(1, "Default");
    }
    else if(p_choice == 5){
      displayLCDCenteredString(0, "Autonomous");
      displayLCDCenteredString(1, "Skills");
    }
    
    wait1Msec(1);
  }
}

A little side question as well: switch cases make code less redundant, however do they loop or run once like multiple if statements?

Just comment out the displayStatusAndTime calls if you don’t want to use them. Perhaps make a copy of vex_competition_includes.c in the directory where you keep your code, rename it say my_competition_includes.c. Edit the file and comment out any references to the LCD, change your competition template to include the new file rather than the existing one, use the LCD as you wish by adding a call in the loop you show to your own information on the LCD. There is nothing special about the competition template other than starting tasks for you when the competition state changes. I can work up an example later perhaps. For my own code (not the teams) I use my own version of the competition template that shows battery voltages when disabled and flashes the backlight if any of them are too low.

Switch statements run once. Using a switch is basically the same thing as using if, else if, else, but as it makes the code shorter and in some cases easier to understand. I do not understand what you mean by less redundant.

I remember attempting this during competition, however my autonomous did not run (nor did driver); I did not document this change, but I guess I changed something else vital. I will try this out right now! Thank you!

Thank you! Opps, wrong grammar on my part, sorry.

Obviously changing the competition template code can be dangerous if you do not understand how it works (and fail to test with a competition switch). I have linked to this post before but, if you missed it, here is some discussion of how the competition code works. https://vexforum.com/t/the-robotc-competition-template/20175/1

I changed it back (and we always test our robot before we go into a match). I I understand the template better now, thanks.

Does it make sense to treat the LCD like a motor, and only update periodically?
Start a task that runs every 20ms to update the SetMotor, based on Variables.
Start a task that runs every 100ms to update the LCD display,
to print the current value of whatever variables your wanted to print?

Yes, absolutely, that’s exactly what I usually do. Use a “debug task” to put variables on the LCD or into the debug stream.

In RobotC when you write to the LCD you are really just updating an internal memory buffer. The contents of the buffer is constantly sent to the serial port around 60 times a second.