I have a strange problem in my code. I cannot receive characters via the serial port.
I've read up on the TI and RI interrupts and I think I am handling these correctly.
The program goes to the serial I/O isr, but just sits at the gets(comin,4) line. When I examine comin in the watch window and input chars via the SIN = xx (where xx is an ascii code), I can see the comin array remains empty.
Below is the serial I/O interrupt routine (my application does not need Tx)
pre void uart_rx_isr (void) interrupt 4 using 3 { signed char index=0; EA=0;
if (RI == 1) { gets(comin,4); command = atoi(comin); } RI=FALSE; /* finished isr - clear flag */ TI=FALSE; /* TI will not be used - always clear it*/ EA=1; }
/pre
Here is a fragment from main() - you can see that I set TI=1 initially to set the UART up
pre
TI=TRUE; /* always set TI=1 initially to allow serial printing */ RI=0;
loop: //RI=0; //IDLE
while ((1));
goto loop; } /pre
Appreciate some pointers here.
Jason
Just one more note about atoi().
The function is intended for use with C strings, but all atoi() implementations I have seen don't care about the existence of a terminating zero as long as there are any other non-digit character terminating the number.
But good-quality code should very explicitly make sure that there always are any form of termination of the number. And relevant code should be grouped together, so the termination character should either be transmitted on the serial link, and used to flag the potential start of an atoi() call, or the termination should be explicitly performed very close to the source lines that receivers the four digit characters and assigns them to the array. The goal is to allow the developer to see a block of code, and without scrolling showing all relevant code to understand what is happening. When too much source lines are needed to get a clear overview, it is time to factor the code into multiple, simpler, functions.
Performing some assigns in an interrupt handler, and some assigns to the same array in the main loop is not a good solution, since that results in a loss of overview. Without the overview, a code change in one section of the code is then likely to introduce bugs because the other section was not updated correspondingly.
The use of "magic numbers" - the value 4 for number of characters - makes this problem even bigger. If the serial transmission is changed to send 5 characters instead, then the loop waiting for all characters has to be changed. And the code line that assigns the termination character has to be changed, unless the code is rewritten to instead increment a character pointer.
Thanks Per and Stephen.
I will re-structure the interrupt to collect chars one at a time. Its clear this is not optimal
For the atoi() problem, I can easily add an alpha char to the front of the string. I always terminate these command strings with a '\n' so this should sort that issue out if I check this and then do the atoi() afterwards.
Anyway, I'll be off line for a few days - other problems to deal with right now.
Again, appreciate the help.
Jason.