Reading & write to RTC 12887 ?

[exxos]

The control register seems to set 12/24H clock and DM for binary encoding..

cr.JPG (11.71 KiB) Viewed 3827 times

I currently have..

%00000010

So bit 1 high must mean 24H mode (hours do output 16 so must be in 24H mode currently)
DM bit 2 is low, low = shit encoding mode. So will see if I can flip it to binary mode....

[exxos]

That's because it binary coded decimal.

I'm just calling it shit mode

[exxos]

I have now set it to %00000100 for binary mode and 12H.. the values are stored (rebooted from power off to make sure) but its not changing anything time wise.. still showing 16 for the hour.. it does say I need to reinitialise for settings to work, but doesn't seem to say how to do that

EDIT:

I programed the clock to 11 Hours, 59mins, 0 seconds.. but oddly it set to 41mins.. then at some point shortly after it jumped to 12 hours, 0mins.. and now the AM/PM has changed to "-1" aka True (or logic 1) ... So not really sure its accepting being programed in binary

EDIT2:

OK probably need to change my code now I changed the format

[exxos]

Theres some good mistakes in the STOS manual.. confused the hell out of me this one... See who spots them ... (BCLR)

IMG_4412.JPG (172.83 KiB) Viewed 3809 times

IMG_4413.JPG (195.79 KiB) Viewed 3809 times

[exxos]

AM 11:59:59 to
PM 140:0:0

I've invented the 140 hour day!

IMG_4414.JPG (224.05 KiB) Viewed 3805 times

Guess I should clear out bit 7

[JezC]

Elements of this look very similar to using the NXP PCF8563 RTC that we use in our products... except that only uses BCD.
It has the same issues with upper (unused) bits in some registers reporting seemingly random values as the seconds/minutes values change.
What really makes it a complete swine is the I2C interface on top of the above.
You have my sympathy... hope you beat it into submission soon.

[exxos]

It has the same issues with upper (unused) bits in some registers reporting seemingly random values as the seconds/minutes values change.

Yeah I read something about that in the pdf.. looks like I need to check a "ready bit" before doing anything.. will get there in the end

[exxos]

Behaving now

Gonna have to poke around in the NVRAM next me thinks...

IMG_4416.JPG (214.03 KiB) Viewed 3789 times

[exxos]

Dang it.. need better software.. oh this gonna keep me busy for a bit.. well I'm cheating..so...

0000.jpg (119.77 KiB) Viewed 3780 times

[exxos]

Got a reply from Maxim finally.. Though kinda worked it out myself now..

R//W should be a 1 when preparing to Read from the address to be latched on the falling edge of AS latches the address state. R//W should be a 0 when preparing for a Write. The state of R//W should be set by the time of the falling edge of AS.

Your assumption is correct, the first part of the cycle is to set the address. The second part of the cycle is the read (for R//W=1) or write (for R//W=0).

Motorola bus timing has two parts, first setting the address then the data access. You can latch the address, using the falling edge of AS, while /CS is inactive high. To access data (read or write) you will need to drive /CS low. As long as the AS pin remains low, the address should remain latched. A rising edge on AS clears the selected address. Since you have latched the address on the previous /CS cycle, and since AS has not changed states, you should be able to process a read/write command (depending on your R//W state) on the subsequent /CS pulse.