Spark Logic

RTC Libs.

ahull Mon May 18, 2015 7:16 pm

One of the things that I would like to get working is the RTC on the STM32F103XXX – We briefly touched on this before.

Most boards have a 32,767 Hz oscillator or crystal on them and therefore only need a battery/battery holder (possibly with an in-line schottky diode, put probably not) to allow us to get the RTC operational.

What I have discovered so far.

1) There is some sort of attempt to get this working in ./hardware/Arduino_STM32/STM32F1/libraries/Untested/RTClock/
This is incomplete and incompatible with the current versions of rcc.c and rcc.h

There is a “new” version of the rcc libraries in ./hardware/Arduino_STM32/STM32F1/libraries/Untested/RTClock/new RCC/
This is not compatible with the current rcc libraries either.

2) I am unclear which rcc.[h,c] I need to try to merge or adapt the changes form “new RCC” to as there seem to be a number of candidates.

./hardware/Arduino_STM32/STM32F3/cores/maple/libmaple/stm32f3/include/series/rcc.h
./hardware/Arduino_STM32/STM32F3/cores/maple/libmaple/stm32f3/f3_rcc.c

./hardware/Arduino_STM32/STM32F3/cores/maple/libmaple/include/libmaple/rcc.h
./hardware/Arduino_STM32/STM32F3/cores/maple/libmaple/rcc.c

./hardware/Arduino_STM32/STM32F1/libraries/Untested/RTClock/new RCC/rcc.h.new
./hardware/Arduino_STM32/STM32F1/libraries/Untested/RTClock/new RCC/rcc.c.new
./hardware/Arduino_STM32/STM32F1/libraries/RTClock/new RCC/rcc.h.new
./hardware/Arduino_STM32/STM32F1/libraries/RTClock/new RCC/rcc.c.new

./hardware/Arduino_STM32/STM32F1/cores/maple/libmaple/rcc.c
./hardware/Arduino_STM32/STM32F1/system/libmaple/stm32f2/include/series/rcc.h
./hardware/Arduino_STM32/STM32F1/system/libmaple/include/libmaple/rcc.h
./hardware/Arduino_STM32/STM32F1/system/libmaple/stm32f1/include/series/rcc.h

./hardware/Arduino_STM32/STM32F4/cores/maple/libmaple/rcc.c
./hardware/Arduino_STM32/STM32F4/cores/maple/libmaple/rcc.h

Replies

victor_pv Mon May 18, 2015 7:53 pm

My wild guess is that you should start looking at this two, to see why we even have those 2 files:

./hardware/Arduino_STM32/STM32F1/system/libmaple/include/libmaple/rcc.h
./hardware/Arduino_STM32/STM32F1/system/libmaple/stm32f1/include/series/rcc.h

mrburnette Tue May 19, 2015 2:57 pm

EDIT 2:
Well, sticking a 32K crystal on PC14 to PC 15 while the Maple Mini was on breadboard (extra capacitance) produced
Time + interrupt counts: 10.457 (10, 0, 1, 1)
Time + interrupt counts: 13.20437 (13, 0, 1, 1)
Time + interrupt counts: 15.7575 (15, 0, 2, 2)
— alarm —
Time + interrupt counts: 18.4175 (18, 0, 2, 2)
Time + interrupt counts: 21.24113 (21, 0, 2, 2)
Time + interrupt counts: 23.11238 (23, 0, 3, 3)
— alarm —
Time + interrupt counts: 26.7796 (26, 0, 3, 3)
Time + interrupt counts: 29.27733 (29, 0, 3, 3)
Time + interrupt counts: 31.14860 (31, 0, 4, 4)
— alarm —
Time + interrupt counts: 34.11417 (34, 0, 4, 4)
Time + interrupt counts: 37.31305 (37, 0, 4, 4)
Time + interrupt counts: 39.18424 (39, 0, 5, 5)
— alarm —
Time + interrupt counts: 42.14973 (42, 0, 5, 5)
Time + interrupt counts: 44.2090 (44, 0, 5, 5)
Time + interrupt counts: 47.22008 (47, 0, 6, 6)
— alarm —
Time + interrupt counts: 50.18555 (50, 0, 6, 6)
Time + interrupt counts: 52.5669 (52, 0, 6, 6)
Time + interrupt counts: 55.25597 (55, 0, 7, 7)
— alarm —

EDIT:
Looks like PC14 & PC15 (D13 & D12 respectively) on the Mini or D22/D23 on the Maple

I was looking over the older, Maple examples for RTC. This one compiles for me, but I do not have a 32K crystal on a Maple Mini to try… I need to find a schematic and determine if I can easily mount one under the magnifying glass….


C:\Users\Ray\AppData\Local\Temp\build7347767204266594424.tmp\RealTimeClock.cpp.bin :
section size addr
.data 16880 0
Total 16880

Binary sketch size is reported above. Check it against a 108000 byte maximum.


/*
* test-rtc.c
*
* Example program that sets up the Real Time Clock and then blinks the
* LED in patterns for seconds and alarm interrupts.
*
* Created by Rod Gilchrist on 11-12-24.
* section size addr
.data 16880 0
Total 16880
*/

#include "wirish.h"

#include "rtc.h"
#include "usb.h"

int globAlmCnt = 0;
int globOvCnt = 0;
int globSecCnt = 0;
int specAlmCnt = 0;
int lastGlobAlmCnt = -1;
int lastSpecAlmCnt = -1;

void rtc_sec_intr() { if (rtc_is_second()) globSecCnt++; }
void rtc_ovf_intr() { if (rtc_is_overflow()) globOvCnt++; }
void rtc_glob_alm_intr() { if (rtc_is_alarm()) globAlmCnt++; }
void rtc_spec_alm_intr() { if (rtc_is_alarm()) specAlmCnt++; }

void setup() {
pinMode(BOARD_LED_PIN, OUTPUT);
delay(5000);
SerialUSB.println("begin RTC blink");
delay(1000);

rtc_init(RTCSEL_LSI);
rtc_set_prescaler_load(0x7fff);
rtc_set_count(0);

rtc_attach_interrupt(RTC_SECONDS_INTERRUPT, rtc_sec_intr);
rtc_attach_interrupt(RTC_OVERFLOW_INTERRUPT, rtc_ovf_intr); // expected every 128000 seconds
rtc_attach_interrupt(RTC_ALARM_GLOBAL_INTERRUPT, rtc_glob_alm_intr);
rtc_attach_interrupt(RTC_ALARM_SPECIFIC_INTERRUPT, rtc_spec_alm_intr);
}

void loop() {
int i,n;

SerialUSB.print("Time + interrupt counts: ");
SerialUSB.print(rtc_get_count());
SerialUSB.print(".");
SerialUSB.print(rtc_get_divider());
SerialUSB.print(" (");
SerialUSB.print(globSecCnt);
SerialUSB.print(", ");
SerialUSB.print(globOvCnt);
SerialUSB.print(", ");
SerialUSB.print(globAlmCnt);
SerialUSB.print(", ");
SerialUSB.print(specAlmCnt);
SerialUSB.println(")");

delay(1000);

digitalWrite(BOARD_LED_PIN, 1);
if ((lastSpecAlmCnt != specAlmCnt) || (lastGlobAlmCnt != globAlmCnt)){
lastGlobAlmCnt = globAlmCnt;
lastSpecAlmCnt = specAlmCnt;

SerialUSB.println(" -- alarm -- ");
for (i=0;i<3;i++) { digitalWrite(BOARD_LED_PIN, 0); delay(100); digitalWrite(BOARD_LED_PIN, 1); delay(100);}
n = rtc_get_count() + 5;
rtc_set_alarm(n);
}

delay(1000);
digitalWrite(BOARD_LED_PIN, 0);
}

ahull Tue May 19, 2015 9:38 pm

That looks pretty interesting, I couldn’t get any of the examples I found to even compile. One of my boards already has a 32kHz oscillator on it the other has a can style watch crystal. They are only missing the battery. Some of the other board available on ebay actually include the battery holder too.

mrburnette Tue May 19, 2015 10:43 pm

ahull wrote:That looks pretty interesting, I couldn’t get any of the examples I found to even compile. <…>.

mrburnette Thu May 21, 2015 9:35 pm

I’m getting a clean compile after modifications to Gilchrist’s RTC example and changes to rcc.h using Roger’s github ZIP (today download) on Windows 8.1

Sketch uses 20,268 bytes (18%) of program storage space. Maximum is 110,592 bytes.
Global variables use 4,552 bytes of dynamic memory.

Rick Kimball Thu May 21, 2015 9:49 pm

I would love to try this stuff..

But each time you post it I have to go through and change all ‘\’ in the #includes to ‘/’

Please library writers … use ‘/’ for path separators. It works on windows and linux and os/x .. the ‘\’ only works on windows.

RogerClark Thu May 21, 2015 9:52 pm

But each time you post it I have to go through and change all ‘\’ in the #includes to ‘/’

Please library writers … use ‘/’ for path separators. It works on windows and linux and os/x .. the ‘\’ only works on windows.

I’m sure there must be a regex replace to do that ;-)

But I agree… All libs need to be cross platform.

ahull Thu May 21, 2015 10:48 pm

I think once we get this working, it should become one of the “standard” libs included with Roger’s git repo. and in light of that, it will have to be “/” rather than “\” throughout.

RogerClark Thu May 21, 2015 11:16 pm

I will see if I can write a regex find for this and run it on the whole thing, but I suspect there cant be that many issues in the core, otherwise people would be complaining about it to me.

mrburnette Thu May 21, 2015 11:17 pm

Déjà Vu … beginning to sound like the old forum: maybe I took a wrong turn?

RCC.h is correct:
#include <libmaple/libmaple_types.h>
#include <libmaple/bitband.h>

ahull Thu May 21, 2015 11:20 pm

I suspect (as I may have said before) that the real screwup is with the IDE which should be able to cope with both and do the right thing.

mrburnette Thu May 21, 2015 11:31 pm

@Roger;

When you validate rcc.h and the RCClock lib, please stick a notice in the libraries section of the forum. I do not wish to do this prematurely. Oh, at that time you can remove the Untested directory in the libraries.

Ray

Rick Kimball Thu May 21, 2015 11:59 pm

I was a windows/dos programmer from the late 1985 til now (sadly). I guess because from 1980 til then I using Unix, I never used ‘\’ for path names. I also tend to avoid upper case file names. I also avoid spaces in names. I also avoid ‘-‘ in names. All this Arduino stuff is cross platform. Let’s make our lives easier.

I really don’t think the IDE should be have anything to do with this. This is a C/C++ compiler issues and how to deal with cross platform development.

RogerClark Fri May 22, 2015 1:04 am

Hi Rick,

I agree.

Classic problems are .

1. Case sensitivity of Unix and not Windows systems, hence always use lower case
2. Don’t use spaces, where possible use underscore. (I’m not sure about the minus character instead of underscore). AFIK The reason that web sites tend to use the minus instead of an underscore is because the way Google parse URLS, as “Arduino_ST32” is treated as if its a whole word by Google, where as “Arduino-stm32” is treated as “Arduino” “stm32”
3. I think one problem is that some parts of windows force you to use back slashes, e.g. I think the PATH env var needs back slashes, but of course this completely screws up Linux and OSX which treat them as an escape symbol :-(

Rick Kimball Fri May 22, 2015 1:22 am

The lib seems to work for me after I fixed up the paths.

Thanks.

mrburnette Fri May 22, 2015 3:08 pm

Rick Kimball wrote:The lib seems to work for me after I fixed up the paths.

Thanks.

victor_pv Fri May 22, 2015 3:38 pm

Besides uncompressing the lib files, is there anything else that needs to be done to use it?
Like changing anything in the core files, or the function or any pin…

zoomx Fri May 22, 2015 3:41 pm

RogerClark wrote:
Classic problems are .

1. Case sensitivity of Unix and not Windows systems, hence always use lower case
2…….

RogerClark Fri May 22, 2015 9:24 pm

Ray

I will try to update the Rtc lib in the repo this weekend and move from untested

As a bit if history… I originally decided to collect all the libraries I could find that claimed to have been ported to libmaple and put them in the libraries folder, just to make it easier for people to find them

However I soon realised that a lot of them didn’t work, or perhaps never really worked correctly. Hence the untested folder

IMHO I think the untested folder seems to be a reasonable location for things until someone gets time to test and fix etc, as in some cases the libs are related to specific hardware that only a few people have.

I think its getting to the stage were its impossible for me to test everything, as it would be a full time job and I’d need to buy all sorts of hardware and connect it up in permanent test rigs.
So I think we will have to trust people when they say that something works for them if it involves external hardware

I can of course test any code that just uses standard features in C,R,V or Z series boards

Thanks

Roger

Sign in to reply