next week I'll get my hands on a win7 machine and give it a spin. :)
Clock calendar implementation on RTC
(152 posts) (17 voices)-
Posted 3 years ago #
-
Work called...
I booted up my Win7 machine and did the following:
- downloaded the MapleRTC library as a zip file from github.
- downloaded the latest MapleIDE (0018) and installed it.
- copied the MapleRTC library to the MapleIDE\libraries folder.
- Changed the name of the folder to MapleRTC, so it's MapleIDE\libraries\MapleRTC. Before it was something like bubulindo-MapleRTC2935oi.
- copied the rcc.h and rcc.c files and replaced the files in the directory MapleIDE\hardware\cores\maple.
- opened the example, chose a board in the IDE.
- clicked compile and had no errors.Can you repeat this procedure to a separate folder in your computer to see if it works on a fresh IDE installation?
Posted 3 years ago # -
I'm going to nuke everything and start from scratch. Gotta stuff the kiddies with sugar first though...
Posted 3 years ago # -
bubulindo, I just reinstalled the latest MapleIDE and MapleRTC just as you describe. It didn't make any difference. I do have WinXPsp3 though. It compiles and downloads other code just fine... Gotta go to work, I'll ponder it more tonight. Thanks for the help.
Posted 3 years ago # -
Sadly, I was forced to change Windows machines when Siemens started supporting Win7. But I developed and tested that, or part of, library in a WinXP machine.
Does anyone has an XP or Win7 machine to test this? My test and installation is obviously flawed, but someone might pick up on something I left behind.
Posted 3 years ago # -
I also failed but I assumed it was because I am only using libmaple from the command line.
It would be nice if your changes to rcc could be rolled into libmaple so you didn't have to do surgery on it.Posted 3 years ago # -
Hmmm...
This is strange. If this was happening in my old machine, it would most likely had been some file that I changed and forgot about. But tested in a brand new computer (ok, with Win7) and it worked fine. :S
Posted 3 years ago # -
I installed the RTClib a few months back and am coming back to it now. Back then and now, the LSE
clock does not seem to be working -- no LED flash on Test_RTClock. I'm running from linux, maple-ide-v0.012 on maple RET6. The LSI and HSE clocks seem to work. Is there really a crystal hooked
to LSE? rcc.c/h were updated as noted in README. Is this an RET6 problem?things to try?
Posted 3 years ago # -
If I remember correctly, the original Maple boards don't have an external crystal hooked up on the LSE pins.
I tested this on an olimexino-stm32, that has teh 32kHz crystal connected. On the Maple boards you can use the HSE (main crystal) or LSI (internal crystal), or connect the 32kHz crystal on the correct pins (not sure which, right now).
Posted 3 years ago # -
Looking at the maple schematic and my board, there are two holes for pins 20 and 21 (no header), so I'll have to do a bit of soldering to test a 32hkz crystal on the Maple.
FYI, you can do pretty good frequency measurements from an NTP host over a serial line. I used a Linux box with NTP and typically the "disciplined" frequency of the Linux box is less than one ppm. So I used a program to poll the MCU every 10 seconds or so to get 4-byte millis() values (or the tick count from an ISR for RTCs). The longer the period over which you calculate the cumulative drift, the more accurate the frequency offset measurement (ppm). Here are some typical results for crystals, oscillators and TXCOs
processor oscillator spec measured(ppm) avr 328p 16Mhz resonator 0.5% -1330 uno 16MHz resonator 0.5% -1422 breadboard 328p 16MHz crystal 50ppm -42 breadboard 328p avr 328p 11Mhz crystal ? -23 3.74v batteries avr 328p 11Mhz crystal ? -16 5v avr 128 14Mhz ? 1738 no schematic, resonator? DUE 12MHz*x crystal ? TBD maple 8MHz*9 crystal ? -5 propeller 5Mhz*16 crystal ? -40 board1 (quickstart) propeller 5Mhz*16 crystal ? -98 board2 (quickstart) ds1307 RTC 32khz 20ppm 23 external "watch" crystal ds3132 RTC 32khz 2ppm 1 chronodot TXCO i2c ds3134 RTC 32khz 2ppm 1 TXCO SPI avr RC 8Mhz 1% 2100 OSCCAL units 3000 ppm avr RC 8Mhz 1% 2700 OSCCAL units 5000 ppm beagle 24MHz*x -5 ntp drift raspberry 19MHz*x -16 ntp drift dell desk -26 ntp drift dell laptop -14 ntp drift
Crystal frequency can vary with age and temperature. The spec'd accuracy is usually for 25C, and frequency varies in ppm as about -.04 * (t-T0)**2, where T0 is 25C, so a delta of 10C will change the frequency by 4ppm.
Posted 3 years ago # -
Would you be interested in testing an AVR with the 32kHz crystal?
I wrote a library for that but on the Arduino boards you'll have to disable the external crystal and put the 32kHz on those pins. It then uses timer 2 to clock the time and runs on the internal RC oscilator. :)
Posted 3 years ago # -
> Would you be interested in testing an AVR with the 32kHz crystal?
Yes, I'll have to burn a new bootloader to run at 8 Mhz, or use the programmer to load the
program with the low fuse set to 8Mhz. Though ultimately it comes down to testing the crytstal, whether it be from the maple or avr. It would be better from avr cause you can prescale and
get a lot more ticks/second. With the maple RTC and one tick per second it takes a long time to get a good drift estimate....
Actually, readingPin 23 (ANTI_TAMP) can be configured as 512 tick/sec output from 32KHz crystal. Have you tried feeding that pulse train into an ISR to count ticks?
Posted 3 years ago # -
manitou - Impressive list of clocks! Did you mean TCXO?
How did you estimate the drift on the TCXO's? They seem to be as accurate as your Linux box using NTP.
Posted 3 years ago # -
The first version is in here:
I have made the code so that it compiles to both the ATmega168/328 and ATmega16 (have some lying around since 2003). I would guess that it would compile to the Mega board, but the official Arduino Mega doesn't break out the clock input pins, so that is a dead end.
Unfortunately work got in the way and the soonest I can put the crystal and logic to the test (I'm not counting seconds on the AVR) will be by the end of December. :(
Posted 3 years ago # -
> How did you estimate the drift on the TCXO's?
yeah TCXO --dyslexic fingers
The RTC's can be configured to tick at various rates on an output (SQ) pin. On the Uno I fed that into an external interrupt pin and counted ticks in the ISR (typically 1024 ticks/sec). When my linux host polls, I send back the latest tick count. The linux box keeps track of elapsed time and accumulates the ticks and calculates a cumulative frequency offset from the beginning of the test.
Well, I put a header on maple pin holes 21/22 and put a 32khz crystal in a breadboard with 22pf caps to ground, but I couldn't get LSE to respond in the RTC software ... bummer. Presumably there is unwanted capacitance in breadboard/jumpers, but i got similar scheme to work with avr 328p and a 16MHz crystal on breadboard. Hardware isn't my strength ... so I'm not so confident about the avr test with your code.
I see your code is only doing tick/second pulse (all you need for RTC), I may see if I can prescale to more ticks per second to accelerate the drift estimation ...
Posted 3 years ago #
Reply »
You must log in to post.