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.
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.
you sayed generally i say yes correct
i copyed code from other system with little time so less work. code worked and big advantage for project bcoz quick devilopment time :)
i happy and my bossman happy. big big advantage :) :)
not much internal data in cpu so less to copying and faster. yes?..
And that is the reason why an ISR should not need to copy any data, and know about the size of data segments. The time the ISR takes to do it's work should not be affected by the amount of memory the main application needs. If you can't guarantee a worst-case execution time for an ISR, you whould have to perform a full requalification of your application for every minimal change you do anywhere in the application.
"i happy and my bossman happy. big big advantage"
Yes, fair enough!
But that only works if you already have the code to copy - evidently the OP doesn't.
You should also beware of Per's warning: your bossman now thinks that you can do this for any application - you're going to have to disappoint him sooner or later...
You may also, as Per warns, find that some apparently "small" and "unrelated" change in your application will completely break your ISR.
We're back to the old saying:
Quick; Reliable; Cheap - pick two
For the solution I sought last week to keep my papers together, I ended up going for a staple.
It was quick, reliable and cheap.
your bossman now thinks that you can do this for any application - you're going to have to disappoint him sooner or later...
i disapoint him last month and quit :)
next person will disapoint him big ;)
you are rite. my answr not good every project.
No, it was quick and reliable.
If you had wanted cheap, you could have stuck the pages together using discarded chewing gum. Much cheaper than a staple.
Don't know what country your in or the local cost of staples here, but where I am the unit cost of a staple is actually very cheap.
Since nobody in our house chews gum, I would have to had walked out the door and down the street to try to find some as your suggested alternative.
Time is money. It would have taken time to find and would therefore have cost. Almost certainly more than your chewing gum.
On this test, I achieved a score of 3 out of 2!
Yah boo sucks!
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