RTC

[leol]

How do you use the RTC?
What modules need to be loaded on the Pi?

Thanks

Leo

[AndyD]

The original tar file (gertduino.tar) on the Element14 website (which was replaced with gertduino.zip). Had a file called setup which contained the following:-

Code: Select all

#!/bin/bash

echo Settup the Pi for DS1374

gpio load i2c

sudo modprobe rtc-ds1374
sudo /bin/bash -c "echo ds1374 0x68 > /sys/class/i2c-adapter/i2c-1/new_device"

sudo hwclock -r

Note I assume gpio is the GPIO utility from Gordon's WiringPi library.

Edit: Although it appears you already have the original gertduino.tar file. (There are some transposed characters in the word hwclock in the original version).

[leol]

The original tar file (gertduino.tar) on the Element14 website (which was replaced with gertduino.zip). Had a file called setup which contained the following:-

Code: Select all

#!/bin/bash

echo Settup the Pi for DS1374

gpio load i2c

sudo modprobe rtc-ds1374
sudo /bin/bash -c "echo ds1374 0x68 > /sys/class/i2c-adapter/i2c-1/new_device"

sudo hwclock -r

Note I assume gpio is the GPIO utility from Gordon's WiringPi library.

Edit: Although it appears you already have the original gertduino.tar file. (There are some transposed characters in the word hwclock in the original version).

Thanks.
Doesn't work here is the out put from the hwclock command:

Code: Select all

root@NSLraspberrypi:~# hwclock -r --debug
hwclock from util-linux 2.20.1
hwclock: Open of /dev/rtc failed: No such file or directory
No usable clock interface found.
hwclock: Cannot access the Hardware Clock via any known method.

[Gert van Loo]

The Pi does not have a RTC. You'd need to buy one as an add-on and install it accordong to the vendor's instructions.

But it is possible to program the AVR48 om the Gertduino to work as RTC, you can also emulate exiting RTCs with it and even make it wake up your PI at a certain time.
The disadvantage at the moment is that your PI will still use rather a lot of power even if halted. Ideally you want to have the Gertduino 48 chip switch on/off a real power supply whilst it keeps running of the battery.

[gordon@drogon.net]

The original tar file (gertduino.tar) on the Element14 website (which was replaced with gertduino.zip). Had a file called setup which contained the following:-

Code: Select all

#!/bin/bash

echo Settup the Pi for DS1374

gpio load i2c

sudo modprobe rtc-ds1374
sudo /bin/bash -c "echo ds1374 0x68 > /sys/class/i2c-adapter/i2c-1/new_device"

sudo hwclock -r

Note I assume gpio is the GPIO utility from Gordon's WiringPi library.

Edit: Although it appears you already have the original gertduino.tar file. (There are some transposed characters in the word hwclock in the original version).

Yes, that's the gpio program from wiringPi - however you don't need wiringPi installed - just modprobe the neccessary I2C modules, or un-blacklist them.

However you'll need to program up the m48p with the RTC code first - please see my other posting for some details on that.

-Gordon

[MattHawkinsUK]

I'm also getting :

Code: Select all

hwclock: Cannot access the Hardware Clock via any known method.
hwclock: Use the --debug option to see the details of our search for an access method.

If I run "sudo i2cdetect -y 1" I get "68 69" in the grid so I assume I must be close?

[gordon@drogon.net]

I'm also getting :

Code: Select all

hwclock: Cannot access the Hardware Clock via any known method.
hwclock: Use the --debug option to see the details of our search for an access method.

If I run "sudo i2cdetect -y 1" I get "68 69" in the grid so I assume I must be close?

Yes! That what to expect.

So now, you need to run the setup script - and have a look at it - it will load in the relevant modules enabling hwclock to work.

-Gordon

[black-cat]

I'm having the same issues as MattHawkinsUK. Made the m48 code from gertduini.tgz (not the .tar which doesn't build as it needs dross or the .zip which is missing the m48 code entirely) and after searching here managed to program using avrdude.

model B pi running raspbian.

I see address 68 and 69 when I do i2cdetect (after having to find the wiringpi source and installing i2c-tools) but still get "hwclock: Cannot access the Hardware Clock via any known method"

gdset also gives "./gdset: Data read failure at: 0 Got: 0xFF, expected: 0xBE"

I had a look on the serial port as the m48 code should print something to the terminal, all I get is a long string of accented 'A's.

So my guess is something is rather unhappy with the m48 or the i2c. Probably the m48. Soldering iron time?

I'm much more used to the bigger AVRs (xmegas and AVR32s) and Atmel's own programmers

[AndyD]

Hi black-cat,
Firstly, ... put that soldering iron down!

With the m48 did you run the avrsetup script(from the gertduino.tgz file available from Gordon's website)? Did you use that script to set the m48 to run at 8Mhz? The m48 code is setup for 8Mhz (FREWQ=8000000 in the Makefile).

With the hwclock command. Are you sure that the rtc-ds1374 is loaded. Run the command lsmod and make sure it is loaded.

[gordon@drogon.net]

Please use the code, scripts, etc. off my website for now. Detaileld here: https://projects.drogon.net/raspberry-p ... ega-setup/

I've not written up the "howto" on the RTC yet, however if you get that far, run my avrsetup script to make sure the ATmega48p is running at 8MHz and you can see 0x68 and 0x69 with i2cdetect, then you're good to go ...

... so at that point you need to tell Linux that it has a new RTC by modprobing the right module. My RTC code emulates the DS1374 RTC chip, so you need to load the module for that, then bind that module to I2C address 0x68. Look in the setup script in my gertduino.tgz file. It has all the right runes.

Trying to use i2cset/get will work - but only if you know the format of the data to send down to it!

If you want to test it from the command-line, then you can use address 0x69 as a 4-byte "RAM" device:

Code: Select all

i2cset -y 1 0x69 0 0xaa
i2cget -y 1 0x69 0

should read back 0xAA. The single 0 above can be 0, 1, 2 or 3. It represents a 4-byte Unix timestamp.

If you have not loaded the RTC module into the kernel, the device 0x68 is the same - a 4-byte Unix timestamp. It will be incrementing once a second.

Hope this helps for now - but the important bit is that once you have the m48 going, you need to tell Linux what type of RTC it is, and where it is (I2C address) before you can use the hwclock command.

Finally - note that Linux never reads the hardware RTC - ever. It maintains its own clock independant of any RTC - Userland code at boot time reads that RTC and sets Linux's internal clock from it. (And at shutdown time it should copy the Linux time back to the RTC, but you'll need to implement that yourself - or load the relevant .deb's (remove fake-hwclock and load the real hwclock package)

More later - but I'm busy today and off to Cambridge tomorrow - will bring a Pi + Gertduino with me.

-Gordon

[black-cat]

Ah yes, setting the fuses I remembered why I dislike the atmegas!

I forgot that as I was trying to get avrdude to work with the m48pa. Will try tonight as my pi is unplugged.

Ta!

[MattHawkinsUK]

I'll have to take another look. I tried the setup program but it threw an error about not recognising the m48 device.

I think the confusion is that if you follow the user manual you end up with a different avrdude setup compared to the web page.

[black-cat]

It solved my problem. But I'd left it overnight with the programming jumpers and the RS232 links in to the AT48... end result one flat battery

Now to make the RTC give a 1Hz tick to the 328 when the power is on and not drain the battery the rest of the time.

[gordon@drogon.net]

It solved my problem. But I'd left it overnight with the programming jumpers and the RS232 links in to the AT48... end result one flat battery

Now to make the RTC give a 1Hz tick to the 328 when the power is on and not drain the battery the rest of the time.

Yes. I never did get to the bottom of why leaving the serial port connected caused it to draw more power - even when shutting down the serial hardware and making the pins input... I'm still on my first battery some months down the line, but mine is mostly powered up though. Longest down-time so-far has been 3 weeks.

Why do you want the 48p to interrupt the 328p when its on? Wouldn't it be just as easy to create a 1Hz interrupt/timer on the 328p?

-Gordon

[texy]

Hi,
I don't own a gertduino, but I was wondering why the ds1374 was chosen to be emulated in particular? Is the ds1374 module supported in raspbian by default, or is it added with the gertduino software package? I know ds1307 and maybe others are, but I wasn't sure about the ds1374 (or how to find out exactly what is supported ).
Texy

[gordon@drogon.net]

Hi,
I don't own a gertduino, but I was wondering why the ds1374 was chosen to be emulated in particular? Is the ds1374 module supported in raspbian by default, or is it added with the gertduino software package? I know ds1307 and maybe others are, but I wasn't sure about the ds1374 (or how to find out exactly what is supported ).
Texy

It's supported by Debian/Raspbian and ... it's easy and I was lazy/efficient.

The ds1374 is a very simple RTC - all it supports is a 32-bit number that increments once a second - just like the Unix time, so in that respect it's actually much more suited to being used with Linux than some other OS which might read the RTC every time. (Unix/Linux just reads it once at boot time)

Part of the issues I had was doing the wake-up code - so with a combination of the date command which can output relative times in timestamp format, it made life easier and less error-prone.

At the end of the day it doesn't really matter as you read the RTC via the hwclock command, so as long as that has a kernel driver it can talk to, all's well.

-Gordon

[MightySmooth]

Is it possible to get this module to load and configure automatically at boot time?

I've got the RTC working, but every time I reboot it stops again:

pi@raspberrypi ~ $ sudo hwclock -r
Thu 09 Jan 2014 00:48:29 UTC -0.822484 seconds
pi@raspberrypi ~ $ sudo reboot
***reboot***
pi@raspberrypi ~ $ sudo hwclock -r
hwclock: Cannot access the Hardware Clock via any known method.
hwclock: Use the --debug option to see the details of our search for an access method.

I've added the module to /etc/modules:

pi@raspberrypi ~ $ cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.

snd-bcm2835
i2c-bcm2708
i2c-dev
rtc-ds1374

...and lsmod reports it as loaded after a reboot:

pi@raspberrypi ~ $ lsmod | grep rtc
rtc_ds1374 3743 0

If I then re-run this:

sudo /bin/bash -c "echo ds1374 0x68 > /sys/class/i2c-adapter/i2c-1/new_device"

Then it starts working, I assume i'm missing some configuration somewhere but i have no idea where!

[AndyD]

...I assume i'm missing some configuration somewhere but i have no idea where!

Hi MightySmooth! No, you are on the right track, you do need to run

Code: Select all

sudo /bin/bash -c "echo ds1374 0x68 > /sys/class/i2c-adapter/i2c-1/new_device"

every time you restart the Raspberry Pi. The simplest way to do this is to add the command to /etc/rc.local
Here is mine

Code: Select all

/bin/bash -c "echo ds1374 0x68 > /sys/class/i2c-adapter/i2c-1/new_device"

# Check for an IP address

_IP=$(hostname -I) || true
_HOSTNAME=$(hostname) || true

if [ "$_IP" ]; then
    # We have a network, set the hwclock from the system time.
    printf "\nSetting hardware clock from system time\n"
    /sbin/hwclock -wu

    printf "\n%s IP address is %s\n" "$_HOSTNAME" "$_IP"
else
    # No network, set the system time from the hw clock
    printf "\nSetting system time from hardware clock\n"
    /sbin/hwclock -s
fi

[MightySmooth]

Ahha! Didn't think of adding that to rc.local, couldn't see the wood for the trees!

I'll give it a go, thanks

[declanmalone]

Hi,

I've read this thread and also the section of the 'duino manual:

4.6 Battery Drain
If a battery is present and the power of the Raspberry-Pi is switched of the Atmega-48 will still
remain powered by the Battery. It will also keep running. Unless the battery is removed or the
Atmega-48 is programmed to go into a special ultra-low-power condition, the battery will be
drained in a short time.
Even if you think the device is in ultra-low-power mode it can still consume power if it has to
drive outputs high.
Measurements have also show that if a UART connection exists between the Atmega-48 to the
Raspberry-Pi (even if it is not used) that increases the lower power current from 1μA to about
100μA.

So if we use the serial connection, we can expect battery drain. There's a post above about draining a battery by running it overnight. That seems pretty crazy to me. Certainly there's no point in having a battery-backed RTC if the battery needs to be changed every day!
Just to clarify things, I'd like to know whether a serial connection to the Pi is needed if we want to run the RTC program on the 48p and have it communicate the time back to the Pi. This is really confusing for me because (a) if we do have to use serial, then the battery drain issue makes the RTC pointless, and (b) if we're not using the serial, then how does the 48p communicate the time back to the Pi?
The CR1025 batteries are not cheap, and I'd rather not waste any on a setup that's going to run it down in short order, so if I could get clarification on this before I start setting up it would be much appreciated. Thanks

[gordon@drogon.net]

Hi,

I've read this thread and also the section of the 'duino manual:

4.6 Battery Drain
If a battery is present and the power of the Raspberry-Pi is switched of the Atmega-48 will still
remain powered by the Battery. It will also keep running. Unless the battery is removed or the
Atmega-48 is programmed to go into a special ultra-low-power condition, the battery will be
drained in a short time.
Even if you think the device is in ultra-low-power mode it can still consume power if it has to
drive outputs high.
Measurements have also show that if a UART connection exists between the Atmega-48 to the
Raspberry-Pi (even if it is not used) that increases the lower power current from 1μA to about
100μA.

So if we use the serial connection, we can expect battery drain. There's a post above about draining a battery by running it overnight. That seems pretty crazy to me. Certainly there's no point in having a battery-backed RTC if the battery needs to be changed every day!
Just to clarify things, I'd like to know whether a serial connection to the Pi is needed if we want to run the RTC program on the 48p and have it communicate the time back to the Pi. This is really confusing for me because (a) if we do have to use serial, then the battery drain issue makes the RTC pointless, and (b) if we're not using the serial, then how does the 48p communicate the time back to the Pi?
The CR1025 batteries are not cheap, and I'd rather not waste any on a setup that's going to run it down in short order, so if I could get clarification on this before I start setting up it would be much appreciated. Thanks

Serial connection to the Pi from the 48p is not needed at all.

I used it for debugging the code and I observed that leaving it connected would increase the battery drain when running off battery with the Pi powered down from 1µA to about 100µA.

Time is communicated back to the Pi via the I2C.

Just don't connect the 48p's serial lines to anything and you'll be fine.

(Alternatively work out what I have done wrong, if anything, when powering down the 48p's UART when running off battery!!!)


-Gordon

[declanmalone]

Ahh... so it's all I2C rather than uart/serial... thanks very much for that, Gordon.

[sanist]

Thanks for this valuable info.

What about making use of the RTC within the arduino environment: is it as simple as making use of DS1374RTC libraries?

[gordon@drogon.net]

Thanks for this valuable info.

What about making use of the RTC within the arduino environment: is it as simple as making use of DS1374RTC libraries?

It's not as simple as that.

I think the Arduino (328p) I2C pins could be wired to the 48p's I2C bus, after the voltage converters that talk to the 3.3v Pi, but then you'd end up with 2 masters on the I2C bus - the Pi and the 328p. This ought to work in theory, but I'm not sure if it would in practice.

However, given that if the 328p is running, the Pi is also running and probably talking to the Pi via serial or SPI, then it ought to be possible to poke the time to the 328p from the Pi.

I'm not sure why the 328p might need the time of day when the Pi knows it, but I'm sure there may be some applications where its needed (just can't think of any)

-Gordon

[Nige C]

So. What is the real time clock on the Gertduino good for? A watchdog and or wake up system, but not keeping the Pi's clock up to date after power downs? I am obviously confused. Not all Pi's are connected to the internet and an NTP server for some applications, so I guess I'm asking can the RTC on the Gertduino be used by the Pi?