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.
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 have an STM32F103C8 board and my program is switching the GPIOB1 with frequency of 500KHz.
At first, microcontroller runs the program perfectly but the main problem is that MCU resets after a couple of hours and stays at reset mode until I disconnect the board from the power supply. If I power the board immediately after disconnecting, MCU will not work but if I power the board few minutes later, the MCU works properly just for a couple of hours and after that, the same problem is repeated.
I already faced another problem that this issue was happening after 15 minutes, I added a 10uF capacitor to the VDD3 pin and now, this problem(going to reset mode) happens after about 5 or 6 hours.
Do you have any suggestions about hardware or program?
What should I do with the reset pin? (Currently, I'm pulling up nRST pin with a 10K Ohm resistor)
Can this happen because of the wrong power-up sequence on VDD, VDDA, and nRST pins?
Is this similar to a clock malfunction?
This is the schematic
Thanks in advance,
Amir
I'm currently working on an app that I want for my app to detect a beacon in background mode just when it gets close to it(Immediate). Based on articles that I've read it cannot be done with didEnterRegion and I should use ranging while it's running in the background mode(Location Update). is there any solution that directly reduces the didEnterRegion threshold? or Should I use the other method? and if that's the case does it work like didEnterRegion but with a limited range of RSSI? does it work when my phone entered the region and it's locked and the screen is off?
Monitoring APIs give you no control over the distance at which you get detection callbacks. You always get a callback the first time a beacon goes within radio range, typically at around 40 meters.
There are two ways to trigger on beacons only at close range:
Configure a lower radio transmission power on your beacon, if the manufacturer supports it.
Combine Ranging APIs with Monitoring, and range for as long as possible in the background (180 secs max on iOS without special background permissions), then trigger your logic when a ranging callback says the CLBeacon accuracy field is immediate.
Option 1 is simpler, but less reliable as it will often trigger at greater distances than you'd like and sometimes has trouble triggering at all even at extremely close range.
Option 2 is more reliable, so long as background ranging time does not run out. If a phone's radio triggers at 40 meters to start ranging, if the user takes more than 180 secs to get to immediate proximity then ranging time runs out and you are unable to get a trigger until the beacon disappears and reappears to reset the ranging time allowed.
I want my Android application to be notified when the user is moving fast.
(lets say faster then 5 meter/second)
It must be battery efficient - so I can not use GPS for example, but can use a sensor.
Latency is not very important - it can be up to 30 seconds after reaching a fast speed.
I am only interested in continues movement. fast tilting the device can be ignored.
How can this be done ?
I am writing an iPhone game. When the user makes his first move a timer kicks of with an interval of 0.01 seconds. A UILabel displaying the time also gets updated every time.
I noticed when testing on an iPod touch 2nd gen and an iPhone 3GS that the iPod was slower (after 20 seconds the iPhone displayed 00:20,00 and the iPod displayed ~00:10,00). Is there a way to make this more reliable? If I'm correct, the NSTimer should run on its ow thread and should not be blocked by user interaction.
JNK
The NSTimer documentation states:
Because of the various input sources a
typical run loop manages, the
effective resolution of the time
interval for a timer is limited to on
the order of 50-100 milliseconds. If a
timer’s firing time occurs while the
run loop is in a mode that is not
monitoring the timer or during a long
callout, the timer does not fire until
the next time the run loop checks the
timer. Therefore, the actual time at
which the timer fires potentially can
be a significant period of time after
the scheduled firing time.
So accuracy can be as bad as 0.1, not 0.01 seconds. Not to mention if your thread is blocked for some reason. So if your firing time is crucial you should be looking at other things. Read this SO post for kick-off. Apple had a metronome sample code (in which, obviously, timing is crucial) but I can't find it just now.
In any case, if you are implementing a timer with NSTimer, you should record your start time. Then, whenever you update your interface, simply take the difference of the current time and your start time (with NSDates).
make sure you're not basing a timer off of sleeps or delays. You should always update a timer based on things like number of clock ticks since program start or current time
sorry I'm not more familiar with your language
You can't rely on a timer to run exactly at the specified time intervals, so the time you are displaying should always be calculated by taking time interval differences. And I doubt that a timer on the iPhone can run every 1 ms, in Quartz it is possible to get a timer call every 16 ms or so, making 60 fps - so scheduling it at 1ms probably means "run as soon as possible", which might be quite different on different hardware.