[EMAIL PROTECTED] wrote: >>> To sum up quickly, my Application and Mac Layers put in place >>> communication with hardware distributed units and standardize access to >>> these heterogeneous units. The main idea is to build a kind of generic >>> middleware that can be "adapted" according to 1) the type of the >>> communication media used (e.g. Ethernet in the frame of our discution), >>> 2) >>> the MAC Layers used to manage communications on these media (one for a >>> given network) and 3) the Application layers used to manage >>> communication >>> with the distributed units (one for each type of units). On top of that >>> middleware, there are several "hardware independant" real-time modules >>> (managing control, and perception activities) that communicate in a >>> transparent way with units. All modules need to be "real-time" because i >>> need to manage precisely task preemption in my control architecture and >>> because the overall dynamics of the system imposes to limit the "cost" >>> of >>> context change (far to high in user mode). >>> >>>> b) the programming model (single application/multiple apps, >>>> user/kernel >>>> space) >>> - Multiple applications: i am programming a generic framework that can >>> be >>> specialized for different applications in the same business domain. >>> - Kernel space only: all modules (MAC modules, Application layer module, >>> control modules) have to be implemented with kernel space tasks. >> Hmm, kernel space applications - sounds like old dinosaurs... ;) > > I think i made a terminological mistake by using the term "kernel space > tasks". I should use "hard real time task", because all tasks of my > architecture are LXRT hard real-time tasks. But the overall design remain > the same -i.e. MAC real time task has to be able to preempt all other > real-time tasks ... > > Maybe it makes a difference for the use of lipcap (with RTCap) ?
As far as I understood your scenario, you don't need capturing for diagnosis purposes, you rather need it in your critical path. Thus this interface is still not suited. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
