Debugging any type of code can be very time consuming, debugging EasyC can be particularly hard as there is no breakpoint capability or anything else. To give you some idea of the process let me describe how I went about looking at your problem and the possible cause and workaround. This is not going to be great english, I’m just going to bash it out so it’s done today.
So I started by adding the code I had suggested earlier, a variable to count each iteration of the while loop in your driver control function and a call to display that variable on the LCD. Having done this I noticed that you are writing to the LCD every time around the loop, usually just “569C - Cthulu!!!” but always some type of information. The code crashed after a few minutes, restarting the code several times I was able to duplicate this. So my next thought was “is the code actually crashing or is it just the LCD display that stops working”. I added code to flash a LED on digital output 12 each time around the while loop and again ran the code. When the code crashes, the LED also stops flashing so it’s a good assumption that it is indeed the code rather than the LCD. Next step, remove the SetLCDText calls and see if we still crash. First thing to notice is that the loop now runs considerably faster so the LED cannot be seen flashing, so slow down the LED and re-run. After 20 minutes I conclude the code will probably not crash so it may well be the excessive serial communication to the LCD.
Next test was to repeat all these tests in an older version of EasyC, 126.96.36.199. Ran the same code as before monitoring the loop counter, waited 20 minutes, no crash. So one solution may be to revert to the older version of EasyC, however, there is a newer version out so lets try that first.
Test everything again under 188.8.131.52, things look promising but then after 10-15 minutes, same problem. It is better but the underlying problem is still there.
Final test, try and reproduce this with some simple code we can send to Intelitek so I create the following small test program.
void OperatorControl ( unsigned long ulTime )
int LoopCounter = 0;
InitLCD ( 1 ) ;
SetLCDLight ( 1 , 1 ) ;
while ( 1 ) // Insert Your RC Code Below
SetLCDText ( 1 , 1 , "%d" , LoopCounter++ ) ;
SetDigitalOutput ( 12 , LoopCounter & 1 ) ;
And voila, code crashes after 10 minutes.
So how can we fix this, well one simple solution is to omit all calls the SetLCDText, however, that removes significant functionality from the program. The better alternative (although still not 100% guaranteed to solve it) would be to only send new text to the LCD when needed and not continuously. To achieve this I wrote a small wrapper function to save the current text sent to each line and compare new text to that before sending to the LCD. Here is the user function, it’s modeled after the SetLCDText function so should be a drop in replacement.
// LcdBuffered.c : implementation file
SetLCDBuffered(unsigned char ucPort, unsigned char nLine, const char *szMsg, ...)
static char LcdData;
unsigned char ret = 0;
// bounds check line
if((nLine < 1) || (nLine > 2))
// create the formatted output string
// we assume it will be suitable for the LCD
vsprintf(str, szMsg, args );
// See if we sent this already
if( strcmp( LcdData[nLine-1], str ) != 0 )
strcpy( LcdData[nLine-1], str );
// send to LCD
ret = SetLCDText(ucPort, nLine, str);
New text will not be sent to the LCD until it changes from what was sent before.
I will attach the whole project for you, but to summarize.
I believe 184.108.40.206 and later has introduced a bug in the serial transmit code that can cause the cortex to crash. Lots of communication with the LCD can cause this bug to happen. We need to report this possible problem (as I can not definitively prove it without lots more testing) so they can implement a fix.
Here is a revised copy of you code with calls to SetLCDText replaced with calls to SetLCDBuffered.
569C Worlds Program revised.zip (93.6 KB)