Matching time conditions

[Melanie]

After all, this is a forum on PicBASIC Pro. I guess I should of registered at Maxim's forum (assuming one exists) to ask for technical assistance with the data format from the DS1307.

Just do as you're told and download that Datasheet!

Then, and ONLY THEN you will be able to compare that I2C Statement with the DS1307's Registers. IT IS the Rosetta stone... until you've looked you won't see it.

I'm NOT being iffy or off-hand with my answer to your query... I'm actually telling you EXPLICITLY that IT WILL HELP YOU UNDERSTAND.

Skip all the crap and jump straight into the section on the Registers... look, it's all laid out crystal clear - it shows you what sequence they're in, how they're addressed, what's inside them... how on earth can you possibly understand what's going on in a piece of code if you don't understand what a particular BYTE of DATA has got inside it at any point in time.

If I told you that Bit 7 of the SECONDS Register was kinda IMPORTANT - How would you know? I could be talking Greek (sorry Ioannis)!

One look, and you know what the $D0 is all about in the I2C Statement. And what about $00 - what's it there for? The answer is screaming at you from the pages of the PBP Manual description of the I2C Command, and the DS1307's Datasheet. The two of them go together hand-in-hand. There's NO other secret document, no Training Course in Electronics or programming... just those two items together allow you fully understand, manipulate and control that chip. Don't handicap yourself unnescessarilly by dismissing it's 'beyond' your understanding. The DS1307 is a simple chip. But more importantly it's a stepping stone on the path to progressing to more complex hardware devices.

Armed with that information, THEN come on the forum and ask your questions. Then folks can point you as to WHY something is the way it is. YOU ASKED about accessing Data out of sequence... that $00 holds the key, and that Datasheet tells you what you should change it to if you wanted just to extract say HOURS. But if I simply said you change it to $02, my answer would be totally meaningless unless you knew WHY!

That is WHY I really PUSH folks to TRY and get to grips with Datasheets. The Ds1307 only has a dozen pages or so, and a chunk of those are irrelevant, so it's not like I'm asking you to digest Tolstoy's War & Peace.

[malc-c]

... And what about $00 - what's it there for? The answer is screaming at you from the pages of the PBP Manual description of the I2C Command, and the DS1307's Datasheet. The two of them go together hand-in-hand.

Mel,

Bear with me on this as I'm sure quite a few of us still have difficulties in getting our heads round bits and bytes and registers etc. But to try and answer your question and see if I've got some grips with the data sheet, here's my take on the above.

$00 is the start of the register address (00H). This byte stores the seconds, bits 0-4 for the digits and bits 5-7 the 10's. The next byte (01H) is the same but for mins. 02H stores the hours, with bit 6 setting the device up for 12/24 hrs depending if set high or low. Bits 0-2 of 03H stores the days, 04H date, 05H month, 06H year (1st 4 bits for digits, last 4 bits decades).

The only part I don't grasp is the $D0 part - The manual stated

I2CREAD DataPin,ClockPin,Control,{Address,}[Var{,Var...}]{,Label}

so in the code I have

I2CRead SDApin,SCLpin,$D0,$00,[RTCSec,RTCMin,RTCHour,RTCWDay,RTCDay,RTCMonth,RTCYear,RTCCtrl]

which transpires as datapin, clockpin, then control. but the only control reference I can find in the data sheet is for SQW (square wave out), and I'm still at a loss as to where you arrive at the $D0

[malc-c]

The only part I don't grasp is the $D0 part -

OK now got it...

from the datasheet The address byte contains
the 7 bit DS1307 address, which is 1101000, followed by the *direction bit (R/W ) which, for a write,
is a 0.

I used a binary to decimal / hex convertor.... 11010000 is D0, therefore the $D0 is the address which the PIC looks for to locate the DS1307 on the I2C buss and sets the DS1307 to either receive data or to send it ?

[Melanie]

You've nailed it Malcolm.

I know I was a bit hard on you, but now you see how simple it all is with that Datasheet and how near impossible it is to understand without.

[malc-c]

Thanks...

Although I now have an understanding of how the DS1307 is accessed and what the registers are... I'm still a long way from understanding a 300 + page data sheet on one of the more complex PICs !, and I must confess I'm still at a loss on how to use the 1307 to match a value in the code an in turn set a value of a variable.

I assume that each byte for each register (01H, 02H etc) is converted from binary into BCD (which I gather is 4bit type code format of binary)... or does pbp simply read each byte at each register.

I guess the simple answer is to wait until I receive the new chip with the alarm function and use that ?

[Melanie]

The I2CRead command will simply grab the content of each Register.

With the DS1307, you find that bit 7 in some of the registers is used for odd things. So, stripping that out, the first four bits (0-3) is the units digit (in binary), and bits 4-6 is the tens digit (in Binary). Which is why they fiendishly called it Binary Coded Decimal.

You've noticed it's in BCD. The first thing is to convert it to something that is useable. So I end up with a single variable that is HOURS, another variable for MINUTES etc. It's easier to have a single byte whose content varies from 0 (zero) to 59 representing MINUTES, because then you can perform math on it directly.

If your Alarm time is stored in the PIC (say your morning alarm at 07 Hours and 15 Minutes) it's a simple matter to compare if those two variables (say ALARMHour and ALARMMinute) match what you've read from the RTC (after converting from BCD). I tend to ignore seconds because unless you're polling better than once a second (or have a hardware interrupt on receipt of the SQUARE wave the RTC can output), or if your code is sloppy, you can easily miss one second.

If you're really clever, you can convert the Date and Time to JULIAN Date & Time, which gives you a single variable which holds a linear combination of Year, Month, Day, Hour, Minute and Second. Now this is great, because then you can simply add 3600 to advance an hour etc etc. There's another thread somewhere on this forum where I did just that with another DS series chip (albeit some years ago). This is the method I choose to use for things like Alarms with a DATE attached (eg Central Heating Timers), whereas Alarms with just TIME (such as your bedside radio's) usually comparing Hours and Minutes suffices.

[malc-c]

Mel,

Thanks for that explanation. I've been watching the US Masters on TV so it's just coming up to midnight here in the UK, so will look at your suggestion tomorrow after work.

If your Alarm time is stored in the PIC (say your morning alarm at 07 Hours and 15 Minutes) it's a simple matter to compare if those two variables (say ALARMHour and ALARMMinute) match what you've read from the RTC (after converting from BCD).

Which is basically what I'm after. I intend to have an ALARMHour1 and ALARMHour2 to set an on time and off time to monitor.

Thanks once again for the push to try and understand these data sheets. It's somewhat clearer now