Pressing the keyboard triggers an interrupt.
Then, EXECUTE of CPU is finished and interrupt check is performed, and ISR is executed.
But if I don't take the keyboard off, the interrupt will continue to occur, and I think that the program won't die.
But even if I keep pressing the keyboard while playing the game, the program doesn't die.
I think the operating system is blocking the keyboard interrupt, but I'm curious to know what it is.
Related
I am solving a problem with the software reset of the STM32F427 microcontroller. Doing a software reset of the MCU is not a problem, it works great and the MCU boots up nicely.
During the software reset, the processor pulls its reset pin to zero. This reset pulse is now a few milliseconds long. I am working on how to make this reset signal longer. I would need it to be about 10ms long.
Does anyone know if and how this signal could be extended by modifying the software? (some wait instructions at the very beginning of the run, modification in the options byte, change in the system initialization code)
This is what the MCU pin reset signal looks like during a software reset.
Background of the problem:
I have a finished hw that runs normally and sometimes it is necessary to do a sw reset (fw update, untreated error, etc.). This hw has a COMMON reset pin for MCU and another chip (hw reset pins of both chips are connected). An RC element is connected to this signal so that the sources have time to warm up before the MCU starts up. It's fine on a cold start, but the SW reset has a reset pulse too short for the second chip. This second chip will then remain in a strange (non-functional) state. Therefore, I would need to extend the reset signal.
The HW is finished, it can no longer be modified. The reset connection was a bad idea.
I want to wake up my stm32 controller from standby mode by giving a rising edge on WKUP pin, but there is a problem. When I press the switch on a WKUP pin for more than 10 seconds, then and then only my controller should wake up not by just pressing and releasing the switch.
Depending on which low power mode the STM32 is in (sleep, stop, standby), there are a couple of ways I see right now to do this:
Software: Wake the MCU up on the rising edge on your WKUP pin immediately. Then wait for 10 seconds and keep polling the state of the pin (in a busy loop) or check if a falling edge interrupt on the pin has happened (the GPIO would probably need to be reconfigured for that). Depending on the low power mode that was used, only the required peripherals would need to be reactivated during the waiting period, and if an IRQ is used for the falling edge, the core would not even need to be clocked during that time (a timestamp could be recorded after wake up). If the WKUP pin is released before 10 seconds have passed, the program could signal that by flashing an LED or a beep, and go to sleep again.
Hardware: An external circuit could be used to wait for 10 seconds until it actually signals the MCU, which isn't bothered at all before the actual wake up event happens and no special software would be required. If accuracy isn't that important, a simple RC circuit could be used. There also exist specialized, accurate delay ICs that do exactly that (e.g. the TimerBlox series by Linear, e.g. LTC6994, you can set the delay time with a resistor).
MCU Peripheral: Use an STM32 peripheral to implement the delay: maybe try to set up an RTC or TIMER/COUNTER interrupt after WKUP, so that an interrupt will be triggered after a certain amount of time, and go to sleep again. However, you would also need to setup an interrupt on the WKUP pin to cancel the action when the pin goes low before the waiting period ends.
Which approach would be the best certainly depends on the application requirements (accuracy, power usage, simplicity etc.). - The first one is the easiest and most straightforward IMHO, since power usage usually isn't an issue for 10 seconds of busy waiting. And accuracy also isn't that important for waking up the MCU after sleeping, right? - So the other solutions are probably overkill.
I was under the impression that NSTimer did not work at all after an application calls applicationWillResignActive. I seems however that existing NSTimers (i.e. ones created before the application resigned active) will continue to run and its only new NSTimers that can't be scheduled in this state, can anyone confirm this?
I am also assuming that its good (and Apple seems to say this too) that when your application calls applicationWillResignActive you should disable any NSTimers and start them again when applicationDidBecomeActive is called, does that make sense?
When an application is inactive, but still in the foreground (such as when the user gets a push notification or presses the sleep button) your application is still running completely. Any timers you have created which you don't stop will fire as normal. However, when your application goes to the background, if you are not registered to run a background thread all execution is stopped. If it is time for a timer to fire, it will not happen because the run loop is not running. When your application is reopened, however, any timers which were supposed to fire while it was in the background will all be fired immediately. Apple suggests doing cleanup in applicationWillResignActive so that you are not doing a lot of work when the user is not focused on your application, but you definitely want to disable timers before going to the background so that they don't all fire one after the other when your application is reopened.
I have an IBAction which starts a number of timers.
I would like to have a second or a pause for a certain time. How can I pause execution?
I know of the [self performSelector:#selector(someMEthod:) withObject:someObject afterDelay:1.0];
but how can I just cause a delay without calling anything?
Thanks
You can call sleep() or +[NSThread sleepForTimeInterval:] but please don't do that on the main thread. Pausing execution of the main thread means your app's UI will be blocked for that time and appear to the user as if it had crashed. If you blocked the main thread for more than a few seconds, Apple's watchdog timer would kill your app instantly.
See this blog post by Jeff LaMarche for more on this issue: http://iphonedevelopment.blogspot.com/2010/05/psa-respect-main-thread.html
You don't want to cause a delay without calling anything. It's bad for the UI, and does not fit Cocoa Touch's event driven paradigm.
Cut the routine in which you want to pause into (at least) two parts/halves. Have the first half set up a delayed call to the second half (perform selector with delay, timer, queue, etc.) and then return to the main loop. The OS will call the second part, later, after potentially doing useful stuff in the mean time (giving the user a responsive UI or saving battery life, catching up with background email, etc.)
You may have to learn how to save state between parts (loop variables, etc.), something that some new programmers seem to miss in their learning.
You can use sleep(int_No_of_Sec); // eg. sleep(1);
I have disabled interactions in my primary view (which contains some subviews I use as buttons).
I keep this disabled while I have a secondary view up indicating network activity (loading data). When it is finished, I re-enable interactions in the primary view.
This is so the user isn't tapping those buttons while the network operation takes place.
Anyway, all seems well, but the if the user starts tapping buttons in the primary view, once the re-enable occurs those touch events (from the past few seconds) actually trigger. Not the touches-began, which highlights the buttons, but the functions called on the touches-ended. Its like its queued the whole time it was disabled and "races to catch up".
It is very bizarre, why would touch events be queued while the view has its user interaction disabled?
It's hard to be confident of an answer here without seeing the code, but here is one idea:
If your network activity is synchronous, aka blocking, then it could be the case that the user's touches are queued before they get a chance to hit any of your code. If that's the case, then those touches won't be sent into your responder chain until the network activity finishes, and they'd never get a chance to "know" that you'd disabled interaction with those controls.
Here's one way you could help debug your situation: Add some debug NSLog statements in the top layer (what you call the secondary view) that's indicating network activity. Make sure the secondary view's frame is big enough to include those touches, and see if it logs the touches as soon as they happen. If not, my guess might be correct. If yes, well, you still get useful information - and you might be able to simply capture the touches at this level, instead of allowing them to queue up.
If this guess is correct, the least hacky fix I can think of would be make your network operations asynchronous.
If you don't want to do that, you could also try using an NSTimer to leave the network activity indicator up for a split second after the synchronous call completes. This way, your responder chain could clear out the queue of incoming touches, and ignore them if that's the desired behavior.