We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi, I tried this example but the isr doent seem to be getting executed.
In the isr i m calling a function to display on 7-segment displays. Otherwise the normal program flow is based on Receiving and Sending data on UART0(using timer1 in 8-bit auto-reload for 9600 baud generation)
i receive numeric Ascii values in UART0 in response to a command.These received values i take into an array. The values received can be characters 1 through 9, decimal or '-' sign.
while(RI!=1) {display();} switch(SBUF) { case 1: a++; arr1[a]=0x0F9; etc, etc..... }
Then i display these values on eight 7-segment display.
void display() { for(x=a;x>0;x--) { P0=disp[x]; P2=scan[x]; //3:8 decoding } }
So why do you feel the need to do the displaying in an ISR?
Alright let me correct my stand...there might not be a need to call display() in an ISR...or rather it is not recommended... BUt the method being used as of now(the code i posted) isnt the best way to do it, isnt it? Maybe i should try the following: An ISR for serial interrupt which will be responsible for interpreting the data received and putting it into the display_array, instead of doing "while(RI!=1){display();}" And apart from the ISR the program will do:
while(1) { display(); }
Please let me know what you think of it
"there might not be a need to call display() in an ISR...or rather it is not recommended..."
I suspect that it is both not recommended and not needed!
"the method being used as of now(the code i posted) isnt the best way to do it, isnt it?"
Clearly not - as it doesn't work!
"An ISR for serial interrupt which will be responsible for interpreting the data received and putting it into the display_array"
No - you've missed the point!
In general, an ISR should not interpret the data at all! Simply receive and buffer it. All interpretation and handling for display should generally be outside the ISR
Take a look at the interrupt-driven serial IO examples in the Downloads area...
Found this in MSC1210 User's Guide
Make interrupt routines small: Interrupt routines should be designed to do as little as possible, as quickly as possible, and leave longer processing to the main program. For example, a receive serial interrupt should read a byte from SBUF and copy it to a temporary buffer defined by the user and exit as quickly as possible. The main program must then handle the process of interpreting the data that was stored in the temporary buffer. By minimizing the amount of time spent in an interrupt, the MSC1210 spends more time in the main program, which means additional interrupts can be handled faster when they occur.
OK, you've got the 'pre' and '/pre' tags now, but don't you beleive in indentation for your code? eg,
void display() { for( x=a; x>0; x-- ) { P0 = disp[x]; P2 = scan[x]; //3:8 decoding } }
And a little whitespace can work wonders for legibility!
Remember: don't use TABs to lay-out your code; use only spaces. (TABs are entirely unreliable)
The 'pre' and '/pre' tags are for source code; don't use them for quoting other text - look what it's done to the width of the message!
:-0
"Make interrupt routines small: Interrupt routines should be designed to do as little as possible, as quickly as possible, and leave longer processing to the main program. For example, a receive serial interrupt should read a byte from SBUF and copy it to a temporary buffer defined by the user and exit as quickly as possible. The main program must then handle the process of interpreting the data that was stored in the temporary buffer. By minimizing the amount of time spent in an interrupt, the MSC1210 spends more time in the main program, which means additional interrupts can be handled faster when they occur."
Exactly - just what has been said already!
yeah, i noticed the width after posting(it was looking fine in preview) but there was no way to modify it after posting!!! :-p