Real-Time Clock (RTC) Library for the MSP430/LaunchPad

[xv4y 46]

Hi Graham,

 

Sorry but I just came to read your message.

I have been busy those last days working, and now it is New Year holidays and my two children are at home wanting me to spend some time with them.

I will try to have a look at what you have done and then publish "our" library on my website.

It could be in more than a week unfortunately but I will try to do it ASAP.

 

I am currently writing a logger weather station.

However I prefered to use an Arduino Nano with one DS1307 module because :

- the ATMega328 as 1k EEPROM for saving measurements

- it has 2ko RAM allowing me to use a cheap NC28J60 ethernet chipset for the web server

- the DS1307 module is battery saved

 

I use a MSP430G2452 for the remote sensor.

 

You can have a look at the prototype (missing daily saving points for weekly and monthly trend statistics) here :

http://cairang.radioclub.asia:8080

 

Wishing you happy new year of the Snake.

Regards,

Yan.

I'd just like to point out that Yan (xv4r) did all the hard work with the code, I just tracked down the cause of the timing bug in Energia 9, and tweaked it a little to make it more suited for a couple of uses that I have for it. I still consider it his library, not mine.

 

Other than the attachment to the posts in this thread, I haven't set up webpage where it is available for download. Yan you are more than welcome to place it on your website, since it is 90% your work anyway. From experiments I've done with it, if dates are turned off, the resulting library compiles to be exactly the same size as your original library - which is proof that it is your work, not mine.

 

Although I won't take much credit for the library, if people do find it useful I would love a PM with a brief rundown of your project.  At the moment I am using it in a clock connected to a 16x2 LCD, where it has run for a couple of weeks and is still within a second of my desktop computer.  I have two plans for projects that will implement this code. One is a logging weather station and the other is a "word clock" - the type that highlights different words to indicate the time.

[sirri 28]

 

xv4y happy new year..

[grahamf72 169]

I have posted an updated version of this library in the "Libraries" section of this forum.  This is quite a significant upgrade. The main changes are:

 

• Now works with both the MSP430G2553 and the MSP430G2452 processors (with some limitations on the 2452). The library may work on other processors, but I don't have any to test with.
• Rewrite of the logic used to detect the number of days in a month and leap year detection so that it uses considerably less RAM.
• Option to use the built-in VLO clock. The VLO is much less accurate than the crystal - about the best that can be achieved is accuracy to within a few minutes per day. The advantage of the VLO is that it frees up 2 IO pins, and can be used if you can't solder the tiny crystal to the launchpad. If you don't need a very accurate clock, or have a means of external synchronisation, the VLO may be sufficient for your needs.
• The #define's that configure the settings of the timer have been moved to a separate RTCconfig.h file, so they are easier to edit without having to edit the main header file.
• Documentation has been moved from the header file into a separate .txt file.
• Some example files have been included in the library.

[jeshuah 1]

Hi all,

 

I'm working on a simple alarm clock with an RGB 16x2 LCD display as a learning vehicle for the MSP430/LaunchPad and Energia.  This thread has been awesome -- many thanks to xv4y and grahamf72 for posting their code!

 

I needed a more full-functioned calendar than what Graham had posted in RTCplus.zip on 1/29 (I haven't checked out his latest update in the "Libraries" section yet), so I took a slightly different tack and used Yan's timer code to create a simple RTC library that can be used to synchronize with the Time.h (and TimeAlarm.h) Arduino libraries here:

http://playground.arduino.cc/Code/time

 

The library is attached, along with an example sketch, in case any one else finds it useful...

 

- Jesh

 

MSP430RTC.zip

LCD_light_clock_example.zip

[roadrunner84 466]

Using a timestamp (time_t) to keep track is very handy if you're doing synchronisation of some sort. I personally like it more that separate time keeping per unit (h,m,s, D,M,Y), but if displaying a clock in realtime, you'd probably need to cache the other stuff too, because it would otherwise require quite some calculations to get human readable time. Especially since you need to take account for all leap years too.

[grahamf72 169]

I agree roadrunner84, that for some purposes timestamp time_t is the better format to use, but it all depends what you are doing with it.

 

If you are logging the time, and then you will be viewing the logs via computer, then timestamp is probably the best method.  

 

But if you will be displaying the time in human-readable format direct from the microcontroller, timestamp comes with quite a lot of overhead in both CPU cycles, and code space, to be able to convert it to something we humans can read.  When I was re-doing the RTC library I did consider using a timestamp as an internal storage method rather than separate variables for each unit, but decided against it because of the code overhead required in making it user readable.  By sticking to hmsDMY, and using #defines to turn on/off different features, it is possible to keep the code quite small.  Using timestamp tends to be an all-or-nothing affair - even if you only need time of day, you still get all the overhead associated with dates.

 

With the current RTC library, implementing a timestamp to record the number of seconds since power-on is as simple as also incrementing a local variable (preferably an unsigned long), in the Timer interrupt function. If you want the timestamp to represent seconds since unix epoch it is simply a matter of calculating the timestamp value when the user changes the time. From then on the local variable and the RTC will stay in synch and you can access the timestamp or the hmsDMY with simple variable access.  Converting hmsDMY to timestamp is quite inexpensive as far as code size goes as it only requires addition & multiplication. If you use the method I have suggested here, conversion only needs to be done rarely.

However if timestamp is used as the native storage method, conversion back to hmsDMY for display is quite expensive as far as both code size and CPU cycles. The conversion requires division & modulus or considerable loop/subtract/test operations. Furthermore, the conversion needs to be done every time you want a human-readable display.

 

As an exercise, I took jeshuah's light-clock example, and took out all the arduino Time & AlarmTime code, and replaced it with the latest version of the RTCplus library (as posted in the Libraries forum), and added a basic Alarm class plus a couple of functions to be able to determine Day-Of-Week.  jeshuah's code compiles to 5652 bytes whereas the adapted sketch with identical functionality compiles to 3702 bytes. Admittedly the Alarm class I created isn't quite as well featured as the Arduino, but when working with small microcontrollers you often don't have the luxury of being able to handle the overhead associated with a do-everything library.  I have attached my quick variant of jeshuah's alarm clock sketch - it might serve as inspiration for someone. One of these days I might create a better alarm clock class to work hand-in-hand with the RTC library, and will consider incorporating a day-of-week function & convert to/from time_t functions.

LCD_light_clock_example_RTCplus.zip

[roadrunner84 466]

I am doing a clock project myself too. I posted it on the board a while back.

I'm keeping time with an Hour, Minute and Second counter, of which Second is not displayed.

I use a charlieplexing algorithm to display hour and minute in binary on an 11 LED display (no segments or digits, just LEDs).

My current code is just a few bytes over 1.5 kB and includes

• time display
• 4 second auto-off display
• alarm display
• switch between 24H and AM/PM mode
• snooze alarm
• ajustable snooze interval

I'd like to reduce the code size to be under 1.25 kB (that is 1024+256 = 1280 bytes) so I can fit it in a 2101 chip, I'm currently stuck with a 2201.

Ofcourse, saving the byte-to-decimal conversion and the LCD display driver routines saves me a lot of code :grin:

[sirri 28]

sorry for disturbing again but I have concerns that RTC_plus timer interrupt is affecting my buzzer sound loop (tone()) it is discontinous ..

the main topic and code is here

 

please check this image as well.. thanks

 

 

 

 

[grahamf72 169]

Hi Sirri,

Unfortunately it probably is the RTC library that is causing the interference with Tone. The Tone & AnalogWrite functions rely on the MSP430's timer, as does the RTC library. Consequently the functions don't play well with the RTC library. There are a couple of solutions. You could use an external oscillator for the buzzer, eg a 555 timer. The output pin could then drive the reset pin of the 555 to turn it on/off.

 

To do it in software, you could make some changes to Energia's wiring.c to configure the Watchdog Timer to use the crystal instead of SMCLK and use the WDT interrupt to drive the RTC. I am working on making this an option with the RTC library, but trying to work out the best way of doing it so as to make minimal changes to the actual Energia code. 

 

Best of luck.

[sirri 28]

Hi Sirri,

Unfortunately it probably is the RTC library that is causing the interference with Tone. The Tone & AnalogWrite functions rely on the MSP430's timer, as does the RTC library. Consequently the functions don't play well with the RTC library. There are a couple of solutions. You could use an external oscillator for the buzzer, eg a 555 timer. The output pin could then drive the reset pin of the 555 to turn it on/off.

 

To do it in software, you could make some changes to Energia's wiring.c to configure the Watchdog Timer to use the crystal instead of SMCLK and use the WDT interrupt to drive the RTC. I am working on making this an option with the RTC library, but trying to work out the best way of doing it so as to make minimal changes to the actual Energia code. 

 

Best of luck.

Thank you Graham,

 

You saved my days and hours of frustration of working and testing things around.

 

// I was trying to solve this buzzer issue for many hours // probably more than 20 hours :]

 

At least now i know i should not work on the code itself, anymore : )) I guess i will go for 555 option, i will see..

 

Thanks again,

 

edit:

a possible monostable 555 oscillator diagram might be as..

[calinp 24]

Hi Sirri,

 

Check this Energia library to see how you can get timer interrupts without disturbing PWM (and tone) generation: http://forum.43oh.com/topic/2861-energia-library-mstimer2/

 

Or try using a different pin. According to pins_energia.h "On the 20pin devices, upto 3 analog outputs are available

T0A1, T1A1 and T1A2 "

 

    T1A0, /* 8 - P2.0 note: A0 output cannot be used with analogWrite */

    T1A1, /* 9 - P2.1 */

    T1A1, /* 10 - P2.2 */

    T1A0, /* 11 - P2.3 note: A0 output cannot be used with analogWrite */

    T1A2, /* 12 - P2.4 */

    T1A2, /* 13 - P2.5 */

 

Regards,

Calin

[sirri 28]

 

Hi Sirri,

 

Check this Energia library to see how you can get timer interrupts without disturbing PWM (and tone) generation: http://forum.43oh.com/topic/2861-energia-library-mstimer2/

 

Or try using a different pin. According to pins_energia.h "On the 20pin devices, upto 3 analog outputs are available

T0A1, T1A1 and T1A2 "

 

    T1A0, /* 8 - P2.0 note: A0 output cannot be used with analogWrite */

    T1A1, /* 9 - P2.1 */

    T1A1, /* 10 - P2.2 */

    T1A0, /* 11 - P2.3 note: A0 output cannot be used with analogWrite */

    T1A2, /* 12 - P2.4 */

    T1A2, /* 13 - P2.5 */

 

Regards,

Calin

Hi Calin, I don't feel that confident to write my own timer interrupt for now indeed. I am already using RTS plus library and this one is interrupting PWM and tone().. If experienced users now how to bypass this interrupt without breaking timer accuracy please let me know.. Thanks.

[grahamf72 169]

Hi Sirri,

I think I have a solution by driving the RTC library off the WDT instead of Timer1. I'll post an update to the library in the next few days that will hopefully fix the interference with Tone() & AnalogWrite().

 

The drawback is that millis() and delay() will only have 2mS resolution, but I don't foresee that being a major problem.

[sirri 28]

Hi Sirri,

I think I have a solution by driving the RTC library off the WDT instead of Timer1. I'll post an update to the library in the next few days that will hopefully fix the interference with Tone() & AnalogWrite().

 

The drawback is that millis() and delay() will only have 2mS resolution, but I don't foresee that being a major problem.

thanks a lot already. i think many people will like it because i think that rtc library is very important for many purposes, so pwm features like tone() and analogwrite() .. looking forward for the update

[roadrunner84 466]

That's a major drawback of these libraries. As almost all depend on your coop being in a certain state, it's hard to let them play nice together.

In my binary watch I use wdt for time keeping and the timer for display multiplexing, button debouncing, menu handling and buzzer. I did not use any libraries. I doubt that I would be able to do all this while maintaining low power when using libraries.