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.
Now, I want to know the start address and length of "_DATA_GROUP_", How can I do it, thanks.
I appreciate for your reply.
And I'll show you what I want to do!
In my project without OS, there are two task, one is Encryption Task, another is Seirial_ISR Task. And Serial_ISR Task has higher PRI than Encryption Task. So, when Encryption Task is running, the Serial_ISR Task would interrupt it, and when entering Serial_ISR it must save the sapce that Encryption Task used. So, I want to know the start adress of _DATA_GROUP.
Thanks very much!
ISR is short for Interrupt Service Routine, and an interrupt handler by definition is not a task. It may interrupt a task and when using a RTOS the return from an ISR may result in a task switch. However, an ISR is not a task.
You should still spend some time thinking about your application layout instead of focusing on how to get the start address of _DATA_GROUP.
You have not specified how the serial data processing relates to the encryption code.
Will the serial ISR retrieve the data to encrypt? In that case, it should need almost no memory at all - except for the ring buffers, it would need two 8-bit registers for the actuall processing of serial data, and would place any received data into the same buffer that the encryption task will use. No need for moving away any data used by the encryption code.
The encryption code should read data from the serial receive buffer and process it. Or it should send encrypted data to the serial transmit buffer for transmission.
If your serial ISR is actually working with data that is not in any way related to the "encryption task", it is most definitely time to think twice. Using an ISR as a "task" makes a lot of assumptions. Especially in relation to any functions that are (directly or indirectly) called by both the encryption code and the ISR. They must be reentrant, or you would get synchronization problems where one ongoing call from the encryption task gets clobbered by a new call from the serial ISR.
If the serial data does not have anything to do with the data being encrypted, then you should change your main application to a "super loop" that switches between encrypting a couple of bytes and processing a couple of received serial data bytes. This is quite easy to do. The encryption code that picks up the next byte to encrypt could be extended to check if there are any serial data to process before returning the next byte to encrypt.
Anyway, unless serial data processing is allowed to clobber any ongoing encryption, the chip must have enough ram to support both serial data processing and encryption at the same time. Hence, there is no need to swap around any data.
And most specifically, you don't want to perform any data swapping everytime you get a serial interrupt!
As Per says, you should not think of an Interrupt Service Routine (ISR) as a Task.
As previously explained, 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!
Again, the 8051's UART only handles a single byte at a time - so there really should be no reason for an 8051 Serial ISR to have any significant memory requirement!
What is it that your serial "task" needs to do that requires so much memory?
If you have spare memory to be able to copy stuff, why can't your encryption task just use that in the first place? Or your serial task?
If you make your serial task and encryption task separate functions called from a "super loop", as Per suggested, the compiler will be able to automatically Overlay their data for you!
If you don't understand the concept of a "super loop", you need to do some basic study on embedded systems; eg, see the booklist on the C51 products page:
http://www.keil.com/books/8051books.asp
The ACCU (Association of C & C++ Users) also has a whole load of book reviews - including a section on embedded:
brian.accu.org/.../
See also: www.8052.com/books.phtml
In my project without OS, there are two task, one is Encryption Task, another is Seirial_ISR Task.
Strictly speaking, the above is self-contradictory. If you have no OS, you don't have tasks to speak of. And this assumption
when entering Serial_ISR it must save the sapce that Encryption Task used.
is pretty much guaranteed to be wrong. Not only would it be terribly much work to do that, it would achieve nothing useful. You would waste a lot more time copying all those data around than it could possibly cost to have the ISR (or the rest program) just use that memory you want to use as an intermediate holding area.
To put it bluntly: you're going at this in entirely the wrong way.