Skip to content

Add simultaneous support for RTC_ALARM_A and RTC_ALARM_B #74

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
batkov opened this issue Aug 14, 2022 · 7 comments · Fixed by #86
Closed

Add simultaneous support for RTC_ALARM_A and RTC_ALARM_B #74

batkov opened this issue Aug 14, 2022 · 7 comments · Fixed by #86
Labels
enhancement New feature or request

Comments

@batkov
Copy link
Contributor

batkov commented Aug 14, 2022

Hi,

I'm trying to run few RTC Alarms on one chip simultaneously.
I've found that RTC_ALARM_A (rtc.c) is used by default and I see no way to run it along with RTC_ALARM_B on chip supporting such a feature.

It seems like RTC_HandleTypeDef RtcHandle initialized once and would be able to run only one type of alarm at one point of time.

Can you add support for RTC_ALARM_B?
Can you suggest how to add such a support?

@fpistm fpistm added the enhancement New feature or request label Aug 22, 2022
@fpistm
Copy link
Member

fpistm commented Aug 22, 2022

Hi @batkov
sorry for the delay (was in vacations).
You're right, RTC_ALARM_B is currently not supported as this library was designed originally to be compliant with Arduino RTCZero library which only support one alarm IIRW. Moreover not all STM32 series have a second alarm.
Anyway, it should be fine to add it. Unfortunately I cannot give a date for this. Any help are welcome.
Maybe a way to add it would be to check if we can extend the alarm API's to select the alarm with RTC_ALARM_A by default to keep backward compatibility and of course available only for STM32 series with RTC_ALARM_B support.

@batkov
Copy link
Contributor Author

batkov commented Aug 22, 2022

Yes, I already implemented something similar to what you've mentioned. Will fix backward compatibility issues and create PR soon.
I have a question though. I've changed RTC methods to receive alarm type, but kept old ones for compatibility.
I've added v2 prefixes for new methods. Probably, @fpistm, you'll have better idea how to name those methods.

@fpistm
Copy link
Member

fpistm commented Aug 23, 2022

Well for example you can do something like that (not tested):

    uint32_t getAlarmSubSeconds(uint32_t alarm = RTC_ALARM_A);
    uint8_t getAlarmSeconds(uint32_t alarm = RTC_ALARM_A );
    uint8_t getAlarmMinutes(uint32_t alarm = RTC_ALARM_A );
    uint8_t getAlarmHours(AM_PM *period = nullptr, uint32_t alarm = RTC_ALARM_A);
    uint8_t getAlarmHours(uint32_t alarm = RTC_ALARM_A);

@batkov
Copy link
Contributor Author

batkov commented Aug 24, 2022

@fpistm please check #75

@fpistm
Copy link
Member

fpistm commented Aug 26, 2022

Hi @batkov
I will review it soon.
As a first feedback I would not use v2_ suffix.

@batkov
Copy link
Contributor Author

batkov commented Aug 26, 2022

Hi @fpistm ,
Yeah, but I did not come with anything better. Please propose something, and I'll update the PR.

@JeroenIoT
Copy link

Hi @batkov,

Would it be an idea to add 1 extra function to set the alarm which we are configuring, setting and getting (by default this is alarmA). This function would only be valid for number of processors capable of handling alarm A / B.

  • Imho changes to the following functions:
void RTC_StartAlarm(uint8_t day, uint8_t hours, uint8_t minutes, uint8_t seconds, uint32_t subSeconds, hourAM_PM_t period, uint8_t mask) {
   |
if (alarmtype == ALARM_B)
{ 	RTC_AlarmStructure.Alarm = RTC_ALARM_B;}
else
{ 	RTC_AlarmStructure.Alarm = RTC_ALARM_A; }
   |
}

At a first glance the following to be changed to handle both alarmA and alarmB (depending on alarmType set by used:

  • void RTC_StopAlarm(void)
  • bool RTC_IsAlarmSet(void)

fpistm added a commit to fpistm/STM32RTC that referenced this issue Jan 13, 2023
Fixes stm32duino#74

Signed-off-by: Frederic Pillon <frederic.pillon@st.com>
fpistm added a commit to fpistm/STM32RTC that referenced this issue Jan 14, 2023
Fixes stm32duino#74

Signed-off-by: Frederic Pillon <frederic.pillon@st.com>
fpistm added a commit to fpistm/STM32RTC that referenced this issue Jan 14, 2023
Fixes stm32duino#74

Signed-off-by: Frederic Pillon <frederic.pillon@st.com>
fpistm added a commit to fpistm/STM32RTC that referenced this issue Jan 14, 2023
Fixes stm32duino#74

Signed-off-by: Frederic Pillon <frederic.pillon@st.com>
fpistm added a commit to fpistm/STM32RTC that referenced this issue Jan 15, 2023
Fixes stm32duino#74

Signed-off-by: Frederic Pillon <frederic.pillon@st.com>
fpistm added a commit to fpistm/STM32RTC that referenced this issue Jan 15, 2023
Fixes stm32duino#74

Signed-off-by: Frederic Pillon <frederic.pillon@st.com>
Co-authored-by: hariton_batkov <yanker90@gmail.com>
fpistm added a commit to fpistm/STM32RTC that referenced this issue Jan 15, 2023
Fixes stm32duino#74

Signed-off-by: Frederic Pillon <frederic.pillon@st.com>
Co-authored-by: hariton_batkov <yanker90@gmail.com>
fpistm added a commit to fpistm/STM32RTC that referenced this issue Jan 17, 2023
Fixes stm32duino#74

Signed-off-by: Frederic Pillon <frederic.pillon@st.com>
Co-authored-by: hariton_batkov <yanker90@gmail.com>
fpistm added a commit to fpistm/STM32RTC that referenced this issue Jan 18, 2023
Fixes stm32duino#74

Signed-off-by: Frederic Pillon <frederic.pillon@st.com>
Co-authored-by: hariton_batkov <yanker90@gmail.com>
fpistm added a commit to fpistm/STM32RTC that referenced this issue Jan 18, 2023
Fixes stm32duino#74

Signed-off-by: Frederic Pillon <frederic.pillon@st.com>
Co-authored-by: hariton_batkov <yanker90@gmail.com>
fpistm added a commit to fpistm/STM32RTC that referenced this issue Jan 18, 2023
Fixes stm32duino#74

Signed-off-by: Frederic Pillon <frederic.pillon@st.com>
Co-authored-by: hariton_batkov <yanker90@gmail.com>
fpistm added a commit to fpistm/STM32RTC that referenced this issue Jan 18, 2023
Fixes stm32duino#74

Signed-off-by: Frederic Pillon <frederic.pillon@st.com>
Co-authored-by: hariton_batkov <yanker90@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants