Hi All,
I have a problem in my code and have been struggling with is for a couple of days now so I could use some help.
Here is the case:
I have a complex motion loop processing at 500Hz by means of an Ticker implementation. So the Ticker interrupts to process the motion loop function at a frequency of 500Hz.
Besides this, I communicate with two OLED displays via serial communication (the serial ports are OLED_L and OLED_R). I initiate two animations subsequently on both OLEDs by sending them the required commands. After each command an OLED responds with an ACK (0x06) back to MBED. This response should be catched properly before the second animation can be send.
I catch this ACK response as follows:
#ifdef FULL_VERSION
LED_1 = 1;//DEBUG
//Read back response
while(OLED_L.readable()==0) {
wait(0.001);
}
while(OLED_L.readable()==1) {
ACK_L = OLED_L.getc(); //printf(" ACK_L %X [Hex]\n", ACK_L);
}
while(OLED_R.readable()==0) {
wait(0.001);
}
while(OLED_R.readable()==1) {
ACK_R = OLED_R.getc(); //printf(" ACK_R %X [Hex]\n", ACK_R);
}
LED_1 = 0;//DEBUG
#endif
This works fine. However, here is the issue; when I have enabled the code snippet above, so by defining #FULL_VERSION, to catch the ACK response from both OLEDs, the motion loop is strongly distorted by this. I notice the following behavior: as long as LED_1 is on the motion loop interrupt 'hangs' (which I visualized by having it blink at a certain rate as well and it stops blinking) till LED_1 is off again. As soon as it is off, so the processing of the OLEDs serial feedback has finished properly, the motion loop interrupt picks it up again however initially it executes much faster than the 500Hz like if it is making up time for the 'hanging' period by compressing the missed interrupts.
This is strange as the motion loop interrupt should have priority over this part of code.
Has anybody ideas on what causes my motion interrupt to hang when my program executes the serial communication code snippet above?
Additional notes:
- I also tested it by a severely stripped version of my complete program to decrease complexity. There the motion interrupt performs fine during execution of the code snippet, confirming it's higher priority. So could this have anything to do with memory issues maybe as the complete program is much more complex in processing stuff?
- When the code snippet is disabled, so Full_VERSION not defined, then the motion loop works fine on the interrupt. Obviously this causes the OLEDs to become unresponsive for the second animation call as the ACK isn't properly catched before the new command is send.
- I also tried to make use of RxIrq as an altertnative. It is shown below but this doesn't properly catch the OLEDs feedback over the serial communication? I don't get nice acknowledges back but instead it seems to miss some ACKs and then pick up mess. (I updated the MBED library as I read about some issues with this.)
OLED_L.attach(&OLED_L_SerialRecvInterrupt, OLED_L.RxIrq);
OLED_R.attach(&OLED_R_SerialRecvInterrupt, OLED_R.RxIrq);
void OLED_L_SerialRecvInterrupt (void)
{
printf("OLED_L_SerialRecvInterrupt\n");
char ACK_L = 0;
while(OLED_L.readable()==1) {
ACK_L = OLED_L.getc();
printf(" ACK_L %X [Hex]\n", ACK_L);
}
}
void OLED_R_SerialRecvInterrupt (void)
{
printf("OLED_R_SerialRecvInterrupt\n");
char ACK_R = 0;
while(OLED_R.readable()==1) {
ACK_R = OLED_R.getc();
printf(" ACK_R %X [Hex]\n", ACK_R);
}
}
Hi All,
I have a problem in my code and have been struggling with is for a couple of days now so I could use some help.
Here is the case:
I have a complex motion loop processing at 500Hz by means of an Ticker implementation. So the Ticker interrupts to process the motion loop function at a frequency of 500Hz.
Besides this, I communicate with two OLED displays via serial communication (the serial ports are OLED_L and OLED_R). I initiate two animations subsequently on both OLEDs by sending them the required commands. After each command an OLED responds with an ACK (0x06) back to MBED. This response should be catched properly before the second animation can be send.
I catch this ACK response as follows:
#ifdef FULL_VERSION LED_1 = 1;//DEBUG //Read back response while(OLED_L.readable()==0) { wait(0.001); } while(OLED_L.readable()==1) { ACK_L = OLED_L.getc(); //printf(" ACK_L %X [Hex]\n", ACK_L); } while(OLED_R.readable()==0) { wait(0.001); } while(OLED_R.readable()==1) { ACK_R = OLED_R.getc(); //printf(" ACK_R %X [Hex]\n", ACK_R); } LED_1 = 0;//DEBUG #endifThis works fine. However, here is the issue; when I have enabled the code snippet above, so by defining #FULL_VERSION, to catch the ACK response from both OLEDs, the motion loop is strongly distorted by this. I notice the following behavior: as long as LED_1 is on the motion loop interrupt 'hangs' (which I visualized by having it blink at a certain rate as well and it stops blinking) till LED_1 is off again. As soon as it is off, so the processing of the OLEDs serial feedback has finished properly, the motion loop interrupt picks it up again however initially it executes much faster than the 500Hz like if it is making up time for the 'hanging' period by compressing the missed interrupts.
This is strange as the motion loop interrupt should have priority over this part of code.
Has anybody ideas on what causes my motion interrupt to hang when my program executes the serial communication code snippet above?
Additional notes:
void OLED_L_SerialRecvInterrupt (void) { printf("OLED_L_SerialRecvInterrupt\n"); char ACK_L = 0; while(OLED_L.readable()==1) { ACK_L = OLED_L.getc(); printf(" ACK_L %X [Hex]\n", ACK_L); } } void OLED_R_SerialRecvInterrupt (void) { printf("OLED_R_SerialRecvInterrupt\n"); char ACK_R = 0; while(OLED_R.readable()==1) { ACK_R = OLED_R.getc(); printf(" ACK_R %X [Hex]\n", ACK_R); } }