Now, I want to know the start address and length of "_DATA_GROUP_", How can I do it, thanks.
Why do you want to do this?
I think this may be one of those cases where, if you explained what you're actually trying to achieve, people may be able to offer you better solutions...
I want to save these variables of _DATA_GROUP_ before entering serial_ISR, and so there will be more space for ISR to use.
Maybe there would be a better way to resolve it, so pls give your suggestion, thanks!
And also, I want to know that is it possible to fix the start address and length of _DATA_GROUP_ in code,thanks!
Liu Song
"I want to save these variables of _DATA_GROUP_ before entering serial_ISR, and so there will be more space for ISR to use."
If you save them, they will still occupy space somewhere - so there will not be any overall gain!
Also, the time taken to copy them out at the start of the ISR, and back in again at the end will almost certainly completely kill the performance of your system!
The general idea of ISRs is to keep them as short and simple as possible - doing large memory block moves is certainly the kind of thing that should generally be avoided!
"Maybe there would be a better way to resolve it..."
Almost certainly there is!
"...so pls give your suggestion, thanks!"
It's impossible to make informed suggestions without knowing exactly what it is that you're actually trying to achieve!
You need to explain further why you want to do this - what are you actually trying to achieve?
What is it about your serial ISR that needs so much memory?
Have you looked at the examples for interrupt-driven, ring-buffered serial IO in the downloads section:
http://www.keil.com/download/docs/200.asp http://www.keil.com/download/docs/71.asp
The serial ISR does not need a lot of room for data buffers, since it is only expected to receive and/or transmit a single character - unless you have a chip where the serial port has a built-in FIFO.
However, it isn't the ISR who should process all received data, so if you are trying to get room for a full line of text or similar, you have misunderstood how your ISR is expected to work.
"if you are trying to get room for a full line of text or similar, you have misunderstood how your ISR is expected to work."
The above-mentioned interrupt-driven, ring-buffered serial IO examples would probably serve well in this case...
"The above-mentioned interrupt-driven, ring-buffered serial IO examples have served me well in such cases..."
Yes, ring buffers are very good. But the important thing for the OP to realize is that the ring buffer is static, i.e. isn't allocated when entering an ISR and then released before the ISR ends.
It isn't the ISR that should create a buffer, receive a full line of text and then process, so swapping large sections of memory does not help/work.
A little addendum.
A serial ISR would probably manage with just two 8-bit registers for it's work (plus what is needed for a return address and to protect processor flags).
Either to check the status of the serial port, to compare the read/write positions of a send or receive ring buffer, to pick up one character from a transmit buffer, move the read position one step and put the character in the serial transmit register or pick up one character from the serial receive register put in the receive buffer and step the write position one step.
If the OP feels the need to allocate large areas of memory in the serial ISR, it is quite obvious that a non-optimum solution has been selected.
i think you not understand q of op
why always say ring bufer is good? it is but not alwiys right answer! i have write code for very low priority isr (emulated 3 or 4 level) that coipes internal data to xdata and does receive of high priority data there
remember what task swap of operating system does. it copies all task state in a tick isr. that not bad is it!
i tried and got error in line 55
"i think you not understand q of op"
I think the OP is asking the wrong question!
This is why it is important for him to explain what he's actually trying to achieve.
But, if you do understand the question, why have you not answered it?
"why always say ring bufer is good?"
Nobody said a ring buffer is always good!
What has been said is that a ring buffer is far more likely to be good than what the OP is suggesting!
Again, without knowing what he's actually trying to achieve, it is impossible to say for sure!
"internal data to xdata"
Maybe it works for you but, in general, if you've got time to copy stuff to XDATA, you would generally have time to just let your ISR work in XDATA, wouldn't you?!
BTW: I had my ring buffers in XDATA.
"remember what task swap of operating system does. it copies all task state in a tick isr."
I very much doubt that any Real-Time OS would do a Task Switch just for an ISR!!
:-0
"i tried and got error in line 55"
You tried what? How is that related to this thread?
link do not give adress of data_group :(
what i done is put vareables in asemble at fixed locatien and public. all variebles in contigues block
isr copys block on entry isr. not before ;)
try not much data in cpu
You tried what?
He got this error in the seventh attempt of compiling his super-efficient operating system of course!
How is that related to this thread?
Must be related, otherwise he wouldn't write it!!??
lol
yodl yodl yodl!
"isr copys block on entry isr"
As already noted, that is generally the kind of thing to be most strenuously avoided in ISRs!!
What advantage do you (think that you) gain by it?
"try not much data in cpu"
What do you mean by that??
It is a misconception that all posters should get answers on their questions, so it is a misconception to think that people who answer don't understand the OP's question if the answers doesn't look like they are a 100% fit for the original question.
Quite often - or maybe I should say VERY often - the OP wants the wrong question answered. It would then be counter-productive to answer the original question. The job then is to try to figure out what problem the OP in reality has, and then suggest a better way of looking at the problem.
If someone asks: How can I switch tires on my car without need for loosening the bolts, the suggestion could be to build a machine that can remove and fit tires - and balance the wheels - while the rim
A very long time ago, there existed operating systems that at each task switch swapped out the full application to disk, before swapping in a new application. A good solution when the memory could only fit a single application at a time. However, not applicable for embedded systems.
No decent operating system should copy a full set of memory, stack or whatever when performing a task switch. The task state is the minimum amount of information that just has to be protected to make the individual tasks behave as expected. I.e. a number of processor registers, and possibly a set of static variables to keep (badly implemented) non-reentrant runtime library functions behaving as expected. If for example a random number generator can't block a task switch while generating a new random number - or if each task is expected to have it's own seed - it might be needed for a task switch to save the internal state of the random number generator. A better solution would of course be to either lock a switch until the next random number has been generated, or let each caller supply a pointer/handle to state information.
Any solution that requires a ISR to swap data could - and should - be rewritten so that it is not needed. A ISR that locks up while waiting for a full line of text should be rewritten so that the serial data is either polled, or the main application explicitly locks up until the ISR have finally inserted enough characters in the receive buffer. For a text-based interface, it would then be enough for the ISR to either flag a buffer overflow, or the reception of a end-of-line or whatever break character that should trig the main application to start doing it's work.
The main application may do anything it likes, since it is always (unless buggy) in a known state when it performs it's actions. An ISR is an asynchronously called function, and hence may be activated at more or less any position in the main application. Because of this, it really should solve a very minimal problem, and then exit.
Managed to press end a bit early...
Was about to write:
If someone asks: How can I switch tires on my car without need for loosening the bolts, the suggestion could be to build a machine that can remove and fit tires - and balance the wheels - while the rim is still mounted on the car. That is a very expensive solution if the OPs original problem just was that he had lost his wrench.
Let's assume that someone is spending a lot of time figuring out how to use ultrasonic sound to upgrade the firmware in an application, to avoid the need to opening the case. If the box already has an external serial port, it might be a better suggestion to ask why the serial port isn't used - since a ultrasonic solution would require special hardware to perform the update.
If someone is all set on trying to get an embedded processor to generate a 10MHz fixed-frequency signal out from an ISR (even if that is expected to consume more than 100% of the processor capacity), it might be better to suggest a cheap external crystal oscillator.
Don't take this wrong, but only a fool would unconditionally try to answer questions. Suggesting solutions is easy. Trying to figure out the original problem is the hard part.