Ds1302 and unmime64
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
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
Comments
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
dro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
in medio virtus
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
Does anyone have it?
Jim
·· coded by Beau Schwabe (Parallax)
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
Thanks
Jim
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.
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
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
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:
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
Note that this currently ignores the am/pm bit thus really only works for 24 hour mode. Anyways, it's a start.
-Rick
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
Thanks for posting the update. Your code (and everyone else's that is posted on the object exchange) is much appreciated.
-rick