Interfacing 20x2 to that blasted DS1302 chip

I going nuts here trying to interface a PICAXE-20X2 to a DS1302 (I know the 07 is easier via I2C but I have my reasons for using the 02, besides I bought 10 so I'm determined to use the damn things).

There seems to be no real guidence specifically for using the HSPI pins on the 20X2 (not to mention a specific 20X2 manual) and I can't find any code other than for the 08M which I just cannot convert. Do I have to use a crystal for example?? What are the correct hspisetup settings to get this to work??

I am a fairly accomplished electronics geek and hate to have to admit defeat here but there it is. All I need, please, is the very simple hook up and cut down code example and I'll take it from there - I can then come in from the windowsill.

Yes, I am running the correct version of the software and hav swopped out both chips just in case. Here's my pathetic attempt.....

To sum up....aaaaagggghhh!!!

Thanking you in advance dear reader.

'************************************************************
'Filename: DS1302_20X_Test
'Date: 01/12/2009
'File Version: V1.0
'Written by: N.Reburn
'Function: Write and read test to DS1307
'Target PICAXE: 20x
'************************************************************
'Pin B.0 =
'Pin B.1 = 24x8 LCD
'Pin B.2 =
'Pin B.3 =
'Pin B.4 =
'Pin B.5 = HSPI SDI to DS1302 leg 6 ---\
'Pin B.6 = |
'Pin B.7 = HSPI SCK to DS1302 leg 7 |-- Joined
'Pin C.0 = |
'Pin C.1 = HSPI SDO to DS1302 leg 6 ---/
'Pin C.2 =
'Pin C.3 =
'Pin C.4 =
'Pin C.5 =
'Pin C.6 =
'Pin C.7 = RST to DS1302 leg 5
'------------------------------------------------------------
; DS1302 RST Connection
Symbol RST = C.7

; LCD Connection
Symbol V_LCDPort=B.1
Symbol V_LCDData=N9600_8

;Time Variables
Symbol V_Year =B21
Symbol V_Day =B22
Symbol V_Month =B23
Symbol V_Date =B24
Symbol V_Hour =B25
Symbol V_Min =B26
Symbol V_Sec =B27
Symbol V_RTCon =B28

; Initial Times
V_Year=$99
V_Day=$06
V_Month=$07
V_Date=$16
V_Hour=$08
V_Min=0
V_Sec=0

'------------------------------------------------------------
PAUSE 100
SEROUT V_LCDPort,V_LCDData,(92,74,0,1) 'LED On
SEROUT V_LCDPort,V_LCDData,(92,64,32,48)
PAUSE 10
SEROUT V_LCDPort,V_LCDData,(92,66,32,34," Quantum InfoTech Ltd ")
SEROUT V_LCDPort,V_LCDData,(92,66,32,35," DS1302_20X_Test ")
SEROUT V_LCDPort,V_LCDData,(92,66,32,36," (C) 2010 ")
SEROUT V_LCDPort,V_LCDData,(92,66,32,37," V 1.10 ")
PAUSE 100
SEROUT V_LCDPort,V_LCDData,(92,74,0,0) 'LED Off
PAUSE 3000
SEROUT V_LCDPort,V_LCDData,(92,64,32,48)
PAUSE 100
'************************************************************
Gosub DispReset
Gosub Setup
Gosub Settime
Main:

Do
Gosub GetTime
'Pause 1000
Loop

End
'************************************************************
SetUp:

SEROUT V_LCDPort,V_LCDData,(92,66,39,39,"Setup...")
PAUSE 500
Input B.5
Output C.1
hspisetup spimode11e, spifast
'hspisetup spimode11e, spimedium
'hspisetup spimode11e, spislow

Return
'************************************************************
Settime: 'set the time

SEROUT V_LCDPort,V_LCDData,(92,66,39,39,"Set time >>>>")
Pause 500
High Rst 'enable data tx
'hspiout($8e,0) 'enable write
Low Rst 'reset RTC
High Rst 'ready for tx
'write all 8 RTC registers in burst mode
'hspiout($be,V_Sec,V_Min,V_Hour,V_Date,V_Month,V_Day,V_Year,0)
Low Rst 'reset RTC

Return
'************************************************************
Gettime: 'read the time from the RTC

SEROUT V_LCDPort,V_LCDData,(92,66,39,39,"Get time <<<<")
Pause 500
High Rst 'ready for tx
hspiout($bf) 'Read all 8 RTC registers in burst mode
hspiin(V_Sec,V_Min,V_Hour,V_Date,V_Month,V_Day,V_Year,V_RTCon)
Low Rst ' Reset RTC
SEROUT V_LCDPort,V_LCDData,(92,66,39,37,V_Date,"/")
SEROUT V_LCDPort,V_LCDData,(92,66,42,37,V_Month,"/")
SEROUT V_LCDPort,V_LCDData,(92,66,45,37,V_Year)
SEROUT V_LCDPort,V_LCDData,(92,66,39,38,V_Hour,":")
SEROUT V_LCDPort,V_LCDData,(92,66,42,38,V_Min,":")
SEROUT V_LCDPort,V_LCDData,(92,66,45,38,V_Sec)

Return
'************************************************************
DispReset:

'Add no scroll etc here
SEROUT V_LCDPort,V_LCDData,(92,66,32,32,"Date : / /")
SEROUT V_LCDPort,V_LCDData,(92,66,32,33,"Time : : :")
SEROUT V_LCDPort,V_LCDData,(92,66,32,34,"Sgnl :")
SEROUT V_LCDPort,V_LCDData,(92,66,32,35,"Sats :")
SEROUT V_LCDPort,V_LCDData,(92,66,32,36," ")
SEROUT V_LCDPort,V_LCDData,(92,66,32,37,"Date :")
SEROUT V_LCDPort,V_LCDData,(92,66,32,38,"Time :")
SEROUT V_LCDPort,V_LCDData,(92,66,32,39,"Stat :")

Return
'************************************************************

Please see this firmware issue for version C.0 - you need an extra 'output' command.

ISSUE - CORRECTED ISSUE WITH HSPISETUP COMMAND
The hspisetup command does not configure the pin B.7 as an output.
To workaround the issue add an 'output B.7' command directly after the hspisetup command.
Fixed in vC.1

Tried that....

Yes it was C.0 and I have added your line as described - it now hangs inside the GetTime procedure.

Do I have it connected correctly should I be using B.6 and C.1 to the IO of the DS1302 and what else can I do but common them together?

Also do I need a crystal and have you seen the settings for HSPI?

Thanks again for helping me.

Do you need a crystal for what?
The 20X2 - NO, the DS1302 - YES.

>> Do I have it connected correctly should I be using B.6 and C.1 to the IO of the DS1302 and what else can I do but common them together?

You can do this but must use a resistor (1k). If you do not you can short out and damage either device when they are both outputs.

Connect the resistor between SDO on PICAXE and the chip data pin
Connect SDI on PICAXE direct to the chip data pin.


>> Also do I need a crystal and have you seen the settings for HSPI?
Yes, essential

Ok tried that...

Sorry yes, I was talking about the crystal on the PicAxe (which I don't have) not the DS1302 which of course must have it.

Have placed the resistor in the circuit as you suggest even though there is never a time when they are both high (and if they were they'd be at the same potential anyway wouldn't they?) - still hangs at the GetTime procedure.

I have tried all of the speed commands too and they make no difference.

To be clear this is how I have this connected.

DS1302 To PicAxe
SCLK C.7
I/O B.5 and C.1 (via 1K)
RST B.7

Surley someone out there has one of these working to a PicAxe 20x2 ?

Thanks again for your suggestions.

It could be that the I/O pin in the ds1302 or the hspioutpin in the picaxe has burned, since you mentioned not having the 1k resistor in there before. Not sure though, why it would make it to hang up on hspiin command.

After initiating a read command from the picaxe, the i/o in the 1302 will turn output, and if you have no resistor in between the chips, one (or both)of them is going to give up, with the picaxe MOSI pin being low and i/o on the 1302 being high.

Interfacing 20x2 to DS1302

Do you have the resistor inserted as per the attached.

Also, you might also consider reading the stickly Read Me First! post at the start of the active forum area and using the [code] and [/code]
markers around you code so that it appears in a small sub window for those who wish to read it ut easly scrolled past by others.

New chips and all...

Hi,

Right I've done all that's has been suggested, 1k resistor etc and have changed out both the PicAxe 20x2 and the DS1302 and it still won't work!

I have added some more lines that report out to my LCD and I can see that the SetTime seems not to cause a problem it's just the hspiin call in GetTime that fails. When it does the PicAXE just goes back to the start of GetTime and fails again at hspiin - it does this all day!

If anyone can give me a hookup and sample code to do this I'll transfer £10 to them via PayPal.

Thanks again you brainy people you!

Here's my code again with the code formating etc - sorry about that....

I would recommend reducing your code to a bare minimum, simply read some byte(s) out of the device and get that working using SERTXD to Programming Editor Terminal, then move to more complex things.

I'd also suggest only using DOUT from the device if that's possible, certainly using separate lines for DIN and DOUT to PICAXE, maybe going to bit-banging SPI. The prototype doesn't have to match the final requirements. Get it working, move towards final required hardware, then simply drop the code in the final application program. To start you don't have to make it work as it should, just prove that it does work.

Having an oscilloscope or logic analyser will help you see what is happening, bit-banged SPI will let that run slowly enough to see using a PC Sound Card scope or even an LED at very slow speed.

Tried that before this...

Thanks for that - yes this is just the cut down version all it's doing is setting the time and reading it back, the rest is just so I can see the results on a LCD screen.

I started out doing the bit banger thing and moved to this as the PicAxe documentation suggests doing it this way!!!

Anyway I have now slowed the whole thing down and can see that it's not faling it's just actually not getting values back from the DS1307.

Do I have the right speed in HPISETUP command do you think?

The DS1302 has been one of the hardest chips I've had to get working.

Bit-banged on a single bi-directional I/O wasn't overly hard but took some time doing it incrementally, getting one thing working then on to the next. It doesn't help that the datasheet timing waveforms don't actually match the description except with a wide stretch of the imagination.

Moving to HSPI was another matter, especially trying to correlate what the actual timing waveforms are with what the PICAXE needs to do it. I'm not convinced the DS1302 is wholly compatible with the PICmicro SPI hardware but it seems to work in practice. Particular problems are -

* Data is present on the bus before the clock is asserted, and disappears when asserted, yet PICmicro only samples on clock assertion edge.

* Bit order of transfer is reversed. DS1302 wants LSB first, PICmicro wants MSB first which is the de-facto standard.

* The 1K trick connecting SDO and SDI to the common IO pin of the DS1302 doesn't work, had to resort to a diode.

I think it fair to say all the problems stem from the DS1302 design rather than PICAXE or 20X2 HSPI; it simply doesn't conform to how a 'normal' SPI peripheral would be expected to.

Anyway, can read and write registers, can see the clock ticking along. Still have to write something which can set and read the time efficiently and be easy to use in a program. That's for tomorrow or some time.

Time for bed said Zebedee.

Here's my understanding of the DS1302 SPI timings and my rationale for saying its design may make it 'technically unusable' with PICAXE and PICmicro hardware SPI.

The descriptions below refer to various transitions indicated in the timing diagram attached. The attached is what I have determined operation to be from the description within the DS1302 datasheet and in getting the DS1302 to work with bit-banged code and using hardware SPI. It is interesting to contrast with the timing diagram within the DS1302 datasheet.

Byte Write

Byte write and burst byte write is compatible with SPI, it is compatible with PICmicro and PICAXE hardware SPI except that the data is transferred lsb first when the hardware sends msb first ( the de-facto standard ). This can be resolved by reversing bits in the byte before sending.

The CE line ( also called RST in other documentation ) is raised to reset and initialise the DS1302. Data is put out on the SDO output line, SCLK is raised (A), the DS1302 samples the bit at that time, SCLK is lowered (B) and we move on to the next bit. SDO only needs to be present across the rising edge of SCLK (A), it can therefore be changed either before or after the falling edge of SCLK (B).

This repeats for eight pulses of SCLK to transfer the eight bits of address byte. It is repeated again to transfer eight bits of the data byte to write to the address specified. In burst write mode, it is the same with extra eight SCLK pulses transferring each additional byte of data. When finished CE is lowered.

Byte Read

Byte read and burst byte read is not compatible with de-facto SPI, it is not compatible with PICmicro and PICAXE hardware SPI but can work, perhaps more by 'luck' than anything else. It can be fairly easily bit-banged, the issue relates to what hardware SPI expects and what the DS1302 delivers ( see next section ).

The initial transfer of the address to the DS1302 commences as for a byte write and is identical up to the last address bit clocked out.

ON the rising SCLK of the last address bit (C) the DS1302 samples that bit and has a complete address byte received. On the falling edge of SCLK (D) the DS1302 turns its common data I/O line to output and puts the first bit of the data it is returning on the line.

In this case, the SDO output from the PICAXE must have been removed ( SDO tristated ) before SCLK falls (D). If it does not then there is a collision on the line with both PICAXE and DS1302 outputting to it.

The PICAXE should read the data bit returned on SCLK falling (D), then raise SCLK (E) at which point the DS1302 tristates its I/O until SCLK falls when it puts out the next bit to return. After eight falling edges of SCLK the returned data will have been read. This equates to 15 ( not 16 ) SCLK pulses in total. In burst read mode an extra eight SCLK pulses are issued to read each subsequent byte returned. When finished CE is lowered.

Conflict with hardware SPI

The main conflict comes with the DS1302's dual use of the SCLK pulse which writes the last bit of the address. The rising edge of SCLK (C) writes the last bit, the falling edge (D) returns the first bit of data. Most SPI devices would not return data until the rising or falling edge of the next SCLK pulse.

Looking at the DS1302 Function and PICmicro function entries at the bottom of the diagram it is clear to see the mismatch between how the DS1302 performs and what the PICmicro expects. This mismatch would IMO occur with most hardware SPI regardless of microcontroller.

The PICAXE and PICmicro hardware SPI cannot be configured so it captures the data output by the DS1302 on the falling edge of SCLK (D) as it is still in an outputting byte phase ( HSPIOUT ). The data can be clocked in on a subsequent rising edge of SCLK (E) and this appears to work, however by design or by luck is unknown. If the real world were perfect, 'infinitely fast', the SCLK edge would simultaneously clock the data into the SPI hardware as the DS1302 were tristating the line. Reading the data would then depend on data line retention, how long the correct data remains on the line due to capacitance of that line. In practice it is likely the hardware SPI samples the line when raising SCLK and DS1302 makes the line tristate just after. Whatever the reason, raising SCLK does in practice capture the previous data put out, at least in my testing.

There are two other conditions of note.

The need to tristate SDO output after the rising edge of SCLK for the last address bit (C) and definitely before the falling edge of SCLK (D). If not, there is a collision on the line with both PICAXE and DS1302 outputting to it. It is not clear from Microchip datasheets that the SDO line is tristated as required or simply becomes undetermined, high or low. Adding a 1K between SDO and DS1302 common I/O would mitigate the issue but that does not appear to work ( this requires further investigation ).

A diode ( cathode towards the DS1302 ) can be used but does not prevent a PICAXE high and a DS1302 low from being output simultaneously.

This collision may last not only for a short period, but the time it takes the PICAXE interpreter to complete its HSPIOUT command and have begun executing the function of the subsequent HSPIIN command.

That hardware SPI requires the generation of eight SCLK pulses results in an additional SCLK pulse which the DS1302 is not expecting ( except within burst reads ) and on the SCLK falling edge (F) causes it to output an additional bit of information. This does not appear to be detrimental to DS1302 operation but has not been fully examined.

Confusion Within DS1302 Datasheet

First there is, the easy to miss, matter of there only being 15 SCLK pulses in total for a single byte read when 16 would be expected.

Secondly, the upwards arrows on SCLK mean "DS1302 samples IO", while the downwards mean "DS1302 outputs at this time", rather than "PICAXE should sample at this time".

That DS1302 outputs on falling SCLK is not clear as the diagram shows a distinct delay between falling edge and data output changing.

That leads to the impression that the previous data will be valid on the falling SCLK.

There is no indication that the DS1302 is tristated ( making data on the line 'invalid' ) on the rising edge of SCLK.

Conclusion

The DS1302 works perfectly well with bit-banged code and appears to work with hardware SPI though whether electrically safe or not has not been determined.

The issues IMO come down to DS1302 design rather than any failings of the PICAXE or PICmicro hardware SPI.

Because of the above issues, including the need to reverse bit orders for transfers, and given the easier nature of interfacing, less I/O pin usage and not much larger code, I would personally recommend using the DS1302 in software-driven bit-banged mode rather than using hardware SPI.

Attachments

My Determined Timing Diagram (Left) / DS1302 Datasheet Diagram (Right)

Attachments

Microchip SPI timing (Left) / What I'd expect as SPI device timing (Right)

Expected would match what Microchip supports ( except shows transfers lsb first )

I haven't read all of hippy's thesis above, but I've always had to use soft (bit-banged/bashed) Shift style comms to get 1302 to work.
Some clever chap on another Forum claims to have to it working fine with hardware SPI but I can't confirm that and I lost patience trying.

Ages ago there were some listings of BS2 to DS1302 using Shift..., they may be adaptable.

I've got a 20X2 working with HSPI but, as said, I'm not that confident about the circumstances in which it runs.

Looking over previous DS1302 bit-banged programs it seems they have some weaknesses, don't implement full functionality, or don't comply with the datasheet - apologies if anyone feels their code is being unfairly slighted as I haven't studied all programs nor in depth and they may well be perfect.

I can understand why code may not be perfect because it's not the easiest of datasheets to follow. I've spend over 12 hours so far understanding it, getting it work, testing it, documenting the issues, and still haven't got to code which can be easily used.

I will produce 'definitive' bit-banged code and HSPI code ( use at ones own risk ) here when I've got it to a satisfactory standard.

I have yet to pose a question in here - but it's already clear that you guys provide an amazing level of tech support in return for a couple of bucks spent on a PICAXE chip. After spending hours just trying to get through to tech support at other companies you (at least partially) restore my faith in business. Thank you.

I've already suggested the PICAXE series to a couple of my friends as the way to go for micro-controller projects.

It's Alive !

Finally, working code for bit-banging and using HSPI. I'll check it later with other than 20X2 then post in the Code Snippets forum.

The 1K trick began working again so I can only presume that it was a dodgy breadboard connection or a broken wire. Under these circumstances I'd say the HSPI version is electrically safe to use, so pick and choose between either code.

Looking at it, it all seems so simple now

Added : Latest code can be found in Post #23 over the page

Finally for today ( as there's not much left of it ), some timing. Time taken to do a ReadClock without any display ...

Bit-Banged : 320ms
HSPI unoptimised : 100ms
HSPI optimised : 34ms

And that's as fast as it's likely to get. Could get it down to 16ms if the bits did not have to be reversed on each read.

There a couple of cosmetic bugs in the released code, and maybe a more significant bug with register addresses in SetClock and ReadClock. Will update code later.

Big Thankyou

Well what can I say?

What a comprehensive analysis, so much information and effort and I've only been offline for 24 hours.

Firstly I echo John's comments and thank you hippy for your determination in resolving this issue (and the other thread we have going). I wish I could buy you a beer or something!

I almost feel bad for wanting to use this damn DS1302 but I have good reason honestly. I tell you what though, in a way I'm glad it wasn't easy to resolve because I was felling pretty pathetic. And having read your various returns it does look as though something is wrong with the spec. Also if it took you 12+ hours to resolve, I may have spent the rest of my natural life trying!

I'm am going to go back to big-banging and try to implement your code as I think that looks the most robust method and I'll keep you posted on this thread.

Again, many, many thanks.

Hi Reburn; I'll email you seperately with an official response to your previous query to Rev-Ed to which this relates.

Looking back at it, it shouldn't have been hard, but was. Than again, that's how it usually goes with anything which 'should just work' but doesn't necessarily, throws up oddities and so on. No worry though as it was an interesting challenge despite the frustrations. It's actually a nice chip and I'm sure others will be interested in using it so it's all been useful.

Having got the '1K trick' to work I'm much happier to say that the DS1302 does work with PICAXE HSPI than I was earlier. I'd now recommend HSPI over bit-banging because it's about ten times faster.

I've been commenting the code and will merge bit-banged code and HSPI into one program example and hope to have that posted soon.

Overtime!!

Hi Hippy,

Brilliant it works fine here bit banging away and writing the clock to the scratchpad now which the Atom reads, and clips off the LSB, but I'll do some further digging.

I'll get back to you on the distance testing once I've sorted that bit out.

By the way, what the hell are you doing working on a Sunday????

Thanks again,

Nigel R (UK)

P.S. - I'll try the HSPI method as you suggest sometime but this actually this works fine now and I saves a pin too.

20X2 Program Code

Latest 20X2 program code attached which does bit-banging or HSPI - Change the #Define as appropriate. This replaces previous code releases.

By the way, what the hell are you doing working on a Sunday????

Too cold to go out and the snow hasn't totally shifted from yesterday - I seem to have missed the forecast for that little surprise ! Nothing on TV.

Besides, spending half my life 'faffing about' with PICAXE and electronics and entertaining myself, getting things to work as a hobby, it all blurs together; I think of it as getting paid for what I enjoy doing. I can make louder 'banging head on desk' noises at home. Well maybe "can" isn't true, but it raises less eyebrows

Edit : See later posts for code.

hippy said:

HSPI optimised : 34ms - And that's as fast as it's likely to get. Could get it down to 16ms if the bits did not have to be reversed on each read.

Click to expand...

Then re-remembered there's a REV operator on X2's to do bit reversal which cuts the code down, speeds it up, and more importantly allows the rest of the code to be rewritten so it's much clearer and runs faster, and full advantage of HSPI can be had.

Voila - Latest version with HSPI running ReadClock in 12ms. That's 26 times faster than the bit-banging version.