• State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 22 subscribers
  • Views 4325 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

returning to different address form interrupt with c routine

mike akbari

i used INTX0 for intering to the MENU of my program
and need to back to a address, labled in my main program. so i need to change the contain of the memory that SP is pointed at.
how can i do it in C . i chaned the SP to the address that point to 0x0000 and expected to be reset but it didnot.

Parents
  • 0 in reply to Jonny Doin

    All that being said, here are a few comments on simple interrupt/main code interworking:

    1) Plan your system following a 'event-driven' architecture, i.e., where actions are taken depending on events that may be triggered on the software. It is a intuitive, clean, simple to understand and simple to document architecture for many control-oriented designs.

    2) The simplest design is a main loop in which all main events are checked and the actions are dispatched. This is simple yet very powerful. Surprisingly fast systems can be realized if all the 'actions' are fast. For example, using distribution and state machines to perform the tasks in granular form, you can achieve a high degree of availability and low latency.

    3) Use 'atomic operations' for the events. In the 8051 you have the bit datatype, that is guaranteed to be set/clear/tested in a single uninterruptible operation. Use the C51 intrinsic _testbit_() to execute-if-set-and-clear in a single operation.

    4) Arrange small, localized actions to be done on well-defined events, and use meaningful names. Having 53 events called flag_1 to flag_53 is sure to atract the wrath of the gods.

    5) If you have to service events triggered in interrupts, set the bit in the ISRs, and execute the actions in the main loop. This is simple and makes the ISR extremelly fast. Avoid any function calls in the ISRs, to allow the C compiler to optimize the overlay memory and static space more efficiently. This makes your code faster and smaller.

    6) When well balanced, the system can be seen as a number of objects that do specific tasks. You can build layers of functionality and make the high-level layer simply to set the right sequence of events to get things done. This can allow effective code reuse and tremendously simplify maintenace.

    7) DOCUMENT, DOCUMENT, DOCUMENT your work and your ideas. Better to have a page of comments than to have no comments at all. If you want to go verbose, remember to change the comments if you change the code. Bugs are mismatches between comments and the code. Good comments tell what the programmer pretends the code to do, rather than describe literally what the code does.

    With those simple guidelines it is possible to do very heavy distributed systems, that manage multiple streams of interface serial data simultaneously, do motor control, and user interface, all at a relatively low latency.

Reply
  • 0 in reply to Jonny Doin

    All that being said, here are a few comments on simple interrupt/main code interworking:

    1) Plan your system following a 'event-driven' architecture, i.e., where actions are taken depending on events that may be triggered on the software. It is a intuitive, clean, simple to understand and simple to document architecture for many control-oriented designs.

    2) The simplest design is a main loop in which all main events are checked and the actions are dispatched. This is simple yet very powerful. Surprisingly fast systems can be realized if all the 'actions' are fast. For example, using distribution and state machines to perform the tasks in granular form, you can achieve a high degree of availability and low latency.

    3) Use 'atomic operations' for the events. In the 8051 you have the bit datatype, that is guaranteed to be set/clear/tested in a single uninterruptible operation. Use the C51 intrinsic _testbit_() to execute-if-set-and-clear in a single operation.

    4) Arrange small, localized actions to be done on well-defined events, and use meaningful names. Having 53 events called flag_1 to flag_53 is sure to atract the wrath of the gods.

    5) If you have to service events triggered in interrupts, set the bit in the ISRs, and execute the actions in the main loop. This is simple and makes the ISR extremelly fast. Avoid any function calls in the ISRs, to allow the C compiler to optimize the overlay memory and static space more efficiently. This makes your code faster and smaller.

    6) When well balanced, the system can be seen as a number of objects that do specific tasks. You can build layers of functionality and make the high-level layer simply to set the right sequence of events to get things done. This can allow effective code reuse and tremendously simplify maintenace.

    7) DOCUMENT, DOCUMENT, DOCUMENT your work and your ideas. Better to have a page of comments than to have no comments at all. If you want to go verbose, remember to change the comments if you change the code. Bugs are mismatches between comments and the code. Good comments tell what the programmer pretends the code to do, rather than describe literally what the code does.

    With those simple guidelines it is possible to do very heavy distributed systems, that manage multiple streams of interface serial data simultaneously, do motor control, and user interface, all at a relatively low latency.

Children