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
Going step at a time, especially when learning, is a good philosophy.
So, you think atoi is problematic. Have you checked to see what the string passed to the function actually is? Is it a valid ASCII numeric string? Has it got a valid terminator?
If the answer to these are yes, then why not pass a pre-built (maybe a constant) string to the function to ensure you get what you would expect.
Then you might build up confidence in the library functions you are using. Consider that the Keil library functions have existed for quite a while and any serious problems would have been sorted long ago.
Finally, I would be extremely cautious of responses like "total misuse of the interrupts". Like many things in life, there is no absolute right or wrong. An interrupt is a mechanism like many others that you, as a programmer, are free to use in any way that is suitable for the situation in hand.
The more you understand what you are doing (and the ramifications of your choices), the better a programmer you can become.
I would advise you not to do it the way you are doing, but you have the final say.
"...your other code (which you may not have implemented yet) will hang.
Depending upon how you write that code influences the answer as to whether it might hang.
It is totally false to assume that it will hang.
It is perfectly acceptable to write code that both uses interrupts and polling techniques - So long as it is done correctly.
I have seen pure interrupt code that hangs and I have seen pure polled code that hangs. I have seen code that uses a combination of the two work.
Please don't assume any favoured approach from that however. The choice depends upon the situation.
It is perfectly acceptable to write code that both uses interrupts and polling techniques - So long as it is done correctly. sure, but the way it is done all processing will come to a screeching halt from the arrival of char 1 till the arrival of char 4. no interrupts, no main NOTHING!
Erik
"... a screeching halt from the arrival of char 1 till the arrival of char 4."
All depends upon the implementation of getchar. Could easily (and quite reasonably) have a timeout check included.
I've done that very same type of thing myself - Just got to make sure it's all done properly.
alright, but I for one would not want to write code that relies on such premises. Yes it can be done and it will work, but it is not intuitive to the naked eye - or in other words a maintenance nightmare. Not on my plate, please.
Tamir,
Sorry but I think you're missing the point.
I'm saying that it could be done that way, not that it should be done that way.
I then went on to indicate that when done properly (i.e., with careful commenting etc), it can be useful. It would NOT be a premise if it were clearly documented.
Not all requirements are the same and therefore not all methods for achieving those requirements are the same.
I've seen your pre-emptive scheduler. It's quite impressive; but there are things you do in that which are normally considered 'off limits' in an application.
I'm simply saying that needs vary - And I believe that simply knocking newbie code with a warning of "it will hang" is (to say the least) not very constructive. The OP might like to know that alternatives may sometimes be acceptable.
And I've just noticed an earlier false problem report by the same person with regards to the OPs code (re: an uninitialised variable).
Whoops.
It would NOT be a premise if it were clearly documented.
Should read:
It would NOT be a problem if it were clearly documented.
And I believe that simply ... with a warning of "it will hang" is (to say the least) not very constructive .. you would see that I gave examples of how e.g. a noise pulse on the serial line would lock the uC up.
And I believe that simply knocking newbie code
not "simply knocking" but, instead of providing pat solutions that help nobody in the long run. suggesting that the op does this absolutely awful thing commonly know as 'thinking' and providing a 'pointer'
Thanks stephen.
I am sending
printf("9012");
from the Tx side.
Additionally, if I use the simulator andd enter
SIN = 57 SIN = 48 SIN = 49 SIN = 50
I get the correct numbers in comin.
I am gount to try and put a space or similar into the first position and try that later today.
cheers
. . . but my codes are getting collected and are in comin. So what's going on here?
I checked again today, and this hangs the MCU
command_string = gets(comin,4)
".. you would see that I gave examples of how e.g. a noise pulse on the serial line would lock the uC up."
Not would, the word should be might. As I've quite cleary shown, it depends on other factors.
(Let's just ignore the atrocious use of punctuation, grammar etc.)
Who is even suggesting that there is anything wrong with thinking? In my opinion, it is an inherent requirement of being a successful developer. My concern is the quality of the teachers and the 'pointers' they choose to give.
Just look at the post with the heading 'study time' - QED.
Jason,
Regardless of the cross conversation going on in this topic, I would suggest that you re-visit the ISR and consider re-structuring it.
At this point in your learning, you might find that it makes it easier for you to follow the problem through.
Regards.
as I said
4) one of the characteristics of good code is that it does not 'die' on unexpected events
it is WILL, I can not count how many pieces of 'working code' I have seen that was faultly coded by ignoring 'might' and surprised the coder by 'might' being 'will' some time later.
Your statements about "nurturing newbies by letting them go ahead with marginal code" how very well intended are deterimental to the future of those. What a newbie picks up is almost impossible to eradicate later.
Just look at the post with the heading 'study time' I see in the above posts that drawing the OPs attention to values made someone think I was ignorant of what they were, as in if I say "do you see the sunset" I am unaware of it ????
"one of the characteristics of good code is that it does not 'die' on unexpected events"
I totally agree with that.
"it is WILL..."
Absolute nonsense. As I quite clearly showed, it is totally dependant upon the rest of the code. Neither you nor I know what that code consists of - So neither you nor I can be 100% certain whether it will work or fail.
Your statements about "nurturing newbies by letting them go ahead with marginal code"
Are you intentionally misreading what was written? I never mentioned the nurturing of marginal code. I am trying to encourage open thinking. I believe a beginner can learn a lot from experimentation and any mistakes they encounter. I know I did.
I see in the above posts that drawing the OPs attention to values made someone think I was ignorant of what they were, as in if I say "do you see the sunset" I am unaware of it ????
Sorry, I'm a native English speaker and I cannot figure out what that is saying. I just hope the comments in code you produce are more comprehensible.
Erik is a realist
what nonsense!!, now you are talking nonsense
If a noise pulse or a difference in the input creates more than 4 RI ints, the code (the code posted before my reply) WILL hang in the UART ISR i.e. die WHATEVER THE REST OF THE CODE DOES.
Since you have nitpicked my language, where did you learn to spell 'dependant'