Rod
Member
Excellent news!
Was any part of the sync stuff required before flipping LSEON do you think?
Yes, it would be really good to get a nice clean pull of rtc.c for LeafLabs.
Want to put your stuff on a github repository? It seems like a great system.
And then you are going to build a library that knows dates via time.h,is that your plan?
bubulindo
Member
I'll start that up on github. I already have a CRC library built up (although I'm still figuring out all possible ways of using it) that I can share through there.
Yes, my plan is to "hide" all this stuff and make the clock work simply. time.h will basically be used for the conversion of the timestamp into date/time and vice-versa.
Right now the problem is that when I included time.h in the IDE it broke the links to delay() and millis(). But since these won't have to be called from the IDE, it's not so bad. :)
bubulindo
Member
I've created a github thingy for the maple.
https://github.com/bubulindo/libmaple/tree/master/libmaple
Turns out that the changes were on the clock selection by "Oring" the selection bits instead of writing the entire register and those inconsistencies between registers pointed out earlier.
Rod
Member
OK, I've merged your changes and merged them into the RTC support pull request. I also did some additional simplification/cleanup and testing.
The LSI clock source works and I've tested it on a Maple Mini.
The LSE clock source should work as well as I've incorporated your changes (Olimexino with 32 kHz crystal).
I tried to make the HSE/128 clock source work, but was unable to. The clock source is on-line, but the first write to a register does not complete (RTOFF flag stays at zero). I suspect this means the RTC is not ticking over.
I did look through the errata for the chip, but didn't find any issues.
This RTC clock source seems to be of relatively little use in any case.
If you wouldn't mind testing it one more time, I'd appreciate it. (Maybe try RTCSEL_HSE as well, in case the issue is specific to my board?)
My Olemexino has shipped...
bubulindo
Member
Rod, just remembered, I couldn't get the HSE clock going either in the beginning, what worked for me was this:
static inline void rcc_start_hse(void) {
// *bb_perip(&RCC_BASE->CR, RCC_CR_HSEON_BIT) = 1;
while (bb_peri_get_bit(&RCC_BASE->CR, RCC_CR_HSERDY_BIT) == 0);
}
I figured that the clock is already running, otherwise the chip would be stopped, so I just check if the bit is up and running and take it from there. Still haven't had time to test this on my board, but this is how I have my rcc.h.
Test it out.
Rod
Member
Yes, the HSERDY bit is high on my board (HSE clock running), but it leaves RTOFF permanently low (i.e. busy) on mine when I try and write to the count register, Works fine with LSI. I spent a couple of hours yesterday fiddling with it. Can't see any more knobs to twiddle.
bubulindo
Member
Maybe there's some difference between my .c files and yours? Both HSE and LSE ran today as I was testing the cpp files from the library. So it may be a little thing like a set or clear bit. :\ Give it a go. I do remember having trouble with HSE and then it started working. So I may finally understand why it did. (I'm being too lazy lately with version control... :( )
higwoshy
Member
Hi,
Many thanks to Rod & bubulindo for the work. I've only just got my Maple clone (Olimexino) and after 2 days have a working RTC running along with a SD card with timestamps. Very pleased.
I've used the MapleRTC that (I think) bubulindo produced/linked to and it works a treat. There is one problem though, and I'm not sure if this was deliberate/debug code or there is a good reason for it, but in the file RTClock.cpp in the RTC constructor code it resets the counter to 0 each time it's initialised. This doesn't quite make sense to me for a RTC as it means the RTC doesn't survive resets or re-programming. I've taken both lines out with no ill effect.
rtc_set_count(0);//initializing... just in case
I'm running the LSE clock which, on the Olimexino at least, is pretty robust as it keeps working even if a reset or program change occurs. It even seems to work in sleep modes and running at very low clock rate (AHB 140khz? div512). It even survived a power down for a second or so. That makes it easy to use as you set the time once, then reprogram with something else. I made a quick test prog that waits for 5 seconds for something from serialusb, then either interprets it as the time or just continues with the RTC as it's setup. Had it running on battery for 12hrs at 140khz or so, no problem, though a time loss of 10 seconds or so. Easily fixed with a fudge or maybe calibration? I just do this to set the time on it date "+%s" >/dev/cu.usbmodem3d121
Incidentally, for anyone else reading this with an Olimexino, I've been going through the MapleSD library and tidying it up so it works fully and is easy to setup on either Maple or Oli. There were a few minor changes to the code, nothing too drastic, just a few fixes for listing and writing files and a bit of timestamp code that only needs to be #included to work with the MapleRTC. I've also written a (very) quick hack to allow all the Arduino examples to compile on the Maple without having to change any code. Would anyone be interested in this as an update?
Will this RTC code by incorporated into libmaple or will it be left as a library?
bubulindo
Member
Hello,
Thanks for testing. I stopped the tests a while ago and the lib isn't quite finished, as you can see by the destructor on it.
I assumed that the time counts wouldn't survive a power down or a new program write, hence the reset to 0. I'll remove that from my files.
That 10 second time loss, were you using LSE? I'm thinking of maybe making something to calibrate the crystal too, since it's apparently common for the internal crystal to need that. The manual however, doesn't specify anything like that to the LSE.
You can change the prescaler values in the constructor to get a better result though.
I'll see if I pick this up later on.
bubulindo
Member
Please do.
I had (probably is still in the library since I didn't quite document it) an overloaded method to specify the prescaler, but thought it would work great so didn't gave it much attention. You can also calibrate the clock, but I haven't looked into it yet.
Maybe when I get home I'll have some more time to check this.
higwoshy
Member
Ok, result of a 10hr test = no time loss. The previous result(s) may have just been because either 1) Running on batteries with voltage varying (low battery) or 2) Very slow AHB clock speed. I'm going with the former....hang on...
<half hour test later on batteries>.
Result : User error - when I unplug the usb and the circuit switches to the battery supply, sometimes my hand gets close or touches the 32k crystal causing it to be unstable, this (I'm guessing) starts up the clock stabilising circuit and the whole cpu hangs while the clocks stabilise. Certainly the flashing led to represent a second stops until I take my hand away and then takes a few seconds to start again. I'll have to remember to unplug from the computer end in future.
So, it seems the LSE is very accurate, even on battery. If I remember I'll set it going again overnight, on battery, with a full cpu load, just to double check.
You must log in to post.