目覚め時計

[skotopes]

What's new

• FuriHal: RTC Alarm API
• Settings: Clock Alarm settings
• Alarm app

Verification

• Set alarm and wait for it to trigger
• Set alarm and poweroff flipper, wait for flipper to power on and alarm to trigger

Checklist (For Reviewer)

• PR has description of feature/bug or link to Confluence/Jira task
• Description contains actions to verify feature/bugfix
• I've built this code, uploaded it to the device and verified feature/bugfix

[github-actions]

Compiled f7 firmware for commit 31c71b2a:

• 📦 Update package
• 📥 DFU file
• ☁️ Web/App updater
• 📊 Size report

[CookiePLMonster]

The basic alarm function works well, incl. waking up the Flipper when it was shut down.

A few notes/ideas, knowing full well that this PR is WIP so I'm aware that some of those may already be planned:

• A "bell" icon, like the Bluetooth/SD card icons are placed currently
• Perhaps allow applications to use ALMB while ALMA is "reserved" for the inbuilt Clock app. Make it possible for the app to choose if it wants to get the default "wake up!" screen and wake the Flipper up, or if it wants to control that by itself
• Allow applications to subscribe to the alarm ISR at least for ALMB, right now it seems to be dominated by the Clock app
• If ALMA and ALMB get exposed to apps, reset them when resetting Flipper settings, and maybe also offer a "Reset alarms" option in the Clock app, if some app leaves alarms configured in a weird state
• One shot timers? Both in furi rtc, and in the Clock app

[skotopes]

@CookiePLMonster

Regarding your previous message: despite of the fact that there are 2 alarm slots, having both of them working in a same way is impossible. Alarm output can only be configured to work with one source.

Also since we don't have way to start app on alarm, I'll hide this API from public use.

PS: I'm open to new creative ideas on how to make this thing usable, but super busy and don't have time to polish this PR further

[CookiePLMonster]

Alarm output can only be configured to work with one source.

Indeed, tricky. I think this could be solved by not treating the alarm callback as an ISR (from the API standpoint), but rather furi_rtc_alarm could be managing this ISR by itself. This way, the alarm ISR callback becomes part of the firmware, and it can further call to user-specified callbacks for ALMA and ALMB. Of course same restrictions as furi_hal_isr apply, so the apps need to un-register this callback before exiting etc.