Hi everyone!
I'm a n00b to microcontroller programming so have patience with me :)
The mission is to handle some uart (rs232) communication, both rx and tx. My part is a small module going into a rest of the software already developed.
The issue is the following: When I use serial ISR it seems to not go into the "main while loop" (which is required).
(I've also tried to poll my self but reliability seems somewhat unstable, loosing a byte here and there)
I've tried the simplest demo/test programs and if I for instance use a printf in the while loop, it will not reach it as soon as ES = 1.
Is it just that any printf will not issue an interrupt and hence no output to my terminal? At the moment I can not test my module with the rest of the software so I'm a bit in the blind here, well could of course try to blink a led or something... but I reacon a answer from here is faster and more reliable :)
Thanks in advance
/Mike
"Is it just that any printf will not issue an interrupt"
Maybe that's just a poor choice of words, but you need to understand that the interrupt is never issued by printf - nor even putchar, nor any other such software.
The interrupt is "issued" by the hardware when it has completed sending a byte.
Sorry if you did realise that, and it was just words - but, for full details, see Chapter 3 of the so-called "bible" for the 8051:
Chapter 1 - 80C51 Family Architecture: www.nxp.com/.../80C51_FAM_ARCH_1.pdf
Chapter 2 - 80C51 Family Programmer's Guide and Instruction Set: www.nxp.com/.../80C51_FAM_PROG_GUIDE_1.pdf
Chapter 3 - 80C51 Family Hardware Description: www.nxp.com/.../80C51_FAM_HARDWARE_1.pdf
Well actually the interrupts for the serial port can be set by software (RI and TI set to 1 will give a interrupt).
Excerpt from the bible: All of the bits that generate interrupts can be set or cleared by software, with the same result as though it had been set or cleared by hardware. That is, interrupts can be generated or pending interrupts can be canceled in software.
But my main problem is the understanding of why the program will not proceed to the while loop and just print the ... indefinately. If I choose to not activate serial interrupt (ES !=1) it does proceed and prints the ... Interrupts usually does not block but interrupt when something exiting happens :).
But my main problem is the understanding of why the program will not proceed to the while loop and just print the ... indefinately.
Can you post your UART init routine ?
Also, you may want to look at 1) the power-on default value of SCON and 2) the putchar() routine (which you can find in \C51\LIB).
The power-on default value for TI in SCON is 0, while putchar will wait in an endless loop while TI is 0 (since it assumes that TI==0 means that a character is currently being transmitted - which is not the case after power-on). Therefore, using putchar() without either 1) sending one character "by hand" or 2) setting TI to 1 manually will result in being stuck in and endless loop.
"Well actually the interrupts for the serial port can be set by software (RI and TI set to 1 will give a interrupt)."
It's true that they can - but printf does not, and neither does putchar, nor any other such software (unless you make it so).
Note that "such" was key there!
Just to clearify, if you add a printf above the ES = 1; row it will be executed.
Any printf below ES = 1; will not be executed. Although any printf done from the interrupt function will work fine.
I need my interrupt to not block the rest of the "show".
I think Christoph has explained that?
You are still using a polled putchar, but your ISR clears TI, so putchar never transmits a character, so no further TIs are generated!
"If I choose to not activate serial interrupt (ES !=1) it does proceed"
If the interrupt is disabled, the ISR never fiddles with TI, and the polled putchar proceeds as normal!
"Interrupts usually does not block"
It's not the interrupt that's blocking - it's you polling putchar! Your ISR is interfering with the condition that your putchar is polling for!
Again, as Christoph said, "Your problem is a good example why interrupt-driven and polling operation on a peripheral should not be mixed"
Although any printf done from the interrupt function will work fine.
Calling a non-reentrant, heavyweight function like printf() inside an interrupt service routine is another bad idea.
Ahhh ok, tnx guys. Well my hunch was not too far from the target at least :).
In the "real world" no printf (even or stdio.h) will be allowed.
The only thing to put my head around is how all the previous debug code will be possible to execute... I just have to develop code that does not need debugging ;)
Thanks again.
There is ready-to-use code in the Keil application notes mentioned earlier.
You can, of course, use them without printf; They are perfectly generic and not limited only to use with printf!
Here they are again:
http://www.keil.com/download/docs/200.asp http://www.keil.com/download/docs/71.asp