Dear all, I have the need to define some functions as "non-interruptible" and I remember some #pragma at least for C51 which would do this. I looked for similar #pragmas for the g21k but apparently I haven't found any hint. Does anyone out there know how to reliably define a function as non-interruptible? I understand that I could disable all interrupts and enable them once the function has completed - which will potentially cause to loose an interrupt, unless level-sensitive - but I believed there are some "utilities" to do that at compilation level. Some additional info: the non-interruptable function is a function which returns system time, therefore if interrupted while the value is being read it may return a wrong value. Al -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
[cross-post] g21k and non-interruptible functions
Started by ●January 10, 2012
Reply by ●January 10, 20122012-01-10
On Tue, 10 Jan 2012 15:17:26 +0100, Alessandro Basili wrote:> Dear all, > > I have the need to define some functions as "non-interruptible" and I > remember some #pragma at least for C51 which would do this. I looked for > similar #pragmas for the g21k but apparently I haven't found any hint. > > Does anyone out there know how to reliably define a function as > non-interruptible? I understand that I could disable all interrupts and > enable them once the function has completed - which will potentially > cause to loose an interrupt, unless level-sensitive - but I believed > there are some "utilities" to do that at compilation level. > > Some additional info: the non-interruptable function is a function which > returns system time, therefore if interrupted while the value is being > read it may return a wrong value.Such #pragmas are exceedingly non-portable. Besides, all they're going to do "under the hood" is disable interrupts for the duration of the function. If your interrupt hardware is decent then you won't miss an interrupt: either the interrupt is level sensitive and the hardware that generates it won't give up until it is explicitly serviced, or the interrupt is edge sensitive and the interrupt controller takes care of remembering. In either case, it's your job to make sure that the interrupt will persist and be serviced as soon as you come out of the protected section of your function. So -- bite the bullet and do it the grown-up way. You want to save interrupt status (because interrupts may already be turned off going into your function), do your interrupt-sensitive stuff as quickly as can be, restore interrupts to their former state, then exit. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
Reply by ●January 10, 20122012-01-10
On 10/01/12 19:04, Tim Wescott wrote:> On Tue, 10 Jan 2012 15:17:26 +0100, Alessandro Basili wrote: > >> Dear all, >> >> I have the need to define some functions as "non-interruptible" and I >> remember some #pragma at least for C51 which would do this. I looked for >> similar #pragmas for the g21k but apparently I haven't found any hint. >> >> Does anyone out there know how to reliably define a function as >> non-interruptible? I understand that I could disable all interrupts and >> enable them once the function has completed - which will potentially >> cause to loose an interrupt, unless level-sensitive - but I believed >> there are some "utilities" to do that at compilation level. >> >> Some additional info: the non-interruptable function is a function which >> returns system time, therefore if interrupted while the value is being >> read it may return a wrong value. > > Such #pragmas are exceedingly non-portable. Besides, all they're going > to do "under the hood" is disable interrupts for the duration of the > function. > > If your interrupt hardware is decent then you won't miss an interrupt: > either the interrupt is level sensitive and the hardware that generates > it won't give up until it is explicitly serviced, or the interrupt is > edge sensitive and the interrupt controller takes care of remembering. > In either case, it's your job to make sure that the interrupt will > persist and be serviced as soon as you come out of the protected section > of your function. > > So -- bite the bullet and do it the grown-up way. You want to save > interrupt status (because interrupts may already be turned off going into > your function), do your interrupt-sensitive stuff as quickly as can be, > restore interrupts to their former state, then exit. >Obviously Tim is right if you need non-interruptable code. But there are other ways of doing the job in hand - sometimes disabling interrupts is not the only solution. For something like system timers like this, you can get correct results by reading repeatedly until you have two successive identical reads (and often you can do it with only partial duplicate reads). Most of the time you only need the two reads - but if you are unlucky and a timer rollover occurs during a read, perhaps because of an interrupt, then you will need an extra read. You'll have to think carefully about the possible interactions between the code, the hardware, and interrupts - but it is typically quite possible without disabling interrupts.
Reply by ●January 10, 20122012-01-10
On Tue, 10 Jan 2012 15:17:26 +0100, Alessandro Basili <alessandro.basili@cern.ch> wrote:>Dear all, > >I have the need to define some functions as "non-interruptible" and I >remember some #pragma at least for C51 which would do this. >I looked for similar #pragmas for the g21k but apparently I haven't >found any hint. > >Does anyone out there know how to reliably define a function as >non-interruptible? I understand that I could disable all interrupts and >enable them once the function has completed - which will potentially >cause to loose an interrupt, unless level-sensitive - but I believed >there are some "utilities" to do that at compilation level. > >Some additional info: the non-interruptable function is a function which >returns system time, therefore if interrupted while the value is being >read it may return a wrong value. > >AlIf your application supports it you could write an inline asm which would mask all the interupts. Atleast on the 21[234]xx the sequencer willl respond to the latched interrupt when they are unmasked. Mark DeArman
Reply by ●January 10, 20122012-01-10
On Tue, 10 Jan 2012 12:53:58 -0800, Mac Decman wrote:> On Tue, 10 Jan 2012 15:17:26 +0100, Alessandro Basili > <alessandro.basili@cern.ch> wrote: > >>Dear all, >> >>I have the need to define some functions as "non-interruptible" and I >>remember some #pragma at least for C51 which would do this. I looked for >>similar #pragmas for the g21k but apparently I haven't found any hint. >> >>Does anyone out there know how to reliably define a function as >>non-interruptible? I understand that I could disable all interrupts and >>enable them once the function has completed - which will potentially >>cause to loose an interrupt, unless level-sensitive - but I believed >>there are some "utilities" to do that at compilation level. >> >>Some additional info: the non-interruptable function is a function which >>returns system time, therefore if interrupted while the value is being >>read it may return a wrong value. >> >>Al > > If your application supports it you could write an inline asm which > would mask all the interupts. Atleast on the 21[234]xx the sequencer > willl respond to the latched interrupt when they are unmasked.The word that I would use to refer to interrupt hardware that did not interrupt in such situations would be "broken". -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
Reply by ●January 10, 20122012-01-10
On Tue, 10 Jan 2012 14:58:35 -0600, Tim Wescott <tim@seemywebsite.please> wrote:>On Tue, 10 Jan 2012 12:53:58 -0800, Mac Decman wrote: > >> >> If your application supports it you could write an inline asm which >> would mask all the interupts. Atleast on the 21[234]xx the sequencer >> willl respond to the latched interrupt when they are unmasked. > >The word that I would use to refer to interrupt hardware that did not >interrupt in such situations would be "broken".Haha, I have never done this but I remember it from the processor manual. That usage of the sequencer is beyond my application. Mark DeArman
Reply by ●January 10, 20122012-01-10
On 1/10/2012 7:04 PM, Tim Wescott wrote: [...]>> Does anyone out there know how to reliably define a function as >> non-interruptible? I understand that I could disable all interrupts and >> enable them once the function has completed - which will potentially >> cause to loose an interrupt, unless level-sensitive - but I believed >> there are some "utilities" to do that at compilation level.[...]> > Such #pragmas are exceedingly non-portable. Besides, all they're going > to do "under the hood" is disable interrupts for the duration of the > function. > > If your interrupt hardware is decent then you won't miss an interrupt: > either the interrupt is level sensitive and the hardware that generates > it won't give up until it is explicitly serviced, or the interrupt is > edge sensitive and the interrupt controller takes care of remembering.Indeed I need to check both cases. I'm not sure the hardware will continue to keep the interrupt until serviced, I'm pretty sure the timer interrupt is kept for 4 clock cycles and that's it, no handshake of any sort. About the interrupt controller is also not so clear to me how I can test it. The description in the user manual is pretty clear about the IRPTL functionality but in a very simple case I tried I was loosing timer interrupts and I'm not quite sure why, yet. Should the interrupt controller work correctly I don't see the reason why the timer interrupt can go lost (no nesting and only the timer interrupt enabled).> In either case, it's your job to make sure that the interrupt will > persist and be serviced as soon as you come out of the protected section > of your function.Actually before posting this reply, I read again the user manual and is clearly stated that masking the interrupt will not prevent latching, therefore I should not disable interrupts, but rather mask them.> > So -- bite the bullet and do it the grown-up way. You want to save > interrupt status (because interrupts may already be turned off going into > your function), do your interrupt-sensitive stuff as quickly as can be, > restore interrupts to their former state, then exit. >Even though I do not need the application to be portable and could in principle whine a little about the lack of a #pragma, I believe that coding the functionality by myself is good practice, surely will teach me much more than a stupid preprocessor directive. Thanks for the push! Al
Reply by ●January 10, 20122012-01-10
In article <05WdnV7-Wtgv4JHSnZ2dnUVZ_g-dnZ2d@web-ster.com>, tim@seemywebsite.com says...> > On Tue, 10 Jan 2012 15:17:26 +0100, Alessandro Basili wrote: > > > Dear all, > > > > I have the need to define some functions as "non-interruptible" and I > > remember some #pragma at least for C51 which would do this. I looked for > > similar #pragmas for the g21k but apparently I haven't found any hint. > > > > Does anyone out there know how to reliably define a function as > > non-interruptible? I understand that I could disable all interrupts and > > enable them once the function has completed - which will potentially > > cause to loose an interrupt, unless level-sensitive - but I believed > > there are some "utilities" to do that at compilation level. > > > > Some additional info: the non-interruptable function is a function which > > returns system time, therefore if interrupted while the value is being > > read it may return a wrong value.Since I don't know the G21K system, I'm not sure if this is true. On an ARM system with 32-bit memory, reading 32-bit Unix time value should be an atomic operation and not require any protection from interrupts. If the function is returning seconds and fractions, the function could use the well-established technique of reading the two or more values and repeating until only the least-significant value changes between reads.> > Such #pragmas are exceedingly non-portable. Besides, all they're going > to do "under the hood" is disable interrupts for the duration of the > function. > > If your interrupt hardware is decent then you won't miss an interrupt: > either the interrupt is level sensitive and the hardware that generates > it won't give up until it is explicitly serviced, or the interrupt is > edge sensitive and the interrupt controller takes care of remembering. > In either case, it's your job to make sure that the interrupt will > persist and be serviced as soon as you come out of the protected section > of your function. > > So -- bite the bullet and do it the grown-up way. You want to save > interrupt status (because interrupts may already be turned off going into > your function), do your interrupt-sensitive stuff as quickly as can be, > restore interrupts to their former state, then exit.Unless the time function is unacceptably long and the system has a killer interrupt-response requirement, that's the way to go. If that technique is a problem, the system needs re-thinking. Mark Borgerson
Reply by ●January 10, 20122012-01-10
In comp.dsp Tim Wescott <tim@seemywebsite.com> wrote: (snip)>> Some additional info: the non-interruptable function is a function which >> returns system time, therefore if interrupted while the value is being >> read it may return a wrong value.> Such #pragmas are exceedingly non-portable. Besides, all they're going > to do "under the hood" is disable interrupts for the duration of the > function.> If your interrupt hardware is decent then you won't miss an interrupt: > either the interrupt is level sensitive and the hardware that generates > it won't give up until it is explicitly serviced, or the interrupt is > edge sensitive and the interrupt controller takes care of remembering.But if you wait too long, you will miss an interrupt. Maybe there are interrupt controllers that can remember that, though the usual solution is that the interrupt routine should take care of everything that needs to be done, emptying any I/O FIFO's, for example. A computer I had a long time ago had a terminal program with a software UART, running on a 6809. At some point, I disassembled that routine and figured out that it took longer than the interrupt period to get through. It seems that it depends on only processing every other interrupt. -- glen
Reply by ●January 10, 20122012-01-10
On 1/10/2012 3:41 PM, David Brown wrote:> On 10/01/12 19:04, Tim Wescott wrote: >> On Tue, 10 Jan 2012 15:17:26 +0100, Alessandro Basili wrote: >> >>> Dear all, >>> >>> I have the need to define some functions as "non-interruptible" and I >>> remember some #pragma at least for C51 which would do this. I looked for >>> similar #pragmas for the g21k but apparently I haven't found any hint. >>> >>> Does anyone out there know how to reliably define a function as >>> non-interruptible? I understand that I could disable all interrupts and >>> enable them once the function has completed - which will potentially >>> cause to loose an interrupt, unless level-sensitive - but I believed >>> there are some "utilities" to do that at compilation level. >>> >>> Some additional info: the non-interruptable function is a function which >>> returns system time, therefore if interrupted while the value is being >>> read it may return a wrong value. >> >> Such #pragmas are exceedingly non-portable. Besides, all they're going >> to do "under the hood" is disable interrupts for the duration of the >> function. >> >> If your interrupt hardware is decent then you won't miss an interrupt: >> either the interrupt is level sensitive and the hardware that generates >> it won't give up until it is explicitly serviced, or the interrupt is >> edge sensitive and the interrupt controller takes care of remembering. >> In either case, it's your job to make sure that the interrupt will >> persist and be serviced as soon as you come out of the protected section >> of your function. >> >> So -- bite the bullet and do it the grown-up way. You want to save >> interrupt status (because interrupts may already be turned off going into >> your function), do your interrupt-sensitive stuff as quickly as can be, >> restore interrupts to their former state, then exit. >> > > Obviously Tim is right if you need non-interruptable code. > > But there are other ways of doing the job in hand - sometimes disabling > interrupts is not the only solution. For something like system timers > like this, you can get correct results by reading repeatedly until you > have two successive identical reads (and often you can do it with only > partial duplicate reads). Most of the time you only need the two reads - > but if you are unlucky and a timer rollover occurs during a read, > perhaps because of an interrupt, then you will need an extra read. > > You'll have to think carefully about the possible interactions between > the code, the hardware, and interrupts - but it is typically quite > possible without disabling interrupts.That can lead to once-every-two-days kind of failure. A debugging nightmare. Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
