Ds1302 and unmime64

christopher

My application will require one cog interfaced to a DS1302 RTC/calendar and another cog to a GSM Modem.

Can anyone help with DS1302/Propeller code ? Also can anyone direct me to a source where I can obtain an algorithm to decode mime64 mail format so I can program the cog ?


Thank You

Christopher

Robert B

I am also interedsted in using the DS1302 with the propeller chip, I am new to programming and dont know yet how to port the code from the BS2 to Spin. I may also be looking for a good spin or assembly programmer to help with a project I am working on.

inservi

Hello,

I already used writen some routine for controling a DS1302 but in CCS C for microship. I planed to migrate my code to the Propeller envi. As it's interesting for other people then i will do that now. Let me some days for make the convertion.

dro

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
in medio virtus

inservi

Hello here is the DS1302 driver with little demo.

dro

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
in medio virtus

Robert B

Thank You inservi, I will try your demo and report back to you.

Robert B

ha, wrong emoticon, these silly things

inservi

Hello,

I just seen that the new version of propeller tools 1.052 is available. With it, Parallax give sample code and driver for the DS1307 real time clock. It is very similar and a few better than with the DS1302.

dro

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
in medio virtus

JTC

I tried the DS1307 demo and I am missing an object file. The one that generates the clock for the chip.
Does anyone have it?

Jim

Robert B

The 1307 has a different pinout configuration than the 1302, unfortunately I already commited to the 1302 in my board design, if there was an easier way than creating a daughter board to use the 1307 I would. Next version I may switch.

Robert B

JTC said...
I tried the DS1307 demo and I am missing an object file. The one that generates the clock for the chip.
Does anyone have it?

Jim

Here you go Jim, I found this on another thread somewhere. The naming scheme didnt match exactly but it seemed to work fine.
·· coded by Beau Schwabe (Parallax)

Beau Schwabe

JTC,

you said...
I tried the DS1307 demo and I am missing an object file. The one that generates the clock for the chip.
Does anyone have it?

Can you point me to the DS1307 demo you are referring to so that I can "fix" this? The 'object' that generates
the clock is the 'Frequency Synthesis' located in the Propeller Object Exchange.

Edit

Here is the DS1307 Demo... I double checked, and the files are intact.
The TOP file for this demo is DS1307 DEMO

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 1/22/2007 4:52:24 AM GMT

JTC

· Is it acceptable to share the memory I2C control line with the DS1307 time chip ?

Thanks

Jim

Beau Schwabe

JTC,

Both are I2C, however, the Propeller drives the CLK line HIGH and LOW for the memory rather than allowing the HIGH to be pulled with a pull-up resistor.
In most cases this would be fine, but for slower I2C slave devices this could cause a problem.· The I2C protocol allows slower devices to "hold" or drive
the clock line LOW in order to throttle the speed of the Master.· Since the Propeller drives the line HIGH, and another I2C device could potentially hold
the same line LOW there is a problem.
·
You can use a 330 Ohm resistor on the CLOCK line as a current limiter (10mA) to your other I2C slave devices and it should be fine.· Also you can add a 10k
pull-up resistor.· This would allow you to read and write to a slave device (even the Propeller memory) without needing to drive the pin HIGH.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Robert B

inservi said...
Hello here is the DS1302 driver with little demo.

dro

Hello Inservi

I have tried your interface and the clock is doing funny things, the seconds count up past 60 as well as the minutes sometimes skipping numbers. For example right now my display is showing 00:71:65 and will counts as high as 89 then reset to 00. I used your demo as an example except I changed it to use the LCD instead.

Robert

inservi

Hello Robert,

I well read your description. I'm surprised. I must investigate because after finishing the translation from C to spin language, I make some test and all was perfect for some hours. The C version is working in a project from more than one years with no problems.
The only change in behaviors is at timing level because the C running in a Microchip µC can control delays of 2 µsec or less and the spin language cannot control so short delays.
But a slowest clock it is not a problem for the DS1302 (I hope).

do you obtain sometimes or often the good hour ?

---

Question for other readers ----
Did someone else test this object and get similar problems ?


dro

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
in medio virtus

rtowler

I see the same issues that Robert sees.

I'm no expert, but if I am reading the code right you're reading in the bits of each register as if they all represented a "straight" value when in fact they don't. For example, the first 4 bits of the seconds register represents secs, the next 3 10's of secs, and the last is chip halt which we can ignore. The way you read in all of the register values is like so:

<snip>
repeat i from 0 to 7                               
    if ina[noparse][[/noparse]io] == 1
      datar |= |< i     ' set bit
    else
      datar &= !|< i    ' reset bit
<snip>
return(datar)

This works up to 9 (%00001001), but at 10 seconds the first bit of the 10's register is set and the first 4 bits are zeroed (%00010000). Your function then returns 16 instead of 10. This goes on and on wrapping around at 89. The problem occurs with every register except day.

I don't think there is an elegant fix, since the registers are not all defined the same. The read function probably has to have a case statement to handle reading the different registers properly. I'll see what I can come up with.

-Rick

rtowler

I'm still quite a beginner but here is my wordy attempt at a fix. I'm sure this could be reduced quite a bit. Two new global vars are declared (byte onez, tens). the read function is replaced by the following two:

PRI read( cmd )

  outa[noparse][[/noparse]ce]~~           
  writeByte( cmd )
  dira[noparse][[/noparse]io]~             'set to input

  case cmd
    $81,$83 : datar := readBits(3,2)
    $85     : datar := readBits(4,-1)
    $87     : datar := readBits(3,1)
    $89     : datar := readBits(3,0)
    $8B     : datar := readBits(2,-1)
    $8D     : datar := readBits(3,3)
    
  outa[noparse][[/noparse]ce]~            
  
  return(datar)
  
PRI readBits(a,b) | i

   onez := %00000000
   repeat i from 0 to a                     
    if ina[noparse][[/noparse]io] == 1
      onez |= |< i     ' set bit

    outa[noparse][[/noparse]clk]~~          
    delay_us(2)
    outa[noparse][[/noparse]clk]~           
    delay_us(2)
    
  tens := %00000000
  repeat i from 0 to b
    if ina[noparse][[/noparse]io] == 1
      tens |= |< i     ' set bit

    outa[noparse][[/noparse]clk]~~          
    delay_us(2)
    outa[noparse][[/noparse]clk]~           
    delay_us(2)

  repeat i from 1 to (6-a-b)
    outa[noparse][[/noparse]clk]~~          
    delay_us(2)
    outa[noparse][[/noparse]clk]~           
    delay_us(2)
  
   return((tens * 10) + onez)

Note that this currently ignores the am/pm bit thus really only works for 24 hour mode. Anyways, it's a start.

-Rick

inservi

Hi,

Thank-you Rick for the good analysis. In fact When i use the driver in c language, i convert the data before writing and after reading. That is what i miss out in this spin version. I'm afraid for this inconvenience.

I have added this conversion now.

I hope that you will now can use this object easily.

Here are the corrected version.

dro.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
in medio virtus

Post Edited (inservi) : 3/14/2007 2:52:34 PM GMT

rtowler

It's no problem. Without your work I would had to have started from scratch and it would have taken me a lot longer!

Thanks for posting the update. Your code (and everyone else's that is posted on the object exchange) is much appreciated.

-rick