> From: Reg > > Thank your for your answer! > > I understand, and agree with all the stuff that you wrote (the need of > ISR, DSR, and the solution). The only reason why I'm calling these > solutions "hack" (in the meaning, that not the best soulution > (workaround) ), because the code is depending on the calling > "enviroment", so the code is somehow application specific. > If for ex. semaphores could be used in DSRs, the code would be better, > because the implementation of the semaphore would handle this group of > questions (if you are in a thread, if you are in a DSR etc) > So in other words, when you write a procedure, you have to think about > "what will call this procedure/ or use the shared resource". If only > threads use a resource, you use mutex. If a thread and a DSR is using > it, you have to lock scheduler or mask the interrupt or lock the > specific DSR, just because no sinchronization object can be used in DSRs. > > I think allowing the use of sinchronization objects in DSRs would be a > great feature from eCos (would need to modify the implemetation of > semaphore, mutex etc.) > + better code quality > + faster developement > + less bugs... > - a bit more time/resource > > So if DSRs are an interface or an intermediate layer between the > "interrupt world" and the "thread world", why are we not allowed to use > sinc. objects?
Ah, I see your fundamental problem. You've misread the documentation if you think all these functions aren't usable in DSR context. Most are, as long as you don't use a function that may block. Read the bit at the end of each function description in the Reference Manual for details about the valid contexts they can be used in. -- Ciao, Paul D. DeRocco Paul mailto:[email protected] -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
