Go Down

Topic: Atmega4809 RTC module (Read 668 times) previous topic - next topic

jwalters1955

Has anyone out there worked out how to use the Watchdog (WDT) and Real Time Counter (RTC) modules yet?

I can't find (doesn't mean they're not there) the necessary header files to define the various registers. I'm also not quite sure how they're configured at startup so I can work out what registers I need to fiddle with to get these two peripherals going.

Including avr/wdt.h obviously doesn't work because it's all written for the wrong processor.

westfw

The header files are include automatically, for the bare register definitions.  (Arduino.h includes avr/io.h includes iom4809.h...)


Quote
Including avr/wdt.h obviously doesn't work because it's all written for the wrong processor.
Why do you thing that?  avr/wdt.h is supposed to support "many" different AVR chips, and has had at least support for "xmega" chips for quite a while.  The m4809 is supposed to be (more or less) XMega peripherals on a mega-sized chip...

jwalters1955

Yep, my mistake. including ..../avr/wdt.h gets the wdt running.

However, I'm still struggling with the RTC, I can't get the 32k Xtal clock to run. The XOSC32KCTRL register is under config change protection so I tried the unlock procedure in 'c' but wasn't able to write to the XOSC32KCTRL register. OK thinks I, perhaps the compiler's slipping in a few extra instructions and quota of 4 is running out I've taken the assembly code for the wdt setup and modified it to set up the 32k clock.

I'm not fully familiar with the megaAVR instruction set or the syntax of inline assembler but what I've done looks right and has less than 4 instruction before writing to the XOSC32KCTRL register but I'm still seeing no change.

I must be writing to the CCP as its value changes from 1 just after the call to osc32_enable to zero after a few more instructions have executed. The attached is a simple strip down to try to get the clock running.

Can anyone see what I'm missing?

Code attached, output is as follows;

_SFR_IO_ADDR(CCP) = 34
CLKCTRL_XOSC32KCTRLA = 7C
CCP_IOREG_gc value = D8
XOSC32KCTRL value = 0
CPU_CCP value = 1
XOSC32KCTRL value = 0
CPU_CCP value = 0

supermalli

Hi jwalters,

I've had a similar issue (working with CLion and avr-g++ on Linux). First set the RTC prescaler etc., then set the enable bit - and nothing worked. Then fxed it by writing the enable bit together with the prescaler in the RTC.CTRLA register at the beginning. Now it works. It looks like an undocumented surplus of the documented silicon erratum in http://ww1.microchip.com/downloads/en/DeviceDoc/80000777A.pdf. Does that fix your problem?

Best regards,
supermalli

goodchip76

Hi!

for RTC, I've rewrited a fork of original arduino Time library for use Internal RTC of 4809 and others MegaAVR 0 series :

https://github.com/goodchip/Time

Look at sketchs TimeInternalRTC_xxx in folder "examples"


If possible, I would like a return for testing before submitting a pull-request to the original Time project.

Thanks!

Juraj

#5
Apr 11, 2019, 12:35 pm Last Edit: Apr 11, 2019, 12:36 pm by Juraj
Hi!

for RTC, I've rewrited a fork of original arduino Time library for use Internal RTC of 4809 and others MegaAVR 0 series :

https://github.com/goodchip/Time

Look at sketchs TimeInternalRTC_xxx in folder "examples"


If possible, I would like a return for testing before submitting a pull-request to the original Time project.

Thanks!
don't make the PR. the TimeLib is and should stay independent from hardware.
for example with RTCZero library I do

Code: [Select]
rtc.begin();
setTime(rtc.getEpoch());


write a library similar to RTCZero
You can't write an Arduino sketch if you didn't learn programming. Not the language, but the concepts of programming - algorithms and data types.

goodchip76

#6
Apr 11, 2019, 12:45 pm Last Edit: Apr 11, 2019, 12:58 pm by goodchip76
My fork is fully tranparent with 328p or 4809 chips, just the RTC is used for time generation if you use 4809. (in fact, interrupts features was enabled only if you use 4809).

With an external RTC library, the original time library uses millis () between each time update, which is extremely imprecise, especially for time-based sensors applications.

Since 4809 uses an internal RTC, I think it is better to use it as a main timebase, which is not possible if not integrated in the time library.

Furthermore, it was difficult (if not impossible) to set the righ second with precision ( with setTime() ) if RTC lib is external, with my fork, the real second is set with +/-25µs average precision.


Juraj

My fork is fully tranparent with 328p or 4809 chips, just the RTC is used for time generation if you use 4809. (in fact, interrupts features was enabled only if you use 4809).

With an external RTC library, the original time library uses millis () between each time update, which is extremely imprecise, especially for time-based sensors applications.

Since 4809 uses an internal RTC, I think it is better to use it as a main timebase, which is not possible if not integrated in the time library.

Furthermore, it was difficult (if not impossible) to set the righ second with precision ( with setTime() ) if RTC lib is external, with my fork, the real second is set with +/-25µs average precision.


see the RTCZero library
You can't write an Arduino sketch if you didn't learn programming. Not the language, but the concepts of programming - algorithms and data types.

goodchip76

I fully agree that the RTCZero library is well coded, probably in a precise way.

Nevertheless, there is for me a contradiction:

  - on the one hand, you give me an example of use with the library time.h (which is not useful because the library RTCZero includes the vast majority of the functions of the library time.h and without making precision).

 - on the other hand, you talk about compatibility, but the RTCZero is specific to an architecture while the Time.h is Arduino generalist.

My fork brings compatibility between two architectures with all the best possible precision if RTC is present in the chip.

Thank you for enlightening me and answer me with arguments.

Juraj

#9
Apr 11, 2019, 02:55 pm Last Edit: Apr 11, 2019, 02:59 pm by Juraj
I fully agree that the RTCZero library is well coded, probably in a precise way.

Nevertheless, there is for me a contradiction:

  - on the one hand, you give me an example of use with the library time.h (which is not useful because the library RTCZero includes the vast majority of the functions of the library time.h and without making precision).

 - on the other hand, you talk about compatibility, but the RTCZero is specific to an architecture while the Time.h is Arduino generalist.

My fork brings compatibility between two architectures with all the best possible precision if RTC is present in the chip.

Thank you for enlightening me and answer me with arguments.
My use case is that I move my project between different architectures. As default I set the time from network. On SAMD I can initialize time from RTC to have it set, if there is a problem with network connection.

Quote
Arduino Time Library

A primary goal was to enable date and time functionality that can be used with a variety of external time sources with minimum differences required in sketch logic.
You can't write an Arduino sketch if you didn't learn programming. Not the language, but the concepts of programming - algorithms and data types.

goodchip76

/!\ Warning

some Uno WiFi Rev2 boards have a component implementation problem that renders the RTC function inoperative (resistance (black) implanted instead of a capacitor (brown) in the quartz resonator circuit).

cf: https://github.com/arduino/ArduinoCore-megaavr/issues/27

pert

(resistance (black) implanted instead of a capacitor (brown) in the quartz resonator circuit).

cf: https://github.com/arduino/ArduinoCore-megaavr/issues/27
I have a question about the picture you posted in that issue thread. In your picture, the component in question (C904 I believe) looks differently colored from the one next to it (C905), but these should be the same value of capacitors. Is that just a trick of the light in the picture?

goodchip76

It's the photo of my own board.

It's an artefact of the photo, it's the same color in real.

pert

Thanks for the clarification. I did realize that was a photo of your board.

The boards MCUdude and I own are very likely to be from the same batch, since they were shipped from Arduino together in the same order. Since your board doesn't have the issue, it appears the problem may be limited to a batch of the boards, as MCUdude hypothesized.

goodchip76

I've updated the photo on GitHub for best comprehension.

I am of the same opinion for the batch ;)

Go Up