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.
"that can be a very long time indeed...! :-0 "
Absolutely! One thing is right about firmware lifetime: it is always longer than the programmer's ... Especially when it is full of unfathomable black magic.
You get really indoctrinated on good software practices only after you inherit some gargantuan spaghettiware from a previous programmer (your predecessor), and is forced to 'catch the bugs' on that nasty piece of junkware.
Per Westermark wrote: "It isn't trivial to do, and to do it correctly, it requires taking care of processor registers, switching stack etc."
That and much more. What escapes people quite often is that the full static context of the running thread must be preserved. That includes ALL static variables that the C runtime and C libraries eventually use, in addition to processor 'bare machine' context. That is only feasible if the particular compiler is designed for preemption. This is NOT the case of C51. That is one of the reasons why preemption on any '51 kernel sucks so badly.
"Letting the interrupt perform the menu choice before returning is also _bad_. It either requires that the processor supports (or are helped with supporting) recursive interrupts, or that other interrupts will not get serviced on time."
Not necessarily. If the systems designer wants to perform lengthy operations on the context of the interrupt service routines, and the system is designed accordingly, i.e., with full context preservation and protection against non-atomic data operations, it is perfectly viable to do so. The system may not require realtime, for example. Actually, that is one model of multitasking, where there are only 2 tasks that operate, one higher priority preempting the other. This is not realtime oriented, and I doubt that there are many embedded systems that would benefit from this architecture.
As you say, that doesn't mean it's a good architecture.
Building your software around a bad idea will cost you (or someone else) dearly for the rest of the life of that software.
And what is worse: will guarantee you bad karma. Generations of programmers after you are fired will send you bad vibrations for that.
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.
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
8) AT THE ENTRY to each and every routine called from the workloop do a SIMPLE test (do I have anything to do) and, if not, get out of Dodge.
Erik
Hey Jonny,
Nice piece.
Just do not say "... tell what the programmer PRETENDS the code to do..."
eheheh
to PRETEND = to Fake
I guess you knew that.
BTW. Did you go to High School in ETFSP?
ED
Thank you! I could pretend that I intended to imply that most programmers' comments are really wishful thinking, but I stand corrected. That's just a bit of the lingua mater showing through.
BTW, I am that same person. ETFSP, '82. Have we met there?