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
All depends upon the implementation of getchar. Could easily (and quite reasonably) have a timeout check included.
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'
Erik
".. 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.
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'
"Erik is a realist"
Not the word I was thinking of ;)
"what nonsense!!, now you are talking nonsense"
I suggest you read and understand the WHOLE thread - Heck, I hope you don't read data sheets in this manner!
"Since you have nitpicked my language, where did you learn to spell 'dependant'"
Perfect example again of your failure to read (and understand) what is written!
I said: I'm a native English speaker
Adj. 1. dependant - contingent on something else
See www.thefreedictionary.com/dependant
Oh, and by the way, it wasn't nitpicking. I really couldn't understand that text you previously wrote. It was just totally meaningless.
I suggest you read and understand the WHOLE thread - Heck, I hope you don't read data sheets in this manner! I read and understood both the 'code' and the datasheet (in this case "the bible")
www.nxp.com/.../80C51_FAM_HARDWARE_1.pdf
"the interrupt system will generate an LCALL to the appropriate service routine, provided this hardware-generated LCALL is not blocked by any of the following conditions: 1. An interrupt of equal or higher priority level is already in progress.
Your link states: dependant Noun a person who depends on another for financial support USAGE: Avoid confusion with dependent.
anyhow, unless you post again, not related to the Ops problem, but to my postings, I will let this be my final word.
erik
Erik,
A little ENGLISH lesson for you ...
The word dependant when used in the context:
"...totally dependant upon the rest of the code."
is not a noun.
So, yet again, you have tried to indicate a fault in something that is correct.
A little advice - If you want to argue about semantics, ensure you have a cogent argument.
Regardless of context, "dependant" is always a noun, unless it is a misspelling and should actually read "dependent".
"Dependent" can be a noun, in which case it's an alternative form of "dependant", or an adjective.
Erik is correct, and the link he gives explains things quite nicely.
Please don't go around trying to teach people incorrect English.
<Extremely big sigh>
Consider British English.
The link that you attribute to Erik (which I actually gave to him) clearly shows a definition for dependant as an adjective (adj=adjective).
If you use a search engine or look in a British English dictionary, you can check for yourself.
Here is another link:
www.audioenglish.net/.../dependant.htm
Just for the record, I will change one thing:
So, yet again, you have tried to indicate a fault in something that is not incorrect.
Your link does.
"USAGE: Dependant is the generally accepted correct spelling in British usage for the noun and always refers to people: if you are single and have no dependants. The adjective should be spelt dependent: tax allowance for dependent (not dependant) children. American usage spells both adjective and noun with an e in the last syllable."
<Even bigger sigh>
Look at the Thesaurus entry and my other link and the many others.
Shame you can't see my British English dictionary that I have right in front of me.
Regardless, all this chatter didn't do anything to reveal the meaning of this gem:
"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 ????"
Jesus Christ (sorry, Jack Sprat! I had to) people, can't you find a proper forum to discuss English spelling...? I think we had enough. Don't you agree?