On Wed, Mar 8, 2017 at 7:21 AM, Dennis Lee Bieber <[email protected]> wrote:
> On Tue, 7 Mar 2017 21:52:21 -0700, William Hermans > <[email protected]> declaimed the following: > > >I get the feeling however that you're misunderstanding the purpose of an > >interrupt. An interrupt is a way for hardware to let software know, > >something has happen that may require attention. Either way you wold > >probably be better off thinking in the context of setting a bitfield, or > in > >this case, a single bit. > > Depending upon one's background, there may be different levels of > things under "interrupt". > > Your focus appears to be on (external) hardware signalling for > service. > > I have encountered systems with the concept of a software interrupt > being used by unprivileged code to signal a request that needs to be > handled in privileged code; or even if the system didn't support > privileged/unprivileged just to give an entry point to system functions > that wouldn't change with system updates (single interrupt with a passed > index into a function table). Many tend to use the name "trap" for a > software interrupt. > > Even Ti-RTOS defines something called a SW interrupt, running at a > lower priority than HW interrupts (with a suggestion that the HW interrupt > should trigger a SW interrupt if more than a minimum amount of processing > is needed -- which, granted, is the opposite of a low priority task > requesting an operation by triggering a SW interrupt) > > Hardware interrupts are pretty much always asynchronous -- taking > control away from whatever process is running. Software interrupts used to > access system services are synchronous -- the running process is the one > transferring control; though they may also be asynchronous if they are part > of a priority scheme and triggering may come from code running at other > priority levels (immediately if triggered by lower priority code, deferred > if triggered by higher priority code, only to be activated when the higher > priority code exits) > For the purpose of this discussion with ags, I do not think the actual definition of what an interrupt is, is quite so important, as much as how to achieve an end goal. On a single threaded "system", I also do not think asynchronous is really ever a factor. But I usually do tend to view interrupts as prioritized, and preemptive. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORo%3DFVHoFxqzZ05nqrQB48pWofy%2B5uczvg1AH0bTOa%3D5pg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
