ds1307 reading wrong

[andrefrejat]

Hello,
I have to make a simulation of a digital clock using the ds1307 and PIC18F4520, but since i'm really new at programing i'm having a lot of problems.
Now, basically when I try to read the hour and date I get it right, no problem. But when I try to increment something the ds1307 give me error like:
1-the months goes from 0 up to 19 (instead of 1-12)
2-the days up to 40
3-the hours up to 30 something....

so basically i'm reading everything wrong. Probably it's simple the answer but I really can't figure it out.

Thanks in advance.

[bkamen]

Are you simulating this with Proteus?

You did see the PIC101 Sticky at the top of this sub-forum message list, yes?

http://www.ccsinfo.com/forum/viewtopic.php?t=47549

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[Ttelmah]

The key thing here is number formats.

The clock chip used 'BCD'. Here the 4bit nibbles of a number each represent one digit.

So the clock represents months with 0x01 for the first month, counting up to 0x09 for the ninth, and then goes 0x10 for the tenth month. Now the 'reason', is that this is a very convenient format if you want (for instance), to feed the numbers to a LED display, where you can take each nibble, separate it out, and just display this as a number from 0 to 9. Problem is that 0x10, is the number 16, if treated as a normal number, so the months would count 1....9, 16,17,18 etc...

Same applies to the values the chip expects to receive when you set it.

This is where the two functions at the end of the driver you are using come in. bin2BCD, and bcd2bin. The latter, will take the number 0x10, and correctly turn it into the binary value 0b00001100, which would then display at '10' if output using printf. The former does the conversion the other way.

Use hex notation in your pre-programmed 'setting' values, so 'year=0x13', which will give the correct value to send to the chip.

When you retrieve the values, use bcd2bin, and then display the output this gives. So:

[ezflyr]

Hi,

In addition to the BCD vs. Binary issue, there are a couple of other things you should consider. If you are using real, physical switches for data entry, you need to be mindful of 'switch bounce', or the likelihood that your switch will 'chatter' when pressed and produce multiple entries. The code that increments the day has a 50ms delay, which might have been an attempt to deal with switch bounce by the original author. You need to look this if you intend to actually build this clock. If not, Proteus probably won't care, which is a major flaw of simulation. I use the 'button' function to handle switch debouncing - it works well, and can be found here on the forum.

The second thing you should consider is making your code 'aware' of valid day, month, and year numbers, etc. and deal with that correctly before sending any data to the RTC chip. For example, 'minutes' are never more than 59, so you want to add this limit to your code. Here is a little code snippet that shows the button function, and value limiting for the minute variable.

[asmallri]

You have SOUT connected to +5V

That is a good way to kill the chip. SOUT if not used should be unconnected. If you want to use it then it should connect to +5v via a pull up resistor.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[temtronic]

Good catch on the SOUT miswiring !
I've never liked anyone's 'ISIS' schematics...no power connections,bypass caps,XTAL,Vee on LCD,etc....
Also, uChip recommends series resistors on any 'switch' input to port pins to reduce blowing up the chip with static 'zaps'.

[Mike Walne]

You need to wake up to the fact that Proteus simulation is a complete waste of both your time and everyone elses.

You set a #FUSES for LP.
The microchip data sheet shows LP is intended for 32kHz watch type crystals.
Then you set a 2MHz clock.
The oscillator probably won't start.

Do yourself a favour, use REAL hardware.

Then come back if (when) there's a problem.

I don't want to sound harsh, but you have to face up to reality.

Mike

[andrefrejat]

[Mike Walne]

Whilst you persist with Proteus, I'm out.

Nuff said.

Mike

[andrefrejat]

Mike, just a quick question. Do you suggest any other simulator or simply test on the real thing?

Andre

[temtronic]

I've got about 25+ years of using PICs, and started using microcomputers back in 1977.
Over the decades I've found out the ONLY proper,rock solid, REAL 'simulation' is to cut code, burn a chip and test in the REAL world.

NO 'simulator' is capable of emulating stuff like miswired PCB,bad etches, EMI,marginal power supplies,faulty grounds,no HF bypass caps onboard,'buzz' from those new 'energy efficient' CFLs and a host of other real world nightmares.

Chips these days are real cheap,protoboards are easy to come by and frankly you'll learn more in one day getting fingers burnt and smelling solder than a month of reading books.

Some here say the MPLAB simulator is good.I can't say as I only use real chips on real noards in the real world.Maybe I'm 'odd' but I still have wirewrapped PIC 'prototypes' in use after 24 years.

hth
jay

[Mike Walne]

Temtronic has answered your question for me.

I do use MPLAB SIM.

1) Produces mostly believable results.
2) Allows you to step through code more quickly than when attached to the real thing.
3) Timings are sometimes an issue, quite often several machine cycles different to the real thing.
4) Is out of the same stable as the PICs, so fewer of the 3rd party issues.
5) It's no substitute for the real thing at the end of the day.

On the real thing you:-

a) Add diagnostic LEDs to give a visual indication of what's going on.
b) Hook the LED pins to a scope for other tests.
c) Connect the UART to a PC for commentary.

Mike


As an aside. You sometimes have to rock the boat.

I design switch mode power supplies for a living.
One of the myths in the trade is that toroidal chokes are near perfect from an EMI point of view.
(If wound as a neat single complete layer covering the whole surface.)
In practice they have winding capacitance which does resonate with the intended inductance.
At resonance you get a standing wave on the winding.
The phases of the currents are such that the whole thing behaves as a good dipole aerial!!
I was not very popular in the labs when I brought this to everyone's attention.

[Ttelmah]

You also have the other 'commonly forgotten' thing, that every wire on a board, connected to a semiconductor junction, can act as a receiver, and can also re-radiate normally odd harmonics only (because of the rectification). Delightful.....
On a different tack, everyone 'knows' semiconductor junctions are light sensitive, but then forgets that things like barometric pressure sensors, unless in an opaque casing with pipes attached, have an almost exposed semiconductor junction.

There are dozens of 'classic lovelies' waiting in the wings to catch you.

The key problem with 'simulators', is the same as in every field. Simulation, while good in many cases, is not 'reality'. Particularly with the PIC's, where the biggest problem commonly is the shear number of places where newer chips in particular 'differ' from their specified behaviour. I had 'great hopes' for Proteus some years ago, but it has been tempered with the increasing discovery of how badly it does get things wrong. Generally it takes longer to get the code working once in Proteus, then fix the problems this missed, than to do it with real hardware from the start.....

Best Wishes

[PCM programmer]

As everyone has said, it's not our job on the CCS forum to fix Proteus
problems. But if you would just use Google to search for

[RF_Developer]

Please ask your professor to comment here, giving us their justification for insisting on the use of Proteus by their students. I suspect the primary motivation is cost, on the somewhat misguided notion that software $£€ are somehow cheaper than hardware $£€.

I am serious: I want to know why students are being forced to use an inappropriate and inadequate "tool".

Proteus, apparently - I haven't used it personally - is useful for other projects. Its with PICs and the ICs they interface with, that it really falls down as the differences between its simulation and reality are often too far apart and cause a lot of additional work - just the sort of additional work simulation is supposed to eliminate! - as the simulation will work when real hardware doesn't and just as bad, the simulation will fail when real hardware would work fine.

RF Developer