echo "running try_sched.sh (v1.14)" >> status.txt
date >> status.txt
if [ ! -e /mnt/cf/temp.txt ]
then
 ../mountcf.sh
 echo "mounting cf"
fi

if [ -e /root/sched ]
then
 mv /root/sched sched
 chmod +x sched
 echo "new sched found in /root" >> status.txt

else if [ -e sched2 ]
then
 mv sched2 sched
 chmod +x sched
 echo "new sched found (sched2)" >> status.txt
else
 echo "using current sched" >> status.txt
fi
fi

./sched odata.dat
OUT=$?
echo "OUT:" >> status.txt
echo $OUT >> status.txt
date >> status.txt

if [ $OUT -eq 1 ]
 then
  echo "exit to shell" >> status.txt
fi

if [ $OUT -eq 2 ]
 then
  echo "rebooting from script" >> status.txt
 /sbin/reboot
fi 

if [ $OUT -eq 3 ]
 then
  echo "shutdown from script" >> status.txt
/sbin/shutdown -h now
fi

if [ $OUT -eq 4 ]
 then
  echo "downloading new try_sched.sh" >> status.txt
  ./server >> status.txt
  ./sched2 test 1
  OUT=$?

if [ $OUT -eq 10 ]
  then
   echo "download ok" >> status.txt
   mv sched2 sched
   chmod +x sched
   /sbin/reboot
else 
 echo "bad download" >> status.txt
  rm sched2
  /sbin/reboot
fi
fi

if [ $OUT -eq 141 ]
 then
  echo "rebooting from 141" >> status.txt
fi

if [ $OUT -eq 139 ]
 then
  echo "rebooting from 139" >> status.txt
fi

What this does is first, it mounts the flash drive if the file 'temp.txt' exists.
Then, it checks to see if sched is in /root, moves it to the current directory, sets the exec flag
and the goes to the './sched odata.dat which executes the sched program.
If there is not sched in root, it checks to see if there is a 'sched2' in the current directory
and changes the name to sched, sets the execute flag and executes it. The 'sched2' is what gets
uploaded by the 'SendFiles' and server program when the client exits with a code '4'.

if [ $OUT -eq 4 ]
 then
  echo "downloading new try_sched.sh" >> status.txt
  ./server >> status.txt
  ./sched2 test 1
  OUT=$?

There is a few lines of code in the very beginning of the sched program that checks if there were
3 command line params passed to it:

else if(argc == 3)
{
	if((strcmp(argv[1],"test") == 0))
	{
		printf("testing\r\n");
	}
	printf("%s\r\n",argv[1]);
	return 10;
}

The 2nd one being the string: 'test'. This way, we can check to see if a valid sched has been uploaded.
Otherwise, it goes to 'bad download', deletes the sched2 and reboots. If the sched returns a code '10'
when the 'test' string is passed in, it means the file is valid so it renames sched2 to sched, sets the
execute flag and reboots.
The other exit codes pertain to what happens when you go to the 'Manage Server' button on the top left
of the client screen.
The 'Reboot Server' button tells the sched program to exit with a code '2', The 'Shutdown' button tells
the sched to exit with a code '3' and the 'Upload New' button makes the sched exit with a '4'.
(Exit to Shell will just make the sched quit and if you are not hooked up to comm1 with a tty,
then you're out of luck, and will have to do a reset.)
At the very end of 'sched.c', when the program exits, a global variable called: 'reboot_on_exit' gets set
to the exit code sent by the client:

	if(reboot_on_exit == 1)
	{
//		printf("sched: exit to shell\r\n");
		return 1;
	}
	else if(reboot_on_exit == 2)
	{
//		printf("sched: reboot\r\n");

		return 2;
	}
	else if(reboot_on_exit == 3)
	{
//		printf("sched: shutdown\r\n");
		return 3;
	}
	else if(reboot_on_exit == 4)
	{
//		printf("doing upload new\r\n");
		return 4;
	}

enum task_types
{
	GET_HOST_CMD,
	MONITOR_INPUTS,
	MONITOR_INPUTS2,
	TIMER,
	TIMER2,
	BUTTONS,
	TCP_MONITOR,
	SERIAL_RECV,
	BASIC_CONTROLS
} TASK_TYPES;

The function for the GET_HOST_CMD thread is in cmd_tasks,c and is a huge switch/case that gets messages
from the TCP connection. If the Windows client is not connected, this section gets skipped over.
The other tasks are in tasks.c.
The MONITOR_INPUTS task just waits for something to change on the input ports of the IO cards.
The MONITOR_INPUTS2 task is a way to programmatically inject 'fake inputs' to the system so it thinks
the input ports have changed. The TIMER_TASK is a task that gets called once a second. The SERIAL_RECV
task gets command from the STM32. The BASIC_CONTROLS task waits on a queue for messages and controls
the output ports.