Tutorial: Add a Real Time Clock to the Raspberry Pi


67 posts   Page 2 of 3   1, 2, 3
by thogue » Mon Oct 29, 2012 12:11 pm
Maybe this is the wrong thread to post, but related to getting my RTC working.

Initial troubleshooting left me with nothing, possibly thinking I fried the RTC while putting it together....

Anyways figured out I was on i2c-1 ? What/how dictates which i2c bus your plugging into? The diagrams for the GPIO header show i2c-1 as an alternative function to the pins that i2c-0 is on.

I eventually realized I was on i2c-1 and thats why I could not detect the clock...
Code: Select all
echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device

Code: Select all
i2cdetect -y 1


Works like a charm now.

ps, running most recent firmware, most recent rasparian
Posts: 131
Joined: Wed Sep 19, 2012 2:16 am
by notarat » Mon Oct 29, 2012 12:55 pm
adafruit wrote:
Jim JKla wrote:Is there any chance of making a real time clock like this as a USB device? Note battery backed in the same way so that it was not drawing power from the USB port.


huh, we don't recall ever seeing a USB based RTC, if you find one can you post a link?


Cymbet makes one.

Here's the pdf brochure

http://www.cymbet.com/pdfs/DS-72-22.pdf
Posts: 106
Joined: Wed Sep 12, 2012 12:32 pm
by poing » Tue Dec 04, 2012 12:16 am
psergiu wrote:Small correction to the tutorial
With Raspbian, in order to correctly set the time using hwclock you have to (as root):
...

Does the RTC then work with Raspian? In the Adafruit tutorial they say it doesn't because the kernel doesn't support it. Thing is, I don't want to use another distro as I'm well underway with the Raspian based Web-distro (yes, for an embedded project, so no Internet but need real time).
Posts: 1090
Joined: Thu Mar 08, 2012 3:32 pm
by psergiu » Tue Dec 04, 2012 10:57 am
Yes, it works with Raspibian but you have to edit some config files in order to load the required kernel modules and enable the RTC on the I2C bus before running "hwclock --hctosys" for the first time during boot.
Simplest way is to edit /etc/init.d/hwclock.sh and to add the required modprobe & echo commands after the line: log_action_msg "Setting the system clock"
User avatar
Posts: 212
Joined: Mon Nov 07, 2011 8:36 am
Location: Bucharest, Romania
by poing » Tue Dec 04, 2012 1:53 pm
OK, thanks. I think I'll get one and try my luck ;)
Posts: 1090
Joined: Thu Mar 08, 2012 3:32 pm
by msmithy12 » Wed Dec 19, 2012 8:09 am
i built an RTC using a ds3231 and i can see the correct time using

Code: Select all
hwclock -r


but cant make my pi set the time as this at boot.

Latest raspian, 256china board

I want to use my pi to do portable testing of bespoke equipment and need a accurate clock

Thank you!
I assume I know what I`m talking about... I probably don`t

Home: 256mb Made in UK, Rasbmc, 40" Sony Bravia KDL-40v3000
Work: 256mb Made in China, Rasbian, 6" Lilliput touchscreen
Posts: 86
Joined: Fri Aug 10, 2012 8:57 am
by saxer » Thu Dec 20, 2012 7:55 am
Hi,

I have exactly the same problem as mentioned from msmithy12:

but cant make my pi set the time as this at boot.


I am using a Rasp Pi Rev B working with a DS1307 Module from abeletronics.
After the boot process I am able to read and write the time of the RTC. But having my Ras Pi disconnected and restarted it show not the correct time. RTC battery is a new one!

Maybe any ideas?
Posts: 1
Joined: Thu Dec 20, 2012 7:48 am
by msmithy12 » Thu Dec 20, 2012 8:09 am
im getting

Code: Select all
i2c i2c-0; Failed to register i2c client ds1307 at 0x68 (-16)


during the verbose boot (not sure if its classed as verbose boot, but if i can see the computers process at boot i consider that verbose)

im sure that is the error thats bumming my RTC
I assume I know what I`m talking about... I probably don`t

Home: 256mb Made in UK, Rasbmc, 40" Sony Bravia KDL-40v3000
Work: 256mb Made in China, Rasbian, 6" Lilliput touchscreen
Posts: 86
Joined: Fri Aug 10, 2012 8:57 am
by arnohr » Wed Jan 23, 2013 8:55 am
Brrr... here in Germany its actually 10 degrees below zero... soooo cold... Better play with the pi and a hot cup of tea in your hands ;-)

So I continued experimenting with the DS1308 RTC from Adafruit an tried to synchronize my "first generation" Pi (using latest Raspbian 2012-12-16-wheezy) at boot time without NTP-Server present.

At first I used the Adafruit-Tutorial and it worked great. I only needed to manually install the i2c-tools and load the needed i2c and ds1308 modules:
Code: Select all
$ sudo apt-get update && sudo apt-get install i2c-tools
$ sudo modprobe i2c-bcm2708
$ sudo modprobe i2c-dev
$ sudo modprobe rtc-ds1307

And after creating the RTC device:
Code: Select all
$ sudo -s
# echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-0/new_device
I was able to set an read the hardwareclock.
Code: Select all
# hwclock -r  // read the hardwareclock
# hwclock -s // set systemtime from hardwareclock
# hwclock -w // set hardwareclock from systemtime

But I needed to set the correct time automatically at boot time. If there was a power loss and no network connection would be available to set time from ntp-server after reboot. The correct timestamp is important, if you are collecting data from external sensors.

So I followed the instructions posted by the user psergiu. But I ran into the same problems as the user 8ctopus. After some testing I figured out, that the hwclock.sh script is saving the systemtime to hardwareclock when I reboot or shutdown the system. Great! Finally half the job is done! But why it doesn't work at boot time? The script is correctly started. I added some "echo string >> local-file" to proof it. But for some reason it wont work and I couldn't find any error message. Only after I added the modprobe commands in the hwclock.sh script I got this error-message:
Code: Select all
i2c i2c-0; Failed to register i2c client ds1307 at 0x68 (-16)

I think there is some timing problem at boot time. The System loaded successfully the modules but when it tries to create the rtc-device something needed isn't loaded or ready. I also tried to move the rcS.d script to the end of the starting order by giving it the highest number. But nothing worked for me.

As a workaround I actually use the rc.local file to synchronize the system time from hardwareclock at boot time. I load the modules in /etc/modules and also creates the rtc-device in the rc.local file:
...
echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-0/new_device
hwclock -s

exit 0


I know this isn't a very sexy solution. But I need some help to debug the init-script solution.
Posts: 27
Joined: Sun May 20, 2012 4:05 pm
by Sob » Thu Jan 24, 2013 8:23 pm
One solution is (in addition to previous steps) to comment out this block in /etc/init.d/hwclock.sh:
Code: Select all
           if [ -d /run/udev ] || [ -d /dev/.udev ]; then
               return 0
           fi

Which is hack, because the intention here was clearly to leave it up to udev.

And udev does something, it detects when RTC appears and runs the script, which unfortunately is not exactly for RasPi. From what I found, it seems that on normal PC, kernel gets the time from CMOS right at the beginning (perhaps on RasPi it would too, if RTC support was directly in kernel and not as module, I'm not sure). And later, when udev detects RTC, it only tries to adjust the time in case it was local time and not UTC. Fortunately there is simple fix, just change "--systz" parameters in /lib/udev/hwclock-set to "--hctosys".

The complete and almost clean solution which I like most so far:

1) Comment out i2c blacklist in /etc/modprobe.d/raspi-blacklist.conf
2) Add i2c-bcm2708 and i2c-dev to /etc/modules (no need to add rtc-ds1307, it will be auto-detected later)
3) Fix /lib/udev/hwclock-set (see above)
4) Create /etc/init.d/rtcdev with following content (and make it chmod 755):
Code: Select all
#! /bin/sh
### BEGIN INIT INFO
# Provides:          rtcdev
# Required-Start:    kmod
# Required-Stop:
# Default-Start:     S
# Default-Stop:
# Short-Description: creates RTC device
### END INIT INFO

. /lib/lsb/init-functions

case "$1" in
  start)
        if [ ! -e /dev/rtc0 ]; then
            log_action_msg "Creating RTC device..."
            echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
        fi
        ;;
  restart|reload|force-reload)
        echo "Error: argument '$1' not supported" >&2
        exit 3
        ;;
  stop)
        # No-op
        ;;
  *)
        echo "Usage: $0 start|stop" >&2
        exit 3
        ;;
esac

5) Enable it:
Code: Select all
update-rc.d rtcdev defaults
update-rc.d rtcdev enable

6) Reboot without network and enjoy clock with correct time. :)

The only thing I don't like is step 3, because it changes existing system file. I could make a copy, but then I would have to change /lib/udev/rules.d/85-hwclock.rules from where it's invoked. And I don't know if I can override some other way, without touching it.
Posts: 10
Joined: Wed Jan 16, 2013 4:33 pm
by Hi-Z » Thu Jan 24, 2013 11:14 pm
Here's my 'hack' to get the RTC to load properly at boot or use the NTP server.

First off ... I'll assume everyone has taken the 2 steps to get the module correctly loaded:
rtc-ds1307 .... added to /etc/modules
echo ds1307 0x68 > /sys/class/i2c-adapters/i2c-1/new_device .... added to /etc/rc.local

According to the Adafruit documentation this is all you need to do ... well, it isn't. By default, the Wheezy image has the the fake-hwclock enabled which can cause issues, so lets get rid of it.
Code: Select all
sudo apt-get --purge remove fake-hwclock


What we need now is a script to choose between the NTP servers time or the RTC. We're going to assume that the NTP server time is more correct than the RTC so it will take precedence if it's there. Since the NTP is automagically loaded on boot when we have internet, we'll presume that if we can see the internet then the NTP time has been loaded. If not then take the RTC time.
Code: Select all
#!/usr/bin/env python

# MUST BE RUN AS ROOT
# This script pings a website to see if we are connected to the internet
#  and should work regardless of eth0 or wlan0
#   -> if connected, assume that NTP set systime and update RTC
#   -> if not, assume systime is incorrect and update from RTC
#
# It should be noted that if you boot up with internet connected then
#  the os will automagically update systime but NOT the RTC
#  hence this code will update RTC when ethernet connected
#
# NOTE:  fake-hwclock may interfere if left enabled
#           sudo apt-get --purge remove fake-hwclock
#

import subprocess
import os

# Any valid website will work
website_to_ping = "www.google.com"

# ping website and get reply
ping = subprocess.Popen(["ping", "-c", "1", website_to_ping], stdout = subprocess.PIPE, stderr = subprocess.PIPE)
out, error = ping.communicate()

# We don't care what the actual reply is, only whether its a valid one or an error
#  hence we check string length to see if it is a null string
#
# We also could have used if/else since there are only two possible conditions
#
if (len(out) <> 0):
  #print out
  print "Network available, copying systime to RTC"
  os.system("hwclock -w")
if (len(error) <> 0):
  #print error
  print "Network NOT available, copying RTC to systime"
  os.system("hwclock -s")


Running the code after the kernel is loaded works no problem, but we want it to run every time the system is booted. The problem arises in that the RTC module may not be fully functional before we run the above code. I had these issues when I tried to run it during the rcS start-up process. So where should we stick it? ... Figuratively speaking, of course.

After scouring this site, I found that you can run the code after loading the desktop. This provided the delay needed to make sure the modules were properly loaded before running. The LXDE (desktop) interface is loaded via
/etc/xdg/lxsession/LXDE/autostart

And after adding my code, it looked like this:
Code: Select all
@lxpanel --profile LXDE
@pcmanfm --desktop --profile LXDE
@xscreensaver -no-splash
sudo python /home/pi/settime.py

NOTE: Network status is NOT echoed back like it would be if run from a terminal.

In testing the system, the RTC is loaded to systime when the ethernet cable is disconnected and NTP is loaded to systime and RTC updated when ethernet is connected.

Improvements to my coding are welcomed and encouraged.

ISSUES that plagued me:
It seems that my monitor was back feeding power through the HDMI port when the RPi was turned off. The effect was that it pulled down the RTC battery voltage to ~1.7volts. This was low enough to stop the clock from running when powered down. Simple solution was to disconnect HDMI cable and everything worked fine.
Posts: 25
Joined: Wed Jan 02, 2013 8:19 pm
Location: Canuckistan
by Sob » Fri Jan 25, 2013 4:05 pm
Problem with rc.local is that it gets executed way too late. Even worse with code executed after desktop loads. If you have RTC only because you sometimes use RasPi offline and don't want to set time manually, then it's probably fine. But if you need it for anything more serious, you really want to have correct time before services start. It's just wrong to let them think it's 1970, even for a short while. :)

But you got me thinking about how it is with updating time in RTC. It does happen when system shuts down correctly. But it would be definitely good idea to do it continuously, in case it shuts down unexpectedly, e.g. on power failure. If the system has few months uptime, then RTC could go noticeably off. Anyone knows if something takes care of that already? If not, then one script in cron.daily, saving current time to RTC, would probably be enough.

--

And a little correction for my previous post, two steps were accidentally left out:

1) Enable hwclock.sh service (to save time to RTC on shutdown)
2) Remove fake-hwclock
Posts: 10
Joined: Wed Jan 16, 2013 4:33 pm
by Hi-Z » Fri Jan 25, 2013 6:36 pm
Sob wrote:But you got me thinking about how it is with updating time in RTC.

Ahh ... my evil plan to get others to think is working :twisted:


From the various testing I've done, I believe the fake-hwclock saves its time on shut down. Might be good to take a look at that code and see how it's done there and apply the same logic to the RTC. I realize my solution is only a "good enough" implementation ... not the ideal way to do it, but it's solid and repeatable and works in the short term.

It should be noted that a GPS module will also function as an accurate time source however, acquisition time could be a big issue. I don't know if it'll spit out a partial string (ie time) after acquiring only one satellite or if waits until it acquires a valid position first (minimum 3 satellites). I'll be adding that time source to my code once the part arrives in the mail.
Posts: 25
Joined: Wed Jan 02, 2013 8:19 pm
Location: Canuckistan
by Sob » Fri Jan 25, 2013 8:02 pm
If you enable hwclock.sh, then it saves time to RTC on shutdown too, no problem. But clean shutdown is not always the case. For example my goal is to make RasPi into all-purpose server and only "planned" shutdowns will be when there's power outage. And when it happens, it might be months since the correct time was last written to RTC and it could drift away a little. It might not be too bad if one chooses the right RTC, for example the cute little board I got with DS3231(*) should not go off more than one minute a year, but I'm perfectionist. :)

(*) For anyone interested: http://dx.com/p/high-accuracy-ds3231-mo ... lue-168974
Posts: 10
Joined: Wed Jan 16, 2013 4:33 pm
by jfornango » Sat Jan 26, 2013 5:46 pm
So... between the AdaFruit tutorial and this thread, I've got my RTC up and running. (thank you to everyone). I just need to write a document to put everything in order so the results can be reproduced.

However, I've noticed two things that are kind of gnawing on my brain.

1> hwclock -r returns the time in UTC, but lists the local time zone.
example: when my clock says 11:32 AM Central Time, the hwclock -r returns 5:32 PM Central Time. (correct UTC time, but the offset isn't calculated in.)
Note that hwclock -u returns the correct time & time zone.

2> A little more important here - hwclock *must* be run as admin (sudo hwclock), or Raspi says
Code: Select all
hwclock: Cannot access the Hardware Clock via any known method.


needless to say, this could be problematic down the road, especially once I start coding for this thing. Anyone got a thought in this one?
I'm only wearing black until they find something darker.
Posts: 113
Joined: Fri Sep 14, 2012 7:46 pm
Location: St. Louis, MO USA
by Sob » Sun Jan 27, 2013 3:03 am
1) Check the third line of /etc/adjtime, if it contains "UTC". Also testing hwclock reads and writes with --debug option might show some interesting info.

2) It's all about permissions. You can make /dev/rtc0 owned by your user and it will work.
Posts: 10
Joined: Wed Jan 16, 2013 4:33 pm
by paulrafu » Mon Feb 04, 2013 10:06 pm
I can't set the time with hwchlock!
Everything working fine but i can't read or write the harware clock. I use ds1307.
this is my debug:
Code: Select all
pi@raspberrypi ~ $ sudo hwclock --show --debug
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1360012828 seconds after 1969
Last calibration done at 1360012828 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc0 does not have interrupt functions. Waiting in loop for time from /dev/rtc0 to change
hwclock: Timed out waiting for time change.
...synchronization failed
hwclock: The Hardware Clock registers contain values that are either invalid (e.g. 50th day of month) or beyond the range we can handle (e.g. Year 2095).


Any idea?
Posts: 5
Joined: Tue Oct 09, 2012 8:35 pm
Location: Romania
by mpl » Tue Feb 19, 2013 7:44 pm
same problem here...

paulrafu wrote:I can't set the time with hwchlock!
Everything working fine but i can't read or write the harware clock. I use ds1307.
this is my debug:
Code: Select all
pi@raspberrypi ~ $ sudo hwclock --show --debug
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1360012828 seconds after 1969
Last calibration done at 1360012828 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc0 does not have interrupt functions. Waiting in loop for time from /dev/rtc0 to change
hwclock: Timed out waiting for time change.
...synchronization failed
hwclock: The Hardware Clock registers contain values that are either invalid (e.g. 50th day of month) or beyond the range we can handle (e.g. Year 2095).


Any idea?
Posts: 32
Joined: Sun Aug 12, 2012 6:14 pm
by Sob » Fri Feb 22, 2013 6:35 pm
I would try to look around. E.g. check output of dmesg, if it contains any RTC-related errors. Or try if these show something:
Code: Select all
cat /proc/driver/rtc
cat /sys/class/rtc/rtc0/date
cat /sys/class/rtc/rtc0/time
Posts: 10
Joined: Wed Jan 16, 2013 4:33 pm
by mpl » Sun Feb 24, 2013 8:31 pm
Code: Select all
pi@raspberrypi ~ $ sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

pi@raspberrypi ~ $ cat /sys/class/rtc/rtc0/time
00:00:00
pi@raspberrypi ~ $ cat /sys/class/rtc/rtc0/date
2000-01-01
pi@raspberrypi ~ $ sudo hwclock -w
hwclock: Timed out waiting for time change.
pi@raspberrypi ~ $ cat /sys/class/rtc/rtc0/time
20:27:18
pi@raspberrypi ~ $ cat /sys/class/rtc/rtc0/date
2013-02-24

pi@raspberrypi ~ $ sudo hwclock
hwclock: Timed out waiting for time change.
hwclock: The Hardware Clock registers contain values that are either invalid (e.g. 50th day of month) or beyond the range we can handle (e.g. Year 2095).
pi@raspberrypi ~ $ sudo hwclock -r
hwclock: Timed out waiting for time change.
hwclock: The Hardware Clock registers contain values that are either invalid (e.g. 50th day of month) or beyond the range we can handle (e.g. Year 2095).


pi@raspberrypi ~ $ dmesg  |grep ds1307
[  292.946598] rtc-ds1307 1-0068: SET TIME!
[  292.949255] rtc-ds1307 1-0068: rtc core: registered ds1307 as rtc0
[  292.949300] rtc-ds1307 1-0068: 56 bytes nvram
[  292.949353] i2c i2c-1: new_device: Instantiated device ds1307 at 0x68
pi@raspberrypi ~ $ dmesg  |grep rtc
[  292.946598] rtc-ds1307 1-0068: SET TIME!
[  292.949255] rtc-ds1307 1-0068: rtc core: registered ds1307 as rtc0
[  292.949300] rtc-ds1307 1-0068: 56 bytes nvram

pi@raspberrypi ~ $ dmesg  |grep i2c
[    4.946318] bcm2708_i2c bcm2708_i2c.0: BSC0 Controller at 0x20205000 (irq 79) (baudrate 100k)
[    5.098714] bcm2708_i2c bcm2708_i2c.1: BSC1 Controller at 0x20804000 (irq 79) (baudrate 100k)
[   24.675056] bcm2835-cpufreq: switching to governor ondemand<6>[  171.891777] i2c /dev entries driver
[  292.949353] i2c i2c-1: new_device: Instantiated device ds1307 at 0x68

Posts: 32
Joined: Sun Aug 12, 2012 6:14 pm
by mpl » Sun Feb 24, 2013 10:23 pm
Code: Select all
pi@raspberrypi ~ $ cat /proc/driver/rtc
rtc_time        : 20:27:18
rtc_date        : 2013-02-24
alrm_time       : 00:00:00
alrm_date       : 1970-01-01
alarm_IRQ       : no
alrm_pending    : no
update IRQ enabled      : no
periodic IRQ enabled    : no
periodic IRQ frequency  : 1
max user IRQ frequency  : 64
24hr            : yes


okay.. i see now ..the ds1307 is not counting...

Code: Select all
pi@raspberrypi ~ $ cat /sys/class/rtc/rtc0/time
22:24:27
pi@raspberrypi ~ $ echo wait 5 sec
wait 5 sec
pi@raspberrypi ~ $ cat /sys/class/rtc/rtc0/time
22:24:27
Posts: 32
Joined: Sun Aug 12, 2012 6:14 pm
by mpl » Mon Mar 04, 2013 8:54 pm
have found tihs on the datasheet(ds1307)

Bit 7 of Register 0 is the clock halt
(CH) bit. When this bit is set to 1, the oscillator is disabled. When cleared to 0, the oscillator is enabled


but i dont know how to set this bit... im a i2c beginner can someone help me plz?

sudo i2cset -y 1 0x68........... ?
Posts: 32
Joined: Sun Aug 12, 2012 6:14 pm
by Hi-Z » Mon Mar 04, 2013 10:59 pm
Funny, I don't remember ever having to set that bit when I first got my device ... even found the reference in the datasheet and it didn't ring a bell.

I can't give you a direct answer but I will save your hours of possible frustration :D
No matter what command you send to talk to the RTC, it will fail ... [enter frustration mode]
Why?
The system has taken over control of the RTC (and being a bully, he/she/it doesn't want to share)
How do you know?
I read the documentation for i2cdetect. "UU". Probing was skipped, because this address is currently in use by a driver. ... Hmmmm, better check your previous post
You mean the act of enabling the real time clock disabled my access to it?
No to check the time ... but yes for everything else
Auuuggghhhhhhh!
It is rather ironic that enabling it actually disables it
So what can I do?
I thought it was obvious ... don't let the system take control of the RTC
And how do I do that? Stand tall in the middle of a bridge like Gandalf and command 'NONE SHALL PASS'
Pretty much like that
Waaaaa? Huh? What the heck are you talking about?
If you remember, he took out the bridge ... that's what we want to do
I get it now. Take out the bridge, so the bully can't get across and take over the system.
You're a quick learner
Alright so what's the bridge?
The SCL is your bridge. By disconnecting it during boot the system can't talk to the RTC and take it over.
And by disconnecting it, I can't talk to it either ... what's the use of that?
Well, once the system is finished booting, we can reconnect it and the device will appear as 0x68 instead of UU
And now it won't fail if I try to talk to it?
More like ... it took out its ear plugs and is ready to listen
Thanks for the help, now I can play with i2cset
I guess you could have disabled the RTC system access in software as well ... but if your system is breadboarded, the hardware method is easier.

{exit split personality mode}
Posts: 25
Joined: Wed Jan 02, 2013 8:19 pm
Location: Canuckistan
by Galaxynik » Fri Aug 23, 2013 8:26 am
playing with the hardware seems a bit drastic lol
I get the UU in device 0x68 when hwclock is working but
Code: Select all
echo 0x68 > /sys/class/i2c-adapter/i2c-1/delete_device


reverts it to 68 and allows i2c-tools to access it ......
Posts: 37
Joined: Mon Jan 02, 2012 2:55 pm
by Hi-Z » Sat Aug 24, 2013 1:00 pm
Playing with the hardware only seems drastic when you already have an alternate solution. In this case, playing with the hardware helped to isolate the root cause ... I'm really surprised it took 5 months before someone figured out how to do the same in software.

Anyways, nice find and a good share.

So does the following code re-enable the clock for use? Or do we need to reboot/re-initialize the entire sequence? I'm in the process of moving so my Pi is packed up at the moment
Code: Select all
echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
Posts: 25
Joined: Wed Jan 02, 2013 8:19 pm
Location: Canuckistan