I need help with creating device that will be able to play sound (can be recorded or from mp3/wav...) at certain time, for example at 8:00PM, 8:15PM; 8:30PM ...until 5:00AM. Device must be powered from battery and must be working for more than 2-3 months. Sound is about max 10 seconds and it should not be loud but also not quiet. I found that for directly recording can be useful ISD1820 but then I need to set relay and clock. Then I found VS1003, and I think that this chip can be able to do that without setting relay and clock. If anyone can help me or know something better I would really appreciate that.

As a similar requirement, we need the VS1005 to boot up at a specified time using RTC. From the datasheet 11.19, it is not clear how the RTC Alarm is set, and whether it can boot the VS1005G (where an SD file would provide further instructions), or whether it only generates an RTC Alarm Interrupt. Also checked Date and SetDate.

If it only generates an interrupt, I would assume some code is necessary to operate the VS1005G at 32 KHz in a super low power mode.

Would timing accuracy be determined by the tolerance/temp coeff of the 32 KHz crystal?

We haven't used the RTC alarm in a VSOS environment so far, but theoretically it should be very simple. Setting the alarm is very similar to setting the date and time. In both cases, a 32 bit seconds counter value is clocked into a RTC data shift register in the RTC battery power domain. The difference is which operation is executed for the value. When you set the value, you set the RTC hardware to execute RTC_I_LOADRTC operation, which will copy the shifter value to the RTC counter. But if you want to set the alarm, you just set the RTC hardware to execute RTC_I_ALARM operation, which will start comparison of the shifter and the counter. You can then power down the VS1005 and the RTC will power it back up when a comparison match occurs. What happens after that is up to you. You could perhaps have a program in CONFIG.TXT to detect that a RTC power up has occurred and do what needs to be done. You can read the shifter value back to the CPU, that might be helpfup, or you could store a copy of the alarm time into one of the 32 battery backed up registers, something like that. We could perhaps also integrate code into the kernel boot to detect this kind of situations.

We could perhaps also integrate code into the kernel boot to detect this kind of situations.

For our application, this is not really necessary. If the alarm triggered a boot sequence, we still must read a stored list of any pending alarms anyway. These alarms are to execute specific tasks which the user may or may not be aware of.

I will test this out on the VS1005 as soon as the display program is complete.