Jump to content

  • Log In with Google      Sign In   
  • Create Account

Photo

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


  • Please log in to reply
95 replies to this topic

#61 xv4y

xv4y

    Level 1

  • Members
  • 102 posts
  • LocationViêt-Nam

Posted 08 February 2013 - 07:42 AM

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 likes this

---
Yannick DEVOS - XV4Y

http://xv4y.radioclub.asia/


#62 sirri

sirri

    Level 2

  • Members
  • 163 posts
  • Locationturkey

Posted 08 February 2013 - 09:22 PM

xv4y happy new year..

#63 grahamf72

grahamf72

    Level 2

  • Members
  • 179 posts
  • LocationAustralia

Posted 13 February 2013 - 01:39 PM

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.

  • xv4y, energia and sirri like this

#64 jeshuah

jeshuah

    Noob Class

  • Members
  • 2 posts

Posted 15 February 2013 - 01:46 AM

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

 

Attached Files


  • calinp likes this

#65 roadrunner84

roadrunner84

    Level 4

  • Members
  • 1,053 posts
  • LocationEindhoven, the Netherlands

Posted 15 February 2013 - 08:14 AM

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.


Always connect a pull-up resistor (47kΩ) and a pull-down capacitor (2.2nF) to reset.

Never use delay() or _delay_cycles(). Never use floating points in embedded systems.


#66 grahamf72

grahamf72

    Level 2

  • Members
  • 179 posts
  • LocationAustralia

Posted 15 February 2013 - 03:40 PM

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.

Attached Files


  • roadrunner84 likes this

#67 roadrunner84

roadrunner84

    Level 4

  • Members
  • 1,053 posts
  • LocationEindhoven, the Netherlands

Posted 15 February 2013 - 04:20 PM

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:


Always connect a pull-up resistor (47kΩ) and a pull-down capacitor (2.2nF) to reset.

Never use delay() or _delay_cycles(). Never use floating points in embedded systems.


#68 sirri

sirri

    Level 2

  • Members
  • 163 posts
  • Locationturkey

Posted 20 February 2013 - 11:07 AM

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

 

Attached File  IMG_3307.JPG   130.64KB   25 downloads

 

 

 



#69 grahamf72

grahamf72

    Level 2

  • Members
  • 179 posts
  • LocationAustralia

Posted 20 February 2013 - 01:28 PM

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 likes this

#70 sirri

sirri

    Level 2

  • Members
  • 163 posts
  • Locationturkey

Posted 20 February 2013 - 01:47 PM

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..

Attached File  images.jpg   7.73KB   12 downloads



#71 calinp

calinp

    Member

  • Members
  • PipPip
  • 27 posts
  • LocationBucharest, RO

Posted 20 February 2013 - 06:30 PM

Hi Sirri,

 

Check this Energia library to see how you can get timer interrupts without disturbing PWM (and tone) generation: http://forum.43oh.co...brary-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 likes this

#72 sirri

sirri

    Level 2

  • Members
  • 163 posts
  • Locationturkey

Posted 21 February 2013 - 11:09 AM

Hi Sirri,

 

Check this Energia library to see how you can get timer interrupts without disturbing PWM (and tone) generation: http://forum.43oh.co...brary-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.



#73 grahamf72

grahamf72

    Level 2

  • Members
  • 179 posts
  • LocationAustralia

Posted 21 February 2013 - 12:19 PM

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 likes this

#74 sirri

sirri

    Level 2

  • Members
  • 163 posts
  • Locationturkey

Posted 21 February 2013 - 09:06 PM

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 ^_^



#75 roadrunner84

roadrunner84

    Level 4

  • Members
  • 1,053 posts
  • LocationEindhoven, the Netherlands

Posted 21 February 2013 - 09:31 PM

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.

Always connect a pull-up resistor (47kΩ) and a pull-down capacitor (2.2nF) to reset.

Never use delay() or _delay_cycles(). Never use floating points in embedded systems.


#76 sirri

sirri

    Level 2

  • Members
  • 163 posts
  • Locationturkey

Posted 22 February 2013 - 07:17 AM

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.

But mortals like me need libraries ; ) : ) i don't think i can handle it. I am not so good at programming at that level.



#77 grahamf72

grahamf72

    Level 2

  • Members
  • 179 posts
  • LocationAustralia

Posted 22 February 2013 - 11:08 AM

Hi Sirri,

I have good news and bad news I'm afraid.

The good news is that I am about 99% done with modifying the RTC library to use the WDT. I just want to do a bit more testing before I release it. Also in the good news category is that when the RTC library is using the WDT I can use analogwrite or tone without issue.

 

The bad news is that analogwrite and tone don't play well together. I have knocked up a basic sketch that uses analogwrite to vary the brightness of an RGB led based on the time, and to sound a 2 second tone every 30 seconds.  If I don't use analogwrite, the tone plays properly every time. If I do use analogwrite, the 1st tone plays correctly but only for about half the time it should, and 2nd and subsequent tones are broken & jerky.

 

Since your project makes use of analogwrite and tone, I think the easiest option is to use a 555 to do your tone and just turn it on/off. Other options would be to use something like a TLC5940 to drive your leds or maybe even a complete re-write of analogwrite & tone.

 

EDIT: After a bit more playing and a bit more studying of the Energia code, it looks like Tone & AnalogWrite will play nice together so long as the pins you choose for AnalogWrite are connected to Timer1 - ie P2.1, P2.2, P2.4, P2.5,


  • sirri likes this

#78 sirri

sirri

    Level 2

  • Members
  • 163 posts
  • Locationturkey

Posted 22 February 2013 - 07:54 PM

Hi Sirri,

I have good news and bad news I'm afraid.

The good news is that I am about 99% done with modifying the RTC library to use the WDT. I just want to do a bit more testing before I release it. Also in the good news category is that when the RTC library is using the WDT I can use analogwrite or tone without issue.

 

The bad news is that analogwrite and tone don't play well together. I have knocked up a basic sketch that uses analogwrite to vary the brightness of an RGB led based on the time, and to sound a 2 second tone every 30 seconds.  If I don't use analogwrite, the tone plays properly every time. If I do use analogwrite, the 1st tone plays correctly but only for about half the time it should, and 2nd and subsequent tones are broken & jerky.

 

Since your project makes use of analogwrite and tone, I think the easiest option is to use a 555 to do your tone and just turn it on/off. Other options would be to use something like a TLC5940 to drive your leds or maybe even a complete re-write of analogwrite & tone.

 

EDIT: After a bit more playing and a bit more studying of the Energia code, it looks like Tone & AnalogWrite will play nice together so long as the pins you choose for AnalogWrite are connected to Timer1 - ie P2.1, P2.2, P2.4, P2.5,

Hi Grahamf,

Thank you for working on this. I have already made a 555 alarm stage. However for further projects, this library you are working on is very important. Do you mean using P2.1, P2.2, P2.4 or P2.5 for analogwrite will solve this problem? In the current library or the one you are working on? Thanks.



#79 grahamf72

grahamf72

    Level 2

  • Members
  • 179 posts
  • LocationAustralia

Posted 22 February 2013 - 09:06 PM

Hi Grahamf,

Thank you for working on this. I have already made a 555 alarm stage. However for further projects, this library you are working on is very important. Do you mean using P2.1, P2.2, P2.4 or P2.5 for analogwrite will solve this problem? In the current library or the one you are working on? Thanks.

Basically the issue is, the RTC, AnalogWrite & Tone all want use of a Timer. The MSP430G2553 has 2 timers, the MSP430G2452 only has 1 timer. So we have 3 libraries attempting to use 1 or 2 timers, and problems will occur if we attempt to use 1 timer for 2 functions.

 

The existing RTC library uses Timer1 if it is available (eg 2553) or Timer0 if not (eg 2452).

Tone() uses Timer0

AnalogWrite() uses Timer0 for the pins on port 1, and Timer1 for the pins on port 2 (2553 only, you can't use AnalogWrite to port 2 with the 2452).

 

This means you simply cannot use all 3 functions. On the 2553 you can use any 2 with care, on the 2452 you can only use 1.  So with the 2553 you can use RTC + Tone or RTC + AnalogWrite to port 1 or Tone + AnalogWrite to port 2. 

 

The soon-to-be-released WDT version of the RTC library doesn't use one of the general purpose Timers so you can take the RTC out of the equation, and use any combination of Tone & AnalogWrite that your chip allows, ie:

2553 - Tone + AnalogWrite on Port 2 or AnalogWrite on Port 1 & 2

2452 - Tone or AnalogWrite

 

Hope this helps make things a bit clearer.


  • sirri likes this

#80 sirri

sirri

    Level 2

  • Members
  • 163 posts
  • Locationturkey

Posted 24 February 2013 - 05:06 PM

Thank you Grahamf, 

Especially your last message made me understand the concept better..

Just wondered, does it also cause problems to millis() function somehow?






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users