I am implementing a kernel module to handle power-off event. Our HW setup will emit an IRQ when power cut-off happens, and device can run 200ms more after that. During this time I have to close all rw-opened Fd to avoid file corruption. I am thinking of two options:
Perform closing all Fds from within the interrupt context itself. It will mask all other interrupts and handle the event until device is off. It may cause freezing issue.
Use Softirqs and do closing in the bottom half.
What would be the best way to implement this? thanks all.
I try to debug a function compute that is called within the context of while-no-input.
(while-no-input (compute arg1 arg2))
Instrumenting compute for edebug and pressing the keys of the edebug have it jump outside the computation and this spoils the execution of the debugger in an ugly way.
I do not know whether it is possible to debug the compute without cutting while-no-input.
Right. while-no-input doesn't care whether the input comes from typing while in the debugger.
To debug in a context like this, I'd insert calls to message in the code you want to debug, echoing to buffer *Messages* any intermediate values or other info that helps.
while-no-input cares only about input, not output (e.g. calls to message).
In the middle of an experiment i got stuck with an issue for which i hope somebody out here might know the solution.
I am using TIMER1 in PWM mode which is supposed be to continuously running in the background. Since triggering ADC using Timer1 update event is not possible in STM32F401, I used the following settings.
TIM1: Trigger Event Selection_Output Compare(OC1REF)
ADC1: External Trigger Conversion Source_ Timer 1 Capture Compare 1 Event
On sensing a particular value through ADC1 i need the Main output to be disable(i don't want to disable the timer) So i cleared the MOE bit in BDTR register.
But disabling the MOE bit actually stops ADC Triggering.
What could be the possible problem for ADC not getting a proper trigger when only the main output is disable and timer is still running ?
If this is not the proper way can ,what is the proper way to turn off output alone ?
I want to run a periodic "housekeeping" event, triggered regularly by a timer interrupt. The interrupt fires frequently (kHz+), while the function may take a long time to finish, so I can't simply have it executed in line.
In the past, I've done this on an ATMEGA, where an ISR can simply permit other interrupts to fire (including itself again) with sei(). By wrapping the event in a "still executing" flag, it won't pile up on the stack and cause a... you know:
if (!inFunction) { inFunction = true; doFunction(); inFunction = false; }
I don't think this can be done -- at least as easily -- on the XMEGA, due to the PMIC interrupt controller. It appears the interrupt flags can only be reset by executing RETI.
So, I was thinking, it would be convenient if I could convince GCC to produce a tail call out of an interrupt. That would immediately execute the event, while clearing interrupts.
This would be easy enough to do in assembler, just push the address and IRET. (Well, some stack-mangling because ISR, but, yeah.) But I'm guessing it'll be a hack in GCC, possibly a custom ASM wrapper around a "naked" function?
Alternately, I would love to simply set a low priority software interrupt, but I don't see an intentional way to do this.
I could use software to trigger an interrupt from an otherwise unused peripheral. That's fine as a special case, but then, if I ever need to use that device, I have to find another. It's bad for code reuse, too.
Really, this is an X-Y problem and I know it. I think I want to do X, but really I need method Y that I just don't know about.
One better method is to set a flag, then let main() deal with it when it gets around to it. Unfortunately, I have blocking functions in main() (handling user input via serial), so that would take work, and be a mess.
The only "proper" method I know of offhand, is to do a full task switch -- but damned if I'm going to effectively implement an RTOS, or pull one in, just for this. There's got to be a better way.
Have I actually covered all the possibilities, and painted myself into a corner? Do I have to compromise and choose one of these? Am I missing anything better?
There are more possibilities to solve this.
1. Enable your timer interrupt as low priority. In this way the medium and high priority interrupts will be able to interrupt this low priority interrupt, and run unaffected.
This is similar to using sei(); in your interrupt handler in older processors (without PMIC).
2.a Set a flag (variable) in the interrupt. Poll the flag in the main loop. If the flag is set, clear it and do your stuff.
2.b Set up the timer but don't enable its interrupt. Poll the OVF interrupt flag of your timer in the main loop. If the flag is set, clear it and do your stuff.
These are timed less accurately according to what else the main loop does, so depends on your expectations for accuracy. Handling more tasks in the main loop without an OS: Cooperative multitasking, State machine.
I am doing one assignment where I have to write and interrupt handler for Keyboard. So in this assignment we have to log the key stroke so it is allowed to do File I/O and we are using Work queue for that.
I know it is not allowed to sleep in Interrupt handler and so we cannot use any file i/o or printk in interrupt handler.
So in real industry how to debug and interrupt handler OR what I can do if I want to debug something ?
Yes! this is correct we can not use printk inside an ISR. As i studied in RTOS(Real time operating System) during interrupt handling it creates message log and save required information in the log file which you can see later.
The similar thing is also available for latest Kernel. Using trace_printk you can debug time critical place. I haven't used this before so no sample for this. You can follow this link to know more about trace_printk.