Hello,
I am working with serial communication interrupt in LPC1768. In that I am receiving a three parameter data in the form of string as X:2341Y:114Z:75 via serial interrupt.
After receiving I am splitting this string and storing 2341 in array1[],114 in array2[] and 75 in array3[] and converting into integer and using in the main function as follows.
int main(){ .... .... .... while(1){ cut_count = (((int)(cut_preset_value[0]-0x30)*1000)+((int)(cut_preset_value[1]-0x30)*100)+((int)(cut_preset_value[2]-0x30)*10)+((int)(cut_preset_value[3]-0x30))); duty_count = (((int)(duty_cycle_value[0]-0x30)*10)+((int)(duty_cycle_value[1]-0x30))); TOTAL_TIME = ceil((ONE_MIN_IN_MSEC)/(cut_count)); //ceil func. is to round off the value dividend_value = ((TOTAL_TIME)*(duty_count)); ON_TIME_VALUE = ceil(dividend_value/PERCENT_DIVISOR_VALUE); //ceil func. is to round off the value OFF_TIME_VALUE = ceil(((TOTAL_TIME)-(ON_TIME_VALUE))); //ceil func. is to round off the value
} }
Note:Here cut_preset_value[],suction_preset_value[] and duty_cycle_value[] are the three globally defined arrays for storing values.
Within the while loop the arrays are not updating without board reset.
kindly provide some solution for this. Thank you.
"So I thought that the data will over-written within allocated 4,3 and 2 bytes."
Irrelevant to this. How do you synchronize? How does the UART ISR know what is the first character of a message? And how does your main loop know when a full message has been received?
"Yes I used to check with the arrays which is defined,but it also doesn't works." Don't know what you mean. But any global variable that is written to by an ISR and that is read by the main loop must be declared volatile, to make sure that the source code generated will read the physical memory for the current variable contents instead of relying on on data that might be cached in a processor register.
Synchronization of UART receive in relation to main loop processing is totally separate from whatever you may do with a timer to control any relay.
Any time you have an ISR produce data that can't be written and handed over to the main loop as one single, atomic, memory write, you (!) must implement some synchronization logic that can switch ownership of the data between ISR and main loop. So ownership of the variables are handed to the ISR until a complete message has been received. Then ownership shifted to the main loop, which needs to be allowed to read out all bytes of data before it returns back the ownership to the ISR again for reception of more data.
Yes the word volatile is missed in previous post.
I checked with the arrays which is defined as volatile,but the same error happens over there also. That's what I came to explain in my older post.
"implement some synchronization logic that can switch ownership of the data between ISR and main loop."
So shall I use some flag variable and wait for it to set after one complete reception is occured? Or any other method is there for synchronising ISR and main loop variable?.
Have you dared to search for different synchronization solutions?
Yes I tried with flag method by setting it after I received a single package of whole 15 bytes by using the following piece of code within the handler,but it also doesn't works.
if((UART0Buffer[UART0Count-str_count])== 'C') { str_count++; if(str_count==TOTAL_CHAR_LENGTH) U0_flag=1; }
In default str_count=0; and TOTAL_CHAR_LENGTH=15;
And once the flag is set, I am retrieving data from the three arrays as discussed earlier. So I am getting data from the array after one complete string reception only.
"also doesn't work" doesn't tell any reader anything useful about your problem.
And you are posting a tiny bit of your source code, making impossible to see if your code have other interesting bugs. You haven't even shown us the declaration of that new flag variable.
And you haven't explained what a correct message should look like. And if your code is written in a way that it can correctly resynchronize if you connect the cable in the middle of a message or if one character for some reason gets corrupted.
Is "C" a unique character terminating a message but never used anywhere else? In that case, the code should be able to do alternative things if str_count does not match TOTAL_CHAR_LENGTH when the 'C' is received.
Anyway - what results do _you_ see when _you_ are busy debugging _your_ code? What did you expect would happen, and what does actually happen? And what are your conclusions from the difference between what was expected and the reality?