Hi all

I'm using the prolific USB-2-serial converter, called PL2303.

Recently installing windows 7 64-bit I installed the latest (3.3.5.122) driver
and it seem to work ok with TeraTermPro. But it didn't work with BasicX.

I fixed the problem by downgrading the PL2303 driver from v. 3.3.5.122 to
3.2.0.0 and bingo, BasicX software are no longer reporting "run-time error
'8020'". I've tested this ok on Vista 64-bit as well.

I hope this advice will save somebody a few hours of work.

I'm uploading the vista installation packages in the files section, if allowed
by Yahoo.

Cheers, Stefan

Hello fellows
The problem was finnally solved as soon as I called Maxim's support line.
According to their Typical Operation Circuit, I had my supply connected
to Vcc2 pin...
Apparently, when you have a single supply, this should be connected to
Vcc1 and not to Vcc2 as they suggest on their scheme...
When I changed the wires, all started to work properly!
Thanks again for all your help!!


Best regards
David M.

Hi,

Suggestion
Do a print of the command data to see if your are sending  command a good
command.
Set the clock low before execute the CE high per DS1302 define instruction.
I know that you are setting it after the shiftin instruction but when you start
the program the setting maybe unknown.
  Add a small delay after the shiftout instruction.
See if it help with your problem.

rosarite





-----Original Message-----
From: David Sousa Mendes <davidsousamendes@...>
To: basicx@yahoogroups.com
Sent: Tue, Nov 10, 2009 3:38 pm
Subject: [BasicX] Keeping track of date and time






























I tried want you suggested: instead of MISO and MOSI pins, I'm only

using one pin connected to IO pin of DS1302...

But the result is the same: "ctrl_reg:  255"























[Non-text portions of this message have been removed]

Do you think I should configure the IO pin as bxInputTristate using Putpin?

I tried want you suggested: instead of MISO and MOSI pins, I'm only
using one pin connected to IO pin of DS1302...
But the result is the same: "ctrl_reg:  255"

> ... both pins are connected to IO pin of DS1302...

Then the output pin will hold the input pin low, won't it?  Try
disconnecting one of the pins and use the same pin for input and output.


Tom

You can't be far from success.  Here is a Cubloc implementation that is
close to Basic-X code:

http://www.cubloc.com/download/etc/app_ds1302.pdf


Tom

yes, both pins are connected to IO pin of DS1302

> public const MISO as byte=14
  > public const MOSI as byte=15

Are these two pins both connected to the DS1302 I/O pin?


Tom

Hello Tom,
I tried the code that you suggested but with no results...
At the moment I'm just trying to read a register where the first 7 bits
are forced to zero, but my code delivers the decimal value of 255...
Below, I'm sending you the code... May be you have an idea what might I
be doing wrong...
Again, thanks for your help...

Option Explicit


public const SCLK as byte=13
public const MISO as byte=14
public const MOSI as byte=15
public const CE as byte=16

Public Const SecReg As Byte  = bx0000_0000 'Seconds Register (#0)
Public Const MinReg As Byte  = bx0000_0010 'Minutes Register (#1)
Public Const HrsReg As Byte  = bx0000_0100 'Hours Register (#2)
Public Const DayReg As Byte  = bx0000_0110 'Day-Of-Month Register (#3)
Public Const DateReg As Byte = bx0000_1000 'Month Register (#4)
Public Const MonReg As Byte  = bx0000_1010 'Day of Week Register (#5)
Public Const YrReg As Byte   = bx0000_1100 'Year Register (#6)
Public Const CtrlReg As Byte = bx0000_1110 'Control Register (#7)
Public Const TchgReg As Byte = bx0001_0000 'Trickle Charge Register (#8)

Public Const ClockReg as Byte = bx1000_0000
Public Const RAMReg as Byte   = bx1100_0000
Public Const ReadReg as Byte  = bx1000_0001
Public Const WriteReg as Byte = bx1000_0000

Public Const nb_of_bits as  byte=8
Public command as byte
Public received_byte as byte


Public Sub Main()


call delay (1.0) ' para set the Xtal stable

'Reads the control
register________________________________________________________________________\
___________
do
     command=ClockReg OR CtrlReg OR ReadReg
     command = FlipBits (command) ' because DS1302 is LSB first
     call putpin(CE,bxOutputHigh)    ' CE must be asserted high during
communication
     Call ShiftOut(MOSI, SCLK, nb_of_bits, command)
     received_byte =Shiftin(MISO, SCLK, nb_of_bits)
     Call PutPin(SCLK, bxOutputLow)    ' sets the SCLK pin to low after
communication
     call putpin(CE,bxOutputLow)    ' CE must be asserted low after
communication
     received_byte=FlipBits(received_byte)
     debug.print "ctrl_reg: " ; CStr(received_byte)
     call delay (1.0)
loop



End Sub

Here is an exploit of the Basic-X register.RTCTick implementation which permits
using Timer(), usually limited to a 24-hour period, to measure beyond 46-day
periods.

Basic-X keeps the time as a 512Hz tick count in a system Long, register.RTCTick.
It normally resets the register.RTCTick count to zero when it detects a count
representing 24 hours since boot (or midnight if the Basic-X clock is set to
correct current time).

If the tick count is positively offset by a value that is larger than one day of
ticks, the 24-hour reset will not occur so the count will continue until the
32-bit value wraps. If the value is considered an UnsignedLong, the wrap
won't happen for more than 97 days of continuous operation since boot. Working
with ULngs, though, is limited since multiplies, divides and Mod functions
are not permitted with that data type. So, staying within the 31 magnitude bits
of a signed Long is easier and provides a ~48.5-day maximum count before the
sign bit changes. If a two-day offset is imposed, a measurable period of ~46.5
days is available.

The following functions illustrate a method to use this feature:


const OneDayInTicks as long = 44236800
const TwoDaysInTicks as long = 88473600
const OneDayInSeconds as long = 86400
const TwoDaysInSeconds as single = 172800.0

function GetDayRTCTicks() as long
' RTC count is offset to avoid midnight, which
' provides >~46-day period measurement with Timer()
' This function provides the one-day count, like the normal register.RTCTick
GetDayRTCTicks = register.RTCTick mod OneDayInTicks
end function

sub SetRTCTicks(byval lTicks as long)
' RTC count is offset to avoid midnight
register.RTCTick = lTicks + TwoDaysInTicks
end sub

function DayTimer() as single
DayTimer = csng(clng(Timer) mod OneDayInSeconds) ' one-day Timer() in whole
seconds
end function

function LongTimer() as single
LongTimer = Timer - TwoDaysInSeconds ' true seconds since boot
end function


The standard system function Timer() will yield seconds since boot plus (2 *
86400) seconds. Days can be counted when (GetDayRTCTicks) decreases in value.
Note that the system date will not automatically increment at midnight, so date
functions will not work properly.

The count must be set via SetRTCTicks(0) to impose the
register.RTCTick offset. Periods between two Timer() executions will be
correct, and as large as ~46 days, but some precision will be lost with long
durations due to the 6-7 digit 32-bit Single float magnitude restriction.  The
full-precision 512Hz tick count, however, will still be available in the 32-bit
Long.


Tom

Edited with minor changes.

> ... FlipBits...

Perfect.  I've never used it, but that's what you need if you use
ShiftIn/Out.


Tom