Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
10 years, 9 months ago.
MODSERIAL doesn't work ???
Hello
I have a key interrupt, the interrupt handler calls inside MODSERIA library defines a variable gprs, when using: gprs.printf ("don"); gprs.txBufferFlush ();
When you do not see "don", see the "d", see "on" until the callback is completed, why??????
My code:
#include "mbed.h"
#include "MODSERIAL.h"
InterruptIn b1_p21(p21);
MODSERIAL gprs(USBTX,USBRX);
void callback(void)
{
gprs.printf("don");
gprs.txBufferFlush();
wait(3);
return;
}
int main() {
b1_p21.rise(&callback);
wait(5);
while(1){
gprs.printf("main level");
wait(5);
}
return 0;
}
1 Answer
10 years, 9 months ago.
I don't understand what you exactly get on your terminal.
However you printf "don", and while it is being printed you flush the tx buffer. This removes everything which was in the buffer and still has to be sent. So by that time probably only the 'd' is sent, and before the 'o' can be sent the buffer is cleared. There is no reason to call that function.
the problem is: when using:gprs.txBufferFlush (); the phenomenon is only see the "d" when do not use:gprs.txBufferFlush (); the phenomenon is see the "d" first, and see "on" until the callback is completed. in short, it can not complete send the command of "don" .
posted by 09 Aug 2013The first part you describe is supposed to happen. The second part isn't. Have looked a bit at it, and for some reason the microcontroller tells there is no space in the TX buffer to write in, so MODSERIAL puts in its own buffer. And inside an IRQ it cannot transfer from its own buffer to the TX buffer, resulting in the behavior you see. Generally it also isn't a good idea to wait so long in an IRQ. So for long strings this is expected. However since there is a 16 deep FIFO buffer, you should be able to send 16 bytes without this problem.
I will look more at it later, but no guarantees.
posted by 09 Aug 2013Okay I checked it. The issue is after writing to the UARTs output register, it isn't immediatly moved to the FIFO buffer for some reason. So when the next char is sent the output register isn't empty yet, and instead MODSERIAL places it in the software buffer. But inside your interrupt routine the interrupts that move the software buffer to the uart aren't called.
So not much you can do about it, besides the generally good idea of not staying long in interrupts. You can also lower the priority of that interrupt, but best would be just not staying long in an interrupt routine.
posted by 09 Aug 2013